Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Nick Johnson via bitcoin-dev]

On Thu, Jun 8, 2017 at 6:44 AM Conner Fromknecht <con...@enigma.co> wrote:

> I don't normally post here, but I'm sorry, if you don't see those two as
> equal, then I think you have misunderstood the *entire* value proposition
> of cryptocurrencies.
>
> The state of any cryptocurrency should entirely (and only) be defined by
> its ledger. If the state of the system can be altered outside of the rules
> governing its ledger, then the system isn't secure.


This is true of any blockchain: you can always change the rules with the
consent of the participants.


> It doesn't matter whether the people making those changes are the ones
> that are leading the project or not. An "irregular state change" is a fancy
> term for a bailout.
>
> I'm sure I speak for more than myself in saying that an "irregular state
> change" is equivalent to modifying the underlying ledger. Let's not let
> semantics keep us from recognizing what actually took place.
>

It's not; modifying the ledger would rewrite history, erasing the record of
the original transactions. That's a fundamentally different operation, both
technically and semantically.


> -Conner
>
> On Wed, Jun 7, 2017 at 14:14 Nick Johnson via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Jun 7, 2017 at 5:27 PM Tao Effect <cont...@taoeffect.com> wrote:
>>
>>> Nick,
>>>
>>> Please don't spread misinformation. Whatever you think of the DAO hard
>>> fork, it's a simple fact that the Ethereum ledger was not edited.
>>>
>>>
>>> This sort of email is unhelpful to this conversation, and it certainly
>>> doesn't help with the perception that Ethereum is nothing but a bunch of
>>> hypocritical Bankers 2.0.
>>>
>>
>>
>>>
>>> Everyone knows you didn't edit Ethereum Classic, but the the hard fork,
>>> which was re-branded as Ethereum, was edited.
>>>
>>
>> That's not what I was suggesting. My point is that the ledger was never
>> edited. An 'irregular state change' was added at a specific block height,
>> but the ledger remains inviolate.
>>
>> I'm sure I don't have to explain the difference between the ledger and
>> the state to you, or why it's significant that the ledger wasn't (and can't
>> be, practically) modified.
>>
>> -Nick
>>
>>
>>> - Greg
>>>
>>> --
>>> Please do not email me anything that you are not comfortable also sharing 
>>> with
>>> the NSA.
>>>
>>> On Jun 7, 2017, at 6:25 AM, Nick Johnson <n...@ethereum.org> wrote:
>>>
>>> On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev <
>>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>>
>>>> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
>>>> <bitcoin-dev@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.
>>>
>>>
>>> Please don't spread misinformation. Whatever you think of the DAO hard
>>> fork, it's a simple fact that the Ethereum ledger was not edited.
>>>
>>> -Nick Johnson
>>>
>>>
>>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Nick Johnson via bitcoin-dev]

On Wed, Jun 7, 2017 at 5:27 PM Tao Effect  wrote:

> Nick,
>
> Please don't spread misinformation. Whatever you think of the DAO hard
> fork, it's a simple fact that the Ethereum ledger was not edited.
>
>
> This sort of email is unhelpful to this conversation, and it certainly
> doesn't help with the perception that Ethereum is nothing but a bunch of
> hypocritical Bankers 2.0.
>


>
> Everyone knows you didn't edit Ethereum Classic, but the the hard fork,
> which was re-branded as Ethereum, was edited.
>

That's not what I was suggesting. My point is that the ledger was never
edited. An 'irregular state change' was added at a specific block height,
but the ledger remains inviolate.

I'm sure I don't have to explain the difference between the ledger and the
state to you, or why it's significant that the ledger wasn't (and can't be,
practically) modified.

-Nick


> - Greg
>
> --
> Please do not email me anything that you are not comfortable also sharing with
> the NSA.
>
> On Jun 7, 2017, at 6:25 AM, Nick Johnson  wrote:
>
> On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
>>  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.
>
>
> Please don't spread misinformation. Whatever you think of the DAO hard
> fork, it's a simple fact that the Ethereum ledger was not edited.
>
> -Nick Johnson
>
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Replay attacks make BIP148 and BIP149 untennable

[Nick Johnson via bitcoin-dev]

On Wed, Jun 7, 2017 at 12:02 AM Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Tue, Jun 6, 2017 at 10:39 PM, Tao Effect via bitcoin-dev
>  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.


Please don't spread misinformation. Whatever you think of the DAO hard
fork, it's a simple fact that the Ethereum ledger was not edited.

-Nick Johnson
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP proposal draft: BIP43 "purpose" allocation for Ethereum

[Nick Johnson via bitcoin-dev]

  BIP: bip-nickjohnson-ethereum-purpose
  Layer: Applications
  Title: Ethereum purpose allocation for Deterministic Wallets
  Author: Nick Johnson 
  Status: Proposed
  Type: Standards Track
  Created: 2017-04-12


==Abstract==

This BIP defines a logical hierarchy for deterministic wallets on the Ethereum
blockchain based on an algorithm described in BIP-0032 (BIP32 from now on) and
purpose scheme described in BIP-0043 (BIP43 from now on).

This BIP is a particular application of BIP43.

==Motivation==

Because Ethereum is based on account balances rather than UTXO, the hierarchy
defined by BIP44 is poorly suited. As a result, several competing
derivation path strategies have sprung up for deterministic wallets, resulting
in inter-client incompatibility. This BIP seeks to provide a path to standardise
this in a fashion better suited to Ethereum's unique requirements.

==Path levels==

We define the following 2 levels in BIP32 path:


m / purpose' / subpurpose' / *


Apostrophe in the path indicates that BIP32 hardened derivation is used.

Each level has a special meaning, described in the chapters below.

===Purpose===

Purpose is a constant set to the hardened value of the BIP number assigned to
this BIP (equivalently, the BIP number, bitwise ORed with 0x8000) following
the BIP43 recommendation.
It indicates that the subtree of this node is used according to this
specification.

Hardened derivation is used at this level.

===Subpurpose===
Subpurpose is set to the EIP number specifying the remainder of the BIP32
derivation path. This permits new Ethereum-focused applications of
deterministic wallets without needing to interface with the BIP process.

Hardened derivation is used at this level.

==Reference== * [[bip-0032.mediawiki|BIP32 - Hierarchical Deterministic
Wallets]] * [[bip-0043.mediawiki|BIP43 - Purpose Field for Deterministic
Wallets]]
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev