* [Bitcoin-development] replace-by-fee v0.10.0rc4
@ 2015-02-12 6:47 Peter Todd
2015-02-12 7:23 ` Tamas Blummer
` (5 more replies)
0 siblings, 6 replies; 79+ messages in thread
From: Peter Todd @ 2015-02-12 6:47 UTC (permalink / raw)
To: bitcoin-development
[-- Attachment #1: Type: text/plain, Size: 4922 bytes --]
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 '((0000000000000003)|(0000000004000001))'
"services" : "0000000000000003",
"services" : "0000000004000001",
"services" : "0000000004000001",
"services" : "0000000000000003",
"services" : "0000000004000001",
"services" : "0000000004000001",
"services" : "0000000000000003",
"services" : "0000000000000003",
Replace-by-fee nodes advertise service bit 26 from the experimental use
range; Bitcoin XT nodes advertise service bit 1 for their getutxos
support. The code sets aside a certain number of outgoing and incoming
slots just for double-spend relaying nodes, so as long as everything is
working you're node should be connected to like-minded nodes a within 30
minutes or so of starting up.
If you *don't* want to advertise the fact that you are running a
replace-by-fee node, just checkout a slightly earlier commit in git; the
actual mempool changes are separate from the preferential peering
commits. You can then connect directly to a replace-by-fee node using
the -addnode command line flag.
1) https://github.com/bitcoinxt/bitcoinxt
2) https://github.com/bitcoin/bitcoin/pull/3883
3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370
4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP
5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html
6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html
7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html
--
'peter'[:-1]@petertodd.org
000000000000000013c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3
[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 650 bytes --]
^ permalink raw reply [flat|nested] 79+ messages in thread* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd @ 2015-02-12 7:23 ` Tamas Blummer 2015-02-12 7:45 ` Peter Todd 2015-02-12 8:16 ` Alex Mizrahi 2015-02-12 11:58 ` Mike Hearn ` (4 subsequent siblings) 5 siblings, 2 replies; 79+ messages in thread From: Tamas Blummer @ 2015-02-12 7:23 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 617 bytes --] Peter, An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Tamas Blummer Bits of Proof [-- Attachment #1.2: Type: text/html, Size: 1626 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 7:23 ` Tamas Blummer @ 2015-02-12 7:45 ` Peter Todd 2015-02-12 8:27 ` Tamas Blummer 2015-02-12 8:16 ` Alex Mizrahi 1 sibling, 1 reply; 79+ messages in thread From: Peter Todd @ 2015-02-12 7:45 UTC (permalink / raw) To: Tamas Blummer; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1617 bytes --] On Thu, Feb 12, 2015 at 08:23:29AM +0100, Tamas Blummer wrote: > Peter, > > An important use of the core is being border router to proprietary software, that is usually indexing the block chain and mempool. That software is also assuming that double spends are not relayed by the core. > > To remain useful as border router, the replace-by-fee patched core should only relay double spend if it actually replaces an earlier transaction, as otherwise the replace logic that is according to your commit more than just fee comparison, would have to be replicated in the proprietary stack and mempool might get out of sync with that of the border router. Absolutely nothing in the replace-by-fee patch is consensus critical; your objection is entirely an artifact of the poor modularity of the Bitcoin Core codebase, something that is being actively improved on as we speak. Anyway, the logic of dealing with double-spends and keeping mempools synced is pretty trivial: for i in range(len(tx.vout)): for double_spent_tx in mempool.mapNextTx[COutPoint(tx.GetHash(), i)]: mempool.remove(double_spent_tx, recursive=True) mempool.add(tx) IOW, assume every transaction your "border router" gives you is now the one and only true transaction, and everything conflicting with it must go. All the complexity of replace-by-fee is in deciding when one transaction should replace another(s). Other than that the code is simple and very similar to block handling logic. -- 'peter'[:-1]@petertodd.org 00000000000000000948f5c1f1a8c8073cc7d5161b98474e33904f8a1d6b0330 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 7:45 ` Peter Todd @ 2015-02-12 8:27 ` Tamas Blummer 2015-02-12 8:49 ` Peter Todd 2015-02-15 20:51 ` Troy Benjegerdes 0 siblings, 2 replies; 79+ messages in thread From: Tamas Blummer @ 2015-02-12 8:27 UTC (permalink / raw) To: Peter Todd, alex.mizrahi; +Cc: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 1094 bytes --] On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi@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 <pete@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 [-- Attachment #1.2: Type: text/html, Size: 2998 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 8:27 ` Tamas Blummer @ 2015-02-12 8:49 ` Peter Todd 2015-02-12 9:01 ` Tamas Blummer 2015-02-15 20:51 ` Troy Benjegerdes 1 sibling, 1 reply; 79+ messages in thread From: Peter Todd @ 2015-02-12 8:49 UTC (permalink / raw) To: Tamas Blummer; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 774 bytes --] On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: > On Feb 12, 2015, at 8:45 AM, Peter Todd <pete@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 000000000000000012613986506ef6592952234a6a04946ef946ff0836405ad4 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 8:49 ` Peter Todd @ 2015-02-12 9:01 ` Tamas Blummer 0 siblings, 0 replies; 79+ messages in thread From: Tamas Blummer @ 2015-02-12 9:01 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development [-- Attachment #1.1: Type: text/plain, Size: 244 bytes --] On Feb 12, 2015, at 9:49 AM, Peter Todd <pete@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 [-- Attachment #1.2: Type: text/html, Size: 1326 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 8:27 ` Tamas Blummer 2015-02-12 8:49 ` Peter Todd @ 2015-02-15 20:51 ` Troy Benjegerdes 1 sibling, 0 replies; 79+ messages in thread From: Troy Benjegerdes @ 2015-02-15 20:51 UTC (permalink / raw) To: Tamas Blummer; +Cc: bitcoin-development On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: > > > On Feb 12, 2015, at 9:16 AM, Alex Mizrahi <alex.mizrahi@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. > If a proprietary stack has problems with replace-by-fee then it's probably succeptible to malicious attack because an attacker could just broadcast one transaction to the network and then replace it when they are able to mine a block themselves. > > On Feb 12, 2015, at 8:45 AM, Peter Todd <pete@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 . > ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 7:23 ` Tamas Blummer 2015-02-12 7:45 ` Peter Todd @ 2015-02-12 8:16 ` Alex Mizrahi 1 sibling, 0 replies; 79+ messages in thread From: Alex Mizrahi @ 2015-02-12 8:16 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 447 bytes --] > 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? [-- Attachment #2: Type: text/html, Size: 793 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd 2015-02-12 7:23 ` Tamas Blummer @ 2015-02-12 11:58 ` Mike Hearn 2015-02-12 12:23 ` Natanael ` (5 more replies) 2015-02-12 18:14 ` Tom Harding ` (3 subsequent siblings) 5 siblings, 6 replies; 79+ messages in thread From: Mike Hearn @ 2015-02-12 11:58 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1208 bytes --] 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. [-- Attachment #2: Type: text/html, Size: 1524 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 11:58 ` Mike Hearn @ 2015-02-12 12:23 ` Natanael 2015-02-12 12:49 ` Mike Hearn 2015-02-12 12:52 ` Alex Mizrahi ` (4 subsequent siblings) 5 siblings, 1 reply; 79+ messages in thread From: Natanael @ 2015-02-12 12:23 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 345 bytes --] Den 12 feb 2015 12:58 skrev "Mike Hearn" <mike@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 [-- Attachment #2: Type: text/html, Size: 559 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 12:23 ` Natanael @ 2015-02-12 12:49 ` Mike Hearn 2015-02-12 13:02 ` Natanael 2015-02-12 13:36 ` Oleg Andreev 0 siblings, 2 replies; 79+ messages in thread From: Mike Hearn @ 2015-02-12 12:49 UTC (permalink / raw) To: Natanael; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 677 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 927 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 12:49 ` Mike Hearn @ 2015-02-12 13:02 ` Natanael 2015-02-12 13:44 ` Mike Hearn 2015-02-12 13:36 ` Oleg Andreev 1 sibling, 1 reply; 79+ messages in thread From: Natanael @ 2015-02-12 13:02 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1761 bytes --] Den 12 feb 2015 13:49 skrev "Mike Hearn" <mike@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. [-- Attachment #2: Type: text/html, Size: 2005 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 13:02 ` Natanael @ 2015-02-12 13:44 ` Mike Hearn 2015-02-12 14:36 ` Natanael 0 siblings, 1 reply; 79+ messages in thread From: Mike Hearn @ 2015-02-12 13:44 UTC (permalink / raw) To: Natanael; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1450 bytes --] > > 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? [-- Attachment #2: Type: text/html, Size: 2627 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 13:44 ` Mike Hearn @ 2015-02-12 14:36 ` Natanael 2015-02-12 14:53 ` Mike Hearn 0 siblings, 1 reply; 79+ messages in thread From: Natanael @ 2015-02-12 14:36 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 5821 bytes --] Den 12 feb 2015 14:44 skrev "Mike Hearn" <mike@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 baaaad, 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 against game theory seems unwarranted. The game theorists that are wrong are typically wrong for one of the following reasons; * Their model is wrong. The system, the actors and/or the options available are misunderstood. * The actors don't understand the avaliable incentives and go for trial and error (the most optimal choices for attack and defense are found at random or not at all, and not always adopted until it has stood the test of time). * That option is on the to-do list, just wait. * There's easier and/or more profitable attacks (a variant of #1 if the game theorist said it is certain to happen). You should NOT EVER rely on security-through-opportunity-cost for the attacker or assume you can always keep doing what you always did. Once the bigger targets are gone, you're next. [-- Attachment #2: Type: text/html, Size: 6544 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 14:36 ` Natanael @ 2015-02-12 14:53 ` Mike Hearn 2015-02-12 15:20 ` Natanael 0 siblings, 1 reply; 79+ messages in thread From: Mike Hearn @ 2015-02-12 14:53 UTC (permalink / raw) To: Natanael; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2784 bytes --] > > > 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 baaaad, 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? [-- Attachment #2: Type: text/html, Size: 3817 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 14:53 ` Mike Hearn @ 2015-02-12 15:20 ` Natanael 2015-02-12 15:30 ` Justus Ranvier 0 siblings, 1 reply; 79+ messages in thread From: Natanael @ 2015-02-12 15:20 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4324 bytes --] Den 12 feb 2015 15:53 skrev "Mike Hearn" <mike@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. [-- Attachment #2: Type: text/html, Size: 5104 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 15:20 ` Natanael @ 2015-02-12 15:30 ` Justus Ranvier 0 siblings, 0 replies; 79+ messages in thread From: Justus Ranvier @ 2015-02-12 15:30 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1949 bytes --] -----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----- [-- Attachment #2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 14416 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 12:49 ` Mike Hearn 2015-02-12 13:02 ` Natanael @ 2015-02-12 13:36 ` Oleg Andreev 1 sibling, 0 replies; 79+ messages in thread From: Oleg Andreev @ 2015-02-12 13:36 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3256 bytes --] > On 12 Feb 2015, at 13:49, Mike Hearn <mike@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. [-- Attachment #2: Type: text/html, Size: 4827 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 11:58 ` Mike Hearn 2015-02-12 12:23 ` Natanael @ 2015-02-12 12:52 ` Alex Mizrahi 2015-02-12 13:18 ` Mike Hearn 2015-02-12 12:54 ` Tamas Blummer ` (3 subsequent siblings) 5 siblings, 1 reply; 79+ messages in thread From: Alex Mizrahi @ 2015-02-12 12:52 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2133 bytes --] > 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? [-- Attachment #2: Type: text/html, Size: 2692 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 12:52 ` Alex Mizrahi @ 2015-02-12 13:18 ` Mike Hearn 2015-02-12 13:45 ` Alex Mizrahi ` (3 more replies) 0 siblings, 4 replies; 79+ messages in thread From: Mike Hearn @ 2015-02-12 13:18 UTC (permalink / raw) To: Alex Mizrahi; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1824 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 2679 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 13:18 ` Mike Hearn @ 2015-02-12 13:45 ` Alex Mizrahi 2015-02-12 13:52 ` Mike Hearn 2015-02-12 14:04 ` Tamas Blummer ` (2 subsequent siblings) 3 siblings, 1 reply; 79+ messages in thread From: Alex Mizrahi @ 2015-02-12 13:45 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 606 bytes --] > Yes, like any P2P network Bitcoin cannot work if a sufficiently large > number of miners decide to attack it. > 1. They won't be attacking Bitcoin, they will attack merchants who accept payments with 0 confirmations. This attack has nothing to do with Bitcoin consensus mechanism (as Bitcoin protocol doesn't provide a consensus over mempool contents), thus it is not an attack on Bitcoin. 2. In the example I used, having 10% of hashpower is enough to offer 10% success rate. Would you mind having 1 out of 10 hamburgers for free? If a system can be attacked by a tiny fraction, it is a shitty system. [-- Attachment #2: Type: text/html, Size: 948 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 13:45 ` Alex Mizrahi @ 2015-02-12 13:52 ` Mike Hearn 0 siblings, 0 replies; 79+ messages in thread From: Mike Hearn @ 2015-02-12 13:52 UTC (permalink / raw) To: Alex Mizrahi; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1300 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 1705 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 13:18 ` Mike Hearn 2015-02-12 13:45 ` Alex Mizrahi @ 2015-02-12 14:04 ` Tamas Blummer 2015-02-12 14:16 ` Mike Hearn 2015-02-12 14:32 ` Alex Mizrahi 2015-02-12 19:49 ` Gregory Maxwell 3 siblings, 1 reply; 79+ messages in thread From: Tamas Blummer @ 2015-02-12 14:04 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 369 bytes --] 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 [-- Attachment #1.2: Type: text/html, Size: 1628 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 14:04 ` Tamas Blummer @ 2015-02-12 14:16 ` Mike Hearn 2015-02-12 14:25 ` Tamas Blummer 0 siblings, 1 reply; 79+ messages in thread From: Mike Hearn @ 2015-02-12 14:16 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 763 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 1099 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 14:16 ` Mike Hearn @ 2015-02-12 14:25 ` Tamas Blummer 2015-02-12 23:08 ` Tom Harding 0 siblings, 1 reply; 79+ messages in thread From: Tamas Blummer @ 2015-02-12 14:25 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 610 bytes --] On Feb 12, 2015, at 3:16 PM, Mike Hearn <mike@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 [-- Attachment #1.2: Type: text/html, Size: 2170 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 14:25 ` Tamas Blummer @ 2015-02-12 23:08 ` Tom Harding 0 siblings, 0 replies; 79+ messages in thread From: Tom Harding @ 2015-02-12 23:08 UTC (permalink / raw) To: Tamas Blummer; +Cc: Bitcoin Dev 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. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 13:18 ` Mike Hearn 2015-02-12 13:45 ` Alex Mizrahi 2015-02-12 14:04 ` Tamas Blummer @ 2015-02-12 14:32 ` Alex Mizrahi 2015-02-12 15:15 ` Mike Hearn 2015-02-12 19:49 ` Gregory Maxwell 3 siblings, 1 reply; 79+ messages in thread From: Alex Mizrahi @ 2015-02-12 14:32 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2012 bytes --] > "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. [-- Attachment #2: Type: text/html, Size: 2708 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 14:32 ` Alex Mizrahi @ 2015-02-12 15:15 ` Mike Hearn 2015-02-12 15:32 ` Natanael 2015-02-12 16:57 ` Btc Drak 0 siblings, 2 replies; 79+ messages in thread From: Mike Hearn @ 2015-02-12 15:15 UTC (permalink / raw) To: Alex Mizrahi; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3353 bytes --] > > 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". [-- Attachment #2: Type: text/html, Size: 4012 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 15:15 ` Mike Hearn @ 2015-02-12 15:32 ` Natanael 2015-02-12 15:42 ` Mike Hearn 2015-02-12 16:57 ` Btc Drak 1 sibling, 1 reply; 79+ messages in thread From: Natanael @ 2015-02-12 15:32 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1845 bytes --] Den 12 feb 2015 16:15 skrev "Mike Hearn" <mike@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. [-- Attachment #2: Type: text/html, Size: 2101 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 15:32 ` Natanael @ 2015-02-12 15:42 ` Mike Hearn 2015-02-12 15:54 ` Natanael 0 siblings, 1 reply; 79+ messages in thread From: Mike Hearn @ 2015-02-12 15:42 UTC (permalink / raw) To: Natanael; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 878 bytes --] > > 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. [-- Attachment #2: Type: text/html, Size: 1346 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 15:42 ` Mike Hearn @ 2015-02-12 15:54 ` Natanael 0 siblings, 0 replies; 79+ messages in thread From: Natanael @ 2015-02-12 15:54 UTC (permalink / raw) To: Mike Hearn; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 933 bytes --] Den 12 feb 2015 16:42 skrev "Mike Hearn" <mike@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. [-- Attachment #2: Type: text/html, Size: 1096 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 15:15 ` Mike Hearn 2015-02-12 15:32 ` Natanael @ 2015-02-12 16:57 ` Btc Drak 2015-02-12 17:24 ` Oleg Andreev 1 sibling, 1 reply; 79+ messages in thread From: Btc Drak @ 2015-02-12 16:57 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2767 bytes --] On Thu, Feb 12, 2015 at 3:15 PM, Mike Hearn <mike@plan99•net> wrote: > 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. > 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. [-- Attachment #2: Type: text/html, Size: 3529 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 16:57 ` Btc Drak @ 2015-02-12 17:24 ` Oleg Andreev 2015-02-12 18:11 ` Justus Ranvier 0 siblings, 1 reply; 79+ messages in thread From: Oleg Andreev @ 2015-02-12 17:24 UTC (permalink / raw) To: Btc Drak; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2010 bytes --] > 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. [-- Attachment #2: Type: text/html, Size: 3538 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 17:24 ` Oleg Andreev @ 2015-02-12 18:11 ` Justus Ranvier 2015-02-12 18:37 ` Allen Piscitello 0 siblings, 1 reply; 79+ messages in thread From: Justus Ranvier @ 2015-02-12 18:11 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3595 bytes --] -----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----- [-- Attachment #2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 14416 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 18:11 ` Justus Ranvier @ 2015-02-12 18:37 ` Allen Piscitello 2015-02-12 19:15 ` Alan Reiner 0 siblings, 1 reply; 79+ messages in thread From: Allen Piscitello @ 2015-02-12 18:37 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 4705 bytes --] 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 <justusranvier@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 > > [-- Attachment #2: Type: text/html, Size: 5856 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 18:37 ` Allen Piscitello @ 2015-02-12 19:15 ` Alan Reiner 2015-02-12 19:34 ` Justus Ranvier 2015-02-12 20:06 ` Peter Todd 0 siblings, 2 replies; 79+ messages in thread From: Alan Reiner @ 2015-02-12 19:15 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 6724 bytes --] 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 <justusranvier@riseup•net <mailto:justusranvier@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 spend or forcing people into > privacy/security sacrifices. > > > > ------------------------------------------------------------------------------ > 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 <mailto: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 [-- Attachment #2: Type: text/html, Size: 9193 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:15 ` Alan Reiner @ 2015-02-12 19:34 ` Justus Ranvier 2015-02-12 19:45 ` Peter Todd 2015-02-12 19:47 ` Allen Piscitello 2015-02-12 20:06 ` Peter Todd 1 sibling, 2 replies; 79+ messages in thread From: Justus Ranvier @ 2015-02-12 19:34 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2797 bytes --] -----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----- [-- Attachment #2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 14416 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:34 ` Justus Ranvier @ 2015-02-12 19:45 ` Peter Todd 2015-02-12 19:49 ` Justus Ranvier 2015-02-12 19:47 ` Allen Piscitello 1 sibling, 1 reply; 79+ messages in thread From: Peter Todd @ 2015-02-12 19:45 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1019 bytes --] On Thu, Feb 12, 2015 at 07:34:22PM +0000, 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 00000000000000000a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:45 ` Peter Todd @ 2015-02-12 19:49 ` Justus Ranvier 0 siblings, 0 replies; 79+ messages in thread From: Justus Ranvier @ 2015-02-12 19:49 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1530 bytes --] -----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----- [-- Attachment #2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 14416 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:34 ` Justus Ranvier 2015-02-12 19:45 ` Peter Todd @ 2015-02-12 19:47 ` Allen Piscitello 2015-02-12 19:52 ` Justus Ranvier 1 sibling, 1 reply; 79+ messages in thread From: Allen Piscitello @ 2015-02-12 19:47 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 3976 bytes --] 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 <justusranvier@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 > > [-- Attachment #2: Type: text/html, Size: 4915 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:47 ` Allen Piscitello @ 2015-02-12 19:52 ` Justus Ranvier 2015-02-12 20:02 ` Natanael 2015-02-12 20:36 ` Allen Piscitello 0 siblings, 2 replies; 79+ messages in thread From: Justus Ranvier @ 2015-02-12 19:52 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1527 bytes --] -----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----- [-- Attachment #2: 0xEAD9E623.asc --] [-- Type: application/pgp-keys, Size: 14416 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:52 ` Justus Ranvier @ 2015-02-12 20:02 ` Natanael 2015-02-12 20:36 ` Allen Piscitello 1 sibling, 0 replies; 79+ messages in thread From: Natanael @ 2015-02-12 20:02 UTC (permalink / raw) To: Justus Ranvier; +Cc: bitcoin-development On Thu, Feb 12, 2015 at 8:52 PM, Justus Ranvier <justusranvier@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. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:52 ` Justus Ranvier 2015-02-12 20:02 ` Natanael @ 2015-02-12 20:36 ` Allen Piscitello 2015-02-14 14:47 ` Ross Nicoll 1 sibling, 1 reply; 79+ messages in thread From: Allen Piscitello @ 2015-02-12 20:36 UTC (permalink / raw) To: Justus Ranvier; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 2796 bytes --] You keep making moral judgements. Reality is, if you live in a world with arsonists, you need to have a building that won't catch on fire, or has fire extinguishers in place. Do not depend on arsonists ignoring you forever as your security model. Penetration testing to know what weaknesses exist, what limitations exist, and what can be improved is essential. Keeping your head in the sand and hoping people choose to do the right thing only ends one way. On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier <justusranvier@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. > > - -- > 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----- > > > ------------------------------------------------------------------------------ > 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 > > [-- Attachment #2: Type: text/html, Size: 3633 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 20:36 ` Allen Piscitello @ 2015-02-14 14:47 ` Ross Nicoll 0 siblings, 0 replies; 79+ messages in thread From: Ross Nicoll @ 2015-02-14 14:47 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 3803 bytes --] -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Arriving slightly late to the discussion, apologies. Personally I wouldn't have written that patch, but I know development of hostile patches happens out of sight, and if it can be written, we have to presume it will be written eventually. I'd have preferred a patch that only replaced non-final txes, which is the use-case I have for transaction replacement, but that's easy to add back in. I'm certainly not terribly convinced of the security of vanilla zero-confirmation transactions myself, for reasons including but not limited to this case. I also think it's important to understand that people do make irrational decisions, and trusting network security on everyone behaving perfectly rationally is not a workable model either. TLDR; me too Ross On 12/02/15 20:36, Allen Piscitello wrote: > You keep making moral judgements. Reality is, if you live in a world with > arsonists, you need to have a building that won't catch on fire, or has > fire extinguishers in place. Do not depend on arsonists ignoring you > forever as your security model. Penetration testing to know what > weaknesses exist, what limitations exist, and what can be improved is > essential. Keeping your head in the sand and hoping people choose to do > the right thing only ends one way. > > On Thu, Feb 12, 2015 at 1:52 PM, Justus Ranvier <justusranvier@riseup•net> > wrote: > > 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. > >> >> >> ------------------------------------------------------------------------------ >> 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQEcBAEBAgAGBQJU31/yAAoJEJFC5fflM8475YIIAI7nxgxUdkKiMePMqtvPOi25 U+WCxjvIK0ZRTAV30POC7fKLT2mK0gPusSS7LtNJpPKvpC98VcSD5HWE49K80Yo9 9+QI7X7xBau1jjLo+27uOex0bJ6JwP1DSMpC12AQbMmi4FnyG+M5FMkr5/OnSxeF cd4lT2UF7yTJPRy0+A9LwertL5Sv1yeOJJ9jtWuXgixapmHN+1Zm2VkGnur55V64 vnonlixlUMwnZNxDVoRhjTWm1P/lmCejvmvTRvcBomUlAEgRQF4TtF4YMBYXS97S 5WYrxOHLgTfTWr3FJuOnd+CVBRgZGw3u30ktaSErelyMG19lJOusBPdHTQFkV30= =eWPj -----END PGP SIGNATURE----- [-- Attachment #2: Type: text/html, Size: 6003 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:15 ` Alan Reiner 2015-02-12 19:34 ` Justus Ranvier @ 2015-02-12 20:06 ` Peter Todd 1 sibling, 0 replies; 79+ messages in thread From: Peter Todd @ 2015-02-12 20:06 UTC (permalink / raw) To: Alan Reiner; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1467 bytes --] 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 00000000000000000a1fb2fd17f5d8735a8a0e7aae841c95a12e82b934c4ac92 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 13:18 ` Mike Hearn ` (2 preceding siblings ...) 2015-02-12 14:32 ` Alex Mizrahi @ 2015-02-12 19:49 ` Gregory Maxwell 2015-02-12 20:18 ` Peter Todd 2015-02-13 11:34 ` Mike Hearn 3 siblings, 2 replies; 79+ messages in thread From: Gregory Maxwell @ 2015-02-12 19:49 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn <mike@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 <jgarzik@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.mizrahi@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. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:49 ` Gregory Maxwell @ 2015-02-12 20:18 ` Peter Todd 2015-02-13 11:34 ` Mike Hearn 1 sibling, 0 replies; 79+ messages in thread From: Peter Todd @ 2015-02-12 20:18 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 1161 bytes --] On Thu, Feb 12, 2015 at 07:49:29PM +0000, 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 00000000000000000a16bcc766361414571a5f961698acc46c27bd79c26ac15c [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 19:49 ` Gregory Maxwell 2015-02-12 20:18 ` Peter Todd @ 2015-02-13 11:34 ` Mike Hearn 1 sibling, 0 replies; 79+ messages in thread From: Mike Hearn @ 2015-02-13 11:34 UTC (permalink / raw) To: Gregory Maxwell; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 698 bytes --] > > > 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) > Hmm. I think this is a disagreement over the term massive. I was meaning we don't see double spending like we see carding fraud in the traditional online payments world. We can talk about Finney attacks by linking to specific discussions of specific events, because they are very rare, which is why merchants generally ignore the possibility. I didn't mean the numeric value of lost coins added up so far. [-- Attachment #2: Type: text/html, Size: 1056 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 11:58 ` Mike Hearn 2015-02-12 12:23 ` Natanael 2015-02-12 12:52 ` Alex Mizrahi @ 2015-02-12 12:54 ` Tamas Blummer 2015-02-12 14:42 ` Alex Mizrahi ` (2 subsequent siblings) 5 siblings, 0 replies; 79+ messages in thread From: Tamas Blummer @ 2015-02-12 12:54 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev [-- Attachment #1.1: Type: text/plain, Size: 318 bytes --] 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 [-- Attachment #1.2: Type: text/html, Size: 989 bytes --] [-- Attachment #2: Message signed with OpenPGP using GPGMail --] [-- Type: application/pgp-signature, Size: 496 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 11:58 ` Mike Hearn ` (2 preceding siblings ...) 2015-02-12 12:54 ` Tamas Blummer @ 2015-02-12 14:42 ` Alex Mizrahi 2015-02-12 15:27 ` Jeff Garzik 2015-02-12 16:15 ` Lawrence Nahum 5 siblings, 0 replies; 79+ messages in thread From: Alex Mizrahi @ 2015-02-12 14:42 UTC (permalink / raw) To: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 610 bytes --] > 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. [-- Attachment #2: Type: text/html, Size: 963 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 11:58 ` Mike Hearn ` (3 preceding siblings ...) 2015-02-12 14:42 ` Alex Mizrahi @ 2015-02-12 15:27 ` Jeff Garzik 2015-02-15 21:25 ` Troy Benjegerdes 2015-02-12 16:15 ` Lawrence Nahum 5 siblings, 1 reply; 79+ messages in thread From: Jeff Garzik @ 2015-02-12 15:27 UTC (permalink / raw) To: Mike Hearn; +Cc: Bitcoin Dev 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 <mike@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/ ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 15:27 ` Jeff Garzik @ 2015-02-15 21:25 ` Troy Benjegerdes 2015-02-15 21:40 ` Adam Gibson 0 siblings, 1 reply; 79+ messages in thread From: Troy Benjegerdes @ 2015-02-15 21:25 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev On Thu, Feb 12, 2015 at 10:27:53AM -0500, Jeff Garzik wrote: > 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. I find Peter's proposal relatively mild. I'd prefer that instead of exchanges going bankrupt, that there be direct blockchain support for key revocation and 'burning' stolen coins, and an economic ecosystem that supports insurance underwriters that pay out when someone inevitably gets hacked. This would definitely be 'scorched earth' at one level, but I think would make for a far more transparent and friendly system. > 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. Most money/payment systems include some method to reverse or undo payments made in error. In these systems, the longer settlement times you mention below are a feature, not a bug, and give more time for a human to react to errors and system failures. > 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. I see a world in which we have many blockchains, along with not-quite blockchain things like ripple that approximate that vision you have of 'credits'. But we cannot have one chain to rule them all, for there are inherent engineering trade-offs that one chain can never resolve. There appear to be some things we will never come to a consensus on, such as transaction reversibility, or what the optimal money supply algorithm is. However we might learn a great deal from sharing code and ideas. So in that line, see my thoughts on reversibility [3][4] > 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. I'll say the same about not stuffing everthing on top of the same blockchain. We might very well have coffee shops that take coffecoin. But Bitcoin will never be able to scale out horizontally like altcoins can. > > [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 [3] https://bitbucket.org/tmagik/catoshi/issue/24 [4] https://bitbucket.org/tmagik/catoshi/issue/27 > > On Thu, Feb 12, 2015 at 6:58 AM, Mike Hearn <mike@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 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 -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-15 21:25 ` Troy Benjegerdes @ 2015-02-15 21:40 ` Adam Gibson 2015-02-19 8:56 ` Troy Benjegerdes 0 siblings, 1 reply; 79+ messages in thread From: Adam Gibson @ 2015-02-15 21:40 UTC (permalink / raw) To: bitcoin-development On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: > > Most money/payment systems include some method to reverse or undo > payments made in error. In these systems, the longer settlement > times you mention below are a feature, not a bug, and give more > time for a human to react to errors and system failures. > Settlement has to be final somewhere. That is the whole point of it. Transfer costs in current electronic payment systems are a direct consequence of their non-finality. That's the point Satoshi was making in the introduction to the whitepaper: "With the possibility of reversal, the need for trust spreads". There is nothing wrong with having reversible mechanisms built on top of Bitcoin, and indeed it makes sense for most activity to happen at those higher layers. It's easy to build things that way, but impossible to build them the other way: you can't build a non-reversible layer on top of a reversible layer. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-15 21:40 ` Adam Gibson @ 2015-02-19 8:56 ` Troy Benjegerdes 2015-02-21 19:09 ` Jorge Timón 0 siblings, 1 reply; 79+ messages in thread From: Troy Benjegerdes @ 2015-02-19 8:56 UTC (permalink / raw) To: Adam Gibson; +Cc: bitcoin-development On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: > > > On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: > > > > Most money/payment systems include some method to reverse or undo > > payments made in error. In these systems, the longer settlement > > times you mention below are a feature, not a bug, and give more > > time for a human to react to errors and system failures. > > > > Settlement has to be final somewhere. That is the whole point of it. > Transfer costs in current electronic payment systems are a direct > consequence of their non-finality. That's the point Satoshi was making > in the introduction to the whitepaper: "With the possibility of > reversal, the need for trust spreads". The problem with that statement is I trust a merchant that I went into a store and made a payment with personally more than I trust the firmware on my hard drive [1]. The attack surface of devices in your computer is huge. A motivated attacker just needs to get an intern into a company that makes some kind of component or system that's in your computer, cloud server, hardware wallet, or what have you that has firmware capable of reading your private keys. With the possibility of mass trojaned hardware, if we are going to trust the system, it must somehow allow reversal through a human-in-the-loop. > There is nothing wrong with having reversible mechanisms built on top > of Bitcoin, and indeed it makes sense for most activity to happen at > those higher layers. It's easy to build things that way, but > impossible to build them the other way: you can't build a > non-reversible layer on top of a reversible layer. We built 'reliable' TCP on top of unreliable ethernet networks. My experience with networking was if you tried to guarantee message delivery at the lowest level, the system got exceedingly complicated, expensive, and brittle. Most applications, in particular paying someone you already trust, are quite happy running on reversible systems, and in some cases more reliable and lower risk. (carrying non-reversible cash is generally considered risky) The problem is that if the base currency is assumed to be non-reversible, then it's brittle and becomes 'too big to fail'. Where the blockchain improves on everything else is in transparency. If you reverse transactions a lot, it will be obvious from an analysis. I would much rather deal with a known, predictable, and relatively continous transaction reversal rate (percentage) than have to deal with sudden failures where some anonymous bad actor makes off with a fortune. We already have zero-conf double-spend transaction reversal, why not explicitly extend that a little in a way that senders and receivers have a choice to use it, or not? [1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-19 8:56 ` Troy Benjegerdes @ 2015-02-21 19:09 ` Jorge Timón 2015-02-21 20:30 ` Mark Friedenbach 0 siblings, 1 reply; 79+ messages in thread From: Jorge Timón @ 2015-02-21 19:09 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: Bitcoin Dev I agree "scorched hearth" is a really bad name for the 0 conf protocol based on game theory. I would have preferred "stag hunt" since that's basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) but I like the protocol and I think it would be interesting to integrate it in the payment protocol. Even if that protocol didn't existed or didn't worked, replace-by-fee is purely part of a node's policy, not part of consensus. From the whitepaper, 0 conf transactions being secure by the good will of miners was never an assumption, and it is clear to me that the system cannot provide those guaranties based on such a weak scheme. I believe thinking otherwise is naive. As to consider non-standard policies "an attack to bitcoin" because "that's not how bitcoin used to work", then I guess minimum relay fee policies can also be considered "an attack to bitcoin" on the same grounds. Lastly, "first-seen-wins" was just a simple policy to bootstrap the system, but I expect that most nodes will eventually move to policies that are economically rational for miners such as replace-by-fee. Not only I disagree this will be "the end of bitcoin" or "will push the price of the btc miners are mining down", I believe it will be something good for bitcoin. Since this is apparently controversial I don't want to push for replace-by-fee to become the new standard policy (something that would make sense to me). But once the policy code is sufficiently modular as to support several policies I would like bitcoin core to have a CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no policy checks at all). One step at a time I guess... On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed•org> wrote: > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: >> >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: >> > >> > Most money/payment systems include some method to reverse or undo >> > payments made in error. In these systems, the longer settlement >> > times you mention below are a feature, not a bug, and give more >> > time for a human to react to errors and system failures. >> > >> >> Settlement has to be final somewhere. That is the whole point of it. >> Transfer costs in current electronic payment systems are a direct >> consequence of their non-finality. That's the point Satoshi was making >> in the introduction to the whitepaper: "With the possibility of >> reversal, the need for trust spreads". > > The problem with that statement is I trust a merchant that I went into > a store and made a payment with personally more than I trust the firmware > on my hard drive [1]. > > The attack surface of devices in your computer is huge. A motivated attacker > just needs to get an intern into a company that makes some kind of component > or system that's in your computer, cloud server, hardware wallet, or what > have you that has firmware capable of reading your private keys. > > With the possibility of mass trojaned hardware, if we are going to trust > the system, it must somehow allow reversal through a human-in-the-loop. > >> There is nothing wrong with having reversible mechanisms built on top >> of Bitcoin, and indeed it makes sense for most activity to happen at >> those higher layers. It's easy to build things that way, but >> impossible to build them the other way: you can't build a >> non-reversible layer on top of a reversible layer. > > We built 'reliable' TCP on top of unreliable ethernet networks. My experience > with networking was if you tried to guarantee message delivery at the lowest > level, the system got exceedingly complicated, expensive, and brittle. > > Most applications, in particular paying someone you already trust, are quite > happy running on reversible systems, and in some cases more reliable and > lower risk. (carrying non-reversible cash is generally considered risky) > > The problem is that if the base currency is assumed to be non-reversible, > then it's brittle and becomes 'too big to fail'. > > Where the blockchain improves on everything else is in transparency. If you > reverse transactions a lot, it will be obvious from an analysis. I would much > rather deal with a known, predictable, and relatively continous transaction > reversal rate (percentage) than have to deal with sudden failures where > some anonymous bad actor makes off with a fortune. > > We already have zero-conf double-spend transaction reversal, why not explicitly > extend that a little in a way that senders and receivers have a choice to > use it, or not? > > > [1] http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-21 19:09 ` Jorge Timón @ 2015-02-21 20:30 ` Mark Friedenbach 2015-02-21 22:47 ` Jeff Garzik 0 siblings, 1 reply; 79+ messages in thread From: Mark Friedenbach @ 2015-02-21 20:30 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Development [-- Attachment #1: Type: text/plain, Size: 6509 bytes --] Thank you Jorge for the contribution of the Stag Hunt terminology. It is much better than a politically charged "scorched earth". On Feb 21, 2015 11:10 AM, "Jorge Timón" <jtimon@jtimon•cc> wrote: > I agree "scorched hearth" is a really bad name for the 0 conf protocol > based on game theory. I would have preferred "stag hunt" since that's > basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) > but I like the protocol and I think it would be interesting to > integrate it in the payment protocol. > Even if that protocol didn't existed or didn't worked, replace-by-fee > is purely part of a node's policy, not part of consensus. > >From the whitepaper, 0 conf transactions being secure by the good will > of miners was never an assumption, and it is clear to me that the > system cannot provide those guaranties based on such a weak scheme. I > believe thinking otherwise is naive. > As to consider non-standard policies "an attack to bitcoin" because > "that's not how bitcoin used to work", then I guess minimum relay fee > policies can also be considered "an attack to bitcoin" on the same > grounds. > Lastly, "first-seen-wins" was just a simple policy to bootstrap the > system, but I expect that most nodes will eventually move to policies > that are economically rational for miners such as replace-by-fee. > Not only I disagree this will be "the end of bitcoin" or "will push > the price of the btc miners are mining down", I believe it will be > something good for bitcoin. > Since this is apparently controversial I don't want to push for > replace-by-fee to become the new standard policy (something that would > make sense to me). But once the policy code is sufficiently modular as > to support several policies I would like bitcoin core to have a > CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no > policy checks at all). > One step at a time I guess... > > > On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed•org> wrote: > > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: > >> > >> > >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: > >> > > >> > Most money/payment systems include some method to reverse or undo > >> > payments made in error. In these systems, the longer settlement > >> > times you mention below are a feature, not a bug, and give more > >> > time for a human to react to errors and system failures. > >> > > >> > >> Settlement has to be final somewhere. That is the whole point of it. > >> Transfer costs in current electronic payment systems are a direct > >> consequence of their non-finality. That's the point Satoshi was making > >> in the introduction to the whitepaper: "With the possibility of > >> reversal, the need for trust spreads". > > > > The problem with that statement is I trust a merchant that I went into > > a store and made a payment with personally more than I trust the firmware > > on my hard drive [1]. > > > > The attack surface of devices in your computer is huge. A motivated > attacker > > just needs to get an intern into a company that makes some kind of > component > > or system that's in your computer, cloud server, hardware wallet, or what > > have you that has firmware capable of reading your private keys. > > > > With the possibility of mass trojaned hardware, if we are going to trust > > the system, it must somehow allow reversal through a human-in-the-loop. > > > >> There is nothing wrong with having reversible mechanisms built on top > >> of Bitcoin, and indeed it makes sense for most activity to happen at > >> those higher layers. It's easy to build things that way, but > >> impossible to build them the other way: you can't build a > >> non-reversible layer on top of a reversible layer. > > > > We built 'reliable' TCP on top of unreliable ethernet networks. My > experience > > with networking was if you tried to guarantee message delivery at the > lowest > > level, the system got exceedingly complicated, expensive, and brittle. > > > > Most applications, in particular paying someone you already trust, are > quite > > happy running on reversible systems, and in some cases more reliable and > > lower risk. (carrying non-reversible cash is generally considered risky) > > > > The problem is that if the base currency is assumed to be non-reversible, > > then it's brittle and becomes 'too big to fail'. > > > > Where the blockchain improves on everything else is in transparency. If > you > > reverse transactions a lot, it will be obvious from an analysis. I would > much > > rather deal with a known, predictable, and relatively continous > transaction > > reversal rate (percentage) than have to deal with sudden failures where > > some anonymous bad actor makes off with a fortune. > > > > We already have zero-conf double-spend transaction reversal, why not > explicitly > > extend that a little in a way that senders and receivers have a choice to > > use it, or not? > > > > > > [1] > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 8120 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-21 20:30 ` Mark Friedenbach @ 2015-02-21 22:47 ` Jeff Garzik 2015-02-22 1:15 ` Peter Todd ` (2 more replies) 0 siblings, 3 replies; 79+ messages in thread From: Jeff Garzik @ 2015-02-21 22:47 UTC (permalink / raw) To: Mark Friedenbach, Jorge Timón; +Cc: Bitcoin Development "scorched earth" refers to the _real world_ impact such policies would have on present-day 0-conf usage within the bitcoin community. All payment processors AFAIK process transactions through some scoring system, then accept 0-conf transactions for payments. This isn't some theoretical exercise. Like it or not many use insecure 0-conf transactions for rapid payments. Deploying something that makes 0-conf transactions unusable would have a wide, negative impact on present day bitcoin payments, thus "scorched earth" Without adequate decentralized solutions for instant payments, deploying replace-by-fee widely would simply push instant transactions even more into the realm of centralized, walled-garden services. On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach <mark@friedenbach•org> wrote: > Thank you Jorge for the contribution of the Stag Hunt terminology. It is > much better than a politically charged "scorched earth". > > On Feb 21, 2015 11:10 AM, "Jorge Timón" <jtimon@jtimon•cc> wrote: >> >> I agree "scorched hearth" is a really bad name for the 0 conf protocol >> based on game theory. I would have preferred "stag hunt" since that's >> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) >> but I like the protocol and I think it would be interesting to >> integrate it in the payment protocol. >> Even if that protocol didn't existed or didn't worked, replace-by-fee >> is purely part of a node's policy, not part of consensus. >> >From the whitepaper, 0 conf transactions being secure by the good will >> of miners was never an assumption, and it is clear to me that the >> system cannot provide those guaranties based on such a weak scheme. I >> believe thinking otherwise is naive. >> As to consider non-standard policies "an attack to bitcoin" because >> "that's not how bitcoin used to work", then I guess minimum relay fee >> policies can also be considered "an attack to bitcoin" on the same >> grounds. >> Lastly, "first-seen-wins" was just a simple policy to bootstrap the >> system, but I expect that most nodes will eventually move to policies >> that are economically rational for miners such as replace-by-fee. >> Not only I disagree this will be "the end of bitcoin" or "will push >> the price of the btc miners are mining down", I believe it will be >> something good for bitcoin. >> Since this is apparently controversial I don't want to push for >> replace-by-fee to become the new standard policy (something that would >> make sense to me). But once the policy code is sufficiently modular as >> to support several policies I would like bitcoin core to have a >> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no >> policy checks at all). >> One step at a time I guess... >> >> >> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed•org> wrote: >> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: >> >> >> >> >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: >> >> > >> >> > Most money/payment systems include some method to reverse or undo >> >> > payments made in error. In these systems, the longer settlement >> >> > times you mention below are a feature, not a bug, and give more >> >> > time for a human to react to errors and system failures. >> >> > >> >> >> >> Settlement has to be final somewhere. That is the whole point of it. >> >> Transfer costs in current electronic payment systems are a direct >> >> consequence of their non-finality. That's the point Satoshi was making >> >> in the introduction to the whitepaper: "With the possibility of >> >> reversal, the need for trust spreads". >> > >> > The problem with that statement is I trust a merchant that I went into >> > a store and made a payment with personally more than I trust the >> > firmware >> > on my hard drive [1]. >> > >> > The attack surface of devices in your computer is huge. A motivated >> > attacker >> > just needs to get an intern into a company that makes some kind of >> > component >> > or system that's in your computer, cloud server, hardware wallet, or >> > what >> > have you that has firmware capable of reading your private keys. >> > >> > With the possibility of mass trojaned hardware, if we are going to trust >> > the system, it must somehow allow reversal through a human-in-the-loop. >> > >> >> There is nothing wrong with having reversible mechanisms built on top >> >> of Bitcoin, and indeed it makes sense for most activity to happen at >> >> those higher layers. It's easy to build things that way, but >> >> impossible to build them the other way: you can't build a >> >> non-reversible layer on top of a reversible layer. >> > >> > We built 'reliable' TCP on top of unreliable ethernet networks. My >> > experience >> > with networking was if you tried to guarantee message delivery at the >> > lowest >> > level, the system got exceedingly complicated, expensive, and brittle. >> > >> > Most applications, in particular paying someone you already trust, are >> > quite >> > happy running on reversible systems, and in some cases more reliable and >> > lower risk. (carrying non-reversible cash is generally considered risky) >> > >> > The problem is that if the base currency is assumed to be >> > non-reversible, >> > then it's brittle and becomes 'too big to fail'. >> > >> > Where the blockchain improves on everything else is in transparency. If >> > you >> > reverse transactions a lot, it will be obvious from an analysis. I would >> > much >> > rather deal with a known, predictable, and relatively continous >> > transaction >> > reversal rate (percentage) than have to deal with sudden failures where >> > some anonymous bad actor makes off with a fortune. >> > >> > We already have zero-conf double-spend transaction reversal, why not >> > explicitly >> > extend that a little in a way that senders and receivers have a choice >> > to >> > use it, or not? >> > >> > >> > [1] >> > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 >> > >> > >> > ------------------------------------------------------------------------------ >> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> > with Interactivity, Sharing, Native Excel Exports, App Integration & >> > more >> > Get technology previously reserved for billion-dollar corporations, FREE >> > >> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk >> > _______________________________________________ >> > Bitcoin-development mailing list >> > Bitcoin-development@lists•sourceforge.net >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > _______________________________________________ > 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/ ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-21 22:47 ` Jeff Garzik @ 2015-02-22 1:15 ` Peter Todd 2015-02-22 3:25 ` Jorge Timón 2015-03-01 17:44 ` Troy Benjegerdes 2 siblings, 0 replies; 79+ messages in thread From: Peter Todd @ 2015-02-22 1:15 UTC (permalink / raw) To: Jeff Garzik, Mark Friedenbach, Jorge Timón; +Cc: Bitcoin Development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik <jgarzik@bitpay•com> wrote: >"scorched earth" refers to the _real world_ impact such policies would >have on present-day 0-conf usage within the bitcoin community. I think you guys are reading too much into the name... Replace-by-fee is called "replace-by-fee" because it considers whether to replace or not based on fee; the idea came about in an discussion about replacement based on nSequence. I forget whether it was myself or John Dillon who came up with the name "scorched earth", but it just refers to the game theory behind the *specific* idea of the receiver combating a zeroconf double-spend by sending all the funds to fees. Scorched earth as in "You're trying to defraud me, so I'm not going yo play this game or negotiate, I'm just going to immediately do what is most likely to make you lose the maximum amount of money to punish you for your vandalism." >All payment processors AFAIK process transactions through some scoring >system, then accept 0-conf transactions for payments. > >This isn't some theoretical exercise. Like it or not many use >insecure 0-conf transactions for rapid payments. Deploying something >that makes 0-conf transactions unusable would have a wide, negative >impact on present day bitcoin payments, thus "scorched earth" I'm not so convinced, precisely because we've seen zeroconf fail in pretty bad ways; the people most vulnerable to losses have generally changed the way they operate. (e.g. ATM's that no longer rely on zeroconf security, instead waiting for confirmations, installing cameras, etc.) My #1 concern right now is person-to-person trading, and people doing that tend to wait for confirmations or otherwise protect themselves. (e.g. reputation systems) >Without adequate decentralized solutions for instant payments, >deploying replace-by-fee widely would simply push instant transactions >even more into the realm of centralized, walled-garden services. Agreed. Deploying it has been something I've made into a long, drawn out, protracted process for precisely that reason. OTOH I sometimes wonder if I've gone too far with that - the services that themselves try to guarantee zeroconf right now through metrics are themselves highly centralised, and there's a big risk of them driving mining centralisation itself when they fail. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6S2N AAoJEMCF8hzn9LncrFUH/1xhuPhYJnjTCxhpv2h5ZJOT3wLsrU1oEDmD5fWy/4wG 7ppr3EiHNX7nB42fgeSGZF8fW1VuBjivJa9ra3IvFysFfaD40Kyre2FTnN03+vTC Upa5ykPzOMqZIHkSf8N1xMbz4SXHHPWu8wPMzj/QGvUpllNiOWn/6Vooqrcp7f6Y NJFykSq+vDNMOUWCiJG8hhoKiOcZhTH0Aj9qPcGs9WhgsF7wDAX7pg6iO6Y5qmt5 LdFcut2caL6mIxpExm0F9V+lyeam/3gvAU3eecHY77KOxRxFTO1xfQXEJFTWN92h +M9BXQZ1UifjTZWMzK0kp3SRJuVSXg4KOAapQFBLTzU= =3Mmw -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-21 22:47 ` Jeff Garzik 2015-02-22 1:15 ` Peter Todd @ 2015-02-22 3:25 ` Jorge Timón 2015-02-22 4:06 ` Jeff Garzik 2015-03-01 17:44 ` Troy Benjegerdes 2 siblings, 1 reply; 79+ messages in thread From: Jorge Timón @ 2015-02-22 3:25 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Development On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: > "scorched earth" refers to the _real world_ impact such policies would > have on present-day 0-conf usage within the bitcoin community. When I posted this: http://sourceforge.net/p/bitcoin/mailman/message/32263765/ Peter Todd clarified that the concept was referred to as "scorched earth" http://sourceforge.net/p/bitcoin/mailman/message/32264039/ Like I said I don't like the name and would prefer "stag hunting" which is more formal and precise. Some people seem to use the same term for "the potential undesirable consequences of widely deployed replace-by-fee policies". I'm not sure that concept deserves its own term. > All payment processors AFAIK process transactions through some scoring > system, then accept 0-conf transactions for payments. > > This isn't some theoretical exercise. Like it or not many use > insecure 0-conf transactions for rapid payments. Deploying something > that makes 0-conf transactions unusable would have a wide, negative > impact on present day bitcoin payments, thus "scorched earth" And maybe by maintaining first seen policies we're harming the system in the long term by encouraging people to widely deploy systems based on extremely weak assumptions. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 3:25 ` Jorge Timón @ 2015-02-22 4:06 ` Jeff Garzik 2015-02-22 11:41 ` Eric Lombrozo 0 siblings, 1 reply; 79+ messages in thread From: Jeff Garzik @ 2015-02-22 4:06 UTC (permalink / raw) To: Jorge Timón; +Cc: Bitcoin Development On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon•cc> wrote: > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com> wrote: >> This isn't some theoretical exercise. Like it or not many use >> insecure 0-conf transactions for rapid payments. Deploying something >> that makes 0-conf transactions unusable would have a wide, negative >> impact on present day bitcoin payments, thus "scorched earth" > And maybe by maintaining first seen policies we're harming the system > in the long term by encouraging people to widely deploy systems based > on extremely weak assumptions. Lacking a coded, reviewed alternative, that's only a platitude. Widely used 0-conf payments are where we're at today. Simply ceasing the "maintaining [of] first seen policies" alone is simply not a realistic option. The negative impact to today's userbase would be huge. Instant payments need a security upgrade, yes. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 4:06 ` Jeff Garzik @ 2015-02-22 11:41 ` Eric Lombrozo 2015-02-22 12:06 ` Eric Lombrozo 0 siblings, 1 reply; 79+ messages in thread From: Eric Lombrozo @ 2015-02-22 11:41 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3080 bytes --] It seems to me we're confusing two completely different motivations for double-spending. One is the ability to replace a fee, the other is the ability to replace outputs. If the double-spend were to merely add or remove inputs (but keep at least one input in common, of course), it seems fairly safe to assume it's the former, a genuine fee replacement. Even allowing for things like coinjoin, none of the payees would really care either way. Conversely, if at least one of the inputs were kept but none of the outputs were, we can be confident it's the the latter. It is possible to build a wallet that always does the former when doing fee replacement by using another transaction to create an output with exactly the additional desired fee. If we can clearly distinguish these two cases then the fee replacement case can be handled by relaying both and letting miners pick one or the other while the output replacement case could be handled by rewarding everything to a miner (essentially all outputs are voided...made unredeemable...and all inputs are added to coinbase) if the miner includes the two conflicting transactions in the same block. Wouldn't this essentially solve the problem? - Eric Lombrozo On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay•com> wrote: > On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon•cc> wrote: > > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com> > wrote: > >> This isn't some theoretical exercise. Like it or not many use > >> insecure 0-conf transactions for rapid payments. Deploying something > >> that makes 0-conf transactions unusable would have a wide, negative > >> impact on present day bitcoin payments, thus "scorched earth" > > > And maybe by maintaining first seen policies we're harming the system > > in the long term by encouraging people to widely deploy systems based > > on extremely weak assumptions. > > Lacking a coded, reviewed alternative, that's only a platitude. > Widely used 0-conf payments are where we're at today. Simply ceasing > the "maintaining [of] first seen policies" alone is simply not a > realistic option. The negative impact to today's userbase would be > huge. > > Instant payments need a security upgrade, yes. > > -- > Jeff Garzik > Bitcoin core developer and open source evangelist > BitPay, Inc. https://bitpay.com/ > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > [-- Attachment #2: Type: text/html, Size: 3936 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 11:41 ` Eric Lombrozo @ 2015-02-22 12:06 ` Eric Lombrozo 2015-02-22 13:41 ` Eric Lombrozo 2015-03-01 17:59 ` Troy Benjegerdes 0 siblings, 2 replies; 79+ messages in thread From: Eric Lombrozo @ 2015-02-22 12:06 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 3405 bytes --] I should note that my proposal does require a change to the consensus rules...but getting bitcoin to scale will require this no matter what. - Eric Lombrozo On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail•com> wrote: > It seems to me we're confusing two completely different motivations for > double-spending. One is the ability to replace a fee, the other is the > ability to replace outputs. > > If the double-spend were to merely add or remove inputs (but keep at least > one input in common, of course), it seems fairly safe to assume it's the > former, a genuine fee replacement. Even allowing for things like coinjoin, > none of the payees would really care either way. > > Conversely, if at least one of the inputs were kept but none of the > outputs were, we can be confident it's the the latter. > > It is possible to build a wallet that always does the former when doing > fee replacement by using another transaction to create an output with > exactly the additional desired fee. > > If we can clearly distinguish these two cases then the fee replacement > case can be handled by relaying both and letting miners pick one or the > other while the output replacement case could be handled by rewarding > everything to a miner (essentially all outputs are voided...made > unredeemable...and all inputs are added to coinbase) if the miner includes > the two conflicting transactions in the same block. > > Wouldn't this essentially solve the problem? > > - Eric Lombrozo > On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay•com> wrote: > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon•cc> wrote: >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com> >> wrote: >> >> This isn't some theoretical exercise. Like it or not many use >> >> insecure 0-conf transactions for rapid payments. Deploying something >> >> that makes 0-conf transactions unusable would have a wide, negative >> >> impact on present day bitcoin payments, thus "scorched earth" >> >> > And maybe by maintaining first seen policies we're harming the system >> > in the long term by encouraging people to widely deploy systems based >> > on extremely weak assumptions. >> >> Lacking a coded, reviewed alternative, that's only a platitude. >> Widely used 0-conf payments are where we're at today. Simply ceasing >> the "maintaining [of] first seen policies" alone is simply not a >> realistic option. The negative impact to today's userbase would be >> huge. >> >> Instant payments need a security upgrade, yes. >> >> -- >> Jeff Garzik >> Bitcoin core developer and open source evangelist >> BitPay, Inc. https://bitpay.com/ >> >> >> ------------------------------------------------------------------------------ >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >> with Interactivity, Sharing, Native Excel Exports, App Integration & more >> Get technology previously reserved for billion-dollar corporations, FREE >> >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk >> _______________________________________________ >> Bitcoin-development mailing list >> Bitcoin-development@lists•sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >> > [-- Attachment #2: Type: text/html, Size: 4474 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 12:06 ` Eric Lombrozo @ 2015-02-22 13:41 ` Eric Lombrozo 2015-02-22 13:53 ` Peter Todd 2015-03-01 17:59 ` Troy Benjegerdes 1 sibling, 1 reply; 79+ messages in thread From: Eric Lombrozo @ 2015-02-22 13:41 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 4392 bytes --] In case it wasn't clear in my earlier post, there's of course a third possibility - namely, some outputs are kept but not all. Here, it is generally impossible to tell whether the motivation was fee replacement, output replacement, or both. My proposal is to always treat these instances as output replacement and punish the sender. The sender needs to make it unambiguously clear it's only a fee replacement by creating a new transaction that produces an output with the desired extra fee and then adding an input that spends it to the original transaction. - Eric Lombrozo On Sunday, February 22, 2015, Eric Lombrozo <elombrozo@gmail•com> wrote: > I should note that my proposal does require a change to the consensus > rules...but getting bitcoin to scale will require this no matter what. > > - Eric Lombrozo > On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail•com > <javascript:_e(%7B%7D,'cvml','elombrozo@gmail•com');>> wrote: > >> It seems to me we're confusing two completely different motivations for >> double-spending. One is the ability to replace a fee, the other is the >> ability to replace outputs. >> >> If the double-spend were to merely add or remove inputs (but keep at >> least one input in common, of course), it seems fairly safe to assume it's >> the former, a genuine fee replacement. Even allowing for things like >> coinjoin, none of the payees would really care either way. >> >> Conversely, if at least one of the inputs were kept but none of the >> outputs were, we can be confident it's the the latter. >> >> It is possible to build a wallet that always does the former when doing >> fee replacement by using another transaction to create an output with >> exactly the additional desired fee. >> >> If we can clearly distinguish these two cases then the fee replacement >> case can be handled by relaying both and letting miners pick one or the >> other while the output replacement case could be handled by rewarding >> everything to a miner (essentially all outputs are voided...made >> unredeemable...and all inputs are added to coinbase) if the miner includes >> the two conflicting transactions in the same block. >> >> Wouldn't this essentially solve the problem? >> >> - Eric Lombrozo >> On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay•com >> <javascript:_e(%7B%7D,'cvml','jgarzik@bitpay•com');>> wrote: >> >>> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon•cc> wrote: >>> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com >>> <javascript:_e(%7B%7D,'cvml','jgarzik@bitpay•com');>> wrote: >>> >> This isn't some theoretical exercise. Like it or not many use >>> >> insecure 0-conf transactions for rapid payments. Deploying something >>> >> that makes 0-conf transactions unusable would have a wide, negative >>> >> impact on present day bitcoin payments, thus "scorched earth" >>> >>> > And maybe by maintaining first seen policies we're harming the system >>> > in the long term by encouraging people to widely deploy systems based >>> > on extremely weak assumptions. >>> >>> Lacking a coded, reviewed alternative, that's only a platitude. >>> Widely used 0-conf payments are where we're at today. Simply ceasing >>> the "maintaining [of] first seen policies" alone is simply not a >>> realistic option. The negative impact to today's userbase would be >>> huge. >>> >>> Instant payments need a security upgrade, yes. >>> >>> -- >>> Jeff Garzik >>> Bitcoin core developer and open source evangelist >>> BitPay, Inc. https://bitpay.com/ >>> >>> >>> ------------------------------------------------------------------------------ >>> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server >>> from Actuate! Instantly Supercharge Your Business Reports and Dashboards >>> with Interactivity, Sharing, Native Excel Exports, App Integration & more >>> Get technology previously reserved for billion-dollar corporations, FREE >>> >>> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk >>> _______________________________________________ >>> Bitcoin-development mailing list >>> Bitcoin-development@lists•sourceforge.net >>> <javascript:_e(%7B%7D,'cvml','Bitcoin-development@lists•sourceforge.net');> >>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development >>> >> [-- Attachment #2: Type: text/html, Size: 5659 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 13:41 ` Eric Lombrozo @ 2015-02-22 13:53 ` Peter Todd 2015-02-22 23:29 ` Eric Lombrozo 0 siblings, 1 reply; 79+ messages in thread From: Peter Todd @ 2015-02-22 13:53 UTC (permalink / raw) To: Eric Lombrozo, Jeff Garzik; +Cc: Bitcoin Dev -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo <elombrozo@gmail•com> wrote: >In case it wasn't clear in my earlier post, there's of course a third >possibility - namely, some outputs are kept but not all. Here, it is >generally impossible to tell whether the motivation was fee >replacement, >output replacement, or both. My proposal is to always treat these >instances >as output replacement and punish the sender. The sender needs to make >it >unambiguously clear it's only a fee replacement by creating a new >transaction that produces an output with the desired extra fee and then >adding an input that spends it to the original transaction. That's a really old idea - I proposed it about two years ago. The optimal way is to allow any txout to be replaced with one with an equal or greater nValue and same scriptPubKey, as well as additional txouts added. (obviously so long as none are removed) Alas, there's lots of situations where this restricts you from doing useful things, for instance collapsing multiple payments into one by repeated updating to reduce tx size. Equally the benefit is marginal at best given how insecure unconfirmed transactions are - breaking what is already broken isn't a negative. -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3 YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs= =1vbN -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 13:53 ` Peter Todd @ 2015-02-22 23:29 ` Eric Lombrozo 2015-02-24 1:11 ` Jeff Garzik 0 siblings, 1 reply; 79+ messages in thread From: Eric Lombrozo @ 2015-02-22 23:29 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 2403 bytes --] On Sunday, February 22, 2015, Peter Todd <pete@petertodd•org> wrote: > -----BEGIN PGP SIGNED MESSAGE----- > Hash: SHA256 > > > > On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo <elombrozo@gmail•com > <javascript:;>> wrote: > >In case it wasn't clear in my earlier post, there's of course a third > >possibility - namely, some outputs are kept but not all. Here, it is > >generally impossible to tell whether the motivation was fee > >replacement, > >output replacement, or both. My proposal is to always treat these > >instances > >as output replacement and punish the sender. The sender needs to make > >it > >unambiguously clear it's only a fee replacement by creating a new > >transaction that produces an output with the desired extra fee and then > >adding an input that spends it to the original transaction. > > That's a really old idea - I proposed it about two years ago. The optimal > way is to allow any txout to be replaced with one with an equal or greater > nValue and same scriptPubKey, as well as additional txouts added. > (obviously so long as none are removed) > > That won't work because in general it is impossible to know which transaction is the original. Did we add outputs to transaction A? Or remove outputs from transaction B? > Alas, there's lots of situations where this restricts you from doing > useful things, for instance collapsing multiple payments into one by > repeated updating to reduce tx size. Equally the benefit is marginal at > best given how insecure unconfirmed transactions are - breaking what is > already broken isn't a negative. > > I think you're unnecessarily complicating use cases. As for 0-conf security, there are instances where 0-conf transactions make a lot of sense - i.e. paying for utilities, ISP, web hosting, or other such services which could be immediately shut off upon detection of a double-spend. > -----BEGIN PGP SIGNATURE----- > > iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6d9O > AAoJEMCF8hzn9LncUOUH/3yY4wDyFSkL9o6GsntphAmJSN35wVAlxPxBmNTk0KR3 > YfVhY1cTBIXKqsfqz/n1Sqn264aMzW48xUTtDF2xLzJc1FY5qTBw7zbVrZgYIvvr > GEakZW1SxLXsfSs2Onutl0WQWi8EMfxEXEPQIiiWy9mq4EtwxMOcDviETycu6Wmn > pmHY00Lo8jhLUyuIkzIZrZetEtWz1VtovbJO5l7WfmLgPWzW+zERPY/pGGioqdiJ > NOEaocQ+2+OZjyx3MJ4YAch5ZtfB45g+NBm8WyeGpBgxzK3ZIpmyZIQ6HqZr0gpl > NMUQh6Sbi8WaTEp6hoYTiEfZcEy4IDPg6f0DEW71BPs= > =1vbN > -----END PGP SIGNATURE----- > > [-- Attachment #2: Type: text/html, Size: 3140 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 23:29 ` Eric Lombrozo @ 2015-02-24 1:11 ` Jeff Garzik 0 siblings, 0 replies; 79+ messages in thread From: Jeff Garzik @ 2015-02-24 1:11 UTC (permalink / raw) To: Eric Lombrozo; +Cc: Bitcoin Dev On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo <elombrozo@gmail•com> wrote: > As for 0-conf security, there are instances where 0-conf transactions make a > lot of sense - i.e. paying for utilities, ISP, web hosting, or other such > services which could be immediately shut off upon detection of a > double-spend. Indeed. 0-conf risk calculus must include business conditions. Business cases such as placing an order for a physical good, making an in-person purchase at a brick-n-mortar store, or subscriptions already have countermeasures in place if funds go astray. Order fulfilment can be stopped, subscriptions cancelled, photos handed to police. A thief wants to maximize return, which usually means either stealing a few large amounts or many small amounts. Double-spending against a SatoshiDICE clone is easy to automate. Many other purchase situations are difficult to repeat without getting caught, or the level of effort (cost) is greater than the payout of double-spending a small amount. 0-conf is typically only used for small amounts, where useful theft relies on high repetition. Purely online, mostly anonymous services like SatoshiDICE will be easily attacked if they accept 0-conf transactions as there is little customer/reputation relationship to leverage. However, that observation cannot be easily applied to most other businesses. -- Jeff Garzik Bitcoin core developer and open source evangelist BitPay, Inc. https://bitpay.com/ ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 12:06 ` Eric Lombrozo 2015-02-22 13:41 ` Eric Lombrozo @ 2015-03-01 17:59 ` Troy Benjegerdes 2015-03-01 19:05 ` Neil Fincham 1 sibling, 1 reply; 79+ messages in thread From: Troy Benjegerdes @ 2015-03-01 17:59 UTC (permalink / raw) To: Eric Lombrozo; +Cc: Bitcoin Dev So let's play this out a little.. Let's call it "Solomon's spend[1]" Exchange gets hacked, bitcoins move. The exchange has a contract with an insurance company and miners for 'scorched earth' theft response that creates a double-spend of the original transaction. So now there's a 10,000 bitcoin incentive for miners to roll back the chain and start (re)mining the block where the theft occurred. The exchange gets an insurance payout, some miner wins the lottery, and the thief gets nothing. Seems like a good deal, what am I missing? [1] http://en.wikipedia.org/wiki/Judgment_of_Solomon On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote: > I should note that my proposal does require a change to the consensus > rules...but getting bitcoin to scale will require this no matter what. > > - Eric Lombrozo > On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail•com> wrote: > > > It seems to me we're confusing two completely different motivations for > > double-spending. One is the ability to replace a fee, the other is the > > ability to replace outputs. > > > > If the double-spend were to merely add or remove inputs (but keep at least > > one input in common, of course), it seems fairly safe to assume it's the > > former, a genuine fee replacement. Even allowing for things like coinjoin, > > none of the payees would really care either way. > > > > Conversely, if at least one of the inputs were kept but none of the > > outputs were, we can be confident it's the the latter. > > > > It is possible to build a wallet that always does the former when doing > > fee replacement by using another transaction to create an output with > > exactly the additional desired fee. > > > > If we can clearly distinguish these two cases then the fee replacement > > case can be handled by relaying both and letting miners pick one or the > > other while the output replacement case could be handled by rewarding > > everything to a miner (essentially all outputs are voided...made > > unredeemable...and all inputs are added to coinbase) if the miner includes > > the two conflicting transactions in the same block. > > > > Wouldn't this essentially solve the problem? > > > > - Eric Lombrozo > > On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay•com> wrote: > > > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon•cc> wrote: > >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com> > >> wrote: > >> >> This isn't some theoretical exercise. Like it or not many use > >> >> insecure 0-conf transactions for rapid payments. Deploying something > >> >> that makes 0-conf transactions unusable would have a wide, negative > >> >> impact on present day bitcoin payments, thus "scorched earth" > >> > >> > And maybe by maintaining first seen policies we're harming the system > >> > in the long term by encouraging people to widely deploy systems based > >> > on extremely weak assumptions. > >> > >> Lacking a coded, reviewed alternative, that's only a platitude. > >> Widely used 0-conf payments are where we're at today. Simply ceasing > >> the "maintaining [of] first seen policies" alone is simply not a > >> realistic option. The negative impact to today's userbase would be > >> huge. > >> > >> Instant payments need a security upgrade, yes. > >> > >> -- > >> Jeff Garzik > >> Bitcoin core developer and open source evangelist > >> BitPay, Inc. https://bitpay.com/ > >> > >> > >> ------------------------------------------------------------------------------ > >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards > >> with Interactivity, Sharing, Native Excel Exports, App Integration & more > >> Get technology previously reserved for billion-dollar corporations, FREE > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Bitcoin-development mailing list > >> Bitcoin-development@lists•sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >> > > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-03-01 17:59 ` Troy Benjegerdes @ 2015-03-01 19:05 ` Neil Fincham 0 siblings, 0 replies; 79+ messages in thread From: Neil Fincham @ 2015-03-01 19:05 UTC (permalink / raw) To: Troy Benjegerdes; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 6559 bytes --] > Seems like a good deal, what am I missing? The disruption caused to every other user or the bitcoin network. Transactions unconfirmed, history is rewritten, the poor Byzantine General who sent his soldiers off to battle finds out that his scouts have been paid to change their reports. Neil On 2 March 2015 at 06:59, Troy Benjegerdes <hozer@hozed•org> wrote: > So let's play this out a little.. Let's call it "Solomon's spend[1]" > > Exchange gets hacked, bitcoins move. > > The exchange has a contract with an insurance company and miners for > 'scorched earth' theft response that creates a double-spend of the > original transaction. > > So now there's a 10,000 bitcoin incentive for miners to roll back the > chain and start (re)mining the block where the theft occurred. > > The exchange gets an insurance payout, some miner wins the lottery, and > the thief gets nothing. Seems like a good deal, what am I missing? > > [1] http://en.wikipedia.org/wiki/Judgment_of_Solomon > > On Sun, Feb 22, 2015 at 04:06:13AM -0800, Eric Lombrozo wrote: > > I should note that my proposal does require a change to the consensus > > rules...but getting bitcoin to scale will require this no matter what. > > > > - Eric Lombrozo > > On Feb 22, 2015 3:41 AM, "Eric Lombrozo" <elombrozo@gmail•com> wrote: > > > > > It seems to me we're confusing two completely different motivations for > > > double-spending. One is the ability to replace a fee, the other is the > > > ability to replace outputs. > > > > > > If the double-spend were to merely add or remove inputs (but keep at > least > > > one input in common, of course), it seems fairly safe to assume it's > the > > > former, a genuine fee replacement. Even allowing for things like > coinjoin, > > > none of the payees would really care either way. > > > > > > Conversely, if at least one of the inputs were kept but none of the > > > outputs were, we can be confident it's the the latter. > > > > > > It is possible to build a wallet that always does the former when doing > > > fee replacement by using another transaction to create an output with > > > exactly the additional desired fee. > > > > > > If we can clearly distinguish these two cases then the fee replacement > > > case can be handled by relaying both and letting miners pick one or the > > > other while the output replacement case could be handled by rewarding > > > everything to a miner (essentially all outputs are voided...made > > > unredeemable...and all inputs are added to coinbase) if the miner > includes > > > the two conflicting transactions in the same block. > > > > > > Wouldn't this essentially solve the problem? > > > > > > - Eric Lombrozo > > > On Feb 21, 2015 8:09 PM, "Jeff Garzik" <jgarzik@bitpay•com> wrote: > > > > > >> On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón <jtimon@jtimon•cc> > wrote: > > >> > On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik <jgarzik@bitpay•com> > > >> wrote: > > >> >> This isn't some theoretical exercise. Like it or not many use > > >> >> insecure 0-conf transactions for rapid payments. Deploying > something > > >> >> that makes 0-conf transactions unusable would have a wide, negative > > >> >> impact on present day bitcoin payments, thus "scorched earth" > > >> > > >> > And maybe by maintaining first seen policies we're harming the > system > > >> > in the long term by encouraging people to widely deploy systems > based > > >> > on extremely weak assumptions. > > >> > > >> Lacking a coded, reviewed alternative, that's only a platitude. > > >> Widely used 0-conf payments are where we're at today. Simply ceasing > > >> the "maintaining [of] first seen policies" alone is simply not a > > >> realistic option. The negative impact to today's userbase would be > > >> huge. > > >> > > >> Instant payments need a security upgrade, yes. > > >> > > >> -- > > >> Jeff Garzik > > >> Bitcoin core developer and open source evangelist > > >> BitPay, Inc. https://bitpay.com/ > > >> > > >> > > >> > ------------------------------------------------------------------------------ > > >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > >> from Actuate! Instantly Supercharge Your Business Reports and > Dashboards > > >> with Interactivity, Sharing, Native Excel Exports, App Integration & > more > > >> Get technology previously reserved for billion-dollar corporations, > FREE > > >> > > >> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > > >> _______________________________________________ > > >> Bitcoin-development mailing list > > >> Bitcoin-development@lists•sourceforge.net > > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >> > > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar corporations, FREE > > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > > > _______________________________________________ > > Bitcoin-development mailing list > > Bitcoin-development@lists•sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > -- > > ---------------------------------------------------------------------------- > Troy Benjegerdes 'da hozer' > hozer@hozed•org > 7 elements earth::water::air::fire::mind::spirit::soul > grid.coop > > Never pick a fight with someone who buys ink by the barrel, > nor try buy a hacker who makes money by the megahash > > > > ------------------------------------------------------------------------------ > 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 > [-- Attachment #2: Type: text/html, Size: 9387 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-21 22:47 ` Jeff Garzik 2015-02-22 1:15 ` Peter Todd 2015-02-22 3:25 ` Jorge Timón @ 2015-03-01 17:44 ` Troy Benjegerdes 2 siblings, 0 replies; 79+ messages in thread From: Troy Benjegerdes @ 2015-03-01 17:44 UTC (permalink / raw) To: Jeff Garzik; +Cc: Bitcoin Development, Jorge Timón Bitcoin was/is a disruptive technology for credit card payment processors, and replace-by-fee/stag-hunt is a disruptive technology for Bitcoin payment processors. I think whether you call it scorched earth is a bit more of a reflection of whether you stand to make money, or lose money from the distruption. Personally, I think 'first-seen' is a dangerous scorched-earth policy that only benefits the people who own the internet routers that determine what is seen first. But from the standpoint of consensus, can we at least agree that it's a *node policy* decision, and the market particpants should be free to choose whichever policy works best for them? Otherwise, I think the only way to make 'first-seen' work is by adding a timestamp to CTransaction. On Sat, Feb 21, 2015 at 05:47:28PM -0500, Jeff Garzik wrote: > "scorched earth" refers to the _real world_ impact such policies would > have on present-day 0-conf usage within the bitcoin community. > > All payment processors AFAIK process transactions through some scoring > system, then accept 0-conf transactions for payments. > > This isn't some theoretical exercise. Like it or not many use > insecure 0-conf transactions for rapid payments. Deploying something > that makes 0-conf transactions unusable would have a wide, negative > impact on present day bitcoin payments, thus "scorched earth" > > Without adequate decentralized solutions for instant payments, > deploying replace-by-fee widely would simply push instant transactions > even more into the realm of centralized, walled-garden services. > > > > > > > On Sat, Feb 21, 2015 at 3:30 PM, Mark Friedenbach <mark@friedenbach•org> wrote: > > Thank you Jorge for the contribution of the Stag Hunt terminology. It is > > much better than a politically charged "scorched earth". > > > > On Feb 21, 2015 11:10 AM, "Jorge Timón" <jtimon@jtimon•cc> wrote: > >> > >> I agree "scorched hearth" is a really bad name for the 0 conf protocol > >> based on game theory. I would have preferred "stag hunt" since that's > >> basically what it's using (see http://en.wikipedia.org/wiki/Stag_hunt) > >> but I like the protocol and I think it would be interesting to > >> integrate it in the payment protocol. > >> Even if that protocol didn't existed or didn't worked, replace-by-fee > >> is purely part of a node's policy, not part of consensus. > >> >From the whitepaper, 0 conf transactions being secure by the good will > >> of miners was never an assumption, and it is clear to me that the > >> system cannot provide those guaranties based on such a weak scheme. I > >> believe thinking otherwise is naive. > >> As to consider non-standard policies "an attack to bitcoin" because > >> "that's not how bitcoin used to work", then I guess minimum relay fee > >> policies can also be considered "an attack to bitcoin" on the same > >> grounds. > >> Lastly, "first-seen-wins" was just a simple policy to bootstrap the > >> system, but I expect that most nodes will eventually move to policies > >> that are economically rational for miners such as replace-by-fee. > >> Not only I disagree this will be "the end of bitcoin" or "will push > >> the price of the btc miners are mining down", I believe it will be > >> something good for bitcoin. > >> Since this is apparently controversial I don't want to push for > >> replace-by-fee to become the new standard policy (something that would > >> make sense to me). But once the policy code is sufficiently modular as > >> to support several policies I would like bitcoin core to have a > >> CReplaceByFeePolicy alongside CStandardPolicy and a CNullPolicy (no > >> policy checks at all). > >> One step at a time I guess... > >> > >> > >> On Thu, Feb 19, 2015 at 9:56 AM, Troy Benjegerdes <hozer@hozed•org> wrote: > >> > On Sun, Feb 15, 2015 at 11:40:24PM +0200, Adam Gibson wrote: > >> >> > >> >> > >> >> On 02/15/2015 11:25 PM, Troy Benjegerdes wrote: > >> >> > > >> >> > Most money/payment systems include some method to reverse or undo > >> >> > payments made in error. In these systems, the longer settlement > >> >> > times you mention below are a feature, not a bug, and give more > >> >> > time for a human to react to errors and system failures. > >> >> > > >> >> > >> >> Settlement has to be final somewhere. That is the whole point of it. > >> >> Transfer costs in current electronic payment systems are a direct > >> >> consequence of their non-finality. That's the point Satoshi was making > >> >> in the introduction to the whitepaper: "With the possibility of > >> >> reversal, the need for trust spreads". > >> > > >> > The problem with that statement is I trust a merchant that I went into > >> > a store and made a payment with personally more than I trust the > >> > firmware > >> > on my hard drive [1]. > >> > > >> > The attack surface of devices in your computer is huge. A motivated > >> > attacker > >> > just needs to get an intern into a company that makes some kind of > >> > component > >> > or system that's in your computer, cloud server, hardware wallet, or > >> > what > >> > have you that has firmware capable of reading your private keys. > >> > > >> > With the possibility of mass trojaned hardware, if we are going to trust > >> > the system, it must somehow allow reversal through a human-in-the-loop. > >> > > >> >> There is nothing wrong with having reversible mechanisms built on top > >> >> of Bitcoin, and indeed it makes sense for most activity to happen at > >> >> those higher layers. It's easy to build things that way, but > >> >> impossible to build them the other way: you can't build a > >> >> non-reversible layer on top of a reversible layer. > >> > > >> > We built 'reliable' TCP on top of unreliable ethernet networks. My > >> > experience > >> > with networking was if you tried to guarantee message delivery at the > >> > lowest > >> > level, the system got exceedingly complicated, expensive, and brittle. > >> > > >> > Most applications, in particular paying someone you already trust, are > >> > quite > >> > happy running on reversible systems, and in some cases more reliable and > >> > lower risk. (carrying non-reversible cash is generally considered risky) > >> > > >> > The problem is that if the base currency is assumed to be > >> > non-reversible, > >> > then it's brittle and becomes 'too big to fail'. > >> > > >> > Where the blockchain improves on everything else is in transparency. If > >> > you > >> > reverse transactions a lot, it will be obvious from an analysis. I would > >> > much > >> > rather deal with a known, predictable, and relatively continous > >> > transaction > >> > reversal rate (percentage) than have to deal with sudden failures where > >> > some anonymous bad actor makes off with a fortune. > >> > > >> > We already have zero-conf double-spend transaction reversal, why not > >> > explicitly > >> > extend that a little in a way that senders and receivers have a choice > >> > to > >> > use it, or not? > >> > > >> > > >> > [1] > >> > http://www.reuters.com/article/2015/02/16/us-usa-cyberspying-idUSKBN0LK1QV20150216 > >> > > >> > > >> > ------------------------------------------------------------------------------ > >> > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > >> > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > >> > with Interactivity, Sharing, Native Excel Exports, App Integration & > >> > more > >> > Get technology previously reserved for billion-dollar corporations, FREE > >> > > >> > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > >> > _______________________________________________ > >> > Bitcoin-development mailing list > >> > Bitcoin-development@lists•sourceforge.net > >> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >> > >> > >> ------------------------------------------------------------------------------ > >> Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > >> from Actuate! Instantly Supercharge Your Business Reports and Dashboards > >> with Interactivity, Sharing, Native Excel Exports, App Integration & more > >> Get technology previously reserved for billion-dollar corporations, FREE > >> > >> http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > >> _______________________________________________ > >> Bitcoin-development mailing list > >> Bitcoin-development@lists•sourceforge.net > >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > > > > > ------------------------------------------------------------------------------ > > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > > with Interactivity, Sharing, Native Excel Exports, App Integration & more > > Get technology previously reserved for billion-dollar corporations, FREE > > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > > _______________________________________________ > > 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/ > > ------------------------------------------------------------------------------ > Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server > from Actuate! Instantly Supercharge Your Business Reports and Dashboards > with Interactivity, Sharing, Native Excel Exports, App Integration & more > Get technology previously reserved for billion-dollar corporations, FREE > http://pubads.g.doubleclick.net/gampad/clk?id=190641631&iu=/4140/ostg.clktrk > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- ---------------------------------------------------------------------------- Troy Benjegerdes 'da hozer' hozer@hozed•org 7 elements earth::water::air::fire::mind::spirit::soul grid.coop Never pick a fight with someone who buys ink by the barrel, nor try buy a hacker who makes money by the megahash ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 11:58 ` Mike Hearn ` (4 preceding siblings ...) 2015-02-12 15:27 ` Jeff Garzik @ 2015-02-12 16:15 ` Lawrence Nahum 5 siblings, 0 replies; 79+ messages in thread From: Lawrence Nahum @ 2015-02-12 16:15 UTC (permalink / raw) To: bitcoin-development Mike Hearn <mike <at> plan99.net> writes: > > > I know you will ignore this as usual, but the entire replace-by-fee folly is based on your fundamental misunderstanding of miner incentives. I disagree, I think it is inevitable (but then of course I'm probably biased and why wouldn't I disagree given I run a service that allows for zero confirmation/double spend protection with third party trust.) Fixing it now avoids having people build on top of very weak/broken foundations (see Coinbase https://botbot.me/freenode/bitcoin- wizards/msg/29818058/) which would cause bigger problems down the line. One thing I don't understand from your position is how do you propose handling transactions being stuck for days or longer because of low fees? Even with floating fees you can have a sudden inflow of high fees transactions taking over post broadcasting your transaction. I also assume restricted replacement is very hard, especially from a UX point of view and adds undue complexity ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd 2015-02-12 7:23 ` Tamas Blummer 2015-02-12 11:58 ` Mike Hearn @ 2015-02-12 18:14 ` Tom Harding 2015-02-12 21:40 ` Josh Lehan ` (2 subsequent siblings) 5 siblings, 0 replies; 79+ messages in thread From: Tom Harding @ 2015-02-12 18:14 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Development 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. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd ` (2 preceding siblings ...) 2015-02-12 18:14 ` Tom Harding @ 2015-02-12 21:40 ` Josh Lehan 2015-02-22 16:36 ` Tom Harding 2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd 5 siblings, 0 replies; 79+ messages in thread From: Josh Lehan @ 2015-02-12 21:40 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development 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 <pete@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 '((0000000000000003)|(0000000004000001))' > "services" : "0000000000000003", > "services" : "0000000004000001", > "services" : "0000000004000001", > "services" : "0000000000000003", > "services" : "0000000004000001", > "services" : "0000000004000001", > "services" : "0000000000000003", > "services" : "0000000000000003", > > Replace-by-fee nodes advertise service bit 26 from the experimental use > range; Bitcoin XT nodes advertise service bit 1 for their getutxos > support. The code sets aside a certain number of outgoing and incoming > slots just for double-spend relaying nodes, so as long as everything is > working you're node should be connected to like-minded nodes a within 30 > minutes or so of starting up. > > If you *don't* want to advertise the fact that you are running a > replace-by-fee node, just checkout a slightly earlier commit in git; the > actual mempool changes are separate from the preferential peering > commits. You can then connect directly to a replace-by-fee node using > the -addnode command line flag. > > 1) https://github.com/bitcoinxt/bitcoinxt > 2) https://github.com/bitcoin/bitcoin/pull/3883 > 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 > 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP > 5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html > 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html > 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html > > -- > 'peter'[:-1]@petertodd.org > 000000000000000013c290b77d45d2ea7f9220aedfadfd556ad41b6bd39822f3 > ------------------------------------------------------------------------------ > 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 ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd ` (3 preceding siblings ...) 2015-02-12 21:40 ` Josh Lehan @ 2015-02-22 16:36 ` Tom Harding 2015-02-22 17:12 ` Peter Todd 2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd 5 siblings, 1 reply; 79+ messages in thread From: Tom Harding @ 2015-02-22 16:36 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development On 2/11/2015 10:47 PM, Peter Todd 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 > This patch immediately simplifies successful double-spends of unconfirmed transactions. But the idea that it "gives a path to making zeroconf transactions economically secure" is quite dubious. * You don't provide sufficient means to detect and relay double-spends, which is necessary to trigger a scorched-earth reaction. Not all double-spends will conform to your replacement rules. * Maybe XT nodes would help to overcome this. But meanwhile, in the ANYONECANPAY design, Bob's replacement is a triple-spend. Even XT nodes won't relay it. * It's unclear when, if ever, any senders/receivers will actually try to use scorched-earth as a double-spend deterrent. Also, this patch significantly weakens DoS protections: * It removes the early conflict check, making all conflict processing more expensive * There is no attempt to protect against the same transaction being continually replaced with the fee bumped by a minimal amount. ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 16:36 ` Tom Harding @ 2015-02-22 17:12 ` Peter Todd 2015-02-22 19:25 ` Tom Harding 0 siblings, 1 reply; 79+ messages in thread From: Peter Todd @ 2015-02-22 17:12 UTC (permalink / raw) To: Tom Harding; +Cc: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 2630 bytes --] On Sun, Feb 22, 2015 at 08:36:01AM -0800, Tom Harding wrote: > On 2/11/2015 10:47 PM, Peter Todd 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 > > > > This patch immediately simplifies successful double-spends of > unconfirmed transactions. But the idea that it "gives a path to > making zeroconf transactions economically secure" is quite dubious. > > * You don't provide sufficient means to detect and relay > double-spends, which is necessary to trigger a scorched-earth > reaction. Not all double-spends will conform to your replacement > rules. No, OTOH if they don't then the situation is no difference from what we have now, and replace-by-fee does no harm. Meanwhile, relaying of bare double-spend signatures can be implemented in the future, as I suggested last year for your/Andresen's double-spend relaying patch. Did you notice the even more obvious way to defeat ANYONECANPAY scorched earth with that patch? > * Maybe XT nodes would help to overcome this. But meanwhile, in > the ANYONECANPAY design, Bob's replacement is a triple-spend. Even > XT nodes won't relay it. So? RBF nodes will. > * It's unclear when, if ever, any senders/receivers will actually > try to use scorched-earth as a double-spend deterrent. I suspect many won't, because few people need to rely on unconfirmed transactions anyway. > Also, this patch significantly weakens DoS protections: > > * It removes the early conflict check, making all conflict > processing more expensive If you're going to consider replacement, conflict processing will definitely be more expensive. :) An actual DoS attacker would do their DoS attack in a way where conflict processing has nothing to do with it, so this change does no actual harm. > * There is no attempt to protect against the same transaction > being continually replaced with the fee bumped by a minimal amount. What exact git commit were you looking at? I did have an early one that did have a bug along those lines, now fixed. The current version ensures every replacement pays at least as much additional fees as would normally cost to broadcast that much data on the network, and additionally requires the fees/KB to always increase; under all circumstances it should be no more of a DoS threat than low-fee transactions are otherwise. I'd like to know if there is a flaw in that code however! -- 'peter'[:-1]@petertodd.org 000000000000000017c2f346f81e93956c538531682f5af3a95f9c94cb7a84e8 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 17:12 ` Peter Todd @ 2015-02-22 19:25 ` Tom Harding 2015-02-22 21:50 ` Peter Todd 0 siblings, 1 reply; 79+ messages in thread From: Tom Harding @ 2015-02-22 19:25 UTC (permalink / raw) To: Peter Todd; +Cc: bitcoin-development On 2/22/2015 9:12 AM, Peter Todd wrote: > Did you notice the even more obvious way to defeat ANYONECANPAY > scorched earth with that patch? Let's see. I could pay 10 people 1 BTC each with one tx, then double-spend it with fees of 2BTC. Now at least three of the 10 have to work together if they want to scorched-earth me, since an individual or two-party claw-back wouldn't have high enough fees. Oops! ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] replace-by-fee v0.10.0rc4 2015-02-22 19:25 ` Tom Harding @ 2015-02-22 21:50 ` Peter Todd 0 siblings, 0 replies; 79+ messages in thread From: Peter Todd @ 2015-02-22 21:50 UTC (permalink / raw) To: Tom Harding; +Cc: bitcoin-development -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Not that issue - that's both easily avoidable, and has nothing to do with the replace-by-fee patch. I'm talking about something in the specific patch - good test to see if you've fully reviewed it. On 22 February 2015 14:25:24 GMT-05:00, Tom Harding <tomh@thinlink•com> wrote: >On 2/22/2015 9:12 AM, Peter Todd wrote: >> Did you notice the even more obvious way to defeat ANYONECANPAY >> scorched earth with that patch? > >Let's see. I could pay 10 people 1 BTC each with one tx, then >double-spend it with fees of 2BTC. Now at least three of the 10 have >to >work together if they want to scorched-earth me, since an individual or > >two-party claw-back wouldn't have high enough fees. Oops! -----BEGIN PGP SIGNATURE----- iQE9BAEBCAAnIBxQZXRlciBUb2RkIDxwZXRlQHBldGVydG9kZC5vcmc+BQJU6k8q AAoJEMCF8hzn9LncssUH/0acS1lhG8igRWBusnpDD+on+ryXNlTDKZGExzUKy7Wq 7SzYfMX8LAf/0Wbzs6wtyGzVjQOGmcM0XTAFN+Rp2rP3ZuSzAqO41Re+aUkiB67y 4PD8R05DmDgbc257HwIQM1aa+NPzzW5p8C+HnyZKpUqMNUAZOUVks22oRGywUXQY WrNKiSFQMxW0l1thjX63/x3iXjV92gxyd9qWK8uPAokwNEdULPU5S1mlZbji+MaJ cfR6WB02JR/GHPDK1rwmM8vAwQY82CMOJK3HB+1Dx88NvN5Ucn+ppVFtNETHA5g8 e7UcFeXXeMRF2AMwc9lFEmYsXmSAMJrTFeO981KoOHs= =fESj -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 79+ messages in thread
* [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd ` (4 preceding siblings ...) 2015-02-22 16:36 ` Tom Harding @ 2015-05-04 4:36 ` Peter Todd 2015-05-05 2:23 ` Kevin Greene 2015-05-23 18:26 ` [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet Peter Todd 5 siblings, 2 replies; 79+ messages in thread From: Peter Todd @ 2015-05-04 4:36 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 4463 bytes --] My replace-by-fee patch is now available for the v0.10.1 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1 No new features in this version; this is simply a rebase for the Bitcoin Core v0.10.1 release. (there weren't even any merge conflicts) As with the Bitcoin Core v0.10.1, it's recommended to upgrade. The following text is the copied verbatim from the previous release: 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.1 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 '((0000000000000003)|(0000000004000001))' "services" : "0000000000000003", "services" : "0000000004000001", "services" : "0000000004000001", "services" : "0000000000000003", "services" : "0000000004000001", "services" : "0000000004000001", "services" : "0000000000000003", "services" : "0000000000000003", Replace-by-fee nodes advertise service bit 26 from the experimental use range; Bitcoin XT nodes advertise service bit 1 for their getutxos support. The code sets aside a certain number of outgoing and incoming slots just for double-spend relaying nodes, so as long as everything is working you're node should be connected to like-minded nodes a within 30 minutes or so of starting up. If you *don't* want to advertise the fact that you are running a replace-by-fee node, just checkout a slightly earlier commit in git; the actual mempool changes are separate from the preferential peering commits. You can then connect directly to a replace-by-fee node using the -addnode command line flag. 1) https://github.com/bitcoinxt/bitcoinxt 2) https://github.com/bitcoin/bitcoin/pull/3883 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP 5) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html 6) http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html 7) http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html -- 'peter'[:-1]@petertodd.org 0000000000000000059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9 [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* Re: [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd @ 2015-05-05 2:23 ` Kevin Greene 2015-05-23 18:26 ` [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet Peter Todd 1 sibling, 0 replies; 79+ messages in thread From: Kevin Greene @ 2015-05-05 2:23 UTC (permalink / raw) To: Peter Todd; +Cc: Bitcoin Dev [-- Attachment #1: Type: text/plain, Size: 5597 bytes --] I feel compelled to re-share Mike Hearn's counter-argument *against * replace-by-fee: https://medium.com/@octskyward/replace-by-fee-43edd9a1dd6d Please carefully consider the effects of replace-by-fee before applying Peter's patch. On Sun, May 3, 2015 at 9:36 PM, Peter Todd <pete@petertodd•org> wrote: > My replace-by-fee patch is now available for the v0.10.1 release: > > https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.1 > > No new features in this version; this is simply a rebase for the Bitcoin > Core v0.10.1 release. (there weren't even any merge conflicts) As with > the Bitcoin Core v0.10.1, it's recommended to upgrade. > > > The following text is the copied verbatim from the previous release: > > 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.1 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 > '((0000000000000003)|(0000000004000001))' > "services" : "0000000000000003", > "services" : "0000000004000001", > "services" : "0000000004000001", > "services" : "0000000000000003", > "services" : "0000000004000001", > "services" : "0000000004000001", > "services" : "0000000000000003", > "services" : "0000000000000003", > > Replace-by-fee nodes advertise service bit 26 from the experimental use > range; Bitcoin XT nodes advertise service bit 1 for their getutxos > support. The code sets aside a certain number of outgoing and incoming > slots just for double-spend relaying nodes, so as long as everything is > working you're node should be connected to like-minded nodes a within 30 > minutes or so of starting up. > > If you *don't* want to advertise the fact that you are running a > replace-by-fee node, just checkout a slightly earlier commit in git; the > actual mempool changes are separate from the preferential peering > commits. You can then connect directly to a replace-by-fee node using > the -addnode command line flag. > > 1) https://github.com/bitcoinxt/bitcoinxt > 2) https://github.com/bitcoin/bitcoin/pull/3883 > 3) https://github.com/bitcoin/bitcoin/pull/3883#issuecomment-45543370 > 4) https://github.com/luke-jr/bitcoin/tree/0.10.x-ljrP > 5) > http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg05211.html > 6) > http://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg06970.html > 7) > http://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04972.html > > -- > 'peter'[:-1]@petertodd.org > 0000000000000000059a3dd65f0e5ffb8fdf316d6f31921fefcf0ef726120be9 > > > ------------------------------------------------------------------------------ > One dashboard for servers and applications across Physical-Virtual-Cloud > Widest out-of-the-box monitoring support with 50+ applications > Performance metrics, stats and reports that give you Actionable Insights > Deep dive visibility with transaction tracing using APM Insight. > http://ad.doubleclick.net/ddm/clk/290420510;117567292;y > _______________________________________________ > Bitcoin-development mailing list > Bitcoin-development@lists•sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > [-- Attachment #2: Type: text/html, Size: 7848 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
* [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet 2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd 2015-05-05 2:23 ` Kevin Greene @ 2015-05-23 18:26 ` Peter Todd 1 sibling, 0 replies; 79+ messages in thread From: Peter Todd @ 2015-05-23 18:26 UTC (permalink / raw) To: bitcoin-development [-- Attachment #1: Type: text/plain, Size: 1977 bytes --] My replace-by-fee patch is now available for the Bitcoin Core v0.10.2 release: https://github.com/petertodd/bitcoin/tree/replace-by-fee-v0.10.2 This release fixes a serious DoS attack present in previous releases. Upgrading is strongly recommended for relay nodes, and mandatory for miners. Users of Luke-Jr's gentoo distribution should either disable RBF until a patch is released, or run their node behind a patched node. Previously replacements that spent outputs the transactions they conflicted with would be accepted. This would lead to orphaned transactions in the mempool, a potential bandwidth DoS attack for relay nodes, and even worse, on mining nodes would cause Bitcoin to crash when CreateNewBlock() was called. Thanks goes to to Suhas Daftuar for finding this issue. Additionally, while investigating this issue I found that Andresen/Harding's relay doublespends patch¹, included in Bitcoin XT², also fails to verify that doublespends don't spend outputs of the transactions they conflict with. As the transactions aren't accepted to the mempool the issue is simply a variant of the bandwidth DoS attack that's a well-known issue of Bitcoin XT. However, interestingly in testing I found that Schildbach's Android Bitcoin Wallet³ fails to detect this case, and displays the transaction as a valid unconfirmed transaction, potentially leading to the user being defrauded with a doublespend. While a well-known issue in general - Schildbach's implementation trusts peers to only send it valid transactions and doesn't even detect doublespends it receives from peers - it's interesting how in this case the attacker doesn't need to also do a sybil attack. 1) https://github.com/bitcoin/bitcoin/pull/3883 2) https://github.com/bitcoinxt/bitcoinxt 3) https://play.google.com/store/apps/details?id=de.schildbach.wallet -- 'peter'[:-1]@petertodd.org 0000000000000000026ca21b4a83e1a818be96db4b532b7e9be2f60d47efff0a [-- Attachment #2: Digital signature --] [-- Type: application/pgp-signature, Size: 650 bytes --] ^ permalink raw reply [flat|nested] 79+ messages in thread
end of thread, other threads:[~2015-05-23 18:26 UTC | newest] Thread overview: 79+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2015-02-12 6:47 [Bitcoin-development] replace-by-fee v0.10.0rc4 Peter Todd 2015-02-12 7:23 ` Tamas Blummer 2015-02-12 7:45 ` Peter Todd 2015-02-12 8:27 ` Tamas Blummer 2015-02-12 8:49 ` Peter Todd 2015-02-12 9:01 ` Tamas Blummer 2015-02-15 20:51 ` Troy Benjegerdes 2015-02-12 8:16 ` Alex Mizrahi 2015-02-12 11:58 ` Mike Hearn 2015-02-12 12:23 ` Natanael 2015-02-12 12:49 ` Mike Hearn 2015-02-12 13:02 ` Natanael 2015-02-12 13:44 ` Mike Hearn 2015-02-12 14:36 ` Natanael 2015-02-12 14:53 ` Mike Hearn 2015-02-12 15:20 ` Natanael 2015-02-12 15:30 ` Justus Ranvier 2015-02-12 13:36 ` Oleg Andreev 2015-02-12 12:52 ` Alex Mizrahi 2015-02-12 13:18 ` Mike Hearn 2015-02-12 13:45 ` Alex Mizrahi 2015-02-12 13:52 ` Mike Hearn 2015-02-12 14:04 ` Tamas Blummer 2015-02-12 14:16 ` Mike Hearn 2015-02-12 14:25 ` Tamas Blummer 2015-02-12 23:08 ` Tom Harding 2015-02-12 14:32 ` Alex Mizrahi 2015-02-12 15:15 ` Mike Hearn 2015-02-12 15:32 ` Natanael 2015-02-12 15:42 ` Mike Hearn 2015-02-12 15:54 ` Natanael 2015-02-12 16:57 ` Btc Drak 2015-02-12 17:24 ` Oleg Andreev 2015-02-12 18:11 ` Justus Ranvier 2015-02-12 18:37 ` Allen Piscitello 2015-02-12 19:15 ` Alan Reiner 2015-02-12 19:34 ` Justus Ranvier 2015-02-12 19:45 ` Peter Todd 2015-02-12 19:49 ` Justus Ranvier 2015-02-12 19:47 ` Allen Piscitello 2015-02-12 19:52 ` Justus Ranvier 2015-02-12 20:02 ` Natanael 2015-02-12 20:36 ` Allen Piscitello 2015-02-14 14:47 ` Ross Nicoll 2015-02-12 20:06 ` Peter Todd 2015-02-12 19:49 ` Gregory Maxwell 2015-02-12 20:18 ` Peter Todd 2015-02-13 11:34 ` Mike Hearn 2015-02-12 12:54 ` Tamas Blummer 2015-02-12 14:42 ` Alex Mizrahi 2015-02-12 15:27 ` Jeff Garzik 2015-02-15 21:25 ` Troy Benjegerdes 2015-02-15 21:40 ` Adam Gibson 2015-02-19 8:56 ` Troy Benjegerdes 2015-02-21 19:09 ` Jorge Timón 2015-02-21 20:30 ` Mark Friedenbach 2015-02-21 22:47 ` Jeff Garzik 2015-02-22 1:15 ` Peter Todd 2015-02-22 3:25 ` Jorge Timón 2015-02-22 4:06 ` Jeff Garzik 2015-02-22 11:41 ` Eric Lombrozo 2015-02-22 12:06 ` Eric Lombrozo 2015-02-22 13:41 ` Eric Lombrozo 2015-02-22 13:53 ` Peter Todd 2015-02-22 23:29 ` Eric Lombrozo 2015-02-24 1:11 ` Jeff Garzik 2015-03-01 17:59 ` Troy Benjegerdes 2015-03-01 19:05 ` Neil Fincham 2015-03-01 17:44 ` Troy Benjegerdes 2015-02-12 16:15 ` Lawrence Nahum 2015-02-12 18:14 ` Tom Harding 2015-02-12 21:40 ` Josh Lehan 2015-02-22 16:36 ` Tom Harding 2015-02-22 17:12 ` Peter Todd 2015-02-22 19:25 ` Tom Harding 2015-02-22 21:50 ` Peter Todd 2015-05-04 4:36 ` [Bitcoin-development] New release of replace-by-fee for Bitcoin Core v0.10.1 Peter Todd 2015-05-05 2:23 ` Kevin Greene 2015-05-23 18:26 ` [Bitcoin-development] Replace-by-fee v0.10.2 - Serious DoS attack fixed! - Also novel variants of existing attacks w/ Bitcoin XT and Android Bitcoin Wallet Peter Todd
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox