[Bitcoin-development] Framework for modular input selection policy for Bitcoin wallets

2014-02-10 Thread Justus Ranvier
One of the areas that isn't as well developed as it could be in terms of wallet design is fine-grained control over input selection policy. Coin control is great when a human is manually crafting transactions, but that's not really a very scalable solution. The attached image is a possible way

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-28 Thread Justus Ranvier
On 02/28/2014 07:25 PM, Mark Friedenbach wrote: Transaction fees are a DoS mitigating cost to the person making the transaction, but they are generally not paid to the people who actually incur costs in validating the blockchain. Actual transaction processing costs are an externality that is

[Bitcoin-development] BIP 70 and OP_RETURN

2014-03-28 Thread Justus Ranvier
The description of the Output message states that the payment request can specify any standard TxOut script, and that OP_RETURN is a standard transaction type that would imply the ability to specify OP_RETURN outputs in BIP 70 payment requests. If the creator of a payment request wanted the

Re: [Bitcoin-development] BIP 70 and OP_RETURN

2014-03-29 Thread Justus Ranvier
On 03/29/2014 01:30 PM, Mike Hearn wrote: They would just encode the OP_RETURN script into an Output structure. I'm not sure about the question - you seem to give the answer yourself in the first paragraph? I guess what I was asking is whether or not all BIP70 compatible clients will support

[Bitcoin-development] Best practices for dust remining

2014-03-29 Thread Justus Ranvier
Suppose am m-of-n multisig wallet receives a bunch of dust deposits due to somebody advertising the Olympics, or any other reason, and the users of the wallet don't want the few satoshis involved. What is the best way to allow all these dust outputs to be re-mined in order to clean up the utxo

Re: [Bitcoin-development] Dust recycling

2014-03-29 Thread Justus Ranvier
On 03/29/2014 07:55 PM, Goss, Brian C., M.D. wrote: Could you collect the dust into a transaction with no outputs (thus making it all tx fees) or putting in to an anyone can spend tx? The large number of signatures (for large n) would make the tx size large...but, if enough dust were out

Re: [Bitcoin-development] Dust recycling

2014-03-29 Thread Justus Ranvier
On 03/29/2014 08:05 PM, Gregory Maxwell wrote: Use dust-b-gone and make it someone elses problem to get it relayed. :) That's a sub-optimal solution, as it introduces a third party. What if his server goes down? An universal solution is preferable. -- Support online privacy by using email

Re: [Bitcoin-development] Okay, time to bring up bitcoin/bitcoin

2014-04-02 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/02/2014 03:41 PM, Laszlo Hanyecz wrote: www.githubb.com resolves to addresses announced by AS53665 Some basic info about AS53665 can be seen at http://bgp.he.net/AS53665 They probably have a dedi or VPS at Cogent. They didn't even create

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/2014 05:16 PM, Gregory Maxwell wrote: When I read resource requirements of a full node are moving beyond I didn't extract from that that there are implementation issues that need to be improved to make it work better for low resource

Re: [Bitcoin-development] Why are we bleeding nodes?

2014-04-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/07/2014 05:40 PM, Mike Hearn wrote: The primary resources it needs are disk space and bandwidth, after an intensive initial day or two of building the database. Check out the kind of hardware causal users are running these days. The

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 06:19 PM, Wladimir wrote: If no one wants to volunteer resources to support the network anymore, we'll have failed. If the security of the network depends on a broken incentive model, then fix the design of the network so that

Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/09/2014 06:50 PM, Gregory Maxwell wrote: Who says anything about a broken incentive model. You've made past claims about resource requirements that I think made no sense and then failed to defend them when they were challenge. Anyone

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 07:55 AM, Mike Hearn wrote: 2. Miners can vote to reallocate the coinbase value of bad blocks before they mature. If a majority of blocks leading up to maturity vote for reallocation, the value goes into a pot that subsequent blocks

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 03:07 PM, Mike Hearn wrote: On Wed, Apr 23, 2014 at 4:52 PM, Justus Ranvier justusranv...@gmail.comwrote: If enough miners don't like a block that has been mined, they can all work to orphan it without any change to the protocol

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 05:47 PM, Gavin Andresen wrote: And why do you think your blog is more public than this open, publicly archived mailing list??? Non-developers are more comfortable using social media tools. Blog posts can be shared, Tweeted, and

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/23/2014 06:37 PM, Mike Hearn wrote: If you want to try and argue that the development list is the wrong place to discuss development, please do so on another thread (or your blog). Let's keep this thread for discussion of the original

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/24/2014 03:37 PM, Jorge Timón wrote: The 21 million bitcoin limit is not important because of its exact value, nor is it important because Satoshi picked it. The 21 million limit is important because users hold bitcoin based on the promise

