Larry Ruane [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2020-10-01 to 2022-07-11
💬 Posted a total of 3 messages
📚 Participated in the following categories: bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 23:11:32

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Sun, Jul 10, 2022 at 3:05 AM vjudeu via bitcoin-dev
<bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> Not really, because people that run full nodes, just accepted Segwit
> and Taproot. They had no choice. And in case of zero satoshis, it could
> be the same: you would see zero if you look at raw bytes, but you will
> see non-zero values, if you use some upgraded client, that will support
> amount hiding, or other features.
>
> Segwit: old nodes see no new signatures, new nodes see all signatures
> Zero satoshis: old nodes see new zero amounts, new nodes see all amounts
>
> It is that simple.
I see what you mean, have the P2P messages depend on whether the peer
is running old code (doesn't know about tail emission) or new code
(does know about it).
I don't think this can work in this case. It worked for Segwit because
the P2P differences involved only signatures (which determine whether
the transaction is valid), not the *effect* of the transaction, that is,
how it changes the UTXO set. Consensus requires all nodes to always
agree on the UTXO set.
Larry Ruane

2023-06-07 23:11:32

- reply

2023-06-07 23:06:37

- reply

📅 Original date posted:2022-03-22
📝 Original message:Greetings list,
This is my first time posting here.
Question for you:
Should the Bitcoin Core mempool replace an existing transaction with one
that has the same txid (having the same effect, same spends and outputs)
but a sufficiently smaller witness (different wtxid) and thus a higher
feerate? This is what https://github.com/bitcoin/bitcoin/pull/24007
proposes, and I'd like to get opinions on two questions:
1. Is this a beneficial change? Specifically, is anyone creating an
application that would broadcast transactions with the same txid but
different witnesses as an earlier transaction?
2. If this change has benefit, what should be considered a sufficiently
better feerate or reduction in witness size?
An advantage of this mempool-accept policy change is that it's
miner-incentive compatible (miners would prefer to mine a transaction
with a higher feerate). But there is of course a code complexity cost,
and transaction-relay DoS concern.
Being miner-incentive compatible is good, but is that sufficient
justification for merging? I'm posting to the mailing list in hopes that
there are use-cases that we (the PR authors) aren't aware of. Please
reply here or on the PR if you can think of any.
A perhaps subtle advantage: This PR may provide a defense against a
mempool pinning attack: if you have a transaction shared with other
parties, and one of them broadcasts the transaction with a bloated
witness (thus intentionally reducing the feerate in hopes of delaying
or preventing confirmation), you currently have no way to change it.
If there is an application out there that uses same-txid-different-witness
transactions shared between counterparties, this PR would help make
those applications safe.
Question 2 gets at a DoS tradeoff: If the new transaction may have
only a very slightly smaller witness, an attacker might re-broadcast it
many times, consuming a lot of relay bandwidth, and CPU to update
the mempool. On the other hand, if the new transaction must have a much
smaller witness, then it wouldn't be possible to replace a transaction with
a beneficially-smaller one.
This could be a per-node setting, but it's desirable for the node
network to largely agree on relay policies (although a configuration
option might be useful for testing and experimentation).
Background:
Bip125 (Replace-by-fee) allows an incoming transaction to replace one
or more existing conflicting transactions if certain DoS-mitigation
conditions are met:
https://github.com/bitcoin/bitcoin/blob/master/doc/policy/mempool-replacements.md
Witness-replacement is similar to RBF, but differs in a few ways:
- RBF rule 4 requires an absolute fee increase, which is not possible if
the txid isn't changing (since the inputs, outputs, and amounts must be
the same). So if transaction witness-replacement (same txid but different
wtxid) is allowed, it can't be considered just a special case of an RBF,
although it may have some similar policies (and for the same reasons).
- With witness-replacement, it's not necessary to evict mempool
descendant transactions because their inputs' txid references to their
parent (who is being replaced) remain valid.
- The new transaction replaces exactly one existing transaction since
the inputs are the same. (In general, with RBF, the new transaction may
conflict-out multiple existing mempool transactions, namely, all that
spend the same outputs as the new transaction.)
- RBF requires the original transaction to signal replaceability
(rule 1). This is so that recipients are warned that their payment may
disappear if the transaction is replaced. But signaling isn't required
by witness-replacement since the outputs can't change (the descendants
remain valid).
Thanks for your time!
Larry Ruane (with lots of help from Gloria Zhao)

2023-06-07 23:06:37

- reply

2023-06-07 18:27:11

- reply

📅 Original date posted:2020-10-01
📝 Original message:Hello Mike and others,
I just want to plug the open-source POW network mining simulator I recently
wrote: https://github.com/LarryRuane/minesim
It simulates Bitcoin's existing POW (of course), but probably would be easy
to modify to correspond to variations such as the one being proposed here.
Sometimes simulating an algorithm can lead to insights beyond what's
possible using only abstract reasoning.
Larry Ruane
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20201001/b36963e0/attachment.html>

2023-06-07 18:27:11

- reply