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 log
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.
> 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 between
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 tra
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 with.
This definit
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 the thing from
acti
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 attac
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 they work for that, at least not for new
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 been done) and negot
>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).
I do
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 cons
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 s
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 critic
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 in those pool operators having to run n
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 about
signaling not being reliable, though
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
i
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 simple
18 matches
Mail list logo
