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

[Eric Lombrozo]

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
> 
> 
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon at jtimon.cc> wrote:
>> 
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo at gmail.com> wrote:
>>> 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…
>> 
>> I disagree with this premise. Please, don't take this as an argument
>> from authority fallacy, but I will cite Satoshi to express what I
>> think the assumptions while using the system should be:
>> 
>> "As long as a majority of CPU power is controlled by nodes that are
>> not cooperating to attack the network, they'll generate the longest
>> chain and outpace attackers."
>> 
>> I can't say for sure what was meant by "attacking the network" in this
>> context but I personally mean trying to rewrite valid and
>> proof-of-work-timestamped history.
>> Unconfirmed transactions are simply not part of history yet. Ordering
>> unconfirmed transactions in a consensus compatible way without a
>> universal clock is impossible, that's why we're using proof of work in
>> the first place.
>> 
>> Alternative policies are NOT attacks on the network.
> 
> Just to be clear, Jorge, I wasn’t suggesting that unconfirmed transactions are part of any sort of global consensus. In fact, they very much AREN’T. Which is exactly why it is extremely dangerous to accept unconfirmed transactions as final unless you clearly have assessed the risks and it makes sense for the particular business use case.
> 
> - Eric Lombrozo

I think the misunderstanding was in perhaps my earlier statement seemed like I was suggesting that it’s the protocol’s responsibility to protect merchants from double-spends. On the contrary - I think we agree - the protocol CANNOT make any guarantees to ANYONE until we do converge on a history. The “design” I speak of here is more on the merchant side.

- Eric Lombrozo
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150620/1ecc0abe/attachment.sig>