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

[Eric Voskuil via bitcoin-dev]

> On Nov 6, 2017, at 20:38, Devrandom  wrote:
> 
> A hard-fork is a situation where non-upgraded nodes reject a block mined and 
> relayed by upgraded nodes.

As Peter pointed out, that is the case here.

> This creates a fork that cannot heal regardless of what follows.

That is not a condition of the hard fork concept.

https://github.com/bitcoin/bips/blob/master/bip-0099.mediawiki
Softfork
A consensus fork wherein everything that was previously invalid remains invalid 
while blocks that would have previously considered valid become invalid. A 
hashrate majority of miners can impose the new rules. They have some deployment 
advantages like backward compatibility.
Hardfork
A consensus fork that makes previously invalid blocks valid. Hardforks require 
all users to upgrade.

The essential element of a hard fork is that the new rule may cause rejection 
of blocks that are not rejected by old rules (thereby requiring that all users 
adopt the new rule in order to avoid a split). The reason a hard fork is 
interesting is that it can create a chain split even if it is enforced by 
majority hash power.

That is not the case with a soft fork and it is not the case here. A split can 
occur. The fact that it is possible for the split to also eventually orphan the 
old nodes does not make it a soft fork. A soft fork requires that a hash power 
majority can impose the rule. However, under the proposed new rule the hash 
power majority (according to the new rule) cannot impose the rule on existing 
nodes.

> 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.

Nothing about this proposal implies an attack. From the Motivation section:

Mitigate centralization pressures by introducing a POW that does not have 
economies of scale
Introduce an intermediary confirmation point, reducing the impact of mining 
power fluctuations

> 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.

Presumably this preference exists because it implies the new rule would not 
cause a chain split, making it more acceptable to a risk-averse economy. This 
is precisely why it should be described correctly.

> 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.

In reality you have no way to know if/when people would adopt this rule. What 
matters in the proposal is that people who do adopt it are well aware of its 
ability to split them from the existing economy.

e

>> On Mon, Nov 6, 2017 at 3:55 PM Eric Voskuil via bitcoin-dev 
>>  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 
>>>  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 n

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

[Jacob Eliosoff via bitcoin-dev]

OK, so nForkId 0 is exactly the "valid on all chains" specifier I was
asking about, cool.  And your LN example (and nLockTime txs in general)
illustrate why it's preferable to implement a generic replay protection
scheme like yours *in advance*, rather than before each fork: all ad hoc RP
schemes I know of break old txs on one of the chains, even when that's not
desirable - ie, they offer no wildcard like nForkId 0.

One comment on your LN example: users would have to take note that nForkId
0 txs would be valid not only on future forks, but on *past* forks too.
Eg, if BCH had been deployed with nForkId 2, then a user setting up BTC LN
txs now with nForkId 0 would have to be aware that those txs would be valid
for BCH too.  Of course the user could avoid this by funding from a
BTC-only address, but it is a potential minor pitfall of nForkId 0.  (Which
I don't see any clean way around.)


On Fri, Nov 10, 2017 at 6:28 AM, Mats Jerratsch  wrote:

> I guess I wasn't clear on the wildcard, `nForkId=0`
>
> This proposal puts Bitcoin at `nForkId=1`, with the purpose of having
> `nForkId=0` valid on *all* future forks. This means you can create a
> `nLockTime` transaction, delete the private key and still be assured to not
> lose potential future tokens.
>
> In theory `nForkId=0` could be used for an address too, the sending wallet
> should display a warning message about unknown side effects though. This
> address would be future-safe, and you can put it into a safe-deposit box
> (even though I see little reason to back up an _address_. You would always
> back up a _private key_, which translates into funds on any fork.)
>
> Furthermore, `nForkId=0` can be used for L2 applications. Let's say Alice
> and Bob open a payment channel. One week later, project X decides to fork
> the network into a new token, implementing a custom way of providing strong
> two-way replay protection. The protocol Alice and Bob use for the payment
> channel has not implemented this new form of replay protection. Alice and
> Bob now have to make a choice:
>
> (1) Ignore this new token. This comes with an evaluation of how much this
> new token could be worth in the future. They will continue normal channel
> operation, knowing that their funds on the other branch will be locked up
> until eternity. When they close their payment channel, the closing
> transaction will get rejected from the other network, because it's not
> following the format for replay protected transactions.
>
> (2) Close the payment channel before the fork. The transaction, which
> closes the payment channel has to be mined before the fork, potentially
> paying a higher-than-normal fee.
>
> With this proposal implemented, there are two additional choices
>
> (3) Create the commitment transactions with `nForkId=0`. This ensures that
> when the channel gets closed, funds on other chains are released
> accordingly. This also means that after the fork, payments on the channel
> move both, the original token and the new token. Potentially, Alice and Bob
> want to wait before further transacting on the channel, to see if the token
> has substantial value. If it has, they can *then* close the channel and
> open a new channel again. (Note: The funding transaction can use a specific
> `nForkId`, preventing you from locking up multiple coins when funding the
> channel, but you can choose to settle with `nForkId=0` to not lock up
> future coins)
>
> (4) Make the protocol aware of different `nForkId`. After the fork, the
> participants can chose to *only* close the payment channel on the new
> token, making the payment channel Bitcoin-only again. This is the preferred
> option, as it means no disruption to the original network.
>
> > I like the idea of specifying the fork in bech32 [0]. On the other hand,
> the standard already has a human readable part. Perhaps the human readable
> part can be used as the fork id?
>
> I was considering this too. On the other hand, it's only _human readable_
> because thy bytes used currently encode 'bc'. For future forks, this would
> just be two random letters than, but potentially acceptable.
>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin Core 0.15.1 released

[Wladimir J. van der Laan via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Bitcoin Core version *0.15.1* is now available from:

  

or

  

Or through bittorrent:

  
magnet:?xt=urn:btih:e83dfdfca54def4e29f5355e8c3f9a7aa45ecbaf&dn=bitcoin-core-0.15.1&tr=udp%3A%2F%2Ftracker.openbittorrent.com%3A80&tr=udp%3A%2F%2Ftracker.opentrackr.org%3A1337&tr=udp%3A%2F%2Ftracker.coppersurfer.tk%3A6969&tr=udp%3A%2F%2Ftracker.leechers-paradise.org%3A6969&tr=udp%3A%2F%2Fzer0day.ch%3A1337&tr=udp%3A%2F%2Fexplodie.org%3A6969

This is a new minor version release, including various bugfixes and
performance improvements, as well as updated translations.

Please report bugs using the issue tracker at GitHub:

  

To receive security and update notifications, please subscribe to:

  

How to Upgrade
==

If you are running an older version, shut it down. Wait until it has completely
shut down (which might take a few minutes for older versions), then run the 
installer (on Windows) or just copy over `/Applications/Bitcoin-Qt` (on Mac)
or `bitcoind`/`bitcoin-qt` (on Linux).

The first time you run version 0.15.0 or higher, your chainstate database will
be converted to a new format, which will take anywhere from a few minutes to
half an hour, depending on the speed of your machine.

The file format of `fee_estimates.dat` changed in version 0.15.0. Hence, a
downgrade from version 0.15 or upgrade to version 0.15 will cause all fee
estimates to be discarded.

Note that the block database format also changed in version 0.8.0 and there is 
no
automatic upgrade code from before version 0.8 to version 0.15.0. Upgrading
directly from 0.7.x and earlier without redownloading the blockchain is not 
supported.
However, as usual, old wallet versions are still supported.

Downgrading warning
- ---

The chainstate database for this release is not compatible with previous
releases, so if you run 0.15 and then decide to switch back to any
older version, you will need to run the old release with the 
`-reindex-chainstate`
option to rebuild the chainstate data structures in the old format.

If your node has pruning enabled, this will entail re-downloading and
processing the entire blockchain.

Compatibility
==

Bitcoin Core is extensively tested on multiple operating systems using
the Linux kernel, macOS 10.8+, and Windows Vista and later. Windows XP is not 
supported.

Bitcoin Core should also work on most other Unix-like systems but is not
frequently tested on them.


Notable changes
===

Network fork safety enhancements
- 

A number of changes to the way Bitcoin Core deals with peer connections and 
invalid blocks
have been made, as a safety precaution against blockchain forks and misbehaving 
peers.

- - Unrequested blocks with less work than the minimum-chain-work are now no 
longer processed even
if they have more work than the tip (a potential issue during IBD where the tip 
may have low-work).
This prevents peers wasting the resources of a node. 

- - Peers which provide a chain with less work than the minimum-chain-work 
during IBD will now be disconnected.

- - For a given outbound peer, we now check whether their best known block has 
at least as much work as our tip. If it
doesn't, and if we still haven't heard about a block with sufficient work after 
a 20 minute timeout, then we send
a single getheaders message, and wait 2 more minutes. If after two minutes 
their best known block has insufficient
work, we disconnect that peer. We protect 4 of our outbound peers from being 
disconnected by this logic to prevent
excessive network topology changes as a result of this algorithm, while still 
ensuring that we have a reasonable
number of nodes not known to be on bogus chains.

- - Outbound (non-manual) peers that serve us block headers that are already 
known to be invalid (other than compact
block announcements, because BIP 152 explicitly permits nodes to relay compact 
blocks before fully validating them)
will now be disconnected.

- - If the chain tip has not been advanced for over 30 minutes, we now assume 
the tip may be stale and will try to connect
to an additional outbound peer. A periodic check ensures that if this extra 
peer connection is in use, we will disconnect
the peer that least recently announced a new block.

- - The set of all known invalid-themselves blocks (i.e. blocks which we 
attempted to connect but which were found to be
invalid) are now tracked and used to check if new headers build on an invalid 
chain. This ensures that everything that
descends from an invalid block is marked as such.


Miner block size limiting deprecated
- 

Though blockmaxweight has been preferred for limiting the size of blocks 
returned by
getblocktemplate since 0