Re: [Bitcoin-development] Coinbase reallocation to discourage Finney attacks

2014-04-29 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/29/2014 02:13 PM, Mike Hearn wrote: I do think we need to move beyond this idea of Bitcoin being some kind of elegant embodiment of natural mathematical law. It just ain't so. I think everybody understands that Bitcoin has a positive net

Re: [Bitcoin-development] About the small number of bitcoin nodes

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 09:11 AM, Jeff Garzik wrote: Meh. I like example configs, perhaps tuned by the distro. If the distro (_not_ Bitcoin Core upstream) chooses to install a bitcoin.conf in the proper location, that's up to them. - bitcoind and

Re: [Bitcoin-development] Paper Currency

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 02:21 PM, Mike Hearn wrote: Submitted with humility and some fear of getting laughed out of here... Off topic aside, a bunch of us have lately started to think about the atmosphere on this list and how to improve it. Nobody

Re: [Bitcoin-development] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 09:41 PM, Gavin Andresen wrote: Now I'm really confused. Why would Mike or I have the authority to write a social contract to promise anything about future-Bitcoin? YOU can make promises about YOUR future behavior. So can everyone

Re: [Bitcoin-development] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 10:06 PM, Mike Hearn wrote: Sorry. I will never agree to the concept of a relevant idea so dangerous it cannot be discussed. That's medieval thinking. If you would like to create a parallel development forum where people have to

Re: [Bitcoin-development] Working on social contracts (was: Paper Currency)

2014-05-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/19/2014 11:07 PM, Gregory Maxwell wrote: I promise that if bad people show up with a sufficient pointy gun that I'll do whatever they tell me to do. I'll make bad proposals, submit backdoors, and argue with querulous folks on mailing lists,

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2014 04:25 PM, Matt Whitlock wrote: How can there be any kind of lottery that doesn't involve proof of work or proof of stake? Without some resource-limiting factor, there is no way to limit the number of lottery tickets any given

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
There can be multiple independent transport networks for Bitcoin. There already is: ipv4, ipv6, Tor, and native_i2p (out of tree patch). As long as multihomed hosts that act as bridges then information will propagate across all of them. -- Justus Ranvier - sent with R2Mail2

Re: [Bitcoin-development] Incentivizing the running of full nodes

2014-06-16 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/16/2014 07:00 PM, Justus Ranvier wrote: There can be multiple independent transport networks for Bitcoin. There already is: ipv4, ipv6, Tor, and native_i2p (out of tree patch). As long as multihomed hosts that act as bridges

Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

2014-06-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/19/2014 05:11 PM, Kevin wrote: Why do you want to punish pools? It's part of a general trend wherein people look at all the things that can be accomplished in an economy that has a division of labor*, and see some misbehavior at the edges, and

Re: [Bitcoin-development] Plans to separate wallet from core

2014-06-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 06/24/2014 09:07 AM, Wladimir wrote: My main argument for the split is that full nodes and wallets have completely different usage scenarios: - A wallet should be online as little as possible, ideally only when you do transactions or want to

Re: [Bitcoin-development] [ANN] Armory 0.92 with Decentralized Multi-sig and Simulfunding

2014-07-31 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/30/2014 09:50 PM, Alan Reiner wrote: (though, in the future, we hope to provide an optional service to help synchronize the data between parties) Before rolling your own service, it might be a good idea to add Bitmessage integration to

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/19/2014 03:30 PM, Richard Moore wrote: Oh, I see. I misread, thinking you wanted the dev team to have a private key and share the public key, similar to alerts. But each peer would have a public/private key pair and use something akin to

[Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

2014-08-19 Thread Justus Ranvier
generated on the fly. Two draft information BIPs are attached. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-19 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/19/2014 11:38 PM, J Ross Nicoll wrote: That's not great, certainly, but how many nodes actually require that level of security All of them. While the rest of the 'net is busy deprecating HTTP and all other unencrypted transport methods,

Re: [Bitcoin-development] Proposal: Encrypt bitcoin messages

2014-08-23 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 08/23/2014 04:17 PM, xor wrote: On Tuesday, August 19, 2014 07:40:39 PM Jeff Garzik wrote: Encryption is of little value if you may deduce the same information by observing packet sizes and timings. Instead of spawning a discussion whether

Re: [Bitcoin-development] Does anyone have anything at all signed by Satoshi's PGP key?

2014-09-15 Thread Justus Ranvier
On 09/15/2014 03:08 PM, Jeff Garzik wrote: Such guidelines are a perfect example of why PGP WoT is useless and stupid geek wanking. A person's behavioural signature is what is relevant. We know how Satoshi coded and wrote. It was the online Satoshi with which we interacted. The online

Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets

2014-09-23 Thread Justus Ranvier
if you'd at least mention our work, since we did share it with you back in January and have been publicly documenting it ever since. Or does the fact that we're implementing it in btcwallet mean what we're working on is unmentionable here? - -- Justus Ranvier | Monetas http

Re: [Bitcoin-development] Proposal: No-Collision mode for Multisig BIP32 Wallets

2014-09-23 Thread Justus Ranvier
on anyone's part (except for not using the same BIP43 purpose code). We resolved this by changing the naming scheme for our proposals, and their associated purpose codes, to not rely on centrally-allocated numbers. https://github.com/Open-Transactions/rfc/tree/master/bips - -- Justus Ranvier

Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

2014-09-25 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 09/26/2014 01:53 AM, Gregory Maxwell wrote: On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier jus...@monetas.net wrote: Two draft information BIPs are attached. I've pinged some people privately but also pinging the list… no commentary

Re: [Bitcoin-development] Something people are forgetting about the Gentoo / Luke-jr censorship issue

2014-10-10 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 10/10/2014 05:26 PM, Mike Hearn wrote: I'm sure this suggestion will go down like a lead balloon, but Bitcoin Core is not the first project that's had issues with Linux distros silently modifying their software as they package it. In this

Re: [Bitcoin-development] Two Proposed BIPs - Bluetooth Communication and bitcoin: URI Scheme Improvements

2014-10-22 Thread Justus Ranvier
that encourage people to reserve BIP numbers to avoid namespace collisions even if their work does not affect any other project. There should be an efficient process for informational BIPs of this type. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net

Re: [Bitcoin-development] The difficulty of writing consensus critical code: the SIGHASH_SINGLE bug

2014-11-06 Thread Justus Ranvier
On 11/06/2014 04:11 PM, Jeff Garzik wrote: RE soft fork vs. hard fork: It's about this time at Mike Hearn will chime in, on the side of hard forks. Hard forks are in a sense much cleaner, and permit solving problems not otherwise solvable with a hard fork. However, hard forks clearly have

Re: [Bitcoin-development] Setting the record straight on Proof-of-Publication

2014-12-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 12/12/2014 01:41 PM, odinn wrote: I think the Mastercoin devs are doing fine work I wonder if all the Mastercoin devs would agree with that statement. - -- Support online privacy by using email encryption whenever possible. Learn how here:

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-29 Thread Justus Ranvier
in the case the first miner's block is orphaned. Inputs to a generation transaction can not be similarly poached. That difference makes some services possible that would can not be safely achieved with pay-to-fee transactions. - -- Justus Ranvier | Monetas http://monetas.net

Re: [Bitcoin-development] BIP: Voluntary deposit bonds

2014-12-30 Thread Justus Ranvier
. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQEcBAEBCAAGBQJUoqXIAAoJEMP3uyY4RQ21OZUH

Re: [Bitcoin-development] determining change addresses using the least significant digits

2015-02-05 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/04/2015 02:23 PM, Isidor Zeuner wrote: Hi there, traditionally, the Bitcoin client strives to hide which output addresses are change addresses going back to the payer. However, especially with today's dynamically calculated miner fees,

Re: [Bitcoin-development] determining change addresses using the least significant digits

2015-02-06 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/06/2015 03:08 PM, Jeff Garzik wrote: Yes. You can certainly add additional inputs and outputs -- and as such you can increase privacy and defrag your wallet at the same time. A lot could be done to make regular spends resemble CoinJoin

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Justus Ranvier
their wallet software from companies/organizations not located in the same country as them. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc

Re: [Bitcoin-development] The legal risks of auto-updating wallet software; custodial relationships

2015-01-20 Thread Justus Ranvier
be lower. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- iQIcBAEBAgAGBQJUvq0CAAoJECpf2nDq2eYjr9kP/RWEg8Az43T

Re: [Bitcoin-development] IMPULSE: Instant Payments using the Bitcoin protocol

2015-01-22 Thread Justus Ranvier
On 01/17/2015 08:45 PM, Rune Kjær Svendsen wrote: Hi list Found this on reddit: http://impulse.is/ PDF: http://impulse.is/impulse.pdf I'd love to hear this list's thoughts. /runeks I'm concerned about the silence that always erupts whenever privacy-hostile products are proposed. --

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:15 PM, Alan Reiner wrote: I'll add fuel to the fire here, and express that I believe that replace-by-fee is good in the long-term. Peter is not breaking the zero-conf, it was already broken, and not admitting it creates a

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 05:24 PM, Oleg Andreev wrote: I think that is a misdirection on your part. The point of replace-by-fee is to make 0-confirms reliably unreliable. Currently people can get away with 0-confirms but it's only because most people

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:47 PM, Allen Piscitello wrote: Nothing will stop that. Bitcoin needs to deal with those issues, not stick our heads in the sand and pretend they don't exist out of benevolence. This isn't a pet solution, but the rules of the

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:45 PM, Peter Todd wrote: None of those solutions are compatible with decentralized networks for a lot of reasons. Given the inability to prevent sybil attacks your suggestions lead to people being unfairly punished for poor

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

2015-02-12 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 03:20 PM, Natanael wrote: Multisignature notaries need to convince people to select them. They want to know that even with collateral, their funds won't be temporarily locked up and unspendable for days at a time. What services

[Bitcoin-development] Fwd: re Improving resistance to transaction origination harvesting

2015-03-20 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 - Forwarded Message Subject: re [Bitcoin-development] Improving resistance to transaction origination harvesting Date: Fri, 20 Mar 2015 14:06:59 +0100 From: Arne Bab. arne_...@web.de To: justus.ranv...@monetas.net Hi Justus, I read

Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups

2015-03-13 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2015 04:48 PM, Mike Hearn wrote: That would be rather new and tricky legal territory. But even putting the legal issues to one side, there are definitional issues. For instance if the Chainalysis nodes started following the protocol

[Bitcoin-development] Criminal complaints against network disruption as a service startups

2015-03-13 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Given the recent news about Chainanalysis (https://www.reddit.com/r/Bitcoin/comments/2yvy6b/a_regulatory_compliance_service_is_sybil/), and other companies who are disrupting the Bitcoin network

Re: [Bitcoin-development] Criminal complaints against network disruption as a service startups

2015-03-13 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 03/13/2015 05:08 PM, Mike Hearn wrote: That definition would include all SPV clients? Don't SPV clients announce their intentions by the act of uploading a filter? I get what you are trying to do. It just seems extremely tricky. Certainly

Re: [Bitcoin-development] alternate proposal opt-in miner takes double-spend (Re: replace-by-fee v0.10.0rc4)

2015-02-22 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 02/22/2015 10:17 AM, Natanael wrote: The problem with this approach is that it is worthless as a predictor. We aren't dealing with traffic safety and road design - we are dealing with adaptive attackers and malicious miners and pools.

Re: [Bitcoin-development] Fwd: Reusable payment codes

2015-04-26 Thread Justus Ranvier
Payment codes establish the identity of the payer and allow for simpler methods for identifying the payee, and automatically provide the payee with the information they need to send a refund. If merchants and customers were using payment codes, they would not need the BIP70 equivalents. I think

[Bitcoin-development] Fwd: Reusable payment codes

2015-04-24 Thread Justus Ranvier
On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So this requires making dust payments to a constantly reused address in order to (ab)use the blockchain as a messaging layer. Indeed, this is more SPV compatible; but it seems likely to me that _in practice_ it would

[Bitcoin-development] Fwd: Reusable payment codes

2015-04-24 Thread Justus Ranvier
/justusranvier/rfc/commit/8c4d3429012eb15847c4ae68f212c8b2dcd1b521 On Sat, Apr 25, 2015 at 12:21 AM, Justus Ranvier justus.ranv...@monetas.net wrote: On Fri, Apr 24, 2015 at 10:58 PM, Gregory Maxwell gmaxw...@gmail.com wrote: So this requires making dust payments to a constantly reused

Re: [Bitcoin-development] Fwd: Reusable payment codes

2015-04-24 Thread Justus Ranvier
On Sat, Apr 25, 2015 at 3:30 AM, Gregory Maxwell gmaxw...@gmail.com wrote: On Sat, Apr 25, 2015 at 12:22 AM, Justus Ranvier justus.ranv...@monetas.net wrote: Taking the hash of the secret would then require an extra step to make sure the hash is valid for secp256k1. The x value may

[Bitcoin-development] Reusable payment codes

2015-04-24 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 https://github.com/justusranvier/rfc/blob/payment_code/bips/bip-pc01.mediawiki This link contains an RFC for a new type of Bitcoin address called a payment code Payment codes are SPV-friendly alternatives to DarkWallet-style stealth addresses

Re: [Bitcoin-development] Reusable payment codes

2015-04-28 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 The notification transactions are a pain point when it comes to privacy, and yet they must exist in order to to ensure that nobody can lose their money as long as they back up their wallet seed. They could be treated as a backup, however, that

Re: [Bitcoin-development] Reusable payment codes

2015-04-27 Thread Justus Ranvier
-level censorship more difficult. - -- Justus Ranvier | Monetas http://monetas.net/ mailto:jus...@monetas.net | Public key ID : C3F7BB2638450DB5 | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc -BEGIN PGP SIGNATURE- Version: GnuPG v2

Re: [Bitcoin-development] Reusable payment codes

2015-04-29 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/27/2015 02:53 PM, Brian Deery wrote: 1. There will be a 1:1 relationship between a payment code owner and their identity. Presumably the payment code would be strongly and publicly tied to the identity. This makes the notification address

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 09:54 PM, Jeff Garzik wrote: By the time we get to fee pressure, in your scenario, our network node count is tiny and highly centralized. Again, this assertion requires proof. Simply saying things is not the same as them being true.

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 05:04 PM, Jeff Garzik wrote: heh - I tend to think people here want bitcoin to succeed. My statement refers to picking winners and losers from within the existing bitcoin community stakeholders. Success is not a sufficiently

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 05:47 PM, Jeff Garzik wrote: Bitcoin needs to be the best it can be (Layer 1), but all solutions cannot and should not be implemented at Layer 1. I can provisionally agree with that statement as long as all solutions cannot and should

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:35 PM, Jeff Garzik wrote: Raising the block size limit then becomes a *human decision* to favor some users over others, a *human decision* to prevent an active and competitive free fee market developing at 1MB, a *human decision*

Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:49 AM, Peter Todd wrote: I'm not sure if you've seen this, but a good paper on this topic was published recently: The Economics of Bitcoin Transaction Fees ..for some very strange definitions of good. That paper may present valid

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 04:04 PM, Jeff Garzik wrote: - This is a major change to the economics of a $3.2B system. This change picks winners and losers. There is attendant moral hazard. This is exactly true. There are a number of projects which aren't

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 04:49 PM, Peter Todd wrote: I think we'll find an basic assumption of civility to be more productive, until proven otherwise. (e.g. NSA ties) I'm not sure why you'd construe my post as having anything to do with accusations like

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/07/2015 03:27 PM, Jeff Garzik wrote: On Thu, May 7, 2015 at 11:16 AM, Justus Ranvier justusranv...@riseup.net wrote: To be extremely specific: should Bitcoin development intenionally limit the network's capabilities to leave room

Re: [Bitcoin-development] Block Size Increase

2015-05-09 Thread Justus Ranvier
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 05/09/2015 02:02 PM, Andrew wrote: The nice thing about 1 MB is that you can store ALL bitcoin transactions relevant to your lifetime (~100 years) on one 5 TB hard drive (1*6*24*365*100=5256000). Any regular person can run a full node and store

[Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report

2015-05-18 Thread Justus Ranvier
://github.com/OpenBitcoinPrivacyProject/wallet-ratings/blob/master/2015-1/threat%20model.wiki Please send any suggestions or corrections via a GitHub issue to the wallet-ratings repository so that we can incorporate it into future reports. - -- Justus Ranvier Open Bitcoin Privacy Project http

Re: [Bitcoin-development] Open Bitcoin Privacy Project Spring 2015 Report

2015-05-18 Thread Justus Ranvier
reviewed. Is there some process to get reviewed I missed? Please add us to the report. - -- Justus Ranvier Open Bitcoin Privacy Project http://www.openbitcoinprivacyproject.org/ jus...@openbitcoinprivacyproject.org E7AD 8215 8497 3673 6D9E 61C4 2A5F DA70 EAD9 E623 -BEGIN PGP SIGNATURE