Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!

From: digitsu@gmail•com
To: "Anthony Towns" <aj@erisian•com.au>
Cc: bitcoin-dev@lists•linuxfoundation.org
Subject: Re: [bitcoin-dev] Let's deploy BIP65 CHECKLOCKTIMEVERIFY!
Date: Mon, 12 Oct 2015 17:08:49 -0700 (PDT)	[thread overview]
Message-ID: <1444694928847.16a3b127@Nodemailer> (raw)
In-Reply-To: <20151012170637.GA21399@navy>

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

Thanks AJ,

That is a must more concise example, which I think makes it very clear all the variables at play. 

I agree with its conclusion. 

Though I'm wondering about its actual significance in ability to do harm as with 5% hash power we would have to wait quite a long time before such a block was created and it would be unpredictable when exactly this would occur, and in order to actually execute such a double spend maliciously you would have to 1) notice that such a block was mined and 2) be in a position to double spend a payment with a merchant for physical goods who you would know was using an SPV wallet at that exact time, correct? (By deliberately publishing a txn which would be blocked by the upgraded network)

Isn't that in itself unlikely enough to make this form of double spend unlikely to be exploitable?

Perhaps with malicious wallet software which always publishes "bad" (will be mostly rejected) txn first and then retries with a normal one?

But I agree with you that if the risk is there why not avoid it if possible.  

—
Regards,

On Tue, Oct 13, 2015 at 2:06 AM, Anthony Towns via bitcoin-dev
<bitcoin-dev@lists•linuxfoundation.org> wrote:

> On Mon, Oct 12, 2015 at 12:02:51AM -0700, digitsu412 via bitcoin-dev wrote:
>> First I think your unsaid assumption about the fragility of a soft
>> fork showing incorrect confirmations is dependent on the percentage
>> of hash power that didn't upgrade.  If using your same numbers this
>> was only 5% of the hash power, the attack is effectively not effective
>> (u less the attacker knew an exact merchant that was unfortunately on
>> the minority of the network. 
> Actually, just to take this scenario more explicitly...
> Say you've got 5% of hashpower running on old software, along with,
> say, 1500 nodes; and meanwhile you've got 95% of hashpower running new
> software, along with 4000 nodes.
> There's still about 750 nodes running 0.9 or 0.8 of 5400 total according
> to bitnodes.21.co/nodes, so those numbers seems at least plausible to
> me for the first week or two after a soft-fork is activated.
> Eventually an old-rules block gets found by the 5% hashpower. The 4000
> new nodes and 95% of hashpower ignore it, of course. With 8 random
> connections, old nodes should have 92% chance of seeing an old node
> as a peer, so I think around ~1300 of them should still be a connected
> subgraph, and the old-rules block should get propogated amongst them
> (until two new-rules blocks come along and orphan it).
> An SPV client with 12 random connections here has 96% chance of having one
> of the ~1300 old nodes as a peer, and if so, will see the old-rules block,
> that will be orphaned, and may be at risk from double-spends as a result.
> So I think even with just 5% hashpower and ~30% of nodes left running
> the old version, a "damaging soft fork" still poses a fairly high risk to
> someone receiving payments via an SPV client, and trusting transactions
> with few confirmations.
> Cheers,
> aj
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists•linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[-- Attachment #2: Type: text/html, Size: 3826 bytes --]