Hi Carlo
This your proposal is similar to the Simple Majority Activation proposal (SMA).
The difference is that your proposal has the final activation threshold set to
80% and SMA has it set to 51%
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-March/018587.html
The problem with
: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
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
Hello LORD HIS EXCELLENCY JAMES HRMH
I find a striking dichotomy between your concern of increased privacy in
bitcoin and your link to a bitcoin mixer in your signature www.go-overt.com
At first your concerns seemed genuine but after seeing your promotion of a
bitcoin mixer I'm thinking your
What would be the tradeoffs of a BIP8(false, ∞) option? That would remove some
of the concerns of having to coordinate a UASF with an approaching deadline.
Cheers
Ariel Lorenzo-Luaces
On Feb 19, 2021, 6:55 PM, at 6:55 PM, ZmnSCPxj via bitcoin-dev
wrote:
>Good morning list,
>
>> It was
Something what strikes me about the conversation is the emotion surrounding the
letters UASF.
It appears as if people discuss UASF as if it's a massive tidal wave of support
that is inevitable, like we saw during segwit activation. But the actual
definition is "any activation that is not a
On May 24, 2020, 1:26 PM, at 1:26 PM, Karl via bitcoin-dev
wrote:
>Hi ZmnSCPxj,
>
>Thanks for your reply. I'm on mobile so please excuse me for
>top-posting.
>
>I'd like to sort these various points out. Maybe we won't finish the
>whole
>discussion, but maybe at least we can update wiki
I would propose a term different than all the others mentioned so far.
I propose Funding Codes.
The word funding can be used as a verb or a noun and this works for the nature
of Bitcoin transactions. Funding can be seen as what someone needs to do with
the code as well as referring to it as
Hello ZmnSCPxj
I like the proposal because it generalizes escrow type mechanisms and I think
it's a useful train of thought for distributed exchanges.
However, consider the situation where a group of participants are playing
poker. One participant loses all their funds and decides to present
Hello Praveen
You're absolutely right. We could refer to transactions by the hash that gets
signed.
However the way that bitcoin transactions reference each other has already been
established to be hash of transaction+signature. Changing this would require a
hard fork.
Segwit is the
11 matches
Mail list logo
