Re: [Bitcoin-development] Bitcoin-development Digest, Vol 45, Issue 37
UNSUBSCRIBE On Wed, Feb 11, 2015 at 2:25 AM, bitcoin-development-requ...@lists.sourceforge.net wrote: Send Bitcoin-development mailing list submissions to bitcoin-development@lists.sourceforge.net To subscribe or unsubscribe via the World Wide Web, visit https://lists.sourceforge.net/lists/listinfo/bitcoin-development or, via email, send a message with subject or body 'help' to bitcoin-development-requ...@lists.sourceforge.net You can reach the person managing the list at bitcoin-development-ow...@lists.sourceforge.net When replying, please edit your Subject line so it is more specific than Re: Contents of Bitcoin-development digest... Today's Topics: 1. Re: Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI (Eric Voskuil) 2. Proposal: Requiring a miner's signature inthe block header (Hector Chu) 3. Re: Proposal: Requiring a miner's signature in the block header (Natanael) -- Message: 1 Date: Tue, 10 Feb 2015 09:56:39 -0800 From: Eric Voskuil e...@voskuil.org Subject: Re: [Bitcoin-development] Proposal for P2P Wireless (Bluetooth LE) transfer of Payment URI To: M?rtin H?bo??tiak martin.habovst...@gmail.com Cc: Bitcoin Dev bitcoin-development@lists.sourceforge.net,Paul Puey p...@airbitz.co Message-ID: 54da4657.5080...@voskuil.org Content-Type: text/plain; charset=utf-8 On 02/10/2015 09:16 AM, M?rtin H?bo??tiak wrote: I'm not sure if I was clear enough. Handshake should be used to establish authenticated AND encrypted communication using ECDH (or just DH, but I think it's easier to use ECDH, since required functions are already used in Bitcoin protocol), like RedPhone does. BTW knowledge of verification string is useless to the attacker. Yes, I think this was clear from your description. Yes, the customer must verify it verbally and the merchant shouldn't send the transaction before verification. Other possibility is that in case of differing verification strings new address is generated, so attacker doesn't know the address. But in this case, amount is leaked and there is quite high probability it can be found in the Blockchain. Yes, for each handshake the payment request would need to contain a different address, mitigating some of the privacy loss. Anyway, I don't believe the transaction can be made securely without such interaction except with white-listing public keys, so I see no reason why interaction should be problematic. It can be done securely and privately by transfer of a shared secret through a private channel. We don't have such strict regulations but I agree that security is important. Currently I think that verbal verification and manual confirmation is the best way to achieve high security and reasonable user-friendliness. I think for a broadcast model (e.g. Bluetooth only) that is the only want to ensure integrity and privacy. A narrow cast can use proximity to establish trust. 2015-02-10 17:55 GMT+01:00 Eric Voskuil e...@voskuil.org: Martin, I like your idea for the commit protocol in that it resolves the vandalous address substitution attack. However, I don't see a way to prevent privacy loss without adverse impact to the scenario. Anyone could perform the handshake and thereby obtain the payment request. Therefore to prevent inadvertent disclosure the customer must visually confirm the phrase and then verbally tell the merchant to proceed by sending the payment request. One might argue that it's sufficient to preserve the integrity of the transaction while suffering the privacy loss, especially given that a hijacked handshake should never result in a completed transaction - unless of course the hijacker pays. But imagine someone purchasing their meds. HIPAA requires the checkout queue to form behind a yellow line. That speaks directly to this question. e On 02/06/2015 01:07 AM, M?rtin H?bo??tiak wrote: 2015-02-06 2:29 GMT+01:00 Eric Voskuil e...@voskuil.org: On 02/05/2015 04:36 PM, Martin Habov?tiak wrote: I believe, we are still talking about transactions of physical people in physical world. So yes, it's proximity based - people tell the words by mouth. :) Notice from my original comment: A MITM can substitute the key. If you don't have verifiable identity associated with the public key (PKI/WoT), you need a shared secret (such as a secret phrase). I said this could only be accomplished using a shared secret or a trusted public key. Exchanging a value that is derived from a pair of public keys is a distinction without a difference. The problem remains that the parties must have a secure/out-of-band channel for communicating this value. The fact that they are face-to-face establishes this channel, but that brings us back to the original
[Bitcoin-development] replace-by-fee v0.10.0rc4
My replace-by-fee patch is now available for the v0.10.0rc4 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.0rc4 Along with demo scripts of the functionality: https://github.com/petertodd/replace-by-fee-tools New to this version is a comprehensive set of unittests under qa/replace-by-fee Additionally the preferential peering support now preferentially peers with Bitcoin XT¹ nodes that support Andresen/Harding's double-spend relaying² patch. While Bitcoin XT nodes don't accept double-spends into their mempool, they do relay them perfectly well and thus are an asset to those doing replace-by-fee mining.³ I've had a number of requests from miners for a version of replace-by-fee against Luke-Jr's Eligius patches⁴; I'll be also releasing that shortly once this release has undergone some more testing. What's replace-by-fee? -- Currently most Bitcoin nodes accept the first transaction they see spending an output to the mempool; all later transactions are rejected. Replace-by-fee changes this behavior to accept the transaction paying the highest fee, both absolutely, and in terms of fee-per-KB. Replaced children are also considered - a chain of transactions is only replaced if the replacement has a higher fee than the sum of all replaced transactions. Doing this aligns standard node behavior with miner incentives: earn the most amount of money per block. It also makes for a more efficient transaction fee marketplace, as transactions that are stuck due to bad fee estimates can be unstuck by double-spending them with higher paying versions of themselves. With scorched-earth techniques⁵ it gives a path to making zeroconf transactions economically secure by relying on economic incentives, rather than honesty and alturism, in the same way Bitcoin mining itself relies on incentives rather than honesty and alturism. Finally for miners adopting replace-by-fee avoids the development of an ecosystem that relies heavily on large miners punishing smaller ones for misbehavior, as seen in Harding's proposal⁶ that miners collectively 51% attack miners who include doublespends in their blocks - an unavoidable consequence of imperfect p2p networking in a decentralized system - or even Hearn's proposal⁷ that a majority of miners be able to vote to confiscate the earnings of the minority and redistribute them at will. Installation Once you've compiled the replace-by-fee-v0.10.0rc4 branch just run your node normally. With -debug logging enabled, you'll see messages like the following in your ~/.bitcoin/debug.log indicating your node is replacing transactions with higher-fee paying double-spends: 2015-02-12 05:45:20 replacing tx ca07cc2a5eaf55ab13be7ed7d7526cb9d303086f116127608e455122263f93ea with c23973c08d71cdadf3a47bae45566053d364e77d21747ae7a1b66bf1dffe80ea for 0.00798 BTC additional fees, -1033 delta bytes Additionally you can tell if you are connected to other replace-by-fee nodes, or Bitcoin XT nodes, by examining the service bits advertised by your peers: $ bitcoin-cli getpeerinfo | grep services | egrep '((0003)|(0401))' services : 0003, services : 0401, services : 0401, services : 0003, services : 0401, services : 0401, services : 0003, services : 0003, Replace-by-fee nodes advertise service bit 26 from the experimental use range; Bitcoin XT nodes advertise service bit 1 for their getutxos support. The code sets aside a certain number of outgoing and incoming slots just for double-spend relaying nodes, so as long as everything is working you're node should be connected to like-minded nodes a within 30 minutes or so of starting up. If you *don't* want to advertise the fact that you are running a replace-by-fee node, just checkout a slightly earlier commit in git; the actual mempool changes are separate from the preferential peering commits. You can then connect directly to a replace-by-fee node using the -addnode command line flag. 1) https://github.com/bitcoinxt/bitcoinxt 2) https://github.com/bitcoin/bitcoin/pull/3883 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP 5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html -- 'peter'[:-1]@petertodd.org 13c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Peter, An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Tamas Blummer Bits of Proof signature.asc Description: Message signed with OpenPGP using GPGMail -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Proposal: Requiring a miner's signature in the block header
A proposal for stemming the tide of mining centralisation -- Requiring a miner's signature in the block header (the whole of which is hashed), and paying out coinbase to the miner's public key. Please comment on whether this idea is feasible, has been thought of before, etc., etc. Thank you. Motivation -- Mining is centralising to a handful of pool operators. This is bad for a number of political reasons, which we won't go into right now. But I have always believed that some years down the line, they could hold the users hostage and change the rules to suit themselves. For instance by eliminating the halving of the block reward. Solution Currently the block header is formed by the pool operator and distributed for hashing by the pooled miners. It is possible to divide the work among the miners as the only thing that is used to search the hash space is by changing a nonce or two. I propose that we require each miner to sign the block header prior to hashing. The signature will be included in the data that is hashed. Further, the coinbase for the block must only pay out to the public key counterpart of the private key used to sign the block header. A valid block will therefore have a signature in the block header that is verified by the public key being paid by the coinbase transaction. Ramifications - Work can no longer be divided among the pooled miners as before, without sharing the pool's private key amongst all of them. If the pool does try to take this route, then any of the miners may redeem the coinbase when it matures. Therefore, all miners will use their own key pair. This will make it difficult to form a cooperating pool of miners who may not trust each other, as the block rewards will be controlled by disparate parties and not by the pool operator. Only a tight clique of trusted miners would be able to form their own private pool in such an environment. Attacks --- Pooled hashpower, instead of earning bitcoins legitimately may try to break the system instead. They may try a double-spending attack, but in order to leverage the pool to its full potential the pool operator would again have to share their private key with the whole pool. Due to the increased cooperation and coordination required for an attack, the probability of a 51% attack is much reduced. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header
Den 11 feb 2015 09:55 skrev Hector Chu hector...@gmail.com: A proposal for stemming the tide of mining centralisation -- Requiring a miner's signature in the block header (the whole of which is hashed), and paying out coinbase to the miner's public key. Please comment on whether this idea is feasible, has been thought of before, etc., etc. Thank you. Motivation -- Mining is centralising to a handful of pool operators. This is bad for a number of political reasons, which we won't go into right now. But I have always believed that some years down the line, they could hold the users hostage and change the rules to suit themselves. For instance by eliminating the halving of the block reward. [...] I propose that we require each miner to sign the block header prior to hashing. The signature will be included in the data that is hashed. Further, the coinbase for the block must only pay out to the public key counterpart of the private key used to sign the block header. [...] This will make it difficult to form a cooperating pool of miners who may not trust each other, as the block rewards will be controlled by disparate parties and not by the pool operator. Only a tight clique of trusted miners would be able to form their own private pool in such an environment. People already trust things like cloud mining, so your solution with increasing technical trust requirements won't help. But you will however break P2Pool instead. Also, note that threshold signatures (group signatures) could probably be used by an actual distrusting pool's miners. There are already a proof of concept for this implemented with secp256k1 that works with Bitcoin clients silently. This wouldn't prevent such a pool from working. -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header
If you're interested in working on mining decentralisation, chipping away at getblocktemplate support would be a better path forward. It's possible to have decentralised pooled mining - I know it sounds like a contradiction but it's not. I wrote about some of the things that can be done in this blog post: https://blog.bitcoinfoundation.org/mining-decentralisation-the-low-hanging-fruit/ -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 08:23:29AM +0100, Tamas Blummer wrote: Peter, An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Absolutely nothing in the replace-by-fee patch is consensus critical; your objection is entirely an artifact of the poor modularity of the Bitcoin Core codebase, something that is being actively improved on as we speak. Anyway, the logic of dealing with double-spends and keeping mempools synced is pretty trivial: for i in range(len(tx.vout)): for double_spent_tx in mempool.mapNextTx[COutPoint(tx.GetHash(), i)]: mempool.remove(double_spent_tx, recursive=True) mempool.add(tx) IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. All the complexity of replace-by-fee is in deciding when one transaction should replace another(s). Other than that the code is simple and very similar to block handling logic. -- 'peter'[:-1]@petertodd.org 0948f5c1f1a8c8073cc7d5161b98474e33904f8a1d6b0330 signature.asc Description: Digital signature -- Dive into the World of Parallel Programming. The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
