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

[digitsu@gmail.com]

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

Thanks for that great breakdown Anthony. I think it helps a lot of us get a better handle on the matter without getting too technical. 


A couple of questions on some of the points you made I'd like to put out there:




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. 




-- snip --


 - non-upgraded bitcoin nodes: total breakage. there will be a push

   alert telling you to upgrade. anyone who doesn't will think they're

   tracking "bitcoin" but will actually be tracking a new "bitcoin-old"

   altcoin. most non-upgraded miners will presumably realise they're

   wasting hashpower and stop doing this pretty quick; and remaining

   miners will only create blocks very slowly due to sudden reduced

   hashpower, without possibility of difficulty adjustment. 

----




Is this true? I thought that un-upgraded nodes would just dump the new blocks from the upgraded miner majority as invalid. This how would they even know (besides the PSA) that they were on the wrong side? 




----snip---

users who

   don't uprade will try to do transactions, but won't see them confirm

   for hours or days due to lack of hashpower.






----




But only for txns for users who are using the new OP code right? Regular transactions will get relayed by both upgraded and in-upgraded nodes and miners alike. 








—
Regards,

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