You can try to redefine all you want but it doesn't make what you're saying
true.
A soft fork is a constriction of rules
A 51% attack is a soft fork with majority mining power.
I didn't say that LOT=true does it I said that it must achieve 51% miner
support to pose reorg risks to force
I personally don’t like the term 51% attack as applied to censorship. A miner
is free to mine or not mine any transactions it wants (censor). The term attack
is better reserved for stealing from someone (reclaiming spends using hash
power), as it implies a moral distinction.
But 51% attack is
To clarify, it is the soft fork enforcement by majority hash power that is the
51% attack, not the stopping of it. Majority hash power censors non-conforming
transactions. To counter it requires only a non-censoring majority to continue
mining.
It is correct that the purpose of supermajority
On Tuesday 02 March 2021 18:22:35 Ariel Lorenzo-Luaces via bitcoin-dev wrote:
> I'm realizing that a clear advantage of LOT=false is that it can happen
> without the need for a social movement. All that is really needed is the
> convincing of 95% miners. Apathetic users will never notice any kind
I agree.
Thank you Erik for proposing it. It's a pretty good idea.
P.S. I wouldn't want a chain split of a low percentage of users though. The
minority will be at the mercy of massive PoW swings and the chain will lose
friends so it's not good for anyone. I recommend changing the final
It's becoming increasingly clear that core might not be able to release
activation code.
Anyone advocating for a UASF must do tremendous amounts of work to convince
users, miners, and service providers to run a UASF client. Anyone advocating
against a UASF or indifferent will take the path of
It is wrong to say that using miner signalling alone for activation
(LOT=false) is a bug.
As we vividly saw in the events of the 2017 UASF, the purpose of miner
signalling isn't to activate or enforce the new rules but to stop a
chain split. A majority of miners can stop a chain split by
On Mon, Mar 01, 2021 at 08:58:46PM +, John Newbery via bitcoin-dev wrote:
> We can increase the permitted number of inbound block-relay-only peers
> while minimizing resource requirement _and_ improving addr record
> propagation, without any changes to the p2p protocol required.
+1.
I found
Antoine,
Nothing in my proposal below precludes introducing a more comprehensive
feature negotiation mechanism at some later date. The only changes I'm
proposing are to Bitcoin Core's policy for how it treats its peer
connections.
> If we don't want to introduce a new message and
> corresponding
The idea of a fully-transparent bitcoin is dead and has been for many
years. This is because of various privacy tech such as CoinJoin,
Lightning Network, PayJoin, change avoidance, avoiding address reuse,
etc, along with a few new ones like CoinSwap and WabiSabi hopefully
coming soon.
On
10 matches
Mail list logo
