public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Eric Lombrozo <elombrozo@gmail•com>
To: Peter Todd <pete@petertodd•org>
Cc: bitcoin-development@lists•sourceforge.net, justusranvier@riseup•net
Subject: Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee
Date: Fri, 19 Jun 2015 08:37:10 -0700	[thread overview]
Message-ID: <04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com> (raw)
In-Reply-To: <20150619151127.GA11263@savin.petertodd.org>

[-- Attachment #1: Type: text/plain, Size: 4718 bytes --]

OK, a few things here:

The Bitcoin network was designed (or should be designed) with the requirement that it can withstand deliberate double-spend attacks that can come from anywhere at any time…and relaxing this assumption without adequately assessing the risk (i.e. I’ve never been hacked before so I can assume it’s safe) is extremely dangerous at best and just horrid security practice at worst. Your users might not thank you for not getting hacked - but they surely will not like it when you DO get hacked…and lack a proper recovery plan.

Furthermore, the protocol itself makes no assumptions regarding the intentions behind someone signing two conflicting transactions. There are many potential use cases where doing so could make a lot of sense. Had the protocol been designed along the lines of, say, tendermint…where signing multiple conflicting blocks results in loss of one’s funds…then the protocol itself disincentivizes the behavior without requiring any sort of altruistic, moralistic assumptions. That would also mean we’d need a different mechanism for the use cases that things like RBF address.

Thirdly, taken to the extreme, the viewpoint of “signing a conflicting transaction is fraud and vandalism” means that if for whatever reason you attempt to propagate a transaction and nobody mines it for a very long time, you’re not entitled to immediately reclaim those funds…they must remain in limbo forever.


- Eric Lombrozo


> On Jun 19, 2015, at 8:11 AM, Peter Todd <pete@petertodd•org> wrote:
> 
> On Fri, Jun 19, 2015 at 03:00:57PM +0000, justusranvier@riseup•net wrote:
>> On 2015-06-19 10:39, Peter Todd wrote:
>> 
>>     Yesterday F2Pool, currently the largest pool with 21% of the hashing
>>     power, enabled full replace-by-fee (RBF) support after discussions
>> with
>>     me. This means that transactions that F2Pool has will be replaced if
>> a
>>     conflicting transaction pays a higher fee. There are no requirements
>> for
>>     the replacement transaction to pay addresses that were paid by the
>>     previous transaction.
>> 
>> 
>> Intentional fraud is a bad thing to add to a financial protocol.
>> 
>> A user who creates conflicting transactions, one that pays someone else
>> and another which does not pay them, and broadcasts both of them, has
>> just self-incriminated themselves by producing prima facie evidence of
>> fraud.
> 
> Depends.
> 
> If you ask me to pay you 1BTC at address A and I create tx1 that pays
> 1BTC to A1 and 2BTC of chain to C, what's wrong with me creating tx2
> that still pays 1BTC to A, but now only pays 1.999BTC to C? I'm not
> defrauding you, I'm just reducing the value of my change address to pay
> a higher fee. Similarly if I now need to pay Bob 0.5BTC, I can create
> tx3 paying 1BTC to A, 0.5BTC to B, and 1.498BTC to C.
> 
> Yet from the point of view of an external observer they have no idea why
> the transaction outputs reduced in size, nor any way of knowing if fraud
> did or did not occur.
> 
> Equally, maybe you tell me "Actually, just give me 0.5BTC to cancel out
> that debt", in which case I'm not breaking any contract at all by giving
> you less money than I first promised - the contract has changed.
> 
> Again, none of this can or should be observable to anyone other than the
> parties directly involved.
> 
>> It may be the case that since Bitcoin spans multiple legal jurisdictions
>> and can be use anonymously that the victims of such fraud can not rely
>> on legal recourse, and it may also be the case that proof of work is how
>> Bitcoin deals with the aforementioned factors, but regardless
>> un-prosecutable fraud is still fraud and anyone who encourages it should
>> be recognied as a bad actors.
>> 
>> Committing vandalism and encouraging fraud to prove a point may be
>> something the network can't stop on a technical level, but there's no
>> reason not to call it out for what it is.
> 
> What do you think of Bitcoin XT then? It relays double-spends, which
> makes it much easier to get double-spends to miners than before. In
> particular you see a lot of zero-fee transactions being replaced by
> fee-paying transactions, relayed through Bitcoin XT nodes and then
> mined. Is that encouraging fraud?
> 
> --
> 'peter'[:-1]@petertodd.org
> 000000000000000003932458055c68d4ee2b6d68441c4764efbdf6b0b1683717
> ------------------------------------------------------------------------------
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development@lists•sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[-- Attachment #2: Message signed with OpenPGP using GPGMail --]
[-- Type: application/pgp-signature, Size: 842 bytes --]

  reply	other threads:[~2015-06-19 15:37 UTC|newest]

Thread overview: 79+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-19 10:39 Peter Todd
2015-06-19 13:33 ` Gavin Andresen
2015-06-19 13:52   ` Peter Todd
2015-06-19 14:00     ` Adrian Macneil
2015-06-19 14:08       ` Peter Todd
2015-06-19 14:30         ` Adrian Macneil
2015-06-19 14:59           ` Peter Todd
2015-06-19 15:20             ` Adrian Macneil
2015-06-19 15:40               ` Peter Todd
2015-06-19 16:18                 ` Adrian Macneil
2015-06-19 16:37                   ` Peter Todd
2015-06-19 20:39                   ` Matt Whitlock
2015-06-19 21:05                     ` Frank Flores
2015-06-19 21:15                       ` Jeff Garzik
2015-06-20  0:47                     ` Andreas Petersson
2015-06-20  1:09                       ` Mark Friedenbach
2015-06-20  1:23                         ` Aaron Voisine
2015-06-20  3:07                           ` Eric Lombrozo
2015-06-20  3:48                           ` Luke Dashjr
2015-06-20  4:02                             ` Eric Lombrozo
2015-06-20 16:43                               ` Ivan Brightly
2015-06-20 17:38                                 ` Cameron Hejazi
2015-06-19 14:40       ` Chun Wang
2015-06-19 15:22         ` Adrian Macneil
2015-06-19 13:33 ` Stephen Morse
2015-06-19 13:37   ` Chun Wang
2015-06-19 13:48     ` Peter Todd
2015-06-19 14:16     ` Lawrence Nahum
2015-06-19 13:40   ` Adrian Macneil
2015-06-19 13:44   ` Peter Todd
2015-06-19 13:52     ` Chun Wang
2015-06-19 15:43       ` Jeff Garzik
2015-06-19 19:49       ` Jeffrey Paul
2015-06-19 15:42     ` Jeff Garzik
2015-06-19 16:15     ` Peter Todd
2015-06-19 15:00 ` justusranvier
2015-06-19 15:11   ` Peter Todd
2015-06-19 15:37     ` Eric Lombrozo [this message]
2015-06-19 15:53       ` justusranvier
2015-06-19 16:36         ` Matt Whitlock
2015-06-19 16:42           ` Eric Lombrozo
2015-06-19 16:46             ` Matt Whitlock
2015-06-19 16:53             ` Peter Todd
2015-06-19 16:54             ` justusranvier
2015-06-19 17:00             ` Tier Nolan
2015-06-20 23:20             ` Jorge Timón
2015-06-20 23:37               ` justusranvier
2015-06-21  0:19                 ` Eric Lombrozo
2015-06-21  0:27                   ` justusranvier
2015-06-21  0:36                     ` Eric Lombrozo
2015-06-21  0:54                     ` Eric Lombrozo
2015-06-21  5:56                       ` Tom Harding
2015-06-21  6:45                       ` Jeff Garzik
2015-06-21  7:42                         ` Eric Lombrozo
2015-06-21  8:35                           ` Eric Lombrozo
2015-06-21  8:41                           ` Btc Drak
2015-06-21  8:51                             ` Eric Lombrozo
2015-06-21 19:49                           ` Jeff Garzik
2015-06-21 18:23                       ` Aaron Voisine
2015-06-19 16:44           ` justusranvier
2015-06-19 17:40             ` Jeff Garzik
2015-06-19 17:48               ` justusranvier
2015-06-19 17:50                 ` Jeff Garzik
2015-06-19 18:00                   ` justusranvier
2015-06-19 16:50           ` Milly Bitcoin
2015-06-19 16:41         ` [Bitcoin-development] Remove Us Please Gigas Gaming Inc.
2015-06-19 18:34           ` Jameson Lopp
2015-06-19 19:55             ` John Bodeen
2015-06-19 20:01               ` Brian Hoffman
2015-06-19 20:27                 ` Jameson Lopp
2015-06-20 23:16       ` [Bitcoin-development] F2Pool has enabled full replace-by-fee Jorge Timón
2015-06-20 23:47         ` Eric Lombrozo
2015-06-20 23:52           ` Eric Lombrozo
2015-06-20 23:56           ` Eric Lombrozo
2015-06-19 15:39     ` justusranvier
2015-06-19 15:39 ` Jeff Garzik
2015-06-20 20:04 ` odinn
2015-06-21  2:11 ` Dario Sneidermanis
2015-06-21  2:23   ` Dario Sneidermanis

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=04CE3756-B032-464C-8FBD-7ACDD1A3197D@gmail.com \
    --to=elombrozo@gmail$(echo .)com \
    --cc=bitcoin-development@lists$(echo .)sourceforge.net \
    --cc=justusranvier@riseup$(echo .)net \
    --cc=pete@petertodd$(echo .)org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox