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
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.
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
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
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
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
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
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
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
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
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
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
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
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
14 matches
Mail list logo