Peter Todd [ARCHIVE] on Nostr: 📅 Original date posted:2015-07-04 📝 Original message:On Fri, Jul 03, 2015 at ...
📅 Original date posted:2015-07-04
📝 Original message:On Fri, Jul 03, 2015 at 10:17:38PM -0700, Raystonn wrote:
Yeah, I was really surprised when I found out today that bitcoinj
doesn't implement any of the soft-fork code. There's no excuse for not
doing that frankly. :(
> <p dir="ltr">SPV clients are at risk in scenarios like this. We should encourage them to check node versions against the minimum required for safety. This check should be upgraded when new BIPs go into effect. It won't help against malicious nodes. But it will help in cases such as today's.<br>
> </p>
> <div class="gmail_quote">On 3 Jul 2015 8:17 pm, Gregory Maxwell <gmaxwell at gmail.com> wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>
>
>
> <div>
> <div>On Sat, Jul 4, 2015 at 3:11 AM, Raystonn <raystonn@hotmail.com> wrote:<br />
> > We need some analysis on why this has happened. It appears the larger hashrate is violating BIP66. Thus it appears the network is rejecting this BIP, though potentially accidentally. If this is an accident, how is such a large portion of hashrate forking, and what can we do to avoid this in the future?<br />
> <br />
> A near majority of the hashrate on the network appears to be SPV mining.<br />
> <br />
> Btcnuggets was a non-upgraded miner that produced an invalid block<br />
> after the lock in and f2pool and antpool have been extending it.<br />
> Fortunately their extension contains no transactions (an artifact of<br />
> SPV mining). Obviously a complete understanding is going to take some<br />
> time; though I would note that this general failure mode was one we<br />
> were aware of and is part of the reason the treshold is so high.<br />
> </div>
> </div>
>
> </blockquote></div>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
'peter'[:-1]@petertodd.org
000000000000000014870ea5d966efbae21588be363949de7cb3838f42b00e2f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 646 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/f9c7ec74/attachment.sig>;
📝 Original message:On Fri, Jul 03, 2015 at 10:17:38PM -0700, Raystonn wrote:
Yeah, I was really surprised when I found out today that bitcoinj
doesn't implement any of the soft-fork code. There's no excuse for not
doing that frankly. :(
> <p dir="ltr">SPV clients are at risk in scenarios like this. We should encourage them to check node versions against the minimum required for safety. This check should be upgraded when new BIPs go into effect. It won't help against malicious nodes. But it will help in cases such as today's.<br>
> </p>
> <div class="gmail_quote">On 3 Jul 2015 8:17 pm, Gregory Maxwell <gmaxwell at gmail.com> wrote:<br type='attribution'><blockquote class="quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
>
>
>
> <div>
> <div>On Sat, Jul 4, 2015 at 3:11 AM, Raystonn <raystonn@hotmail.com> wrote:<br />
> > We need some analysis on why this has happened. It appears the larger hashrate is violating BIP66. Thus it appears the network is rejecting this BIP, though potentially accidentally. If this is an accident, how is such a large portion of hashrate forking, and what can we do to avoid this in the future?<br />
> <br />
> A near majority of the hashrate on the network appears to be SPV mining.<br />
> <br />
> Btcnuggets was a non-upgraded miner that produced an invalid block<br />
> after the lock in and f2pool and antpool have been extending it.<br />
> Fortunately their extension contains no transactions (an artifact of<br />
> SPV mining). Obviously a complete understanding is going to take some<br />
> time; though I would note that this general failure mode was one we<br />
> were aware of and is part of the reason the treshold is so high.<br />
> </div>
> </div>
>
> </blockquote></div>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
--
'peter'[:-1]@petertodd.org
000000000000000014870ea5d966efbae21588be363949de7cb3838f42b00e2f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 646 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150704/f9c7ec74/attachment.sig>;