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

[Eric Lombrozo <elombrozo@gmail.com>]

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

I should also add that I think many in this space believe they have assessed the risk as acceptable but haven’t really considered how to cap potential losses nor made contingency plans for when the inevitable attacks *do* come.

- Eric Lombrozo

> On Jun 20, 2015, at 4:47 PM, Eric Lombrozo <elombrozo@gmail.com> wrote:
> 
> 
>> On Jun 20, 2015, at 4:16 PM, Jorge Timón <jtimon@jtimon.cc> wrote:
>> 
>> On Fri, Jun 19, 2015 at 5:37 PM, Eric Lombrozo <elombrozo@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


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