Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 08:15:01PM +0100, Alan Reiner wrote: The Bitcoin network achieves something that we didnt' think was possible 10 years ago: a totally trustless, decentralized ledger. The cost? It takes time for the decentralized network to reach consensus that transactions happened. That is quite literally the trade-off that we make: you can centralize things by putting a bank in the middle and getting instant confirmation, or you decentralize and let the network reach consensus over time without the central authority. If you want instant confirmations, you're going to need to add centralization because Bitcoin never offered it. I support efforts to dispel any such myths as soon as possible and encourage building robust solutions (payment channels, insured zero-conf services, etc.). Speaking of, a relatively simple thing that would help dispel these notions would be if some wallets supported replace-by-fee-using fee-bumping and an attempt undo button. Armory is an (unfortunately!) special case because it uses a full node and has good privacy guarantees, but most wallets could implement this by just sending the doublespend transactions to any node advertising either the replace-by-fee or GETUTXO's service bits. 1) https://www.schneier.com/blog/archives/2009/09/the_doghouse_cr.html -- 'peter'[:-1]@petertodd.org 0a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 07:49:29PM +, Gregory Maxwell wrote: One challenge is that without rather smart child-pays-for-parent logic the positive argument for replace by fee doesn't really work. That's actually incorrect now, as a mechanism for implementing scorched-earth without child-pays-for-parent using SIGHASH_ANYONECANPAY is available: http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html I greatly prefer this mechanism as it's an opt-in mechanism - many wallets double-spend on occasion by accident - and can have the incentives be adjusted to suit the % of hashing power that actual supports replace-by-fee. (and the % probability you'll see the doublespend) My patch implements 90% of the logic required for the above to work, however I've intentionally limited the total depth of recursion when the replacement is being evaluated as an interm anti-DoS measure in the spirit of belt-and-suspenders engineering. This can certainly be improved on, e.g. by limiting total mempool size. -- 'peter'[:-1]@petertodd.org 0a16bcc766361414571a5f961698acc46c27bd79c26ac15c 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-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 false sense of security. I don't want to see systems that are built on the assumption that zero-conf tx are safe solely because it has always appeared safe. You can argue about rational miner behaviors all day, but in a decentralized system you have no idea what miners consider rational, or speculate about their incentives. As noted elsewhere in the thread, there are two problems with this analysis: 1. It asserts that zero-confirmation transactions are in a binary state of safe/broken instead of recognizing that relying on them is a non-binary risk analysis on the part of a merchant. 2. Assumptions about what is profitable for miners are based on all miners having short time horizons for calculating profits. In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more honest node operators from patching their nodes to blacklist any peer that relays replace-by-fee transactions, and maybe even publish an IP address list of those peers? Punishing Bitcoin users for not adopting somebody's pet solution to a problem neither responsible nor ethical. Child-pays-for-parent allows for stuck transactions to be cleared from the mempool, and allows recipients of zero-conf transactions to adjust their risk exposure as much or as little as they like. It's a solution that gives Bitcoin users more freedom, instead of trying to coerce them into pre-determined directions. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99 kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/ F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5 sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0 F9dKdL5zCGofvU/U5BVq =kEMr -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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 07:34:22PM +, Justus Ranvier wrote: In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more honest node operators from patching their nodes to blacklist any peer that relays replace-by-fee transactions, and maybe even publish an IP address list of those peers? 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 connectivity that may be entirely out of their control. They also make maintaining a Bitcoin node and mining the blockchain require a significant amount of hands on maintenance, again incompatible with a decentralized system. -- 'peter'[:-1]@petertodd.org 0a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-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 arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. Here's value-free assessment of the issue here: 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer instant payments solution if possible. 3. As a social artifact, today zeroconf txs happen to work for some people in some situations. 4. Replace-by-fee will break #3 and probably hasten development of #2. The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner. I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons). TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined. You've left out of the discussion that many (or all) proposed solutions for 2 either reduce privacy, or security, or both. That fact should not be ignored or swept under the rug. There's also no mention of the degree to which child-pays-for-parent achieves the stated aims of the original proposal (clearing mempool of stuck transactions, increasing payee assurance of conformation) without introducing incentives to double spend or forcing people into privacy/security sacrifices. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5 6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4 bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF 2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45 RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232 FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM 7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8 XjbkwrkFIuKfUJyfIuR+ =ony0 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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 8:52 PM, Justus Ranvier justusranv...@riseup.net wrote: -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 protocol and what is realistically possible given the nature of distributed consensus. Relying on altruism is a recipe for failure. If there's a risk of fire burning down wooden buildings, pass out fire extinguishers and smoke detectors, not matches. The latter makes one an arsonist. Controlled fires is a valid tactic when necessary to reduce harm. It is frequently used in areas with periods of extreme heat including Australia. By burning off grids, you isolate the majority of flammable matter into islands. An accident fire would cause much more damage. Placing yourself in the way of the fire and asking them to find another solution isn't that bright. It is only a matter of time until a fire starts, controlled or not! If you want another solution, go figure one out yourself! More to the point, it is unreasonable to knowingly expose yourself to risk of harm and blame everybody else who isn't making your life easier without you having to change anything. If the majority decides that the best option to reduce harm for everybody requires that you move out of the way and find another way to do things, you're better off moving. Telling people it is fine to keep being careless when there's a fire hazard is the real crime, because that would cause more harm than what those who try to get the system changed does. -- 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 2/11/2015 10:47 PM, Peter Todd wrote: ... replace-by-fee ... Replace-by-fee creates the power to repudiate an entire tree of payments, and hands this power individually to the owner of each input to the top transaction. Presumably this is why the original replacement code at least required that all of the same inputs be spent, even if the original outputs got jilted. Replace-by-fee strengthens the existing *incentive discontinuity* at 1-conf, and shouts it from the rooftops. There is diffraction around hard edges. Expect more Finney attacks, even paid ones, if replace-by-fee becomes common. Regardless of how reliable 0-conf can ever be (much more reliable than today imho), discontinuities are very undesirable. There is no money in mining other people's double-spends. Miners of all sizes would welcome a fair way to reduce them to improve the quality of the currency, whether or not that way is DSDW. You mischaracterize DSDW as being in any way trust- or vote-based. It is based on statistics, which is bitcoin-esque to the core. -- 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
-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 protocol and what is realistically possible given the nature of distributed consensus. Relying on altruism is a recipe for failure. If there's a risk of fire burning down wooden buildings, pass out fire extinguishers and smoke detectors, not matches. The latter makes one an arsonist. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QRrAAoJECpf2nDq2eYjLtwP/3t0uplMwjpt6MP0wrPwOfkJ tRRyAaSkEsZi3+XjU2GVThG7kAlP2oIGFnoHc1QldhlEeWEJgPZyn7qq+mPx+I5+ OKb0PhSwRpTe0lh+r1dGyVqN+sSfbasJ9RSXYPmw1OW9ud4WOsgOh+oBTQWfuhvc p32Fxxx5JKjc4AnCVajSzNlPlXrBy3pFfL5F1ek4Wu+H0haz39VE/EYAWlXjyWxT vhUzv+9bcy3r8pe3eYUAmsXYLZAKb/9hWJdht6SKd509BlV6LVSrUh8Y2SJ3PYKt z3l4WmiUXkkdk1blqtLDyfUTEZSnBK8X4esj8Sp53WfOXNkgBKe1vr4EhTXaEQMU KD1e5s12xspPYgJdW9TWacIYKp3Ft3yBODJOTNZL3j0ryzYA+KU5ZumdHIm10J3S J1IDQBraONESinHybGPKYtUCikTkl6TemW/CpfjRhQONov4708FIg+KQAo6ui56N otfDGEwqH1qKgbt5DugdEBtxDmYmcYdFjID2+ZLwK6ngat8UAw2dQoCnUtkZ7w+i Oxz4cm1vIRjv+BYipQjg4IRRZNvpEXSolz6u91qqj8SlXXdY7sZ3B5HwtGSOVX5y l3NxYVOazA/NA/zcCG9ZPjr/O5sKJ40IjcLbTHvE1POuiF167xF2+U2Sdf/43d9d cE68utrIaurfJsDA/L/+ =pTe/ -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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
You cannot close Pandora's box. Whether or not this type of patch should exist is irrelevant. It does, and there are incentives to use it by miners. These are the bounds we have to deal with and the world we must adapt to. On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier justusranv...@riseup.net wrote: -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 arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. Here's value-free assessment of the issue here: 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer instant payments solution if possible. 3. As a social artifact, today zeroconf txs happen to work for some people in some situations. 4. Replace-by-fee will break #3 and probably hasten development of #2. The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner. I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons). TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined. You've left out of the discussion that many (or all) proposed solutions for 2 either reduce privacy, or security, or both. That fact should not be ignored or swept under the rug. There's also no mention of the degree to which child-pays-for-parent achieves the stated aims of the original proposal (clearing mempool of stuck transactions, increasing payee assurance of conformation) without introducing incentives to double spend or forcing people into privacy/security sacrifices. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3OzkAAoJECpf2nDq2eYjDM8P/1a4bNa5s0ryMZHBxyhGcVk5 6hTSPpUF2/Y81JaC/EqzH8MMKqnPVcLxoikKoO5tIUxeo5bwC5OO8YyGk4NrpeCM HTmROR+4XFOULi1dsUs5LP5oBQ+sPu1uNOZKn2fPCgtkO0xj8/w3mCdlVlf7g+v4 bYt6rSmSCzyCY0qFQVYvyBoYeSVt6icdz45D54BvyNsEtlT+HvbNdG/SznT7QsLF 2rOZezp5zbIyhbhaV5KtCKwYzATFYr0nWFHVnBkYWcOY3mJdPg6zODUO5ocbGs45 RHEB8KMsKtrD+gnCwCoSb+J6TNlA8y//ilKemPb+gRSVVM1JJpHBwv7fc8jUu2Ap V9YNKOVOrmoGb5X2sCctAZ6474p8HCUgZh50OluQph01tGtq3uC1djJUvnVCP232 FQD47AU2LhU3wPjWSGEDIGtpeAk91+6huRCzv600xnIISd5KpryKpD6qWC3M4MGs G4omAZhHjW5/E8CO/CH21nbPA2P1wozrGE5N8UTc2kwias/4Vn+v3IedjnSiS+IF n37MzlyCVs9qXyT7WylT4UAnc9exxHwGXKrvcCUaIAw7FOFEHjiHYLjZFIrVWmpM 7qxjMD/yM3kDmd/+YxCbITAERsHh04k4PITLVbnOyXY+axi+Xuow9v5HvwqERvt8 XjbkwrkFIuKfUJyfIuR+ =ony0 -END PGP 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 -- 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.
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
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 false sense of security. I don't want to see systems that are built on the assumption that zero-conf tx are safe solely because it has always appeared safe. You can argue about rational miner behaviors all day, but in a decentralized system you have no idea what miners consider rational, or speculate about their incentives. If there's one thing I learned playing poker (many years ago), was that always assuming your opponent is rational can lose you a lot of money. You made play that, in hindsight, was terrible given what he actually had. But you assumed no sane or rational person in his position would make such a play so you discounted it in your decision-making process. You're right that his actions were terrible and irrational, but he still won your money because you discounted his ability to make such a bad play. Here, you are speculating that an opponent uses the same values/motivations/rationality as yourself, and then building systems that depend on that being true. Even if it should be true doesn't mean that it is true and will remain that way. And you will get burned by it eventually. The Bitcoin network achieves something that we didnt' think was possible 10 years ago: a totally trustless, decentralized ledger. The cost? It takes time for the decentralized network to reach consensus that transactions happened. That is quite literally the trade-off that we make: you can centralize things by putting a bank in the middle and getting instant confirmation, or you decentralize and let the network reach consensus over time without the central authority. If you want instant confirmations, you're going to need to add centralization because Bitcoin never offered it. I support efforts to dispel any such myths as soon as possible and encourage building robust solutions (payment channels, insured zero-conf services, etc.). -Alan On 02/12/2015 07:37 PM, Allen Piscitello wrote: You cannot close Pandora's box. Whether or not this type of patch should exist is irrelevant. It does, and there are incentives to use it by miners. These are the bounds we have to deal with and the world we must adapt to. On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier justusranv...@riseup.net mailto:justusranv...@riseup.net wrote: 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 arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. Here's value-free assessment of the issue here: 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer instant payments solution if possible. 3. As a social artifact, today zeroconf txs happen to work for some people in some situations. 4. Replace-by-fee will break #3 and probably hasten development of #2. The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner. I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons). TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined. You've left out of the discussion that many (or all) proposed solutions for 2 either reduce privacy, or security, or both. That fact should not be ignored or swept under the rug. There's also no mention of the degree to which child-pays-for-parent achieves the stated aims of the original proposal (clearing mempool of stuck transactions, increasing payee assurance of conformation) without introducing incentives to double
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn m...@plan99.net wrote: history. Lots of miners have dropped out due to hardware obsolescence, yet massive double spending hasn't happened. How many thousands of BTC must be stolen by miners before you'd agree that it has, in fact, happened? (https://bitcointalk.org/index.php?topic=321630.0) On Thu, Feb 12, 2015 at 3:27 PM, Jeff Garzik jgar...@bitpay.com wrote: The fundamental engineering truths diverge from that misty goal: Bitcoin is a settlement system, by design. The process of consensus settles upon a timeline of transactions, and this process -- by design -- is necessarily far from instant. Alt-coins that madly attempt 10-second block times etc. are simply a vain attempt to paper over this fundamental design attribute: consensus takes time. As such, the blockchain can never support All The Transactions, even if block size increases beyond 20MB. Further layers are -- by design -- necessary if we want to achieve the goal of a decentralized payment network capable of supporting full global traffic. I just wanted to pull this out and say that I agree with this completely; to the point where I'm continually surprised to see people expressing other views (but they do). I don't have much opinion about replace-by-fee; It has pluses and minuses. In the past I've considered it a oh perhaps best to not talk about that idea. I think making zero conf actively less secure would be generally regrettable, though it might make building alternatives for fast and acceptably safe transactions more attractive sooner. I do favor a version of replace by fee that adds the extra constraint that all prior outputs must be paid equal or more; which would capture many of the 'opps paid too little' without opening up the malicious double spends quite as much (so soon). One challenge is that without rather smart child-pays-for-parent logic the positive argument for replace by fee doesn't really work. On Thu, Feb 12, 2015 at 12:52 PM, Alex Mizrahi alex.mizr...@gmail.com wrote: This would be right if you assume that all Bitcoin miners act as a single entity. In that case it is true that that entity's goal is to maximize overall ROI. But each miner makes decisions on his own. Are you familiar with a concept of Nash equilibrium, prisoner's dilemma, etc? The fact that nobody is using this kind of a behavior right now doesn't mean that we can rely on it. For example, Peercoin was horribly broken in 6 months after its release (e.g. people reported that they are able to generate 50 consecutive blocks simply by bringing a cold wallet online) and yet nobody bothered to exploit it, and it managed to acquire non-negligible market cap. As a point for historical accuracy: PPC was actively attacked with stake grinding and had to use developer signed blocks to prevent the attacker from mining all the blocks and then later made a hard fork to make it harder, and retains the developer block signing to stop it. This doesn't contradict your point, which I agree with: an absence of attacks doesn't mean an absence of vulnerability, and people counting on things that they wouldn't if they understood them better is something to avoid. And the prior point about game theory is one I think some people have a hard time with: partipants are looking out for their own interests, not some global optimum. It may not be the case that everyone (or even anyone) is maximally short sighted; but it's even more unreasonable to assume that no one will ever break rank and do something selfish. I don't know that RBF even needs to be debated on these terms, since there is an argument for RBF as good even if we assume miners are all fully protocol conforming. -- 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
-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 connectivity that may be entirely out of their control. They also make maintaining a Bitcoin node and mining the blockchain require a significant amount of hands on maintenance, again incompatible with a decentralized system. So maybe scorched-earth solutions aren't a good idea after all. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QO8AAoJECpf2nDq2eYj4bUP/R8Lwjpdvc8Wu573+cGVRI88 /J8fURgYTxS9yvNNGRRHDYkHiqAcGI4sHIQQkqGs+A6mdDTbq6bJ04RjHoznlYbj TcpaKQkEynVSD5AjMnZ7Z/zLsc+qjFChNGNgxC3k4AW5UdBgo3VTE8HR1rVXM5C3 JLCSKv8uCRkHJxRlXZwE9/sZTZAAuLFVdTQb6sfi4Kb4Ztn8P2K2IsEnOlFwv1cZ ZNByxa56iBbNrVQa7hbbNXauIGOkj0fM3MB75JUQK/dHnW5d19bNHRIG0vnTtczH eoVvEdMtpSF/e7S6Kzx5xfcmCQsBRX7JIHyuZpBYAgr1HxjXOrdvqgWQCWDSUtNO ybzYwNKUbSCgbp6tbVTQuskm0QKVRcrrqMPZepPcgjQ/FLB8EALqarROkJTop/3p 8YatD3iq77SdnOfmFMZCFGHzn4UaxturRdEYIfeqz2Ia0YyyH3GWs1juhazyH+CM u6HbXXrq6AJmKWLYbSK1ycUBo9OhFObT9X3XswsWa0uNtSwLveqlvaI77UHkJbnr U9Ek9V0WznV1H9hn6qJpKyS/d+M64dfGjBSo79b50IxvlKrHKBPZkdHfSUyjnMFW rl9uE0jB6oLFUcqchypJ89HUeso7fD/8l36w0Z4TkMrcAy9V0RIj6P5nBYBU1U1s cLblEvdmUqmt4t+D1o4K =YnGT -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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
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 protocol and what is realistically possible given the nature of distributed consensus. Relying on altruism is a recipe for failure. On Thu, Feb 12, 2015 at 1:34 PM, Justus Ranvier justusranv...@riseup.net wrote: -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 false sense of security. I don't want to see systems that are built on the assumption that zero-conf tx are safe solely because it has always appeared safe. You can argue about rational miner behaviors all day, but in a decentralized system you have no idea what miners consider rational, or speculate about their incentives. As noted elsewhere in the thread, there are two problems with this analysis: 1. It asserts that zero-confirmation transactions are in a binary state of safe/broken instead of recognizing that relying on them is a non-binary risk analysis on the part of a merchant. 2. Assumptions about what is profitable for miners are based on all miners having short time horizons for calculating profits. In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more honest node operators from patching their nodes to blacklist any peer that relays replace-by-fee transactions, and maybe even publish an IP address list of those peers? Punishing Bitcoin users for not adopting somebody's pet solution to a problem neither responsible nor ethical. Child-pays-for-parent allows for stuck transactions to be cleared from the mempool, and allows recipients of zero-conf transactions to adjust their risk exposure as much or as little as they like. It's a solution that gives Bitcoin users more freedom, instead of trying to coerce them into pre-determined directions. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3QA+AAoJECpf2nDq2eYjnagQAJzxQtMMe0ZwAV6UZX+ORrzt vWh3bfbaO2/NfGL6dXK2i5rWeLTGIkiqZatwaW8S0M53ExMHaqDmW6db6TeE7aDO hZg4x618FWhYdG7DsfDxThd3rRupSGNJoL3L2763tSz+TrX5HptRh+e8gdy1Sq99 kk1Fyv1jJVBIXBmck19fj0iKOF8rS7n45d4jXO85VF/kfPegslZ7g9lwyH+b/iJ/ F0dfQmMefjEugpSrHww0Dnb4jjoOHz5tdW/Tv5DDNWDmsj/gYAMYRxZvoSl+AvAt P76odgDUwtbMpb+w3skLRLJCcBuTpSlmYVIhp5YlBrpc9ibznxGe+T3BfYoVGKvh pz/AxsLcNW3Wc0l0zOHdzoOj4lHjQ/WjJGC/dujnYlZozN+7nuU/GTuSR1GpMxg5 sOM3RuE/Fd+/JII7k7+zMNore44X0p/QVko8OK3kVVPx02Pu1PxRWNHJ2DMY0p7f b1nsVU5i/853sUez7SyBz5oaNgCgsz4lDKw++TeXhrD6gkdi0LMVOEUjIGMyTZwd j1wfdfdhhPakcDuyl0ybd9SpSgsUmXkU7N2nkpG8MxMdbopqIhACknZZOrXgoJqL LtbP1O6v8wvbsdeEH7cXJJhi1IBJK28dv0aBLN6fcqukP23s//Qe+5hhX5nNeUg0 F9dKdL5zCGofvU/U5BVq =kEMr -END PGP 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 -- 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 Feb 12, 2015, at 9:16 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: Why don't you use getrawmempool RPC call to synchronize mempool contents? Since RPC interface does not scale to serve a multi user service. In absence of better alternative, the interfaces used by a proprietary extension are usually the same as in P2P consensus. POW is used to figure the longest chain and until now broadcasted transactions were assumed the one and only. These simple rules ensure a consensus between the proprietary stack and the border router, and that is the consensus I referred to. On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic . 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Probably out of my league, but I will respond here anyway. I am in favor of replace-by-fee, but only if it were to be applied to a very limited subset of transactions: namely, transactions that seek to supplement, not replace, the original transaction. In other words, a replacement transaction would only be accepted if it were adding additional value (additional transaction inputs and/or outputs). Otherwise, the original transaction would stand. Reducing any of the promised outputs, or diverting them to some other recipient, would not be allowed. This would solve the problem of a stuck transaction: a transaction that is taking seemingly forever to confirm, because one forgot to pay the miner’s fee, something that happened to me once. Stuck transactions are bad, both for the recipient (they aren’t getting paid) and the sender (some of their funds are still tied up, because change from that transaction has not returned yet). With replace-by-fee, the sender of a transaction can send it again, with additional inputs (to pay more miner’s fees) and additional outputs (to receive the change, if any is desired, from those inputs). So, now the sender is self-empowered to “shove through” their stuck transaction, by voluntarily choosing to pay more for it, a market-driven solution to the problem. There are really good reasons to not allow replace-by-fee as a general policy that can apply to all transactions, as others have already mentioned. However, I still believe the idea has merit, for this special limited case of supplementing a transaction. Josh Lehan On Feb 11, 2015, at 22:47, Peter Todd p...@petertodd.org wrote: 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,
[Bitcoin-development] BIP for deterministic multisig addresses
Not sure what happened there - I'll drop the PGP. Hi all, I have drafted a BIP with Jean Pierre and Ruben after the last discussion, related to a standard for deriving a canonical pay-to-script-hash address given a set of public keys and the number of signatures required. There have been two or three discussions about it on the mailing list to date, and various services already carry out this process. I hope a BIP to describe this process will allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. BIP: XX Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft Type: Standards Track Created: 8 February 2015 ==Abstract== This BIP describes a method to deterministically generate multi-signature transaction scripts. It focuses on defining how the public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. ==Motivation== Most multi-signature transactions are addressed to P2SH (pay-to-script-hash) addresses, as defined in BIP-0016. Multi-signature redeem scripts do not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to a an ordering scheme and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address. By adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account. This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts: only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses. While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this. Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions. This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider. ==Implementation== For a set of public keys, ensure that they have been received in compressed form, sort them lexicographically according to their binary representation before using the resulting list of keys in a standard multisig redeem script. Hash the redeem script according to BIP-0016 to get the P2SH address. ==Compatibility== * Uncompressed keys are incompatible with this specificiation. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation. * P2SH addressses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork. * Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets. * Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses. * If a group of users were not entirely compliant, there is the possibility that a participant will derive an address that the others will not recognize as part of the common multisig account. ==Test vectors== The required number of signatures in each case is 2. Vector 1 * List ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f * Sorted ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 * Script ** 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae * Address ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z Vector 2 (Already sorted, no action required) * List: ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404 * Sorted: **
Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
Where is the Specification section?? Does this support arbitrary scripts, or only the simplest CHECKMULTISIG case? On Thursday, February 12, 2015 9:42:23 PM Thomas Kerin wrote: Hi all, I have drafted a BIP with Jean Pierre and Ruben after the last discussion, related to a standard for deriving a canonical pay-to-script-hash address given a set of public keys and the number of signatures required. There have been two or three discussions about it on the mailing list to date, and various services already carry out this process. I hope a BIP to describe this process will allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. BIP: XX Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft Type: Standards Track Created: 8 February 2015 ==Abstract== This BIP describes a method to deterministically generate multi-signature transaction scripts. It focuses on defining how the public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. ==Motivation== Most multi-signature transactions are addressed to P2SH (pay-to-script-hash) addresses, as defined in BIP-0016. Multi-signature redeem scripts do not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to a an ordering scheme and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address. By adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account. This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts: only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses. While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this. Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions. This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider. ==Implementation== For a set of public keys, ensure that they have been received in compressed form, sort them lexicographically according to their binary representation before using the resulting list of keys in a standard multisig redeem script. Hash the redeem script according to BIP-0016 to get the P2SH address. ==Compatibility== * Uncompressed keys are incompatible with this specificiation. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation. * P2SH addressses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork. * Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets. * Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses. * If a group of users were not entirely compliant, there is the possibility that a participant will derive an address that the others will not recognize as part of the common multisig account. ==Test vectors== The required number of signatures in each case is 2. Vector 1 * List ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f * Sorted ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 * Script ** 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102f f12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae * Address ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z Vector 2 (Already sorted, no action required) * List: **
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On 2/12/2015 6:25 AM, Tamas Blummer wrote: Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure. The statistics come from the aggregate actions of all nodes, especially those miners who watch p2p transactions and assemble blocks. Any one node makes deterministic decisions based on its own observation -- just like today's valid/invalid decision based on whether a blocktime is within the next 2 hours or not. The idea is that miners will exclude respends because they put the block at risk of being forked off, with no offsetting payback. The design point is to make sure this is sufficiently unlikely to happen accidentally, or via some attack vector. -- 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
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. Why don't you use getrawmempool RPC call to synchronize mempool contents? -- 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 09:27:22AM +0100, Tamas Blummer wrote: On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You are right that the assumption about the one and only transaction have to be relaxed. Broadcasting double spend only if it is actually replacing an earlier - for whatever reason, would simplify internal consensus logic . Wait, what the heck do you mean by only if it is actually replacing an earlier? How does my replace-by-fee patch *not* do that? -- 'peter'[:-1]@petertodd.org 12613986506ef6592952234a6a04946ef946ff0836405ad4 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
[Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hi all, I have drafted a BIP with Jean Pierre and Ruben after the last discussion, related to a standard for deriving a canonical pay-to-script-hash address given a set of public keys and the number of signatures required. There have been two or three discussions about it on the mailing list to date, and various services already carry out this process. I hope a BIP to describe this process will allow services to declare themselves as BIPXX compliant, working towards interoperability of services and simplifying the derivation of scripts and their addresses by all parties. BIP: XX Title: Deterministic Pay-to-script-hash multi-signature addresses through public key sorting Author: Thomas Kerin, Jean-Pierre Rupp, Ruben de Vries Status: Draft Type: Standards Track Created: 8 February 2015 ==Abstract== This BIP describes a method to deterministically generate multi-signature transaction scripts. It focuses on defining how the public keys must be encoded and sorted so that the redeem script and corresponding P2SH address are always the same for a given set of keys and number of required signatures. ==Motivation== Most multi-signature transactions are addressed to P2SH (pay-to-script-hash) addresses, as defined in BIP-0016. Multi-signature redeem scripts do not require a particular ordering or encoding for public keys. This means that for a given set of keys and number of required signatures, there are as many as 2(n!) possible standard redeem scripts, each with its separate P2SH address. Adhering to a an ordering scheme and key encoding would ensure that a multi-signature “account” (set of public keys and required signature count) has a canonical P2SH address. By adopting a sorting and encoding standard, compliant wallets will always produce the same P2SH address for the same given set of keys and required signature count, making it easier to recognize transactions involving that multi-signature account. This is particularly attractive for multisignature hierarchical-deterministic wallets, as less state is required to setup multi-signature accounts: only the number of required signatures and master public keys of participants need to be shared, and all wallets will generate the same addresses. While most web wallets do not presently facilitate the setup of multisignature accounts with users of a different service, conventions which ensure cross-compatibility should make it easier to achieve this. Many wallet as a service providers use a 2of3 multi-signature schema where the user stores 1 of the keys (offline) as backup while using the other key for daily use and letting the service cosign his transactions. This standard will help in enabling a party other than the service provider to recover the wallet without any help from the service provider. ==Implementation== For a set of public keys, ensure that they have been received in compressed form, sort them lexicographically according to their binary representation before using the resulting list of keys in a standard multisig redeem script. Hash the redeem script according to BIP-0016 to get the P2SH address. ==Compatibility== * Uncompressed keys are incompatible with this specificiation. A compatible implementation should not automatically compress keys. Receiving an uncompressed key from a multisig participant should be interpreted as a sign that the user has an incompatible implementation. * P2SH addressses do not reveal information about the script that is receiving the funds. For this reason it is not technically possible to enforce this BIP as a rule on the network. Also, it would cause a hard fork. * Implementations that do not conform with this BIP will have compatibility issues with strictly-compliant wallets. * Implementations which do adopt this standard will be cross-compatible when choosing multisig addressses. * If a group of users were not entirely compliant, there is the possibility that a participant will derive an address that the others will not recognize as part of the common multisig account. ==Test vectors== The required number of signatures in each case is 2. Vector 1 * List ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f * Sorted ** 02fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f ** 02ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f8 * Script ** 522102fe6f0a5a297eb38c391581c4413e084773ea23954d93f7753db7dc0adc188b2f2102ff12471208c14bd580709cb2358d98975247d8765f92bc25eab3b2763ed605f852ae * Address ** 39bgKC7RFbpoCRbtD5KEdkYKtNyhpsNa3Z Vector 2 (Already sorted, no action required) * List: ** 02632b12f4ac5b1d1b72b2a3b508c19172de44f6f46bcee50ba33f3f9291e47ed0 ** 027735a29bae7780a9755fae7a1c4374c656ac6a69ea9f3697fda61bb99a4f3e77 ** 02e2cc6bd5f45edd43bebe7cb9b675f0ce9ed3efe613b177588290ad188d11b404 * Sorted: **
Re: [Bitcoin-development] BIP for deterministic pay-to-script-hash multi-signature addresses
On Thu, Feb 12, 2015 at 10:13:33PM +, Luke Dashjr wrote: Where is the Specification section?? Does this support arbitrary scripts, or only the simplest CHECKMULTISIG case? It might be enough to rewrite this BIP to basically say all pubkeys executed by all CHECKMULTISIG opcodes will be in the following canonical order, followed by some explanatory examples of how to apply this simple rule. OTOH we don't yet have a standard way of even talking about arbitrary scripts, so it may very well turn out to be the case that the above rule is too restrictive in many cases - I certainly would not want to do a soft-fork to enforce this, or even make it an IsStandard() rule. -- 'peter'[:-1]@petertodd.org 13cf8270118ba2efce8b304f8de359599fef95c3ab43dcb1 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
On 12 Feb 2015, at 13:49, Mike Hearn m...@plan99.net wrote: If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks. How about a Ripple-like IOU-based payment network that is 100% decentralized, for dumb and daily payments only? IOUs will propagate from node to node and will trusted because of a joint escrow transaction between each pair of nodes (locking up certain amount on both ends in 2-of-2 multisig). Total amount of debt from one node to another will be limited to 50% of the locked amount (e.g. if both nodes lock up $20 each, they allow debt up to $10 in each direction). When debt is reaching its limit, it's being cleared by debtor via a real BTC transaction or simply by closing the contract transaction with correct proportion on outputs to pay off the debt. Every node may require an arbitrary fee for a service of providing his funds to back IOUs, when making a payment, merchant/customer may find several possible paths and choose the quickest/cheapest one to use. Centralization is possible at a proportional capital expense. If some node wants to be Visa-scale with millions of contracts and a lot of fees to earn, they'll have to lock up huge amount of money. This puts natural limit on centralization or associated risk. Example: I pay $10. The following path is discovered and signed off by the Merchant who accepts an ad-hoc 0.3% fee: Me: $10 - $9.99 (Alice) - $9.98 (Bob) - $9.97 (Merchant). Now I owe $10 to Alice, Alice owes $9.98 to Bob, Bob owes $9.97 to Merchant. Clearing of debts happens independently between each participant based on their debt-to-capital ratio and whether any party wishes to exit. Of course, if several paths are discovered within a reasonable timeframe, Merchant will choose the cheapest one. And maybe abort transaction if the proposed path is too expensive (e.g. total fee is 1%). Pros: - Decentralized. - Mere seconds to settle a payment. - Infinite scalability (no global consensus). Each payment involves 5-7 nodes only. - No trusted parties or federation (trust is purchased using joint escrow txs on blockchain) - No funny currency, IOUs denominated in BTC. - No global consensus or protocol. Nodes can be semi-compatible, upgrade independently. All risks are local. Political problems solved: - No need to debate zeroconf transactions. We don't *need* them anymore to buy a coffee. - No need to debate block size limit. It'd still be nice to raise it when needed, but for 99% of transactions we'll have a good decentralized solution off-chain, so the issue is less pressing. Cons: - Some amount of cash needs to be locked up with random nodes most of the time. If one of the nodes is offline, payments can't be cleared through that node. Although, it could not be a big problem as the network is useful for small-ish payments and every node will have 10-15 contracts, so it will tolerate occasional unavailability of some of them. -- 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
Mike, You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some. Some other’s might have seen the replaced transaction, but that only indicates for sure that the signer is fraudulent. What should a node do that really cares of good reputation? Ignore both to be on the safe side? Tamas Blummer 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. Scorched earth makes no sense by itself. However, it can be a part of a bigger picture. Imagine an insurance service which will make sure that merchants are compensated for every scorched-earth or double-spend transaction, as long they pay 0.1% premium from their revenue. Merchants won't really care how it works as long as it does. All they know is that they need to use a particular open-source wallet, and they will receive a payment no matter what. You won't need a TTP to process each payment. -- 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
You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some. Fraudulent in what sense? If you mean the legal term, then you'd use the legal beyond reasonable doubt test. You mined a double spend that ~everyone thinks came 5 minutes later once? OK, that could be a fluke. Reasonable doubt. You do it 500 times in a row? Probably not a fluke. If you mean under a technical definition then I think Tom Harding has been researching this topic, though I've only kept half an eye on it. I guess it's some statistical approximation of the above, i.e. sufficient to ensure good incentives with only small false positive losses. Sort of like how the block chain algorithm already works w.r.t orphans. -- 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 Feb 12, 2015, at 3:16 PM, Mike Hearn m...@plan99.net wrote: You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some. Fraudulent in what sense? Assume a wallet that sends double spend of the coin spent for services with higher fees to some of its nodes simultaneously. Merchants will catch and reject most of the attempts, but that will not stop the scheme in a setup where customer are anonymous and distant. Miner will see a mixed picture and will struggle to act “honestly” on a statistical measure. Tamas Blummer 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
The approach is how Bitcoin has always worked. Mike, you're making it worked before, and thus it will work in future kind of an argument. It is an extremely shitty kind of an argument. And it can be used to justify any kind of bullshit. E.g. any scamcoin which haven't yet collapsed will work forever. As I mentioned, it depends on scale. Highly sophisticated attacks are only feasible when scale is sufficiently big. I.e. when you have millions of dollars transacted each day it is one thing, but if you process billions of dollars, it becomes a whole another matter. The best way to profit from zero-confirmation payment disruption is through derivatives: short-sell Bitcoin while performing this attack. But this kind of an attack depends on a number of conditions: 1. highly liquid and reliable derivative market 2. sufficiently stable exchange rate 3. significant attack impact: lots of merchants relying on zero-confirmation payments, and lots of customers paying this way 4. significant amounts of capital available to the attacker These conditions are not yet met, and were never met in the Bitcoin's history so far. This is why I wrote 5 years from now, I believe that we might reach those conditions around that time. Direct impact of an attack might actually be low (but even if it is just 0.1%, 0.1% of 1 billion is 10 million, which isn't bad), but attacker might profit from the panic it causes. Note that I'm talking about situation where Bitcoin-aware PoS solutions are deployed on a big scale, so cost of upgrade might be huge. So anyway, in my opinion, it is actually great that Bitcoin is still relatively small: we have an opportunity to analyze and improve things. But you seem to be hostile to people who do that (and who do not share your opinion), which is kinda uncool. Also, you do not bother to back your intuition with rigorous reasoning, while also attacking people who offer alternatives with non-rigorous slipper-slope kind of arguments. Which is doubly uncool. -- 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
Den 12 feb 2015 14:44 skrev Mike Hearn m...@plan99.net: You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. There have been lots of e-cash schemes proposed in the academic literature that work like this, or variants of it. Schemes where participants are anonymous until they double spend are popular. Let's re-write your proposal but substituting the word notary for miner: To profit, the miner would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. That's the exact argument we're having. The assertion is that a rational notary would kill his own business to increase his profits in the next few hours. So you're just arguing that a notary is different to a miner, without spelling out exactly why. Does the notary have to make a big up front investment? If so, why is that different to mining investment? Miners are transient. You don't depend on any given subset of them. Centralized e-currency give you no choice but to trust one set of notaries. The notary don't have any large maintenance costs. The initial investment is small, they don't need more than a few servers and maybe a HSM and some office. In the non-collateral version, they're a centralized entity. Note that in the fully centralized model, if the notary goes bad you're screwed. Your tokens are useless or maybe gone. Essentially you can't know if you're up for the long con or not. Anybody can set up a miner with capital investments. No individual miner has a large impact on the system as a whole. In Bitcoin, you aren't dependent on any one multisignature notary. One going gown only represents a small loss and done temporarily locked funds. Anybody can set up a multisignature notary, but people won't trust you unless you show you're trustable - you need to market yourself to get to the point where a malicious doublespend can be profitable. You can't really replicate the collateralized multisignature notary model in centralized systems. Because having the e-currency bank be the notary means they have the same powers a 51% miner would have - they can block the transaction claiming the collateral, they can censor any other transactions at will, and all your funds depend on them and the market's trust in them. Is the notary non-anonymous and afraid of being charged with payment fraud? If so, note that big miners do lots of non-anonymous things too, like renting warehouses and importing specialised equipment. As notaries can be small operations, they can perform the doublespend as they escape across the border. Is it because of the big up front collateral they're meant to have lying around? If so, how do you ensure a fluid market for notaries? With collateralized multisignature notaries, my assumption is that organizations that are related to Bitcoin transactions that has sufficient sums of unallocated funds would use them for collateral in a scheme like this (almost every large organization in the world have some unallocated funds somewhere). As sellers have almost no risk of losing money to them, any notary backed by somebody they know and trust would be good enough As buyers also have no risk, they'd use them when they want to make quick payments. - You seem to be making a lot of arguments from the status quo. I don't care what people have been doing, preserving every habit isn't a sacred goal. I care about stable incentives and long term predictability regarding what behavior is safe. Behavior that becomes unsafe if incentives change is bad and shouldn't be relied on. Also, Bitcoin is the concensus mechanism. As mentioned, trying to provide a guarantee for what will end up in the blocks without servers involved is to reinvent Bitcoin within Bitcoin. I can go Xzibit on you all day long if you like! What you consider an attack is irrelevant. You assume a certain behavior is desired without first making sure it is reliable. Depending on that which isn't guaranteed is bd, and breaking other people's assumptions is by itself NOT an attack if there never was a guarantee or even as little as an implicit understanding it is safe. Your also assume people will expect the Bitcoin network to keep zero-conf safe forever and that Bitcoin valuation is tied to that. Given the options available and current state of things, I'm assuming that's wrong. Besides, zero-conf will never be secure if you don't add external contextual information as a requirement when validating blocks. Otherwise defecting miners will frequently doublespend against you. And adding such information is messy and probably not secure in itself, as it opens up for gaming the system through network level attacks. And your remarks
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 13:49 skrev Mike Hearn m...@plan99.net: Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party you can fix things, but then you're back to having the disadvantages of centralised trust. That trust you put in them is extremely limited, and temporary. First of all, the standard multisignature notary model applies like how I originally described it in my blog post over a year ago. You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. After confirmation in the blockchain, you have standard Bitcoin transaction security. To profit, the notary would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. To provide security for high value transactions, NRW adds a collateral transaction that the notary stands for and signs in advance, and gives to the seller. The key here is that it is constructed such that if the original payment gets doublespent, then this collateral transaction to the seller becomes spendable. So there is two outcomes - either the customer or the notary pays the seller. The customer can't force a doublespend. The notary can't steal or freeze funds (due to nlocktime fund recovery option). The seller knows he'll get the funds for sure before delivering the goods. Nobody is at risk. -- 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
1. They won't be attacking Bitcoin, they will attack merchants who accept payments with 0 confirmations. Which is basically all of them other than exchanges. Any merchant that uses BitPay or Coinbase, for instance, or any physical shop. If you want to play word games and redefine Bitcoin to be something other than what people are actually using, go right ahead. You will win the argument under your own definitions which nobody else is using. In your scenario I won't be able to get hamburgers for free because people will stop selling them for ordinary bitcoin transactions. Most will say, you know what, just pay me with Visa instead. And a few might knuckle down and set up some network of PKI-like trusted third parties that interacts with the block chain in some way. Though eventually, if that were to happen, cunning merchants will notice that having received a transaction counter-signed by a TTP they don't actually have to broadcast it or pay miner fees at all. They can just keep it around in their wallet and pass it along to the next guy when they purchase something with those coins. Eventually whoever ends up not being able to find a matching TTP gets to be the sucker who pays all the miner fees at once, because he is the only one who actually needs their services. -- 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
Miners are *not* incentivised to earn the most money in the next block possible. They are incentivised to maximise their return on investment. This would be right if you assume that all Bitcoin miners act as a single entity. In that case it is true that that entity's goal is to maximize overall ROI. But each miner makes decisions on his own. Are you familiar with a concept of Nash equilibrium, prisoner's dilemma, etc? The fact that nobody is using this kind of a behavior right now doesn't mean that we can rely on it. For example, Peercoin was horribly broken in 6 months after its release (e.g. people reported that they are able to generate 50 consecutive blocks simply by bringing a cold wallet online) and yet nobody bothered to exploit it, and it managed to acquire non-negligible market cap. So we have an empiric evidence that proof-of-stake miners are motivated to keep network secure. So, maybe, we should switch to proof-of-stake, if it was demonstrated that it is secure? There are good reasons to not switch to proof-of-stake. Particularly, the kind which is used in Peercoin is not game-theoretically sound. So even if it works right now, it can fail in a big way once attackers will really get around to it. An attack requires significant knowledge, effort and, possibly, capital, so it might be only feasible on a certain scale. So, well, anyway, suppose Peter Todd is the only person interested in maintaining replace-by-fee patches right now, and you can talk him into abandoning them. OK, perhaps zero-confirmation payments will be de-facto secure for a couple of years. And thus a lot of merchants will rely on zero-confirmation payments protected by nothing but a belief in honest miners, as it is damn convenient. But, let's say, 5 years from now, some faction of miners who own soon-to-be-obsolete equipment will decide to boost their profits with a replace-by-fee pool and a corresponding wallet. They can market it as 1 of 10 hamburgers are free if they have 10% of the total hashpower. So would you take a responsibility for pushing the approach which isn't game-theoretically sound? -- 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
You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. There have been lots of e-cash schemes proposed in the academic literature that work like this, or variants of it. Schemes where participants are anonymous until they double spend are popular. Let's re-write your proposal but substituting the word notary for miner: To profit, the *miner* would have to be sure the payout from agreeing on collusion (or to perform the doublespend themselves) would pay out better than acting honestly for a given amount of time info the future. This means transactions for small sums are secure. That's the exact argument we're having. The assertion is that a rational notary would kill his own business to increase his profits in the next few hours. So you're just arguing that a notary is different to a miner, without spelling out exactly why. Does the notary have to make a big up front investment? If so, why is that different to mining investment? Is the notary non-anonymous and afraid of being charged with payment fraud? If so, note that big miners do lots of non-anonymous things too, like renting warehouses and importing specialised equipment. Is it because of the big up front collateral they're meant to have lying around? If so, how do you ensure a fluid market for notaries? -- 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
But, let's say, 5 years from now, some faction of miners who own soon-to-be-obsolete equipment will decide to boost their profits with a replace-by-fee pool and a corresponding wallet. They can market it as 1 of 10 hamburgers are free if they have 10% of the total hashpower. Yes, like any P2P network Bitcoin cannot work if a sufficiently large number of miners decide to attack it. This is an ancient argument. It came up the moment Bitcoin was first invented. But this argument could have been made at any time in Bitcoin's entire history. Lots of miners have dropped out due to hardware obsolescence, yet massive double spending hasn't happened. Perhaps the system is not as simple as you boil it down to be. Anyway, what would happen in that event is within a few days some people would stop selling Bitcoin for hamburgers, others would find workarounds, and the fees collected from the double spends would be worth very little. Nobody wins. So would you take a responsibility for pushing the approach which isn't game-theoretically sound? The approach is how Bitcoin has always worked. People have been using game theory to predict the imminent demise of Bitcoin since I first found it. Just one example: Bitcoin will collapse when the 50-25 BTC drop happens was promoted as a dead cert thing by game theorists. Every miner becomes unprofitable and stops at once! So far game theory based predictions tend to be proven wrong by reality, so this sort of argument doesn't impress me much. Anyway, going around this loop again is pointless. I brought up the counter argument so people who see this thread don't mistakenly think Peter's position is some kind of de-facto consensus about how Bitcoin should work. Not because I love rehashing the same arguments every six months ad nauseum. -- 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
A similar idea was proposed by Sirer and me as a part of two-phase proof of work (2P-PoW) [1]. In 2P-PoW the first phase is Bitcoin's standard PoW and the second phase requires the signature. This way Bitcoin doesn't lose its mining power (read: security) in one day, but rather it is possible to gradually switch from the current PoW to the signature-based one, slowly phasing out the existing hardware and mining datacenters. For a more general view of nonoutsourceable puzzles you can check out Miller et al.'s paper [2]. Ittay [1] http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/ [2] https://cs.umd.edu/~amiller/nonoutsourceable.pdf -- Message: 2 Date: Wed, 11 Feb 2015 08:54:15 + From: Hector Chu hector...@gmail.com Subject: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header To: bitcoin-development@lists.sourceforge.net Message-ID: caao2fkefxc_byt4xvjb0s-7yy0m7m-av7mhuh-rbduri_ga...@mail.gmail.com Content-Type: text/plain; charset=utf-8 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. -- next part -- An HTML attachment was scrubbed... -- Message: 3 Date: Wed, 11 Feb 2015 10:25:27 +0100 From: Natanael natanae...@gmail.com Subject: Re: [Bitcoin-development] Proposal: Requiring a miner's signature in the block header To: Hector Chu hector...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Message-ID: CAAt2M1_qj0r03= ref9mn7bjlg-odep3m5tez7jwdlc+zknq...@mail.gmail.com Content-Type: text/plain; charset=utf-8 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
Den 12 feb 2015 12:58 skrev Mike Hearn m...@plan99.net: [...] Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. NoRiskWallet: https://github.com/baleato/bitcoin-hackathon -- 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
Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party you can fix things, but then you're back to having the disadvantages of centralised trust. If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people will look at the new tradeoffs/complexity, and decide that Bitcoin is no longer better for them than banks. -- 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
Mike, Peter’s pull request might be a foot gun, but we are here to find out. One can’t claim Bitcoin core code is there to fork and then be disappointed if some really do it. I am not sure protecting unconfirmed transactions ranks higher than fostering innovation not to depend on the same. Tamas Blummer 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
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
So you're just arguing that a notary is different to a miner, without spelling out exactly why. I'm afraid I still don't understand why you think notaries would build long term businesses but miners wouldn't, in this model. I think you are saying because notaries have identity, brand awareness and because they have big up front bonds, that means they will be trustworthy. Well, sure. It's the same model governments use and is why being a money transmitter in the USA is so difficult: you need to put up large sums of money as collateral and have your fingerprints taken 48 times. *Then* you can start advertising to get customers! The reason mining is such a nice model is it doesn't have these sorts of requirements. As notaries can be small operations . [snip] .. (almost every large organization in the world have some unallocated funds somewhere). Which is it? Are notaries small operations or large operations? I think exploring new consensus models with semi-trusted notaries is interesting, but it's not Bitcoin. Depending on that which isn't guaranteed is bd, and breaking other people's assumptions is by itself NOT an attack if there never was a guarantee or even as little as an implicit understanding it is safe. Please don't try and apply this logic in the real world :( Rephrased: *That's a nice house. I noticed it's made of wood. I'm going to start fires until it burns down, because there is no guarantee your house won't burn down in future and it's important you understand that wooden houses aren't safe. Really I'm just doing you a favour*. Don't get me wrong. I'm all for what *you're* doing - please do continue to research and explore alternative trust configurations! This is helpful and useful work. Perhaps we will find something that solves the burger problem in a way that satisfies everyone. I'm really not a fan of Peter's approach, which is hey let's try and cause as many problems as possible to try and prove a point, without having created any solutions. Replace-by-fee-scorched-earth doesn't work and isn't a solution. Miners can easily cut payment fraudsters in on the stolen money, and as they'd need to distribute custom double-spending wallets to make the scheme work it'd be very easy to do. Your also ssume people will expect the Bitcoin network to keep zero-conf safe forever and that Bitcoin valuation is tied to that. Given the options available and current state of things, I'm assuming that's wrong. Why? You think ability to make payments in a few seconds is some irrelevant curiousity? Let's put it this way. If BitPay's business model evaporates tomorrow, along with all the merchants they support, do you think that'd have any effect on Bitcoin's value? If not, why not? -- 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
So anyway, in my opinion, it is actually great that Bitcoin is still relatively small: we have an opportunity to analyze and improve things. But you seem to be hostile to people who do that (and who do not share your opinion), which is kinda uncool. To clarify once more, I'm all for people researching and building ways to make Bitcoin better and safer. And debating that here is cool too. The replace by fee patches don't do this; as you said yourself the whole scorched earth thing makes no sense. It's not a solution to anything and it's important people realise that. Perhaps it will help if I spell out why this whole approach won't work (but can easily damage bitcoin a lot along the way). Normal Bitcoin nodes pick which transaction to put into a block by simply selecting whichever they saw arrive first, as determined by the arrival order of network packets. This rule is simple and has multiple advantages for people using Bitcoin to buy and sell things. Replace-by-fee changes this so nodes select whichever chain of unconfirmed transactions pays the highest miner fees. Up until the point that a transaction appears in a block, anyone can broadcast a double spend (or a spend of an unconfirmed transaction) which pays higher fees than before, causing that tx chain to become the candidate for chain inclusion. Peter argues that this is stable and makes unconfirmed transactions safe because a fraudster can buy something, walk out of the shop, and broadcast a double spend with a higher fee. But then the merchant can re-spend the original payment back to themselves with an *even* higher fee than that. Then the fraudster can re-spend their double spend with an *even* higher fee than that, and so on back and forth, until *all* the money has been spent to miner fees. Thus the merchant loses their goods but the fraudster has still paid in some sense because they don't get the money either. This argument makes no sense for two reasons. The first is that this setup means miners can steal arbitrary payments if they work together with the sender of the money. The model assumes this collaboration won't happen, but it will. Because no existing wallet has a double spend this button, to make the scheme work the dishonest miners must create and distribute such a wallet that implements the whole scorched-earth protocol. At that point it's easy for miners to reward the payment fraudster with some of the stolen money the merchant lost, meaning it now makes sense for the fraudster to always do this. The situation isn't stable at all. The second is that it incentivises competitors to engage in payment fraud against each other. A big rich coffee shop chain that is facing competition from a small, scrappy newcomer can simply walk into the new shop and buy things, then trigger the scorched earth. Even with no miner collaboration, this means the big company is down the cost of the product *but* so is the little company who lost everything. Whoever can outspend the other wins. We don't really need game theory to tell us that this plan is a bad idea. Just imagine trying to explain it to an actual shop keeper. They would think you were crazy. Bitcoin is already a hard enough concept to understand without throwing into the mix anyone can burn the money they gave you after walking out of the shop. -- 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
Den 12 feb 2015 15:53 skrev Mike Hearn m...@plan99.net: So you're just arguing that a notary is different to a miner, without spelling out exactly why. I'm afraid I still don't understand why you think notaries would build long term businesses but miners wouldn't, in this model. I think you are saying because notaries have identity, brand awareness and because they have big up front bonds, that means they will be trustworthy. Miners aren't contractors, they don't have to care about repeat business. Individual miners don't have enough impact to have a negative impact on their own capital investment. Zero-conf transactions also aren't that tied to the Bitcoin valuation. 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 would miners provide here, do you think? Well, sure. It's the same model governments use and is why being a money transmitter in the USA is so difficult: you need to put up large sums of money as collateral and have your fingerprints taken 48 times. Then you can start advertising to get customers! Obviously you need to have collateral to provide collateral. Can't make cryptographic verifiable guarantees if you don't have the resources to back them. The reason mining is such a nice model is it doesn't have these sorts of requirements. And also can't make these assurances. Any minority miner can be overrun. As notaries can be small operations . [snip] .. (almost every large organization in the world have some unallocated funds somewhere). Which is it? Are notaries small operations or large operations? The operation itself is small. A few people maintaining a few servers. The collateral needed depends on how many and how large simultaneous transactions they want to provide assurances for, so they can chose to be a small player for one niche market or large and global if they have the funds for it. I think exploring new consensus models with semi-trusted notaries is interesting, but it's not Bitcoin. Methods for decentralized consensus that aren't PoW also aren't Bitcoin. Please don't try and apply this logic in the real world :( Rephrased: That's a nice house. I noticed it's made of wood. I'm going to start fires until it burns down, because there is no guarantee your house won't burn down in future and it's important you understand that wooden houses aren't safe. Really I'm just doing you a favour. Actually that IS often a bad idea. But fortunately the risk and threat is low, and mitigation is well understood. I'm really not a fan of Peter's approach, which is hey let's try and cause as many problems as possible to try and prove a point, without having created any solutions. Replace-by-fee-scorched-earth doesn't work and isn't a solution. Miners can easily cut payment fraudsters in on the stolen money, and as they'd need to distribute custom double-spending wallets to make the scheme work it'd be very easy to do. Security analysis requires having the mindset of an attacker. Sometimes that reveals suboptimal choices. Then you want them changed to more stable choices such that once the incentives change, the risk already is gone. Minimization of damage, simply put. Your also ssume people will expect the Bitcoin network to keep zero-conf safe forever and that Bitcoin valuation is tied to that. Given the options available and current state of things, I'm assuming that's wrong. Why? You think ability to make payments in a few seconds is some irrelevant curiousity? No. But you can't be certain it is secure without having a solid reliable mechanism to provide such a guarantee. You want zero-conf to stay safe without involvement of servers? Then please, try to find a way to secure it. Right now you're assuming it can remain safe based on circumstances which can change and assumptions about market participant's valuations that likely aren't true. Let's put it this way. If BitPay's business model evaporates tomorrow, along with all the merchants they support, do you think that'd have any effect on Bitcoin's value? If not, why not? It would. They'd tank. But you're assuming too much about the basis for valuation. -- 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
Repeating past statements, it is acknowledged that Peter's scorched earth replace-by-fee proposal is aptly named, and would be widely anti-social on the current network. At a high level, we can see that this thread is contentious because this covers _what we want bitcoin to be_, and that is an opinion (versus engineering fact), and it varies from person to person. However, hope is the denial of reality...instead we should walk forward with our eyes open[1]. My interest in bitcoin originates from the science fiction concept of credits[2], a universal money that transcends national borders and even planets. That is what I hoped bitcoin would be. universal payments is both a laudable goal and a shopworn bitcoin marketing slogan. The fundamental engineering truths diverge from that misty goal: Bitcoin is a settlement system, by design. The process of consensus settles upon a timeline of transactions, and this process -- by design -- is necessarily far from instant. Alt-coins that madly attempt 10-second block times etc. are simply a vain attempt to paper over this fundamental design attribute: consensus takes time. As such, the blockchain can never support All The Transactions, even if block size increases beyond 20MB. Further layers are -- by design -- necessary if we want to achieve the goal of a decentralized payment network capable of supporting full global traffic. Bitcoin payments are like IP packets -- one way, irreversible. For larger value transfers this attaches attendent risk of loss -- as we've seen in the field time again. The world's citizens en masse will not speak to each other with bitcoin (IP packets), but rather with multiple layers (HTTP/TCP/IP) that enable safe and secure value transfer or added features such as instant transactions. This opinion is not a conspiracy to put the bankers back in charge -- it is a simple acknowledgement of bitcoin's design. The consensus system settles on a timeline. Bitcoin transactions are, by definition, not instant. Zero confirmation transactions are, by definition, not secure. Proposals such as Oleg's are _necessary_ to fully build out the bitcoin system. Avoid short-sighted, short-term thinking that views the lowest layer (one-way value xfer) at the most optimal layer at which free persons will transact freely instantly across planet Earth. It is foolish to think the entire world will connect directly to the P2P block network and broadcast all the morning coffees to all the miners. That's not how the system works. It is a settlement layer. We _must_ build decentralized layered solutions on top of bitcoin, rather than stuffing everything into bitcoin itself. [1] http://www.goodreads.com/quotes/35199-hope-is-the-denial-of-reality-it-is-the-carrot [2] http://garzikrants.blogspot.com/2013/06/shadowrun-and-bitcoins-roots.html On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn m...@plan99.net wrote: I know you will ignore this as usual, but the entire replace-by-fee folly is based on your fundamental misunderstanding of miner incentives. Miners are not incentivised to earn the most money in the next block possible. They are incentivised to maximise their return on investment. Making Bitcoin much less useful reduces demand for the bitcoins they are mining, reducing coinbase and fee income in future blocks. Quite possibly, to the point where those miners are then making a loss. Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. If enough miners do it they will simply break Bitcoin to the point where it's no longer an interesting payments system for lots of people. Then miners who have equipment to pay off will be really screwed, not to mention payment processors and all the investors in them. I'm sure you can confuse a few miners into thinking your ideas are a super-duper way to maximise their income, and in the process might facilitate a pile of payment fraud. But they aren't. This one is about as sensible as your let's never increase the block size and let's kill SPV clients crusades - badly thought out and bad for Bitcoin. -- 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 -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ -- Dive into the World
Re: [Bitcoin-development] replace-by-fee v0.10.0rc4
-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 would miners provide here, do you think? Well, sure. It's the same model governments use and is why being a money transmitter in the USA is so difficult: you need to put up large sums of money as collateral and have your fingerprints taken 48 times. Then you can start advertising to get customers! Obviously you need to have collateral to provide collateral. Can't make cryptographic verifiable guarantees if you don't have the resources to back them. tl;dr: Bitcoin users aren't getting very excited about somebody's pet hub-and-spoke project, so they decide to distribute a patch that will change Bitcoin's behavior such that people are forced to adopt them. Scorched earth, indeed. - -- Support online privacy by using email encryption whenever possible. Learn how here: http://www.youtube.com/watch?v=bakOKJFtB-k -BEGIN PGP SIGNATURE- iQIcBAEBCAAGBQJU3McnAAoJECpf2nDq2eYjxI8P/iClVQKNhGPr0K4D8KktUDUS CB8Gu6Rg4VqgjzwhSd1AD1CAhSkxRRgNfHOkxeu2n1wA/fs9V/x66W9G33OyHvf4 1M+BwkiNszxvfxvZVkXyPa/eqa8/alIs1jEhb19dBRn6sJ6EQyca93PG00wDhhRU JbHeYj2pYYMuu+xRpJWhRdUOpJOsLu5E9XMocS12wun7+zQCs4QfoLVcGhMv3+Ug iS3/H1NNQJegIFMQzgi5hr7CxClZ+MrsLDO7MBEZknjr0toEJXe7c5Logwc3oF8h klhFeSnhexCHNeDSGKDhG89hrgWPSDDuuyMRa3e3L4xsT2zAFcsmw0ScCmyNSto4 gUCy1gQsShDJSvsYvqjJkOcL5UfP2WLQiVJecpblf1R/tgjC0SsBoPeRMT/DeSjV xpcjUrAUzkIBuEcunFarkt7wBvL/4pvGnbYcx3uW2YX50oO7LjCcgwJLMW4ecsvn zAoc+aXqeORo2SAI3tTJKqpnn5K2k7DVTiFt1vzHVR7OxnKa/+sXk+bCkQi9/dAL bWjiBUV8hXBVIt0UBgj7Q5wgQSoAXI0D816GIA2Qb9XQfmpRb8QTmf9kQ1DrcV68 Qt1KOHPY1yCynqLMxN3ONWu4JMF+YYwrxx47Gg7wSJr5q70mHNlLljfnfb5PNLtS J6t2/QfPTMmyN3V6xkbU =hna5 -END PGP SIGNATURE- 0xEAD9E623.asc Description: application/pgp-keys -- 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
Den 12 feb 2015 16:15 skrev Mike Hearn m...@plan99.net: The first is that this setup means miners can steal arbitrary payments if they work together with the sender of the money. The model assumes this collaboration won't happen, but it will. Because no existing wallet has a double spend this button, to make the scheme work the dishonest miners must create and distribute such a wallet that implements the whole scorched-earth protocol. At that point it's easy for miners to reward the payment fraudster with some of the stolen money the merchant lost, meaning it now makes sense for the fraudster to always do this. The situation isn't stable at all. The second is that it incentivises competitors to engage in payment fraud against each other. A big rich coffee shop chain that is facing competition from a small, scrappy newcomer can simply walk into the new shop and buy things, then trigger the scorched earth. Even with no miner collaboration, this means the big company is down the cost of the product but so is the little company who lost everything. Whoever can outspend the other wins. We don't really need game theory to tell us that this plan is a bad idea. Just imagine trying to explain it to an actual shop keeper. They would think you were crazy. Bitcoin is already a hard enough concept to understand without throwing into the mix anyone can burn the money they gave you after walking out of the shop. I see no fundamental difference in outcome from miner collusion in scorched-fee (which isn't guaranteed to pay the right pool!) and miner collusion in knowingly mining a doublespend transaction. Both outcomes pay the miner and thief equally when successful. The merchant loses in both. Zero-conf needs something else for security. A guarantee it can not be doublespent in the relevant time frame. -- 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
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 arent actively double spending, and when they do it is for higher value targets. Double spend attacks are happening a lot more frequently than is being admitted here, according to Peter from work with various clients. Like single address reuse, people have gotten used to something which is bad. Generally accepting 0-conf is also a bad idea(tm) and instant confirmation solutions should be sought elsewhere. There are already interesting solutions and concepts: greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment channels for example. Rather than supporting and promoting risky 0-confirms, we need to spend time on better alternative solutions that will work for everyone and not during the honeymoon phase where attackers are fewer. Here's value-free assessment of the issue here: 1. Zero-conf txs are unsafe. 2. We'd all want to have a safer instant payments solution if possible. 3. As a social artifact, today zeroconf txs happen to work for some people in some situations. 4. Replace-by-fee will break #3 and probably hasten development of #2. The discussion boils down to whether we should make #2 happen sooner by breaking remnants of #3 sooner. I personally would rather not break anything, but work as fast as possible on #2 so no matter when and how #3 becomes utterly broken, we have a better solution. This implies that I also don't want to waste time debating with Peter Todd and others. I want to be ready with a working tool when zeroconf completely fails (with that patch or for some other reasons). TL;DR: those who are against the patch are better off building a decentralized clearing network rather than wasting time on debates. When we have such network, we might all want this patch to be used for all the reasons Peter has already outlined. -- 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
Den 12 feb 2015 16:42 skrev Mike Hearn m...@plan99.net: Remember that you aren't paying the bad pool, the bad pool is paying you. Whichever pool benefits from the scorched earth protocol can simply pick an address out of the transaction it perceived as starting the protocol, and pay that. My counterargument: with zero-conf but no replace-by-fee scorched earth, there would instead be a market which thieves use where pools would offer to execute doublespends that pay the thief and the pool, and where the pools would set what terms and payouts they ask for. All bidding pools with acceptable terms get a doublespend transaction that pays that specific pool and the thief, the first to mine theirs win (and the merchant loses). Your protocol requires less setup, but that's the only notable difference (besides risk of paying non-participating pools with scorched earth). No notable difference in security for merchants. -- 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
I see no fundamental difference in outcome from miner collusion in scorched-fee (which isn't guaranteed to pay the right pool!) and miner collusion in knowingly mining a doublespend transaction. Well, they're the same thing. Replace-by-fee *is* miner collusion in knowingly mining a double spend, just triggered in a certain way. Remember that you aren't paying the bad pool, the bad pool is paying you. Whichever pool benefits from the scorched earth protocol can simply pick an address out of the transaction it perceived as starting the protocol, and pay that. Zero-conf needs something else for security. A guarantee it can not be doublespent in the relevant time frame. I think this is the core point which many of these debates revolve around. No payment system provides *guarantees*, though some are stronger than others. All they do is manage risk. -- 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 Feb 12, 2015, at 9:49 AM, Peter Todd p...@petertodd.org wrote: How does my replace-by-fee patch *not* do that? Does it broadcast a double spend only if it IS replacing an earlier? If yes, I am fine with it. Tamas Blummer 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
