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

2015-03-01 Thread Neil Fincham
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

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

2015-03-01 Thread Troy Benjegerdes
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

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

2015-03-01 Thread Troy Benjegerdes
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

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

2015-02-23 Thread Jeff Garzik
On Sun, Feb 22, 2015 at 6:29 PM, Eric Lombrozo elombr...@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

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

2015-02-22 Thread Eric Lombrozo
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 elombr...@gmail.com wrote: It seems to me we're confusing two completely different motivations for

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

2015-02-22 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@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

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

2015-02-22 Thread Eric Lombrozo
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

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

2015-02-22 Thread Peter Todd
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

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

2015-02-22 Thread Tom Harding
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

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

2015-02-22 Thread Eric Lombrozo
On Sunday, February 22, 2015, Peter Todd p...@petertodd.org wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 22 February 2015 08:41:56 GMT-05:00, Eric Lombrozo elombr...@gmail.com javascript:; wrote: In case it wasn't clear in my earlier post, there's of course a third

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

2015-02-21 Thread Jeff Garzik
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.

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

2015-02-21 Thread Peter Todd
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 21 February 2015 17:47:28 GMT-05:00, Jeff Garzik jgar...@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

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

2015-02-21 Thread Jorge Timón
On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@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

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

2015-02-21 Thread Jeff Garzik
On Sat, Feb 21, 2015 at 10:25 PM, Jorge Timón jti...@jtimon.cc wrote: On Sat, Feb 21, 2015 at 11:47 PM, Jeff Garzik jgar...@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

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

2015-02-21 Thread Mark Friedenbach
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 jti...@jtimon.cc wrote: I agree scorched hearth is a really bad name for the 0 conf protocol based on game theory. I would have

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

2015-02-21 Thread Jorge Timón
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

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

2015-02-15 Thread Troy Benjegerdes
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

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

2015-02-15 Thread Troy Benjegerdes
On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: On Feb 12, 2015, at 9:16 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: Why don't you use getrawmempool RPC call to synchronize mempool contents? Since RPC interface does not scale to serve a multi user service. In

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

2015-02-14 Thread Ross Nicoll
-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

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

2015-02-13 Thread Mike Hearn
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

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

2015-02-12 Thread Peter Todd
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.

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

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 07:49:29PM +, Gregory Maxwell wrote: One challenge is that without rather smart child-pays-for-parent logic the positive argument for replace by fee doesn't really work. That's actually incorrect now, as a mechanism for implementing scorched-earth without

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

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

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

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 07:34:22PM +, Justus Ranvier wrote: In addition, I'll add that there is an assumption that honest actors can not alter their behavior in response to changing conditions. Since scorched-earth solutions to problems are apparently acceptable now, what would stop more

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

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

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

2015-02-12 Thread Natanael
On Thu, Feb 12, 2015 at 8:52 PM, Justus Ranvier justusranv...@riseup.net wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 02/12/2015 07:47 PM, Allen Piscitello wrote: Nothing will stop that. Bitcoin needs to deal with those issues, not stick our heads in the sand and pretend they

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

2015-02-12 Thread Tom Harding
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

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

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

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

2015-02-12 Thread Allen Piscitello
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

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

2015-02-12 Thread Alan Reiner
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

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

2015-02-12 Thread Gregory Maxwell
On Thu, Feb 12, 2015 at 1:18 PM, Mike Hearn m...@plan99.net wrote: history. Lots of miners have dropped out due to hardware obsolescence, yet massive double spending hasn't happened. How many thousands of BTC must be stolen by miners before you'd agree that it has, in fact, happened?

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

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

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

2015-02-12 Thread Allen Piscitello
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

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

2015-02-12 Thread Tamas Blummer
On Feb 12, 2015, at 9:16 AM, Alex Mizrahi alex.mizr...@gmail.com wrote: Why don't you use getrawmempool RPC call to synchronize mempool contents? Since RPC interface does not scale to serve a multi user service. In absence of better alternative, the interfaces used by a proprietary

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

