Re: [bitcoin-dev] Moving towards user activated soft fork activation

[Jameson Lopp via bitcoin-dev]

You've made many salient points, Shaolin, though I have a few questions:

1) How well does this model work under adversarial conditions? Fair point
about signaling not being reliable, though it seems more vague in terms of
safety given that you can't actually know what percentage of hashrate that
is /not/ signaling for the soft fork has taken the necessary precautions to
avoid mining an invalid block and potentially causing a hard fork. It's
probably safe to say that if a flag-day soft fork is activated, there will
be at least a few parties who will attempt to trigger a chain fork by
crafting transactions that are valid via non-fork rules but invalid via the
soft fork rules.

2) If the flag day soft fork is activated with only a minority of hashrate
support + safely opted-out hashrate, isn't it possible for the rest of
miners to coordinate orphaning any soft fork compatible blocks to kill the
soft fork chain? This would be a major difference from a miner-activated
soft fork, correct? Unless perhaps many miners colluded to signal soft fork
support while not actually supporting it...

3) In terms of complexity for mining pool operators, how well does this
model scale if there are N soft forks and the pool doesn't want to opt-in
to any of them? Couldn't this result in those pool operators having to run
not just one border node, but a multitude of "chained" border nodes if the
soft forks are spread across different software implementations?

It seems to me that this type of user-driven approach would preferably be
coupled with assurances from major Bitcoin wallets / exchanges / payment
processors that they will not honor coins from a chain fork that results
from invalid spends of outputs encumbered by soft fork rules. Though on the
other hand, I don't see such an assurance being possible given that
exchanges have an incentive to take the first mover advantage in listing a
new coin.

- Jameson

On Sat, Feb 25, 2017 at 6:55 PM, shaolinfry via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Some thoughts about the activation mechanism for soft forks. In the past
> we used IsSuperMajority and currently use BIP9 as soft fork activation
> methods, where a supermajority of hashrate triggers nodes to begin
> enforcing new rules. Hashrate based activation is convenient because it is
> the simplest and most straightforward process. While convenient there are a
> number limitations with this method.
>
> Firstly, it requires trusting the hash power will validate after
> activation. The BIP66 soft fork was a case where 95% of the hashrate was
> signaling readiness but in reality about half was not actually validating
> the upgraded rules and mined upon an invalid block by mistake[1].
>
> Secondly, miner signalling has a natural veto which allows a small
> percentage of hashrate to veto node activation of the upgrade for everyone.
> To date, soft forks have taken advantage of the relatively centralised
> mining landscape where there are relatively few mining pools building valid
> blocks; as we move towards more hashrate decentralization, it's likely that
> we will suffer more and more from "upgrade inertia" which will veto most
> upgrades.
>
> Upgrade inertia in inevitable for widely deployed software and can be seen
> for example, with Microsoft Windows. At the time of writing 5.72% of all
> Microsoft Windows installations are still running Windows XP, despite
> mainstream support ending in 2009 and being superseded by 4 software
> generations, Vista, 7, 8 and 10.
>
> Thirdly, the signaling methodology is widely misinterpreted to mean the
> hash power is voting on a proposal and it seems difficult to correct this
> misunderstanding in the wider community. The hash powers' role is to select
> valid transactions, and to extend the blockchain with valid blocks. Fully
> validating economic nodes ensure that blocks are valid. Nodes therefore
> define validity according to the software they run, but miners decide what
> already valid transactions gets included in the block chain.
>
> As such, soft forks rules are actually always enforced by the nodes, not
> the miners. Miners of course can opt-out by simply not including
> transactions that use the new soft fork feature, but they cannot produce
> blocks that are invalid to the soft fork. The P2SH soft fork is a good
> example of this, where non-upgraded miners would see P2SH as spendable
> without a signature and consider them valid. If such an transaction were to
> be included in a block, the block would be invalid and the miner would lose
> the block reward and fees.
>
> So-called "censorship" soft forks do not require nodes to opt in, because
> >51% of the hash power already have the ability to orphan blocks that
> contain transactions they have blacklisted. Since this is not a change in
> validity, nodes will accept the censored block chain automatically.
>
> The fourth problem with supermajority hash power signaling is it draws
> unnecessary attention to 

Re: [bitcoin-dev] SHA1 collisions make Git vulnerable to attakcs by third-parties, not just repo maintainers

[Steve Davis via bitcoin-dev]

> On Feb 26, 2017, at 1:36 AM, Pieter Wuille  wrote:
> 
> Typical hash function breaks produce collision attacks, while a preimage 
> attack is needed to reduce single-key address security.

Thank you Pieter - that was really helpful. I realize now that I was thinking 
of a preimage attack but had mistakenly assumed that the birthday bound 
applied...

So the unit operation: [genkeypair; ripemd160(sha256(pubkey));check_utxoset] 
would need to be performed 2.9*10^42 and not (as I had first calculated) 
2.4*10^18. 

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