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

2017-03-12 Thread shaolinfry via bitcoin-dev
Thank you all for the insightful feedback, on list, in private and on various social media platforms. I have extended the generalized proposal which extends BIP9. This basically introduces an extra workflow state if activationtime > starttime and < timeout - 1 month. It allows extra business

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

2017-03-07 Thread Alphonse Pace via bitcoin-dev
I fail to see how any non-mining user can attack a miner. The worst they can do is refuse to buy their coinbase transaction. Do you believe that users are obligated to buy coins from miners? If not, then all miners are voluntarily choosing a set of rules to enforce and a set of policy to mine.

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

2017-03-07 Thread Eric Voskuil via bitcoin-dev
> Bitcoin would lose the security and in the short term even the ability to mine blocks every 10 minutes. Presumably a POW hard fork would be accompanied by a difficulty reset, so that the deployment didn't have *both* of these problems from the outset. There's really little difference

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

2017-03-07 Thread Tom Zander via bitcoin-dev
On Tuesday, 7 March 2017 00:23:47 CET Gareth Williams via bitcoin-dev wrote: > What you're describing is a hashpower activated soft fork to censor > transactions, in response to a user activated soft fork that the majority > of hashpower disagrees with. It is incorrect to say that censoring of

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

2017-03-07 Thread Eric Voskuil via bitcoin-dev
On 03/06/2017 05:07 PM, Edmund Edgar via bitcoin-dev wrote: > On 7 March 2017 at 08:23, Gareth Williams wrote: >> What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees

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

2017-03-06 Thread Edmund Edgar via bitcoin-dev
On 7 March 2017 at 08:23, Gareth Williams wrote: > What you're describing is a hashpower activated soft fork to censor > transactions, in response to a user activated soft fork that the majority of > hashpower disagrees with. Well, they'd be censoring transactions to prevent

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

2017-03-06 Thread Gareth Williams via bitcoin-dev
What you're describing is a hashpower activated soft fork to censor transactions, in response to a user activated soft fork that the majority of hashpower disagrees with. It is always possible for a majority of hashpower to censor transactions they disagree with. Users may view that as an

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

2017-03-06 Thread Edmund Edgar via bitcoin-dev
On 6 March 2017 at 18:18, David Vorick via bitcoin-dev wrote: > User activated soft forks, or perhaps more accurately called 'economically > forced soft forks' are a tool to use if the miners are in clear opposition > to the broader economy. I don't think

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

2017-03-06 Thread David Vorick via bitcoin-dev
On Mar 5, 2017 6:48 PM, "Eric Voskuil" wrote: Independent of one's opinion on the merits of one fork or another, the state of centralization in Bitcoin is an area of great concern. If "we" can sit down with 75% of the economy and/or 90% of the hash power (which of course has

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

2017-03-05 Thread Eric Voskuil via bitcoin-dev
There are two aspects of system security in Bitcoin, mining (hash power) and payment validation (economy). The security of each is a function of its level of decentralization. Another way to think of it is that a system with less decentralization has a smaller community (consensus). A large

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

2017-03-05 Thread David Vorick via bitcoin-dev
I also think that the UASF is a good idea. Hashrate follows coin price. If the UASF has the higher coin price, the other chain will be annihilated. If the UASF has a lower coin price, the user activated chain can still exist (though their coins can be trivially stolen on the majority chain). The

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

2017-03-05 Thread Chris Belcher via bitcoin-dev
I think UASF is a great idea for the reasons mentioned before that it more closely matches the balance of powers in bitcoin, and that its much more opt-in. Many people are comparing an UASF fork with a hard fork. I disagree with this view and I think there is a difference between the two kinds of

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

2017-02-28 Thread Luke Dashjr via bitcoin-dev
Without at least a majority hashrate validating blocks, it is possible just a single invalid block could split the chain such that the majority continue building a most-work on that invalid block. This failure to validate a softfork is similar in some respects to a hardfork, but with one

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

2017-02-27 Thread Eric Voskuil via bitcoin-dev
On Feb 27, 2017, at 8:02 AM, shaolinfry via bitcoin-dev wrote: >> 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

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

2017-02-27 Thread shaolinfry via bitcoin-dev
Dear Jameson, Thank you for your questions. Answers inline below: Jameson Lopp via bitcoin-dev wrote: 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

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

2017-02-26 Thread 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

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

2017-02-25 Thread shaolinfry via bitcoin-dev
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