Jorge Timón [ARCHIVE] on Nostr: 📅 Original date posted:2015-10-05 📝 Original message:On Mon, Oct 5, 2015 at ...

📅 Original date posted:2015-10-05
📝 Original message:On Mon, Oct 5, 2015 at 2:10 PM, Mike Hearn <hearn at vinumeris.com> wrote:
> Hi Jorge,
>
> I'm glad we seem to be reaching agreement that hard forks aren't so bad
> really and can even have advantages. It seems the remaining area of
> disagreement is this rollout specifically.
>>
>> a non-upgraded full node and an upgraded full will converge on what they
>> see: "the most-work valid chain" will be the same for both.
>
> Indeed it will, but the point of fully verifying is to not converge with the
> miner majority, if something goes wrong and they aren't following the same
> rules as you. Defining "work" as "converge with miner majority" is fine for
> SPV wallets and a correct or at least reasonable definition. But not for
> fully verifying nodes, where non-convergence is an explicit design goal!
> That's the only thing that stops miners awarding themselves infinite free
> money!

As Greg explained to you repeatedly, a softfork won't cause a
non-upgraded full node to start accepting blocks that create more
subsidy than is valid.
It's only the new rule (in this case, BIP65) that they won't validate.
That's very different security from an SPV node, and as Greg also
explained, SPV nodes could be much more secure than bitcoinj nodes
(they could, for example, validate the coinbase transaction of every
block).
If a non-upgraded node it's not a "full node" for you, that's fine,
but it is for everyone else. So please stop confusing other people.
Assuming the majority of the hashrate upgraded, there's almost no risk
for non-upgraded full nodes.

>> Are you going to produce a bip65 hardfork alternative to try to convince
>> people of its advantages over bip65 (it is not clear to me how you include a
>> new script operand via hardfork)?
>
> No, I'm focused on the block size issue right now. I don't think there's
> much point in improving the block chain protocol if most users are going to
> be unable to use it. But the modification is simple, right? You just replace
> this bit:
>
> CHECKLOCKTIMEVERIFY redefines the existing NOP2 opcode
>
> with this
>
> CHECKLOCKTIMEVERIFY defines a new opcode (0xc0)
>
> and that's it. The section upgrade and testing plan only says TBD so that
> part doesn't even need to change at all, as it's not written yet.

Thanks, I wasn't aware that there was room for new opcodes that
weren't noops already.
Can you give an example of an attack in which a non-upgraded full node
wallet is defrauded with BIP65 but could not with the hardfork
alternative (that nobody seems to be willing to implement)?
Please, don't assume 0 confirmation transactions or similar
unreasonable assumptions (ie see section 11 "Calculations" of the
Bitcoin whitepaper).