2015-02-12 Thread Josh Lehan
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

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

2015-02-12 Thread Tom Harding
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

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

2015-02-12 Thread Alex Mizrahi
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

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

2015-02-12 Thread Peter Todd
On Thu, Feb 12, 2015 at 09:27:22AM +0100, Tamas Blummer wrote: On Feb 12, 2015, at 8:45 AM, Peter Todd p...@petertodd.org wrote: IOW, assume every transaction your border router gives you is now the one and only true transaction, and everything conflicting with it must go. You are

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

2015-02-12 Thread Oleg Andreev
On 12 Feb 2015, at 13:49, Mike Hearn m...@plan99.net wrote: If unconfirmed payments become flaky enough that people stop using them, then a portion of the Bitcoin community will find workarounds like trusted third parties, trusted hardware, whatever and will just struggle one. Other people

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

2015-02-12 Thread Tamas Blummer
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

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

2015-02-12 Thread Alex Mizrahi
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

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Tamas Blummer
On Feb 12, 2015, at 3:16 PM, Mike Hearn m...@plan99.net wrote: You can not consider the outcome resulting by replace-by-fee fraudulent, as it could be the world as observed by some. Fraudulent in what sense? Assume a wallet that sends double spend of the coin spent for services with

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

2015-02-12 Thread Alex Mizrahi
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

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

2015-02-12 Thread Natanael
Den 12 feb 2015 14:44 skrev Mike Hearn m...@plan99.net: You can prove a doublespend instantly by showing two conflicting transactions both signed by thar party. This pair can be distributed as a proof of malice globally in seconds via a push messaging mechanism. There have been lots of e-cash

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

2015-02-12 Thread Natanael
Den 12 feb 2015 13:49 skrev Mike Hearn m...@plan99.net: Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. It makes unconfirmed transactions useless in the classical Bitcoin model. Obviously if you introduce a trusted third party

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Alex Mizrahi
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

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Natanael
Den 12 feb 2015 12:58 skrev Mike Hearn m...@plan99.net: [...] Your scorched earth plan is aptly named, as it's guaranteed to make unconfirmed payments useless. Are you not counting collateralized multisignature notaries? Its an extended version of the Greenaddress.it model. NoRiskWallet:

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Tamas Blummer
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.

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Natanael
Den 12 feb 2015 15:53 skrev Mike Hearn m...@plan99.net: So you're just arguing that a notary is different to a miner, without spelling out exactly why. I'm afraid I still don't understand why you think notaries would build long term businesses but miners wouldn't, in this model. I think you

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

2015-02-12 Thread Jeff Garzik
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

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

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

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

2015-02-12 Thread Natanael
Den 12 feb 2015 16:15 skrev Mike Hearn m...@plan99.net: The first is that this setup means miners can steal arbitrary payments if they work together with the sender of the money. The model assumes this collaboration won't happen, but it will. Because no existing wallet has a double spend this

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

2015-02-12 Thread Oleg Andreev
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

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

2015-02-12 Thread Natanael
Den 12 feb 2015 16:42 skrev Mike Hearn m...@plan99.net: Remember that you aren't paying the bad pool, the bad pool is paying you. Whichever pool benefits from the scorched earth protocol can simply pick an address out of the transaction it perceived as starting the protocol, and pay that. My

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

2015-02-12 Thread Mike Hearn
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

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

2015-02-12 Thread Tamas Blummer
On Feb 12, 2015, at 9:49 AM, Peter Todd p...@petertodd.org wrote: How does my replace-by-fee patch *not* do that? Does it broadcast a double spend only if it IS replacing an earlier? If yes, I am fine with it. Tamas Blummer signature.asc Description: Message signed with OpenPGP using

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

2015-02-11 Thread Tamas Blummer
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

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

2015-02-11 Thread Peter Todd
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