Re: [bitcoin-dev] Introducing a POW through a soft-fork

[Devrandom via bitcoin-dev]

A hard-fork is a situation where non-upgraded nodes reject a block mined
and relayed by upgraded nodes.  This creates a fork that cannot heal
regardless of what follows.

This proposal is not a hard-fork, because the non-upgraded node *will heal*
if the attack has less than 1/2 of the original-POW power in the long term.

The cost of such an attack is the cost of a normal "51%" attack, multiplied
by the fractional weight of the original POW (e.g. 0.75 or 0.5).

So rather than saying this is a hard-fork, I would say that this is a
soft-fork with reduced security for non-upgraded nodes. I would also say
that the reduction in security is proportional to the reduction in weight
of the original POW at the time of attack.

As mentioned before, the original-POW weight starts at 1.0 and is reduced
over a long period of time.  I would set up the transition curve so that
all nodes upgrade by the time the weight is, say, 0.75.  In reality, nodes
protecting high economic value would upgrade early.

On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> If a block that would be discarded under previous rules becomes accepted
> after a rule addition, there is no reason to not simply call the new rule a
> hard fork. IOW it's perfectly rational to consider a weaker block as
> "invalid" relative to the strong chain. As such I don't see any reason to
> qualify the term, it's a hard fork. But Peter's observation (the specific
> behavior) is ultimately what matters.
>
> e
>
> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> +1 to all of Peter Todd's comments
>
> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote:
>>
>> Some quick thoughts...
>>
>> > Hi all,
>> >
>> > Feedback is welcome on the draft below.  In particular, I want to see if
>> > there is interest in further development of the idea and also
>> interested in
>> > any attack vectors or undesirable dynamics.
>> >
>> > (Formatted version available here:
>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>> >
>> > # Soft-fork Introduction of a New POW
>>
>> First of all, I don't think you can really call this a soft-fork; I'd
>> call it a
>> "pseudo-soft-fork"
>>
>> My reasoning being that after implementation, a chain with less total
>> work than
>> the main chain - but more total SHA256^2 work than the main chain - might
>> be
>> followed by non-supporting clients. It's got some properties of a
>> soft-fork,
>> but it's security model is definitely different.
>>
>> > ### Aux POW intermediate block
>> >
>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the
>> chain
>> > alternates between the two POWs.
>> > Each aux-POW block points to the previous normal block and contains
>> > transactions just like a normal block.
>> > Each normal block points to the previous aux-POW block and must contain
>> all
>> > transactions from the aux-POW block.
>>
>> Note how you're basically proposing for the block interval to be
>> decreased,
>> which has security implications due to increased orphan rates.
>>
>> > ### Heaviest chain rule change
>> >
>> > This is a semi-hard change, because non-upgraded nodes can get on the
>> wrong
>> > chain in case of attack.  However,
>>
>> Exactly! Not really a soft-fork.
>>
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>>
>> ___
>> 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
>
> ___
> 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

[bitcoin-dev] Centralizing mining by force

[Robert Taylor via bitcoin-dev]

Forgive me if this has been asked elsewhere before, but I am trying to
understand a potential failure mode of Bitcoin mining.

A majority of miners can decide which valid blocks extend the chain. But
what would happen if a majority of miners, in the form of a cartel decided
to validly orphan any blocks made by miners outside of their group? For
example, they could soft fork a new rule where the block number is signed
by set of keys known only to the cartel, and that signature placed in the
coinbase. Miners outside of the cartel would not be able to extend the
chain.

It would be immediately obvious but still valid under the consensus rules.
What are the disincentives for such behavior and what countermeasures could
be done to stop it and ensure mining remained permissionless? I think this
is a valid concern because while it may not be feasible for one actor to
gain a majority of hash alone, it is certainly possible with collusion.

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

Re: [bitcoin-dev] Generalised Replay Protection for Future Hard Forks

[Jacob Eliosoff via bitcoin-dev]

Thanks Mats, this proposal makes sense to me (especially the idea of
fork-specific addresses).  It prevents replay across forks, and makes it
easy for client software, and thus potentially users, to specify which fork
a tx is for.  But, like other (rougher) past proposals I've seen, it does
little to prevent users from accidentally sending on the wrong fork.

Take the specific and common case of non-upgraded wallet software.  Suppose
a HF happens, and becomes the network used by 90% of users.  Will old
wallets still default to the old nForkId (10% legacy chain)?  If so, I'd
expect a lot of accidental mis-sends on that chain.

This is just a gap in your proposal, not a flaw, but it's worth thinking
about less hazard-prone ways wallets could default nForkId.  Perhaps they
could listen to all forks, and default to the one whose last (recent) block
had the highest difficulty?  Or just check those blocks to see if multiple
forks are (nontrivially) active, and if so warn the user and force them to
confirm?  Something like that.


On Nov 6, 2017 7:05 AM, "Mats Jerratsch via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:


Presented is a generalised way of providing replay protection for future
hard forks. On top of replay protection, this schema also allows for
fork-distinct addresses and potentially a way to opt-out of replay
protection of any fork, where deemed necessary (can be beneficial for some
L2 applications).

## Rationale

Currently when a hard fork happens, there is ad-hoc replay protection built
within days with little review at best, or no replay protection at all.
Often this is either resource problem, where not enough time and developers
are available to sufficiently address replay protection, or the idea that
not breaking compatibility is favourable. Furthermore, this is potentially
a recurring problem with no generally accepted solution yet. Services that
want to deal in multiple forks are expected to closely follow all projects.
Since there is no standard, the solutions differ for each project,
requiring custom code for every fork. By integrating replay protection into
the protocol, we advocate the notion of non-hostile forks.

Users are protected against accidentally sending coins on the wrong chain
through the introduction of a fork-specific incompatible address space. The
coin/token type is encoded in the address itself, removing some of the
importance around the question _What is Bitcoin?_. By giving someone an
address, it is explicitly stated _I will only honour a payment of token X_,
enforcing the idea of validating the payment under the rules chosen by the
payee.

## Iterative Forks

In this schema, any hard fork is given an incremented id, `nForkId`.
`nForkId` starts at `1`, with `0` being reserved as a wildcard. When
project X decides to make an incompatible change to the protocol, it will
get assigned a new unique `nForkId` for this fork. A similar approach like
for BIP43 can be taken here. Potentially `nForkId` can be reused if a
project has not gained any amount of traction.

When preparing the transaction for signing or validation, `nForkId` is
appended to the final template as a 4B integer (similar to [1]). Amending
BIP143, this would result in

```
Double SHA256 of the serialization of:
1. nVersion of the transaction (4-byte little endian)
2. hashPrevouts (32-byte hash)
3. hashSequence (32-byte hash)
4. outpoint (32-byte hash + 4-byte little endian)
5. scriptCode of the input (serialized as scripts inside CTxOuts)
6. value of the output spent by this input (8-byte little endian)
7. nSequence of the input (4-byte little endian)
8. hashOutputs (32-byte hash)
9. nLocktime of the transaction (4-byte little endian)
   10. sighash type of the signature (4-byte little endian)
   11. nForkId (4-byte little endian)
```


For `nForkId=0` this step is ommitted. This will immediately invalidate
signatures for any other branch of the blockchain than this specific fork.
To distinguish between `nForkId=0` and `nForkId` hardcoded into the
software, another bit has to be set in the 1B SigHashId present at the end
of signatures.

To make this approach more generic, payment addresses will contain the fork
id, depending on which tokens a payee expects payments in. This would
require a change on bech32 addresses, maybe to use a similar format used in
lightning-rfc [2]. A wallet will parse the address, it will extract
`nForkId`, and it displays which token the user is about to spend. When
signing the transaction, it will use `nForkId`, such that the transaction
is only valid for this specific token. This can be generalised in software
to the point where replay protection *and* a new address space can be
introduced for forks without breaking existing clients.

For light clients, this can be extended by enforcing the coinbase/block
header to contain the `nForkId` of the block. Then the client can
distinguish between different chains and tokens it 

Re: [bitcoin-dev] Introducing a POW through a soft-fork

[Eric Voskuil via bitcoin-dev]

If a block that would be discarded under previous rules becomes accepted after 
a rule addition, there is no reason to not simply call the new rule a hard 
fork. IOW it's perfectly rational to consider a weaker block as "invalid" 
relative to the strong chain. As such I don't see any reason to qualify the 
term, it's a hard fork. But Peter's observation (the specific behavior) is 
ultimately what matters.

e

> On Nov 6, 2017, at 12:30, Paul Sztorc via bitcoin-dev 
>  wrote:
> 
> +1 to all of Peter Todd's comments
> 
>> On Nov 6, 2017 11:50 AM, "Peter Todd via bitcoin-dev" 
>>  wrote:
>> On Wed, Nov 01, 2017 at 05:48:27AM +, Devrandom via bitcoin-dev wrote:
>> 
>> Some quick thoughts...
>> 
>> > Hi all,
>> >
>> > Feedback is welcome on the draft below.  In particular, I want to see if
>> > there is interest in further development of the idea and also interested in
>> > any attack vectors or undesirable dynamics.
>> >
>> > (Formatted version available here:
>> > https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>> >
>> > # Soft-fork Introduction of a New POW
>> 
>> First of all, I don't think you can really call this a soft-fork; I'd call 
>> it a
>> "pseudo-soft-fork"
>> 
>> My reasoning being that after implementation, a chain with less total work 
>> than
>> the main chain - but more total SHA256^2 work than the main chain - might be
>> followed by non-supporting clients. It's got some properties of a soft-fork,
>> but it's security model is definitely different.
>> 
>> > ### Aux POW intermediate block
>> >
>> > Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
>> > alternates between the two POWs.
>> > Each aux-POW block points to the previous normal block and contains
>> > transactions just like a normal block.
>> > Each normal block points to the previous aux-POW block and must contain all
>> > transactions from the aux-POW block.
>> 
>> Note how you're basically proposing for the block interval to be decreased,
>> which has security implications due to increased orphan rates.
>> 
>> > ### Heaviest chain rule change
>> >
>> > This is a semi-hard change, because non-upgraded nodes can get on the wrong
>> > chain in case of attack.  However,
>> 
>> Exactly! Not really a soft-fork.
>> 
>> --
>> https://petertodd.org 'peter'[:-1]@petertodd.org
>> 
>> ___
>> 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
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Introducing a POW through a soft-fork

[Devrandom via bitcoin-dev]

>
> Note how you're basically proposing for the block interval to be decreased,
>> which has security implications due to increased orphan rates.
>>
>
> Note that the total transaction rate and block size don't materially
> change, so I don't
> see why the orphan rate will change.  Normal blocks are constrained to have
> all of the txs of the aux blocks, so propagation time should stay the
> same.  Am I missing
> something?
>

Ah, yes, I'm missing that the expected time to find each type of block is
halved, so the orphan rate doubles.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Generalised Replay Protection for Future Hard Forks

[Mats Jerratsch via bitcoin-dev]

Presented is a generalised way of providing replay protection for future hard 
forks. On top of replay protection, this schema also allows for fork-distinct 
addresses and potentially a way to opt-out of replay protection of any fork, 
where deemed necessary (can be beneficial for some L2 applications).

## Rationale

Currently when a hard fork happens, there is ad-hoc replay protection built 
within days with little review at best, or no replay protection at all. Often 
this is either resource problem, where not enough time and developers are 
available to sufficiently address replay protection, or the idea that not 
breaking compatibility is favourable. Furthermore, this is potentially a 
recurring problem with no generally accepted solution yet. Services that want 
to deal in multiple forks are expected to closely follow all projects. Since 
there is no standard, the solutions differ for each project, requiring custom 
code for every fork. By integrating replay protection into the protocol, we 
advocate the notion of non-hostile forks.

Users are protected against accidentally sending coins on the wrong chain 
through the introduction of a fork-specific incompatible address space. The 
coin/token type is encoded in the address itself, removing some of the 
importance around the question _What is Bitcoin?_. By giving someone an 
address, it is explicitly stated _I will only honour a payment of token X_, 
enforcing the idea of validating the payment under the rules chosen by the 
payee.

## Iterative Forks

In this schema, any hard fork is given an incremented id, `nForkId`. `nForkId` 
starts at `1`, with `0` being reserved as a wildcard. When project X decides to 
make an incompatible change to the protocol, it will get assigned a new unique 
`nForkId` for this fork. A similar approach like for BIP43 can be taken here. 
Potentially `nForkId` can be reused if a project has not gained any amount of 
traction.

When preparing the transaction for signing or validation, `nForkId` is appended 
to the final template as a 4B integer (similar to [1]). Amending BIP143, this 
would result in

```
 Double SHA256 of the serialization of:
 1. nVersion of the transaction (4-byte little endian)
 2. hashPrevouts (32-byte hash)
 3. hashSequence (32-byte hash)
 4. outpoint (32-byte hash + 4-byte little endian)
 5. scriptCode of the input (serialized as scripts inside CTxOuts)
 6. value of the output spent by this input (8-byte little endian)
 7. nSequence of the input (4-byte little endian)
 8. hashOutputs (32-byte hash)
 9. nLocktime of the transaction (4-byte little endian)
10. sighash type of the signature (4-byte little endian)
11. nForkId (4-byte little endian)
```


For `nForkId=0` this step is ommitted. This will immediately invalidate 
signatures for any other branch of the blockchain than this specific fork. To 
distinguish between `nForkId=0` and `nForkId` hardcoded into the software, 
another bit has to be set in the 1B SigHashId present at the end of signatures.

To make this approach more generic, payment addresses will contain the fork id, 
depending on which tokens a payee expects payments in. This would require a 
change on bech32 addresses, maybe to use a similar format used in lightning-rfc 
[2]. A wallet will parse the address, it will extract `nForkId`, and it 
displays which token the user is about to spend. When signing the transaction, 
it will use `nForkId`, such that the transaction is only valid for this 
specific token. This can be generalised in software to the point where replay 
protection *and* a new address space can be introduced for forks without 
breaking existing clients.

For light clients, this can be extended by enforcing the coinbase/block header 
to contain the `nForkId` of the block. Then the client can distinguish between 
different chains and tokens it received on each. Alternatively, a new P2P 
message type for sending transactions could be introduced, where prevOut and 
`nForkId` is transmitted, such that the lite client can check for himself, 
which token he received.

Allowing signatures with `nForkId=1` can be achieved with a soft fork by 
incrementing the script version of SegWit, making this a fully backwards 
compatible change.

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013542.html
 

[2]
https://github.com/lightningnetwork/lightning-rfc/blob/master/11-payment-encoding.md
 



signature.asc
Description: Message signed with OpenPGP
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev