> No it does not. This narrative is the worst. A bad explanation of speedy
> trial can mislead people into thinking miner signalling is how Bitcoin
> upgrades are voted in. But a bad explanation can explain anything badly.
I agree it is worst but why do you think this narrative exists? People ha
@Pushd
> Speedy trial makes it worse by misleading lot of bitcoin users including
miners to consider signaling as voting and majority votes decide if a soft
fork gets activated
No it does not. This narrative is the worst. A bad explanation of speedy
trial can mislead people into thinking miner si
Hi Ruben,
After sending that last night, I realized the solution I had to
deprivatizing the sender wouldn't work because it had the same problem of
even divisibility in modulo N. And my math was incomplete I think. Also
Marco D'Agostini pointed out other errors. And all this assumes that a
modulus
Hello List,
tl;dr, users of WabiSabi coinjoin can pay arbitrary amounts of bitcoin,
so that the sender does not learn the address/output of the receiver,
and the receiver does not learn the input of the sender. This improves
the previously proposed 'Wormhole' for Chaumian blind signature
coin
> Any case where a flawed proposal makes it through getting activation
parameters set and released, but doesn't achieve supermajority hashpowersupport
is made worse by bip8/lot=true in comparison to speedy trial.
- Flawed proposal making it through activation is a failure of review process
- Sup
> the sender can get in trouble too if they send money
Good point.
> how well this can be optimized without resorting to reducing anonymity
Complete shot in the dark, but I wonder if something akin to compact block
filters could be done to support this case. If, for example, the tweaked
key wer
