Re: [Bitcoin-development] F2Pool has enabled full replace-by-fee

[Eric Lombrozo <elombrozo@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 4052 bytes --]


> On Jun 20, 2015, at 5:27 PM, justusranvier@riseup.net wrote:
> 
> Signed PGP part
> On 2015-06-20 19:19, Eric Lombrozo wrote:
> >> On Jun 20, 2015, at 4:37 PM, justusranvier@riseup.net wrote:
> >>
> >> Signed PGP part
> >> On 2015-06-20 18:20, Jorge Timón wrote:
> >> > On Fri, Jun 19, 2015 at 6:42 PM, Eric Lombrozo <elombrozo@gmail.com>
> >> > wrote:
> >> >> If we want a non-repudiation mechanism in the protocol, we should
> >> >> explicitly define one rather than relying on “prima facie”
> >> >> assumptions. Otherwise, I would recommend not relying on the existence
> >> >> of a signed transaction as proof of intent to pay…
> >> >
> >> > Non-repudiation can be built on top of the payment protocol layer.
> >>
> >>
> >> Non-repudiation is an intrinsic property of the ECDSA signatures which
> >> Bitcoin uses - it's not a feature that needs to be built.
> >>
> >> There's no way to accidentally sign a transaction and accidentally
> >> announce it publicly. There is no form of third-party error that can
> >> result in a payee receiving an erroneous contract.
> >>
> >>
> >
> > Justus,
> >
> > We don’t even have a concept of identity in the Bitcoin protocol, let
> > alone non-repudiation. What good is non-repudiation if there’s no way
> > to even associate a signature with a legal entity?
> >
> > Sure, we could use the ECDSA signatures in transactions as part of a
> > non-repudiation scheme - but the recipient would have to also have a
> > means to establish the identity of the sender and associate it with
> > the the transaction.
> >
> >
> > Furthermore, in light of the fact that there *are* fully legitimate
> > use cases for sending conflicting transactions…and the fact that
> > determination of intent isn’t always entirely clear…we should refrain
> > from attaching any further significance transaction signatures other
> > than that “the sender was willing to have it included in the
> > blockchain if a miner were to have seen it and accepted it…but perhaps
> > the sender would have changed their mind before it actually did get
> > accepted.”
> 
> Bitcoin has no concept of identity, but in any type of commercial
> transaction the parties involved must know some minimal amount of
> identity information in order to transact at all.
> 
> Except for some identifiable special cases, I think a payee is perfectly
> justified in treating a double spend of a payment sent to them as part
> of a commercial transaction as a fraud attempt and employing whatever
> non-Bitcoin recourse mechanisms, if any, they have access to.
> 
> From the perspective of the network, the obviously correct action for
> any node or miner is to relay the first version of any transaction they
> see. The primary purpose of mining is to resolve this
> otherwise-unresolvable problem of determining which transaction among a
> set of conflicting transactions happened first.
> 
> If a node or miner wants to deviate from the obviously correct
> behaviour, and if they want to avoid harming the value of the network,
> they should be particularly careful to make sure their deviation from
> "first seen" doesn't introduce harmful unintended side effects, like
> making fraud easier.
> 

The contract between the buyer and seller is actually outside the Bitcoin network. Yes, a merchant that gets cheated could seek some other recourse in such an event…but the behavior you’re claiming as “obviously correct” is NOT obviously correct.  In fact, there are arguments against this “obviously correct” way even if we were to accept the premise that the signature implies a promise to pay (which I think many reasonable individuals would also dispute). For instance, by relaying conflicting transactions it makes it potentially easier for others to discover the double-spend attempt (of course, this requires wallets to not be lazy about this…perhaps such relays could be flagged or placed in a special message type).

- Eric Lombrozo




[-- Attachment #1.2: Type: text/html, Size: 5772 bytes --]

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