On 2023-11-07 17:12, Andrew Chow via bitcoin-dev wrote:
I would prefer that we continue to have a mailing list where email is a
functional and first class user interface. So that would be to migrate
to groups.io or Google Groups. I think Google Groups is probably the
better choice of the two.
I read Antoine's original post on this and got the general gist, and
here also, it makes sense, but I'd like to ask: is it necessary that
(B, C) in the above not *see* A's opt-out "pre-replacement" (inputs:
A1, outputs: A, fees: low; call it TX_2)? I get that they cannot
replace it
Is it
technically, all we need is for *miners* to consistently mine "full
rbf"
There's another important point I think:
technically, all we need is for *miners* to consistently mine the
highest fee-rate transaction (or the one with the most incentive).
Miners could probably be incentivized to
would prevent a transaction from
being pinned.
On 2022-11-08 15:54, yancy via bitcoin-dev wrote:
Peter,
It sounds like there are two attack vectors; neither of which require
full-rbf (correct me if I'm wrong).
1) Bob has staked liquidity in a payment channel with Alice who later
double spends
spamming many nodes.
Cheers,
-Yancy
On 2022-11-07 15:32, Peter Todd wrote:
On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev
wrote:
AJ/Antoine et al
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?
Assuming Alice
adding a
full-rbf
config flag is particularly trivial. It requires just a single line in
the
mempool code.
Agree the flag is trivial. The interplay between mempool policies may
not be trivial.
Cheers,
-Yancy
On 2022-10-31 18:51, Peter Todd wrote:
On Mon, Oct 31, 2022 at 06:21:08PM +010
AJ/Antoine et al
What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
solve that problem if they have only opt-in RBF available?
Assuming Alice is a well funded advisory, with enough resources to spam
the network so that enough nodes see her malicious transaction first,
how
Protocol Devs,
After reading through this email thread and BIP125, I'm curious if
non-rbf nodes will relay full-rbf transactions and vice versa. That is
to say, if only one non-rbf node exists on the network, however, every
other node implements full-rbf, will the transaction still be
Whether that's terrible or not depends on how easy it is to retry (and
how
likely the retry is to succeed) after a failure -- if a TCP packet
fails,
it just gets automatically resent, and if that succeeds, there's a
little
lag, but your connection is still usable
I'm not sure if that
...and the easiest way to avoid Bitcoin being a system that doesn't
arbitrarily
change rules, is to rely on economically rational rules that aren't
likely to
change!
Yes, I think many people on this thread have been making the same point.
This is the basis of the Nash Equilibrium, from
I had one other idea on the topic. Namely, in the last section
"calculation", Satoshi talks more about what he/she/they consider to be
bad actors. The idea that someone is not doing "tip mining" does not
mean they are dishonest.
We consider the scenario of an attacker trying to generate
not sure if this is helpful, but when i'm code reviewing a change to
an existing, functioning and very complex system, i rarely go back to
"first principles" to analyze that change independently, and instead
try to decide if it's better or worse than what we have now
I agree that it's
Hi Jeremy,
Thanks for the reply. I do find the semantics of mempool and block org
interesting (although there's a lot on the topic I don't know).
E.g., suppose:
Block N: Fees = 10, reward = 1
Mempool: Fees = 2
Mining block N+1 with the mempool leads to reward 2+1 = 3, reorging
leads to
The proof-of-work also solves the problem of determining
representation in majority decision
making. If the majority were based on one-IP-address-one-vote, it
could be subverted by anyone
able to allocate many IPs. Proof-of-work is essentially
one-CPU-one-vote. The majority
decision is
Prayank,
I believe the p2pderivatives DLC application is still under active
development here (single oracle):
https://github.com/p2pderivatives/rust-dlc
I was once involved in the project in a galaxy far far away but haven't
kept up with the project. Also, I'm a few days behind in the
I appreciate the bluntness, Jeremy, and agree it's high time folks enjoy the
holiday.
Cheers,
-Yancy
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Ok thanks. Using the correct terminology helps people understand what you're
talking about and take you seriously.
Cheers,
-Yancy
Mar 13, 2021 4:02:18 PM Lonero Foundation :
> Hi, I know the differences between the cryptographic hashing algorithm and
> key validation. I know hashing is for
17 matches
Mail list logo
