Hi Mempoololic Anonymous fellow,
> 2. Staggered broadcast of replacement transactions: within some time
> interval, maybe accept multiple replacements for the same prevout, but
only
> relay the original transaction.
If the goal of replacement staggering is to save on bandwidth, I'm not sure
it's
@Aj Your steps seem reasonable. I definitely agree step one (talking to
each other) is obviously the ideal solution, when it works.
Step 2 (futures market) is the option I would say I understand the least.
In any case, a futures market seems like it only incorporates the
opinions/predictions of th
On Fri, Mar 11, 2022 at 5:32 PM Billy Tetrud via bitcoin-dev
wrote:
>
> I think involving users more in activation is a good avenue of thought for
> improving how bitcoin does soft forks. I also think the idea you brought up
> of some way for people to signal opposition is a good idea. I've sugg
On Sat, Mar 12, 2022 at 2:35 PM Russell O'Connor via bitcoin-dev
wrote:
>
> On Fri, Mar 11, 2022 at 9:03 AM Jorge Timón wrote:
> A mechanism of soft-forking against activation exists. What more do you
> want? Are we supposed to write the code on behalf of this hypothetical group
> of users who
On Sat, Mar 12, 2022 at 7:34 PM Billy Tetrud via bitcoin-dev
wrote:
>
> > If I find out I'm in the economic minority then I have little choice but
> > to either accept the existence of the new rules or sell my Bitcoin
>
> I do worry about what I have called a "dumb majority soft fork". This is
On Tue, Mar 15, 2022 at 4:45 PM Anthony Towns wrote:
>
> On Fri, Mar 11, 2022 at 02:04:29PM +, Jorge Timón via bitcoin-dev wrote:
> People opposed to having taproot transactions in their chain had over
> three years to do that coordination before an activation method was merged
> [0], and then
> I've done it in about 40 lines of python:
https://github.com/jeremyrubin/forkd
This python script using `invalidateblock` RPC is an attack on Bitcoin. Just
kidding although I won't be surprised if someone writes about it on reddit.
Thanks for writing the script, it will be helpful.
pushd
---
@Jorge
> Any user polling system is going to be vulnerable to sybil attacks.
Not the one I'll propose right here. What I propose specifically is
a coin-weighted signature-based poll with the following components:
A. Every pollee signs messages like for each UTXO they want to respond to the poll w
@Antoine
> B overrides A and starts to replace package A in the network mempools
nearest to Alice. I think those peers won't have bandwidth saving from
adopting a replacement staggering strategy.
That's an interesting point, but even with that fact, the method would be
effective at limiting spam.
