Tao Effect [ARCHIVE] on Nostr: ð Original date posted:2017-06-06 ð Original message:Hey Greg, It wasn't my ...
ð
Original date posted:2017-06-06
ð Original message:Hey Greg,
It wasn't my intention to insult anyone (a bit defensive?).
Maybe this is yet another example of a recurring criticism of Core: that core doesn't community these issues very well to journalists / reports / media / community outside of this list.
Because outside of this list it's been all about those 148 coins, and almost zero mention of replay attacks.
> BIP149 is arguably something of another matter in particular because
> it has a time-frame that allows dealing with replay and other issues--
> and particularly because it has a time-frame that can allow for the
> avoidance of a meaningful fork at all.
Are there other, more reasonable / feasible ways of addressing replay attacks in Bitcoin / BIP149 scenario?
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:02 PM, Gregory Maxwell <greg at xiph.org <mailto:greg at xiph.org>> wrote:
>
> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> I believe the severity of replay attacks is going unvoiced and is not
>> understood within the bitcoin community because of their lack of experience
>> with them.
>
> Please don't insult our community-- the issues with replay were
> pointed out by us to Ethereum in advance and were cited specifically
> in prior hardfork discussions long before Ethereum started editing
> their ledger for the economic benefit of its centralized
> administrators.
>
> The lack of extensive discussion on these issues you're seeing is
> rather symptomatic of engineers that take stability seriously not
> taking BIP148 seriously; not symptomatic of people not knowing about
> them. The same concerns also applies to all these HF proposals (which
> for some reason you don't mention), arguably even stronger. The same
> basic pattern exists: There are people that just don't care about the
> technical issues who have made up their minds, and so you don't see
> technical discussion. Those people who do see the issues already
> called out the proposals as being ill-advised. Replay isn't even the
> largest of the technical issues (network partitioning, for example, is
> a much larger one).
>
> BIP149 is arguably something of another matter in particular because
> it has a time-frame that allows dealing with replay and other issues--
> and particularly because it has a time-frame that can allow for the
> avoidance of a meaningful fork at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.sig>;
ð Original message:Hey Greg,
It wasn't my intention to insult anyone (a bit defensive?).
Maybe this is yet another example of a recurring criticism of Core: that core doesn't community these issues very well to journalists / reports / media / community outside of this list.
Because outside of this list it's been all about those 148 coins, and almost zero mention of replay attacks.
> BIP149 is arguably something of another matter in particular because
> it has a time-frame that allows dealing with replay and other issues--
> and particularly because it has a time-frame that can allow for the
> avoidance of a meaningful fork at all.
Are there other, more reasonable / feasible ways of addressing replay attacks in Bitcoin / BIP149 scenario?
Cheers,
Greg
--
Please do not email me anything that you are not comfortable also sharing with the NSA.
> On Jun 6, 2017, at 4:02 PM, Gregory Maxwell <greg at xiph.org <mailto:greg at xiph.org>> wrote:
>
> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org <mailto:bitcoin-dev at lists.linuxfoundation.org>> wrote:
>> I believe the severity of replay attacks is going unvoiced and is not
>> understood within the bitcoin community because of their lack of experience
>> with them.
>
> Please don't insult our community-- the issues with replay were
> pointed out by us to Ethereum in advance and were cited specifically
> in prior hardfork discussions long before Ethereum started editing
> their ledger for the economic benefit of its centralized
> administrators.
>
> The lack of extensive discussion on these issues you're seeing is
> rather symptomatic of engineers that take stability seriously not
> taking BIP148 seriously; not symptomatic of people not knowing about
> them. The same concerns also applies to all these HF proposals (which
> for some reason you don't mention), arguably even stronger. The same
> basic pattern exists: There are people that just don't care about the
> technical issues who have made up their minds, and so you don't see
> technical discussion. Those people who do see the issues already
> called out the proposals as being ill-advised. Replay isn't even the
> largest of the technical issues (network partitioning, for example, is
> a much larger one).
>
> BIP149 is arguably something of another matter in particular because
> it has a time-frame that allows dealing with replay and other issues--
> and particularly because it has a time-frame that can allow for the
> avoidance of a meaningful fork at all.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.html>;
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 801 bytes
Desc: Message signed with OpenPGP
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170606/6748ec9e/attachment-0001.sig>;