Peter Todd [ARCHIVE]

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2012-04-26 to 2023-06-03
💬 Posted a total of 1150 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin, RFC, BIP proposal, ann, BIP draft, softfork proposal, Libbitcoin, bitcoin-dev, BIP-draft, BIP 1xx - Draft, BIP/Draft, BIP Proposal, BIP, BIP Draft, Pre-BIP, Update, Lightning-dev, Opt-in full-RBF, At least 17% of Bitcoin Core 24.x listening nodes are running full-rbf, Mempool spam, PATCH v3, BOLT RFC#1, Question, c-lightning, META, try2
🔇 Please do not DM this user as it's used for archive purposes only.

Public Key

npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2

Profile Code

nprofile1qqsd4ghuva4ztca4k3tyg4qte0g7z95tzy2z0ngw8ncec4sef7err2sprpmhxue69uhhyetvv9ujumn0wdmksetjv5hxxmmdqyt8wumn8ghj7un9d3shjtnwdaehgu3wvfskueqx92myn

Publishing to

relay.noswhere.com

relay.nostr.band

nostr21.com

Author Public Key

npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2

Show more details

Last Notes

2023-09-07 11:52:36

- reply

📅 Original date posted:2023-09-05
🗒️ Summary of this message: Cut-through transactions will not eliminate inscriptions in the blockchain. Full archival nodes will still have access to the transaction data.
📝 Original message:
On Sun, Sep 03, 2023 at 06:01:02PM +0200, vjudeu via bitcoin-dev wrote:
> > Given the current concerns with blockchain size increases due to inscriptions, and now that the lightning network is starting to gain more traction, perhaps people are now more willing to consider a smaller blocksize in favor of pushing more activity to lightning?
>
> People will not agree to shrink the maximum block size. However, if you want to kill inscriptions, there is another approach, that could be used to force them into second layers: it is called cut-through, and was described in this topic: https://bitcointalk.org/index.php?topic=281848.0
>
> Then, if you have "Alice -> Bob -> ... -> Zack" transaction chain, and for example some inscriptions were created in "Alice -> Bob" transaction, then cut-through could remove those inscriptions, while leaving the payment unaffected, because the proper amount of coins will be received by Zack, as it should be.
You are incorrect: cut-through transactions will not meaningfully affect
inscriptions. While it is true that with fancy cryptography we can prove the
Alice -> ... -> Zack chain, that does not change the fact that Alice -> Bob ->
Zack was mined in the blockchain, and those transactions exist. Anyone running
a full archival node will still have those transactions, and can provide them
(and all their inscription data) to anyone who needs it.
This is not unlike how in Bitcoin right now many people run pruned nodes that
do not have any archival inscription data. Them running those nodes does not
prevent others from running full archival nodes that do make that data
available.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230905/d69e604b/attachment.sig>

2023-09-07 11:52:35

- reply

📅 Original date posted:2023-09-05
🗒️ Summary of this message: The author suggests using a reference height and encoding the exact transaction output with a delta to save space in Bitcoin transactions.
📝 Original message:
On Fri, Sep 01, 2023 at 01:56:18PM +0000, Andrew Poelstra via bitcoin-dev wrote:
> We can swag what the space savings would be: there are 122MM utxos right
> now, which is a bit under 2^27. So assuming a uniform distribution of
> prefixes we'd need to specify 28 bits to identify a UTXO. To contrast,
> to identify a blockheight we need 20 bits and then maybe 12 more bits to
> specify a TXO within a block. Plus whatever varint overhead we have.
> (I've been working on this project but busy with family stuff and don't
> remember exactly where we landed on the varints for this. I think we
> agreed that there was room for improvement but didn't want to hold up
> posting the rest of the concept because of it.)
Since most transactions spend txouts that are similar in height to each other,
you could save further bits by specifying a reference height and then encoding
the exact txout with a delta.
If you're sending multiple txins or multiple transactions in a single packet,
you could achieve this by starting the packet with the reference block height.
If your application tends to send just a single transaction, you could use a
reference height that is a function of the current time. Since sender and
receiver might not agree on the exact time, you could try slightly difference
reference heights via bruteforcing until the transaction signatures validate.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230905/8a5b529c/attachment.sig>

2023-08-22 19:18:17

- reply

📅 Original date posted:2023-08-21
🗒️ Summary of this message: The author suggests considering Morocco, Algeria, or South Africa as backup options for a conference location, but notes concerns about safety and visa requirements.
📝 Original message:
On Sat, Aug 19, 2023 at 12:02:39AM +0100, Antoine Riard wrote:
> As a backup plan, I think we could consider countries like Morocco or
> Algeria, which given current composition of the organization committee is
> straightforward due to the french-speaking communities, or South Africa,
> which is itself beautiful and where they're doing Bitcoin events [1],
> though this latter is very far far away in term of international travel
> logistic.
I asked a native Algeria friend of mine what she thought about holding a
conference in Algeria:
No. No. No. no
No conference in Algeria
It's not a tourist friendly destination!!
It's an high-violence Islamic country where much of the population has
fundamentalist beliefs, and it does not have a significant tourism industry.
Visiting as a solo female is a sketchy thing to do.
> Note for Ghana, from a quick look it sounds like a visa will be required
> for all Schengen, US and Commonwealth passport holders will need a travel
> visa. ECOWAS passport holders sound to be exempted.
Visa's are really annoying to deal with. They aren't always granted, and tend
to require the applicant to pre-arrange travel (incurring expenses) well in
advance of the conference. I would rule out anywhere with non-trivial visa
requirements for the super-majority of attendees.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230821/78480560/attachment.sig>

2023-08-21 09:55:29

- reply

📅 Original date posted:2023-08-16
🗒️ Summary of this message: Approximately 31% of hash power from different pools is currently mining full-RBF, confirming previous research findings.
📝 Original message:
Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption,
I've been doing high-fee full-RBF testing to re-confirm my findings.
Specifically, that means sending a high fee tx1 with a fee more than sufficient
to get mined in the next block. Then 30 seconds later, I send tx2, a double
spend with an even higher fee, removing one of tx1's outputs. Propagation was
verified for each full-RBF double-spend by checking debug.log on another very
well-connected node.
Results: >31% of hash power, over at least 4 different pools, is mining
full-RBF at the moment, assuming Binance Pool is mining full-RBF with half
their hashing power (see below for details). This finding confirms my OTS
calendar research, which found similar results.
Specifically, in my testing yesterday I successfully did the following full-RBF
double-spends:
Antpool: 2ebe68edca320dabdd8b39ebae5f18efaac829055058a2c0f4bc2b37c69cd88c
dac9895795efa3956cc775b4f48a5d2b01fa0ea0d7a915fa350baa4779d2e0e9
b7d43485bf8f0f9792ba6889ab2f53fb462aa4997f3995d9d027375993fa7907
e2cd91093399dcad5ad3fd73627e497c5e808434ecc7aaec13d9d488973f099c
5bb7e7d6c34dfd2ae65466a2968a0e500ef25d9b70f7f2b299203dffc1a1b10d
ad7d2f74eab240726604dfd66231f52ac7778567028cf818387dc9395474f63b
1ddb11bad477e8b5bcdb36dbaa26065ae8e3c37b39b37a2b34780b98274bd076
f16bb35670b66ab3c8ccbbaf5f06da5f311e9b05a02b23a77a6fec5e8e5951a4
b6123a7c126b7937a23bf93cce09358bc2c1047a3bd20fad47bf187e453aadc5
66f3da902d43ab0a2561d0477c7050d057bb0f69ade79015494363ad08ed172d
17a6995a757e027b2a51b9cc58635b29553ccc6c164555c0ed922074a23bcbfe
Poolin: 68ca9ee95748dc98ba24018ea64c18de31fca552e4753ef012acd0b615cd7384
477089a1e997a0115b3d4cd1d4ce21eb9dc83c45c14a7f7441e4fc74c3649ba2
EMCDPool: dde0975ad42fd9e03677f64b6c4f7efbe2ec0b6f905206d47893a77ac6336fca
a0131d4f8cc13d70443cd87f2ee7543e1142640666a88f80d1e0c885c7eb2c12
Binance Pool: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5
637c58f3c0447ee99808b37e4f9559096c00ceb0d21130a9254558c4d2d7ae63
Anyone running a full-RBF node with debug=mempool can easily verify all these
double-spends by examining their debug.log files.
With Antpool, Poolin, and EMCDPool, it is most likely that they're mining
full-RBF with ~100% of their hash power. These pools mined every double-spend
available to them, with the exception of some Antpool blocks found very close
to when the double-spend was broadcast. Binance Pool did *not* mine a full-RBF
replacement on two occasions, which makes me suspect they're mining full-RBF
with less than 100% of their hash power. During this testing, Binance Pool,
AntPool, Poolin, and EMCDPool, also all mined multiple double-spends from my
OTS calendars, further confirming my findings.
My OTS research also found examples of KuCoinPool and ULTIMUSPOOL mining
full-RBF double spends. They didn't find any blocks during this testing, so I
have no data on them with this testing. Luxor _did_ mine some blocks without
mining the double-spends, so at the moment it's reasonable to assume they have
full-RBF fully or partially disabled, or have some kind of full-RBF propagation
issue. They have confirmed similar issues to me in the past (eg employees
unintentionally disabling it on some nodes during an upgrade), so it's likely
that has happened again. MARA Pool also mined some blocks without mining
double-spends, so they too may have full-RBF fully or partially disabled, as I
mentioned in my OTS research.(1)
The tool I used is the following:
https://github.com/petertodd/replace-by-fee-tools/blob/master/doublespend.py
Note that this script was written years ago, pre-segwit, and I hastily updated
it for recent Bitcoin Core/python-bitcoinlib versions. I haven't checked if all
the options like OP_Return outputs and multisig still work, and it doesn't even
take segwit into account when calculating fees. Don't use it on a wallet with
funds you can't afford to lose; it definitely has bugs in it.
For reference, here is the logs from a successful double-spend attempt:
$ sleep 15 ; ./doublespend.py --fee1 0.00018 --fee2 0.000224 `/home/user/bitcoin/src/bitcoin-cli getnewaddress` 0.00001
DEBUG:root:Delta fee: 0.00002296
DEBUG:root:Adding new input caec040f4435e98de9ae44a385e301312c5a3cddfb33f1bd08e1cf63307f87ce:0 with value 0.00072549 BTC
DEBUG:root:Delta fee: 0.00003035
DEBUG:root:Payment tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff028a0f0100000000001600149e12f3ef33ba4ccde4b85978e675c9fe59bb24a2e8030000000000001600149049e0f57ec5899c1eed2c5e9aab1c34ff5cec1f02473044022063834a187727c1eceb9b3e6ae9ccd0d369b51af3493fafba1d61ed3b273d48f7022049fbe71ecd600c7345fb6002e04275eb8445031df746eceaa6e6f5f413f67497012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412d1ea49a8b00000000
INFO:root:Payment tx size: 0.222 KB, fees: 0.00002035, 0.00009166 BTC/KB
INFO:root:Sent payment tx: 1c28870a78efd1c4616726ea0ca3f9d67f5591aab415222e2c9ec6184fc0b4f2
INFO:root:Sleeping for 30 seconds
DEBUG:root:Delta fee: 0.00004279
DEBUG:root:Double-spend tx 01000000000101ce877f3063cfe108bdf133fbdd3c5a2c3101e385a344aee98de935440f04ecca0000000000ffffffff01ae0a0100000000001600149e12f3ef33ba4ccde4b85978e675c9fe59bb24a20247304402201289c26da70e9ec4424fc2ff7194b57384c78c9c986c2efe6771ac6f5fda199702200cefa72560f21cd9abe846078ce13197029562102f7a44b8ec50772a851c1799012102c56d86e3031851822485d1a2f9f0e402f14b96b64e711d5a2567412d1ea49a8b00000000
INFO:root:Double-spend tx size: 0.191 KB, fees: 0.00004279, 0.00022403 BTC/KB
INFO:root:Sent double-spend tx: fb62691537d92f61dcb8ace979e0947b47dcbc7e9f50e79f77059ba0a669cdb5
Remember that if you want to replicate this, don't be surprised if it takes
quite a few attempts if you're sending tx1 with next-block fees. A minority of
hash power is mining full-RBF. There's also a chance that in the ~30s or
whatever you wait between tx1 and tx2, a block is found and tx1 gets mined.
This chance is actually even higher than the ~5% you'd expect, because miners
don't instantly update their block templates.
So if ~30% of hash power is actively mining full-RBF, you might actually have a
~20% chance per attempt at succeeding at a naive high-fee/higher-fee
double-spend. Thus there's a (1-20%)^10 = 11% chance that 10 attempts in a row
fail. Being that unlucky happens all the time; the Gods of Probability,
probably hate you. :)
Finally, research like this is expensive in terms of my time and transaction
fees; research via the OTS calendar approach is essentially free. Donations are
appreciated as no-one is paying me to do full-RBF work or covering these
expenses.
Cheapest/easiest way is via Lightning: https://stacker.news/petertodd
Or on-chain: 1FCYd7j4CThTMzts78rh6iQJLBRGPW9fWv
# References
1) https://github.com/bitcoin/bitcoin/pull/28132
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230816/5589441e/attachment.sig>

2023-08-21 09:55:29

- reply

📅 Original date posted:2023-08-16
🗒️ Summary of this message: Peter Todd made a correction to his previous statement, acknowledging that it was Anthony Towns, not Andrew Chow, who criticized his use of OTS to measure full-RBF adoption.
📝 Original message:
On August 16, 2023 12:25:58 PM GMT+02:00, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Since Andrew Chow criticized my use of OTS(1) to measure full-RBF adoption,
Correction: Anthony Towns
I am truly terrible with names...

2023-08-21 09:48:48

- reply

📅 Original date posted:2023-08-16
🗒️ Summary of this message: The author disagrees with the necessity and potential dangers of fraud proofs in Lightning Network, suggesting a different approach and highlighting a potential use case for a "latest state backup" oracle scheme. They also discuss the benefits and drawbacks of Phoenix's approach.
📝 Original message:
On Wed, Aug 16, 2023 at 09:56:21AM +0200, Bastien TEINTURIER wrote:
> Hi Thomas,
>
> I don't think those fraud proofs are necessary at all. They're also
> dangerous, because they impose a hard penalty on LSPs for something
> that should be best effort (and could get desynchronized by connection
> issues, especially with flaky mobile connections).
Note that a hard pentalty might be more appropriate for a paid service, where
there's a clear expectation that the service works.
Also I'll point out to Thomas, that he's actually come up with a generic
"latest state backup" oracle scheme that might be useful for applications
outside of Lightning. It might be wortwhile to forward it to bitcoin-dev,
pointing that out, so it sees a wider audience. I can't recall anyone else
coming up with that precise mechanism before.
> I agree with Peter Todd that since the mobile wallet can check the state
> of the returned backup at every connection request, this makes it highly
> unlikely that the LSP can cheat: that's the approach we've taken for
> Phoenix.
Does Phoenix tell the user this has happened? Phoenix being a centralized
entity, a useful outcome would be people finding out something is wrong and
saying so on, eg, social media.
Similarly, the most likely reason why that would be triggered is Phoenix making
a mistake, not malice. Having clients loudly shutdown probably protects Phoenix
overall from their own mistakes in that scenario, by quickly getting people to
stop using Phoenix wallet temporarily until the situation is fixed. Bad for
reputation in the short term. But IMO better in the long term.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230816/e27888fd/attachment.sig>

2023-08-10 23:09:38

- reply

📅 Original date posted:2023-08-10
🗒️ Summary of this message: The author is skeptical of expiration dates for Bitcoin addresses as they may weaken silent payments and not solve certain problems.
📝 Original message:
On Sun, Aug 06, 2023 at 02:20:06PM +0000, josibake wrote:
> Hi Peter,
>
> Thanks for the feedback! As you mentioned, this is a more general problem in Bitcoin and not specific to BIP352. Therefore, if expiration dates are indeed something we want, they should be proposed and discussed as their own BIP and be a standard that can work for xpubs, static payment codes, as well as existing and future address formats. If that were to happen, it would be easy enough to add this expiration standard to silent payments as a new silent payments address version.
>
> That being said, I'm a bit skeptical in general of expiration dates and think that they weaken the value proposition of silent payments while not actually solving the problems you described. Consider the following scenarios:
>
> 1. Bob's wallet is compromised with a one-year expiry and for the next year, funds are sent to the attacker. The attacker may have the ability to update the expiration, and thus be able to keep receiving funds as Bob.
The ability to "update the expiration" is the ability to trick someone into
thinking a new address came from Bob, eg by modifying a donation address in a
social media profile. This attack works whether or not expiration exists.
> 2. Bob loses his keys with a one-year expiry but finds them again 3 years later. The expiration causes Bob to miss out on 2 years worth of potential payments.
If Bob has lost his keys, the safe thing to do is for people sending funds to
Bob to ask Bob for a new address. It is much more likely that Bob doesn't find
the keys, and multiple years worth of funds are wasted.
> 3. Bob dies with a one-year expiry but an heir inherits his backups several years down the road. The expiration date causes the heir to miss out on several years worth of potential payments.
If Bob is dead, why are people sending Bob money? In this example expiration
prevented an unintentional fraud.
> 4. Bob is prevented from updating his address for several years but retains access to his keys/backups. The expiration date causes Bob to miss out on several years worth of potential payments.
Same category as #2 and #3. The main cause of this example is going to jail,
which would usually be a circumstance where both key loss is likely, *and*
people may want to reconsider sending Bob money. Expiration is much more likely
to prevent a loss of funds due to theft or fraud.
> 5. Bob regularly updates his address with a new expiry, but not all senders are able to find the new, updated address causing Bob to miss out on potential payments.
If the senders can't find Bob's up-to-date address, how much due dilligence are
they possibly doing on where they're sending funds?
You need to provide a clear example of how you think Bob is distributing this
address, and yet, can't update it. Social media, webpages, github repos, etc.
are all easily updatable. How, concretely, is Bob going to be in a position
where updating an address is hard?
> 6. By updating his address, Bob is leaking metadata about himself, potentially compromising his safety.
This is an extremely marginal concern. Any silent payment address associated
with, eg, a social media profile is revealing far more metadata from other
actions of the user.
People pay other people for reasons, eg a developer writing code. Those reasons
translate into far more metadata than updating a donation address once every
year or two.
> You could argue that none of the scenarios above would be an issue if Bob just sets a very long expiry, but then the expiry doesn't really help in solving the issues you mentioned. What we really want is a way for Bob to revoke his silent payment address. For this, I think building a wallet protocol on top of silent payments is a better path to explore. Additionally, expiration dates as proposed degrade the privacy of silent payments: any outside observer can conclude that all transactions mined at block height N or greater were not payments to any silent payment address with an expiry less than N. As I mentioned already, there may also be privacy and safety concerns with the user needing to regularly update their silent payment address expiration date.
Outside observers can already do this kind of analysis with or without
expiration, as users regularly expire addresses in other ways (eg by updating a
social media profile).
I also find this attack extremely marginal due to how little information the
attacker gets: the k-anonymity set of silent payments is already very large.
> Lastly, on the subject of expiration dates in general, your proposed solution is not enforceable: any wallet can just ignore the extra bytes and send to the address/xpub/static payment code, anyways. For expiration dates to be useful, I'd argue they need to be enforced by consensus (which I am not convinced is a good idea).
Checksums are similar to expiration in this fashion: neither are enforced by
the consensus layer, and they don't need to be. For them to work in almost all
cases it is more than sufficient to just standardize them and enforce them in
the client. 99.999% of clients will respect expiration, solving the problem
nearly 100% of the time.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230810/a8674e4f/attachment.sig>

2023-08-05 21:58:15

- reply

📅 Original date posted:2023-08-05
🗒️ Summary of this message: Adding a field to silent payment addresses to encode expiration dates is suggested, with different byte lengths for different granularities.
📝 Original message:
On Fri, Aug 04, 2023 at 03:27:17PM -0700, Brandon Black wrote:
> I agree. Non-expiring addresses are a significant risk to bitcoin users.
>
> On 2023-08-04 (Fri) at 17:39:03 +0000, Peter Todd via bitcoin-dev wrote:
> > Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
> > the expiration date in terms of days after some epoch. 2^24 days is 45,000
> > years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
> > years. We'll be lucky if Bitcoin still exists in 180 years.
>
> Instead of a fixed width nDays, consider a custom compact encoding with
> the position of the first 0-bit indicating the number of extension bytes
> and the encoded granularity.
>
> bytes | prefix | usable bits | granularity | max expiration
> ------|------------|-------------|-------------|---------------
> 1 | 0b0 | 7 | year | 128 years
> 2 | 0b10 | 14 | week | 315 years
> 3 | 0b110 | 21 | day | 5700 years
> 4 | 0b1110 | 28 | block | 5100 years
> 5 | 0b11110 | 35 | ??? | ???
> 6 | 0b111110 | 42 | ??? | ???
> 7 | 0b1111110 | 49 | ??? | ???
> 8 | 0b11111110 | 56 | ??? | ???
>
> For address expiration, year or week expiration will typically be
> sufficiently granular, but for rare occasions more granularity can be
> encoded with longer addresses. This method also degrades cleanly even if
> the same address format is still in use in 100 or 300 years.
1) Having the granularity of the limit depend on *when* the limit is to be
applied in a UX nightmare. It is far simpler to just pick a useful granularity,
and include enough bytes of integer to work until well into the future. 3
bytes, 24-bits, of days is 45,000 years. That's plenty.
2) Your suggestion would result in a protocol that degrades over time, as the
granularity of *newly* created addresses goes up. This isn't like CTV/CLTV,
where we're creating something now with a limit in the future. 100 years from
now - if silent payments still exists - people will still want to create silent
payment addresses that expire, say, 30 days in the future. Your suggestion does
not allow that.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230805/82374bb3/attachment.sig>

2023-08-05 21:58:15

- reply

📅 Original date posted:2023-08-05
🗒️ Summary of this message: Samson Mow questions the 180-year limit for planning, suggesting a longer timeframe, and provides examples of historical inventions.
📝 Original message:
On Fri, Aug 04, 2023 at 11:41:39AM -0700, Samson Mow wrote:
> Why the 180 year limit? imho should plan for longer.
You know, it was only 137 years ago that the first practical electric motor was
invented; 143 years ago that the first practical light bulb was invented.
180 years is a long time.
But if that seems too short, as I said, 3 bytes is sufficient for 45,934 years.
The invention of agriculture is only 12,000 years old. Although I guess as a
toxic bitcoin carnivore you care more about the invention of the bow and arrow,
70,000 years ago.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230805/e99335b2/attachment.sig>

2023-08-04 20:19:32

- reply

📅 Original date posted:2023-08-04
🗒️ Summary of this message: Silent Payment addresses, which allow for multiple payments without privacy concerns, should have an expiration date to prevent funds from being lost forever. Adding a 3-byte field to encode the expiration date is a simple solution. Wallets should have a default expiration date and attempts to pay an expired address should fail.
📝 Original message:
tl;dr: Wallets don't last forever. They are often compromised or lost. When
this happens, the addresses generated from those wallets become a form of toxic
data: funds sent to those addresses can be easily lost forever.
All Bitcoin addresses have this problem. But at least existing Bitcoin
addresses aren't supposed to be reused. Silent Payments are: the whole point is
to have a single address that you can safely pay to multiple times, without
privacy concerns. Failing to make Silent Payment addresses eventually expire in
a reasonable amount of time is thus a particularly harmful mistake.
Fixing this is easy: add a 3 byte field to silent payments addresses, encoding
the expiration date in terms of days after some epoch. 2^24 days is 45,000
years, more than enough. Indeed, 2 bytes is probably fine too: 2^16 days is 180
years. We'll be lucky if Bitcoin still exists in 180 years.
Wallets should pick a reasonable default, eg 1 year, for newly created
addresses. Attempts to pay an expired address should just fail with a simple
"address expired". Lightning invoices are a good example here: while invoices
does not require expiration from a technical point of view, they do expire for
similar UX reasons as applies to silent payments.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230804/70c37a09/attachment.sig>

2023-08-03 12:35:35

- reply

📅 Original date posted:2023-08-03
🗒️ Summary of this message: The author of the pull request intends to remove restrictions on OP_Return outputs, despite potential transaction pinning vectors.
📝 Original message:
https://github.com/bitcoin/bitcoin/pull/28130
Sjors Provoost suggested that I email this mailing list as notice of my intent
to get a pull-req merged that would remove the arbitrary 80-byte, 1 output /
tx, standardness restrictions on OP_Return outputs. His rationale was that
removing these standardness restrictions could potentially open up additional
transaction pinning(1) vectors. Since this is a potential problem with any
relaxation of standardness rules, I don't consider this to be an important
concern. But consider this email your notice.
At least some miners appear to be mining non-bitcoin-core-standard
transactions. So with respect to the hash power of those miners these pinning
vectors may in fact exist already.
# References
1) https://bitcoinops.org/en/topics/transaction-pinning/
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230803/33786fbc/attachment-0001.sig>

2023-08-02 10:19:21

- reply

📅 Original date posted:2023-08-01
🗒️ Summary of this message: Daniel Lipshitz argues that the research is flawed and reaches an incorrect conclusion. He provides evidence of Coinspaid's use of 0-conf and offers to connect with Max, the CEO, for confirmation. He also mentions Changelly's offer to confirm GAP600 as a service provider. However, the request for concrete examples of merchants relying on unconfirmed transactions remains unanswered.
📝 Original message:
On Wed, Aug 02, 2023 at 01:27:24AM +0300, Daniel Lipshitz wrote:
> Your research is not thorough and reaches an incorrect conclusion.
>
> As stated many times - we service payment processors and some merchants
> directly - Coinspaid services multiple merchants and process a
> significant amount of BTC they are a well known and active in the space -
> as I provided back in December 2022 a email from Max the CEO of Coinspaid
> confirming their use of 0-conf as well as providing there cluster addresses
> to validate there deposit flows see here again -
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
> - if this is not sufficient then please email support at coinspaid.com and ask
> to be connected to Max or someone from the team who can confirm Conspaid is
> clients of GAP600. Max also at the time was open to do a call, I can check
> again now and see if this is still the case and connect you.
>
> That on its own is enough of a sample to validate our statistics.
Why don't you just give me an example of some merchants using Coinspaid, and
another example using Coinpayments, who rely on unconfirmed transactions? If
those merchants actually exist it should be very easy to give me some names of
them.
Without actual concrete examples for everyone to see for themselves, why should
we believe you?
> I have also spoken to Changelly earlier today and they offered to email pro
> @ changelly.com and they will be able to confirm GAP600 as a service
Emailed; waiting on a reply.
> provider. Also please send me the 1 trx hash you tested and I can see if it
> was queried to our system and if so offer some info as to why it wasnt
> approved. Also if you can elaborate how you integrated with Changelly - I
> can check with them if that area is not integrated with GAP600.
Why don't you just tell me exactly what service Changelly offers that relies on
unconfirmed transactions, and what characteristics would meet GAP600's risk
criteria? I and others on this mailing list could easily do test transactions
if you told us what we can actually test. If your service actually works, then
you can safely provide that information.
I'm not going to give you any exact tx hashes of transactions I've already
done, as I don't want to cause any problems for the owners of the accounts I
borrowed for testing. Given your lack of honesty so far I have every reason to
believe they might be retalliated against in some way.
> As the architect of such a major change to the status of 0-conf
> transactions I would think you would welcome the opportunity to speak to
> business and users who actual activities will be impacted by full RBF
> becoming dominant.
Funny how you say this, without actually giving any concrete examples of
businesses that will be affected. Who exactly are these businesses? Payment
processors obviously don't count.
> Are you able to provide the same i.e emails and contacts of people at
> the mining pools who can confirm they have adopted FULL RBF ?
I've already had multiple mining pools complain to me that they and their
employees have been harassed over full-rbf, so obviously I'm not going to
provide you with any private contact information I have. There's no need to
expose them to further harassment.
If you actually offered an unconfirmed transaction guarantee service, with real
customers getting an actual benefit, you'd be doing test transactions
frequently and would already have a very good idea of what pools do full-rbf.
Why don't you already have this data?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230802/7f826021/attachment.sig>

2023-08-01 15:59:57

- reply

📅 Original date posted:2023-08-01
🗒️ Summary of this message: The author argues that implementing a first seen safe rule would avoid negative impacts on merchants and users who accept unconfirmed transactions. However, the author questions the validity of the claim, as they could not find any evidence of actual merchants accepting unconfirmed payments.
📝 Original message:
On Mon, Jul 31, 2023 at 01:26:11PM +0300, Daniel Lipshitz via bitcoin-dev wrote:
> This would unnecessarily and extremely negatively impact merchants and
> users who choose to accept 0-conf while using mitigation tools like GAP600.
> This negative impact could be avoided by simply adding first seen safe rule
> - ie a trx can be replaced but needs to include the original outputs.
>
> At GAP600 we continue to see strong use of our service for BTC we have seen
> circa 350k unique trx hash per month (over the last 3 months) requested to
> our platform. Our clients include - Coinpayments, Coinspaid and Changelly.
I checked, and Coinpayments and Coinspaid are both merchant processors. I could
not find any example of actual merchants using their platform accepting
unconfirmed payments. I also could not find any documentation on their websites
indicating unconfirmed transaction acceptance.
As for Changelly, their website says right on the front that "With an average
transaction speed of 5–40 minutes, we ensure you can swiftly take advantage of
market opportunities." Obivously, 5 minutes is not an unconfirmed payment.
Additionally, I verified myself by doing test transactions with BIP125 disabled
and an adequate fee: unconfirmed payments are not accepted by Changelly. As
their exchange flow clearly says "Once BTC is confirmed in the blockchain,
we’ll start exchanging it to <coin>."
You need to provide an genuine example of an actual merchant who accepts
unconfirmed transactions as payment, and actually relies on first-seen
behavior.
> We have not seen any impact of full RBF on double spend rates for our trxs
Based on the above findings, this appears to be because you don't actually have
any clients who rely on unconfirmed payments.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230801/0d59f467/attachment.sig>

2023-07-30 22:52:21

- reply

📅 Original date posted:2023-07-30
🗒️ Summary of this message: A pull request has been submitted to enable full-RBF by default in Bitcoin Core, as approximately 40% of Bitcoin hash power is already using it.
📝 Original message:
FYI I have submitted a pull-req to Bitcoin Core to enable full-rbf by default:
https://github.com/bitcoin/bitcoin/pull/28132
At the moment approximately 40% of the total Bitcoin hash power is mining
full-rbf replacements, spread over 8 different pools. Multiple block explorers,
including blockstream.info(1) and mempool.space(2), have enabled full-rbf on
all their nodes. Nodes installed via BTCPay Server(3) and MyNode(4), among
others, enable full-rbf by default. Measurements also indicate that a
significant percentage of nodes have manually enabled full-rbf(5), and there
exists a well-connected set of nodes running my full-rbf peering patch(6).
As https://mempool.space/rbf#fullrbf shows, successful full-rbf replacements
are fairly common. Though the fact that only a minority of nodes relay full-rbf
replacements is still a nuisance barrier to taking advantage of them, eg in
multi-party transactions(7). A typical non-listening node with only 8 outgoing
connections is certainly *not* guaranteed to have full-rbf peers. Thus, my
pull-req to enable full-rbf by default.
Meanwhile, the last time full-rbf was discussed on this mailing list the only
opposition to full-rbf from actual entities with an actual claimed use(8) of
unconfirmed transactions was Bitrefill. I've checked multiple times, most
recently today, and I can find no evidence that Bitrefill actually accepts
unconfirmed transactions as payment any more even though their payment page
claims otherwise. Every test transactions I've done - from a variety of emails
and accounts not linked to myself - has required a confirmation.
Finally, on-chain wallets have been moving towards removing the ability to set
non-BIP125-rbf transactions entirely. For example, Electrum removed the ability
to turn off BIP125 last year(9), and Phoenix, Green, Nunchuck, and Zeus, -
among others - also provide no way to turn BIP125 off. For these wallets, the
existence of "non-replaceable" transactions is merely a support headache(10).
The fact is the dream of "on-chain coffee payments" is well and truly dead.
There is clearly no value in having the BIP125 distinction when ~40% of hashing
power ignores it. There is also clear value in *not* having that distinction:
https://petertodd.org/2023/why-you-should-run-mempoolfullrbf
We should enable full-rbf by default in Bitcoin Core github master, to be
released in the upcoming v26.0. Following that, we can depreciate and
eventually remove all BIP125 code and associated complexity in future releases
after that.
# References
1) https://github.com/Blockstream/esplora/commit/289cc6539497c3f42ab5c591c2369b75d90046e6
2) https://github.com/mempool/mempool/pull/3867
3) https://docs.btcpayserver.org/FAQ/Wallet/#does-btcpay-server-use-mempoolfullrbf-1-
4) https://github.com/mynodebtc/mynode/commit/a6cd63583cab8c62510925492bb2cfda9d2add09
5) https://petertodd.org/2022/bitcoin-core-nodes-running-fullrbf
6) https://github.com/petertodd/bitcoin/tree/full-rbf-v25.0
7) https://petertodd.org/2023/fullrbf-multiparty-protocols
8) While GAP600 claimed to act as a payment processor for unconfirmed
transactions, they refused to actually provide examples of real services
making use of them. Given their ties to BSV, I'm inclined to believe that
they are lying.
9) https://github.com/spesmilo/electrum/commit/e1dc7d1e6fb2fc5b88195b62cbe1613b252db388
10) https://github.com/spesmilo/electrum/issues/8490
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230730/141db94b/attachment.sig>

2023-06-19 18:19:51

- reply

📅 Original date posted:2023-06-03
🗒️ Summary of this message: A potential misalignment could result in developers and businesses constructing systems based on assumptions that could be compromised in the future.
📝 Original message:
On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev wrote:
> Depending on policy to mitigate this annex malleability vector could
> mislead developers into believing their transactions are immune to
> replacement, when in fact they might not be. This potential misalignment
> could result in developers and businesses constructing systems based on
> assumptions that could be compromised in the future, mirroring the
> situation that unfolded with zero-confirmation payments and rbf.
>
> It may thus be more prudent to permit the utilization of the annex without
> restrictions, inform developers of its inherent risks, and acknowledge that
> Bitcoin, in its present state, might not be ideally suited for certain
> types of applications?
In the specific case of annex replacement leading to larger transactions, in
almost all cases you only care about the annex malleability causing the
transaction to take longer to get mined, due to it being larger. The fact the
transaction has become larger does not matter if the transaction does in fact
get mined, eg due to an out-of-band payment by the "attacker".
The only exception is the rare cases where some transaction processing
software/hardware has actual limits on transaction size. Eg you could imagine a
hardware wallet that simply *can't* process a transaction larger than a certain
size due to a lack of RAM.
I don't think this is a good rational to make use of the annex standard. Quite
the contrary: we should be thinking about if and how to fix annex malleability
in a future soft fork.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/b7420b57/attachment.sig>

2023-06-15 00:33:42

- reply

📅 Original date posted:2023-06-05
🗒️ Summary of this message: ZeroSync proposes a proof system using SNARKs to compress the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. However, there are concerns about potential forks and the risk of losing decentralization if proof-generation becomes fast enough.
📝 Original message:
On Fri, May 12, 2023 at 02:12:03PM +0200, Robin Linus via bitcoin-dev wrote:
> Hi all,
>
> Today we are publishing a summary of our research on "ZeroSync: Introducing Validity Proofs to Bitcoin".
>
>
> Here's the preface:
>
> We introduce ZeroSync, the first-ever proof system addressing Bitcoin’s scalability challenges with Succinct Non-Interactive Argument of Knowledge (SNARKs). ZeroSync compresses the entire Bitcoin blockchain into a compact proof of validity, enabling instant verification and unlocking various innovative applications. We discuss our prototype implementation of a chain state proof, utilizing the Cairo language, Utreexo, and recursive STARKs. Our work enables diverse applications, including quick bootstrapping of full nodes, trustless light clients, enhanced Lightning Network privacy, and secure cross-chain bridges. Chain state proofs require no consensus changes, which is crucial as forks in Bitcoin are challenging to implement and achieve consensus for. Despite the existing bottleneck of prover performance, we present a range of optimization strategies and demonstrate the practicality of generating a complete chain state proof.
> Finally, we introduce zkCoins, a client-side validation protocol combined with zeroknowledge SNARKs, drastically improving privacy and throughput of token transactions. In combination with future Bitcoin features, such as Simplicity, zkCoins also enables private and more scalable BTC transactions.
> The groundbreaking compression capabilities of SNARKs initiated a paradigm shift in cryptocurrency design, and ZeroSync is pioneering their application to Bitcoin.
>
>
> You can find the full paper here: https://zerosync.org/zerosync.pdf <https://zerosync.org/zerosync.pdf>
> Happy to receive any comments and answer any questions the bitcoin dev community may have about the paper!
Two serious issues with this proposal:
1) You're creating an alternative implementation of the Bitcoin protocol. There
is a _long_ history of such implementations failing to implement an exact copy
of the consensus rules, leading to potential forks. Obviously, if only used by
otherwise lite clients, there is less of a risk associated with this. But the
risk is there and will expand as this tech is used for more sophisticated
things.
2) If the tech advances to the point where proof-generation is fast enough to
happen in real time, Bitcoin miners adopting it along with and other widepsread
adoption it may cause Bitcoin to lose its decentralization. At the heart,
Bitcoin's consensus is a proof of publication scheme: miners are (weakly)
forced to publish blocks by the fact that users and other miners demand blocks
to both validate their coins, and mine further. Without blocks themselves being
published on a timely basis, the censorship resistance of Bitcoin fails because
only a subset of miners actually have the necessary block data to create new
blocks with transactions in them. There's also other scenarios where these
capabilities could be abused, eg with "illegal data" being published in the
chain.
Re: #2, the Bitcoin technical community would be smart to find ways to *defeat*
ZKP schemes, with the goal of making it technologically infeasible to use them
for recently created blocks (eg the last few days worth).
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230605/452eab79/attachment.sig>

2023-06-09 13:13:26

- reply

📅 Original date posted:2023-06-03
🗒️ Summary of this message: Satoshi Nakamoto praises the Lightning Network for its ability to conduct global business and scale with fast, secure payments, and creates a lightning address.
📝 Original message:
On Sat, Jun 03, 2023 at 09:53:31PM +0000, Satoshi Nakamoto wrote:
> The Lightning Network is a great achievement. I have created satoshi at vistomail.com as my lightning address. I feel comfortable now that humans have the ability to conduct global business and scale with fast, and secure lightning payments. Lightning can process more transactions per second than any financial instrument. You are light years ahead of the traditional banking system. Bitcoin is a huge success and will continue to scale.
>
> Satoshi Nakamoto
BTW Vistomail seems to have recently changed ownership based on the fact that
the whois records and website content were recently changed:
$ whois vistomail.com
Domain Name: VISTOMAIL.COM
Registry Domain ID: 534373285_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Updated Date: 2023-04-26T18:36:42Z
Creation Date: 2006-07-27T09:46:18Z
Registry Expiry Date: 2026-07-27T09:46:18Z
Obviously, we can assume this is yet another scammer pretending to be Satoshi.
I would suggest we block this entire domain from the list.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230603/66d7329c/attachment.sig>

2023-06-09 13:08:57

- reply

📅 Original date posted:2023-06-03
📝 Original message:
On Sat, Jun 03, 2023 at 09:53:31PM +0000, Satoshi Nakamoto wrote:
> The Lightning Network is a great achievement. I have created satoshi at vistomail.com as my lightning address. I feel comfortable now that humans have the ability to conduct global business and scale with fast, and secure lightning payments. Lightning can process more transactions per second than any financial instrument. You are light years ahead of the traditional banking system. Bitcoin is a huge success and will continue to scale.
>
> Satoshi Nakamoto
BTW Vistomail seems to have recently changed ownership based on the fact that
the whois records and website content were recently changed:
$ whois vistomail.com
Domain Name: VISTOMAIL.COM
Registry Domain ID: 534373285_DOMAIN_COM-VRSN
Registrar WHOIS Server: whois.godaddy.com
Registrar URL: http://www.godaddy.com
Updated Date: 2023-04-26T18:36:42Z
Creation Date: 2006-07-27T09:46:18Z
Registry Expiry Date: 2026-07-27T09:46:18Z
Obviously, we can assume this is yet another scammer pretending to be Satoshi.
I would suggest we block this entire domain from the list.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20230603/66d7329c/attachment.sig>

2023-06-09 13:06:17

- reply

📅 Original date posted:2022-06-14
📝 Original message:
On Mon, May 02, 2022 at 08:59:49AM -0700, Jeremy Rubin wrote:
> Ok, got it. Won't waste anyone's time on terminology pedantism.
>
>
> The model that I proposed above is simply what *any* correct timestamping
> service must do. If OTS does not follow that model, then I suspect whatever
> OTS is, is provably incorrect or, in this context, unreliable, even when
> servers and clients are honest.
Do you think RFC 3628 is "provably incorrect" too? It's just a standard for
Trusted Time-Stamping Authorities to issue timestamp proofs via digital
signatures, in the most straight forward manner of signing a message claiming
that some digest existed as of some time.
As the RFC says in the introduction:
The TSA's role is to time-stamp a datum to establish evidence indicating that a
datum existed before a particular time. This can then be used, for example, to
verify that a digital signature was applied to a message before the
corresponding certificate was revoked thus allowing a revoked public key
certificate to be used for verifying signatures created prior to the time of
revocation.
Simple and straight forward.
The problem here is starts with the fact that you're asking timestamp services
to do things that they're not claiming they do; a timestamp proof simply proves
that some message m existed prior to some time t. Nothing more.
Worse though, linearization is a busted approach.
> Unreliable might mean different things to
> different people, I'm happy to detail the types of unreliability issue that
> arise if you do not conform to the model I presented above (of which,
> linearizability is one way to address it, there are others that still
> implement epoch based recommitting that could be conceptually sound without
> requiring linearizability).
>
> Do you have any formal proof of what guarantees OTS provides against which
> threat model? This is likely difficult to produce without a formal model of
> what OTS is, but perhaps you can give your best shot at producing one and
> we can carry the conversation on productively from there.
So as you know, an OpenTimestamps proof consists of a series of commitment
operations that act on an initial message m, leading to a message known to have
been created at some point in time. Almost always a Bitcoin block header. But
other schemes like trusted timestamps are possible too.
A commitment operation (namely hashes + concatenation) simply needs the
property that for a given input message m, the output H(m) can't be predicted
without knowledge of m. In the case of concatenation, this property is achieved
trivially by the fact that the output includes m verbatim. Similarly, SHA1 is
still a valid commitment operation.
Behind the scenes the OTS infrastructure builds merkle trees of commitment
operations for scalability reasons. But none of those details are relevant to
the validity of OTS proofs - the OTS infrastructure could magically mine a
block per transaction with the digest in the coinbase, and from the client's
point of view, everything would work the same.
The important thing to recognize is that timestamp proof is simply a one-sided
bound on when a given message existed, proving a message existed _prior_ to
some point in time. For example:
$ ots verify hello-world.txt.ots
Assuming target filename is 'hello-world.txt'
Success! Bitcoin block 358391 attests existence as of 2015-05-28 EDT
Obviously, the message "Hello World!" existed prior to 2015 (Indeed, it's such
a short message it's brute-forcable. But for sake of example, we'll ignore
that).
Thus your claim re: linearization that:
> Having a chain of transactions would serve to linearize history of
> OTS commitments which would let you prove, given reorgs, that knowledge of
> commit A was before B a bit more robustly.
...misunderstands the problem. We care about proving statements about messages.
Not timestamp proofs. Building infrastructure to order timestamp proofs
themselves is pointless.
What you're alluding to is dual-sided bounds on when messages were created.
That's solved by random beacons: messages known to have been created *after* a
point in time, and unpredictable prior. A famous example of course being the
genesis block quote:
The Times 03/Jan/2009 Chancellor on brink of second bailout for banks
Bitcoin block hashes make for a perfectly good random beacon for use-cases with
day to hour level precision. For higher precision, absolute time, there are
many trusted alternatives like the NIST random beacon, Roughtime, etc.
OpenTimestamps could offer a trustless _relative_ random beacon service by
making the per-second commitments a merkle mountain range, and publishing the
tip digests. In fact, that's how I came up with merkle mountain ranges in the
first place, and there's code from 2012 to do exactly that in depths of the git
repo. But that's such a niche use-case I decided against that approach for now;
I'll probably resurrect it in the future for trusted timestamps/clock sync.
Again, involving the transactions themselves in any of this random beacon stuff
is pointless.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220614/569cfb2a/attachment.sig>

2023-06-09 13:06:16

- reply

📅 Original date posted:2022-06-28
📝 Original message:
On Tue, Jun 28, 2022 at 11:31:54AM -0400, Matt Corallo wrote:
> On 6/28/22 9:05 AM, Christian Decker wrote:
> > It is worth mentioning here that the LN protocol is generally not very
> > latency sensitive, and from my experience can easily handle very slow
> > signers (3-5 seconds delay) without causing too many issues, aside from
> > slower forwards in case we are talking about a routing node. I'd expect
> > routing node signers to be well below the 1 second mark, even when
> > implementing more complex signer logic, including MuSig2 or nested
> > FROST.
>
> In general, and especially for "edge nodes", yes, but if forwarding nodes
> start taking a full second to forward a payment, we probably need to start
> aggressively avoiding any such nodes - while I'd love for all forwarding
> nodes to take 30 seconds to forward to improve privacy, users ideally expect
> payments to complete in 100ms, with multiple payment retries in between.
Idle question: would it be worthwhile to allow people to opt-in to their
payments happening more slowly for privacy? At the very least it'd be fine if
payments done by automation for rebalancing, etc. happened slowly.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220628/0853d86e/attachment.sig>

2023-06-09 13:05:50

- reply

📅 Original date posted:2022-04-28
📝 Original message:
On Sun, Apr 17, 2022 at 01:57:28PM -0700, Jeremy Rubin wrote:
> the 'lots of people' stuff (get confused, can't figure out what i'm
> quoting, actually are reading this conversation) is an appeal to an
> authority that doesn't exist. If something is unclear to you, let me know.
> If it's unclear to a supposed existential person or set of persons, they
> can let me know.
It's pretty simple: bitcoin-dev is read by hundreds of people. This has nothing
to do with authority. It's about not wasting the time of those people.
> concretely, I am confused by how OTS can both support RBF for updating to
> larger commitments (the reason you're arguing with me) and not have an
> epoch based re-comittings scheme and still be correct. My assumption now,
> short of a coherent spec that's not just 'read the code', is that OTS
> probably is not formally correct and has some holes in what is
> committed to, or relies on clients re-requesting proofs if they fail to be
> committed. in any case, you would be greatly aided by having an actual spec
> for OTS since i'm not interested in the specifics of OTS software, but I'm
> willing to look at the protocol. So if you do that, maybe we can talk more
> about the issue you see with how sponsors works.
OpenTimestamps is, as the name suggests, for cryptographic timestamping. As is
obvious to anyone with a good knowledge of cryptography, a cryptographic
timestamp proves that data existed prior to some point in time. That's it.
> further, I think that if there is something that sponsors does that could
> make a hypothetical OTS-like service work better, in a way that would be
> opaque (read: soft-fork like wrt compatibility) to clients, then we should
> just change what OTS is rather than committing ourselves to a worse design
> in service of some unstated design goals. In particular, it seems that
> OTS's servers can be linearized and because old clients aren't looking for
> linearization, then the new linearization won't be a breaking change for
> old clients, just calendar servers. And new clients can benefit from
> linearization.
The fact you keep bringing up linearization for a timestmaping service makes me
think something is missing in your understanding of cryptography. Tell me, how
exactly do you think linearization would help in an example use-case? More
specifically, what attack would be prevented?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220428/3d16d41a/attachment.sig>

2023-06-09 13:05:49

- reply

📅 Original date posted:2022-04-15
📝 Original message:
On Mon, Apr 11, 2022 at 09:18:10AM -0400, Jeremy Rubin wrote:
> > nonsense marketing
>
> I'm sure the people who are confused about "blockchain schemes as \"world
> computers\" and other nonsense
> marketing" are avid and regular readers of the bitcoin devs mailing list so
> I offer my sincerest apologies to all members of the intersection of those
> sets who were confused by the description given.
Of course, uninformed people _do_ read all kinds of technical materials. And
more importantly, those technical materials get quoted by journalists,
scammers, etc.
> > useless work
>
> progress is not useless work, it *is* useful work in this context. you have
> committed to some subset of data that you requested -- if it was 'useless',
> why did you *ever* bother to commit it in the first place? However, it is
> not 'maximally useful' in some sense. However, progress is progress --
> suppose you only confirmed 50% of the commitments, is that not progress? If
> you just happened to observe 50% of the commitments commit because of
> proximity to the time a block was mined and tx propagation naturally would
> you call it useless?
Please don't trim quoted text to the point where all context is lost. Lots of
people read this mailing list and doing that isn't helpful to them.
> > Remember that OTS simply proves data in the past. Nothing more.
> > OTS doesn't have a chain of transactions
> Gotcha -- I've not been able to find an actual spec of Open Time Stamps
The technical spec of OpenTimestamps is of course the normative validation
source code, currently python-opentimestamps, similar to how the technical spec
of Bitcoin is the consensus parts of the Bitcoin Core codebase. The explanatory
docs are linked on https://opentimestamps.org under the "How It Works" section.
It'd be good to take the linked post in that section and turn it into better
explanatory materials with graphics (esp interactive/animated graphics).
> anywhere, so I suppose I just assumed based on how I think it *should*
> work. Having a chain of transactions would serve to linearize history of
> OTS commitments which would let you prove, given reorgs, that knowledge of
> commit A was before B a bit more robustly.
I'll reply to this as a separate email as this discussion - while useful - is
getting quite off topic for this thread.
> > I'd rather do one transaction with all pending commitments at a
> particular time
> rather than waste money on mining two transactions for a given set of
> commitments
>
> This sounds like a personal preference v.s. a technical requirement.
>
> You aren't doing any extra transactions in the model i showed, what you're
> doing is selecting the window for the next based on the prior conf.
...the model you showed is wrong, as there is no reason to have a linearized
transaction history. OpenTimestamps proofs don't even have the concept of
transactions: the proof format proves that data existed prior to a merkle root
of a particular Bitcoin block. Not a Bitcoin transaction.
> See the diagram below, you would have to (if OTS is correct) support this
> sort of 'attempt/confirm' head that tracks attempted commitments and
> confirmed ones and 'rewinds' after a confirm to make the next commit
> contain the prior attempts that didn't make it.
>
> [.........................................................................]
> ------^ confirm head tx 0 at height 34
> ------------------------^ attempt head after tx 0
> -----------^ confirm head tx 1 at height 35
> --------------------------^ attempt head after tx 1
> ------------^ confirm head tx 2 at height 36
> -------------------------------^
> attempt head after tx 2
> -------------------------------^
> confirm head tx 3 at height 37
>
> you can compare this to a "spherical cow" model where RBF is always perfect
> and guaranteed inclusion:
>
>
> [.........................................................................]
> ------^ confirm head tx 0 at height 34
> -------------------------^ confirm head tx 1 at height 35
> -----------^ confirm head at tx 1
> height 36
> -----------------^
> confirm head tx 3 at height 37
>
> The same number of transactions gets used over the time period.
None of the above has anything to do with how OpenTimestamps works.
Anyway, getting back to the topic at hand, I remain of the opinion that in the
unlikely event that fee accounts is ever implemented, it should be opt-in.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220415/3d390f28/attachment-0001.sig>

2023-06-09 13:05:49

- reply

📅 Original date posted:2022-04-10
📝 Original message:
On Sun, Feb 20, 2022 at 08:29:00AM -0800, Jeremy Rubin wrote:
> > On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > > > As I said, it's a new kind of pinning attack, distinct from other types
> > > of pinning attack.
> > >
> > > I think pinning is "formally defined" as sequences of transactions which
> > > prevent or make it less likely for you to make any progress (in terms of
> > > units of computation proceeding).
> >
> > Mentioning "computation" when talking about transactions is misleading:
> > blockchain transactions have nothing to do with computation.
> >
>
> It is in fact computation. Branding it as "misleading" is misleading... The
> relevant literature is https://en.wikipedia.org/wiki/Non-blocking_algorithm,
> sponsors helps get rid of deadlocking so that any thread can be guaranteed
> to make progress. E.g., this is critical in Eltoo, which is effectively a
> coordinated multi-party computation on-chain to compute the highest
> sequence number known by any worker.
>
> That transactions are blobs of "verification" (which is also itself a
> computation) less so than dynamic computations is irrelevant to the fact
> that series of transactions do represent computations.
It's misleading in the blockchain environment where lots of people have been
trying to portray blockchain schemes as "world computers" and other nonsense
marketing. You would have been better off just saying "make any progress"
without mentioning "computation" at all.
> > > Something that only increases possibility to make progress cannot be
> > > pinning.
> >
> > It is incorrect to say that all use-cases have the property that any
> > version of
> > a transaction being mined is progress.
> >
>
> It is progress, tautologically. Progress is formally definable as a
> transaction of any kind getting mined. Pinning prevents progress by an
> adversarial worker. Sponsoring enables progress, but it may not be your
> preferred interleaving. That's OK, but it's inaccurate to say it is not
> progress.
Let's try to use terminology with straight-forward meanings. I've yet to see
any other protocol where "progess" can also mean useless work being done.
> I didn't claim there to be a chain of unconfirmed, I claimed that there
> could be single output chain that you're RBF'ing one step per block.
>
> E.g., it could be something like
>
> A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {bar}}
>
> such that A_i provably can't have an unconfirmed descendant. The notion
> would be that you're replacing one with another. E.g., if you're updating
> the calendar like:
>
>
> Version 0: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo}}
> Version 1: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar}}
> Version 2: A_0 -> {A_1 w/ CSV 1 block, OP_RETURN {blah, foo, bar, delta}}
>
> and version 1 gets mined, then in A_1's spend you simply shift delta to
> that (next) calendar.
>
> A_1 -> {A_2 w/ CSV 1 block, OP_RETURN {delta}}
>
> Thus my claim that someone sponsoring a old version only can delay by 1
> block the calendar commit.
You seem to still be confused about OpenTimestamps. There is no output chain at
all; OTS has no reason to use CheckSequenceVerify and does not. OTS
transactions are, from the point of view of the timestamp proofs, entirely
independent of one another.
Remember that OTS simply proves data in the past. Nothing more.
> > > Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> > > third party for OTS, you should be relatively happy because it cost you
> > > less fees overall, since the undoing of your later RBF surely returned
> > some
> > > satoshis to your wallet.
> >
> > As I said above, no it doesn't.
> >
> >
> It does save money since you had to pay to RBF, the N+1st txn will be
> paying higher fee than the Nth. So if someone else sponsors an earlier
> version, then you save whatever feerate/fee bumps you would have paid and
> the funds are again in your change output (or something). You can apply
> those change output savings to your next batch, which can include any
> entries that have been dropped .
Again, that is not true. Because OTS doesn't have a chain of transactions, I'd
rather do one transaction with all pending commitments at a particular time
rather than waste money on mining two transactions for a given set of
commitments that need timestamping.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220410/e4530413/attachment.sig>

2023-06-09 13:05:10

- reply

📅 Original date posted:2022-02-19
📝 Original message:
On Sat, Feb 19, 2022 at 05:20:19PM +0000, darosior wrote:
> > Necromancing might be a reasonable name for attacks that work by getting an
> > out-of-date version of a tx mined.
>
> It's not an "attack"? There is no such thing as an out-of-date transaction, if
> you signed and broadcasted it in the first place. You can't rely on the fact that
> a replacement transaction would somehow invalidate a previous version of it.
Anyone on the internet can send you a packet; a secure system must be able to
receive any packet without being compromised. Yet we still call packet floods
as DoS attacks. And internet standards are careful to avoid making packet
flooding cheaper than it currently is.
The same principal applies here: in many situations transactions _do_ become
out of date, in the sense that you would rather a different transaction be
mined instead, and the out-of-date tx being mined is expensive and annoying.
While you have to account for the _possibility_ of any transaction you have
signed being mined, Bitcoin standards should avoid making unwanted necromancy a
cheap and easy attack.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220219/d50565cf/attachment.sig>

2023-06-09 13:05:09

- reply

📅 Original date posted:2022-02-19
📝 Original message:
On Fri, Feb 18, 2022 at 04:38:27PM -0800, Jeremy Rubin wrote:
> > As I said, it's a new kind of pinning attack, distinct from other types
> of pinning attack.
>
> I think pinning is "formally defined" as sequences of transactions which
> prevent or make it less likely for you to make any progress (in terms of
> units of computation proceeding).
Mentioning "computation" when talking about transactions is misleading:
blockchain transactions have nothing to do with computation.
> Something that only increases possibility to make progress cannot be
> pinning.
It is incorrect to say that all use-cases have the property that any version of
a transaction being mined is progress.
> If you want to call it something else, with a negative connotation, maybe
> call it "necromancing" (bringing back txns that would otherwise be
> feerate/fee irrational).
Necromancing might be a reasonable name for attacks that work by getting an
out-of-date version of a tx mined.
> In particular, for the use case you mentioned "Eg a third party could mess
> up OpenTimestamps calendars at relatively low cost by delaying the mining
> of timestamp txs.", this is incorrect. A third party can only accelerate
> the mining on the timestamp transactions, but they *can* accelerate the
> mining of any such timestamp transaction. If you have a single output chain
> that you're RBF'ing per block, then at most they can cause you to shift the
> calendar commits forward one block. But again, they cannot pin you. If you
> want to shift it back one block earlier, just offer a higher fee for the
> later RBF'd calendar. Thus the interference is limited by how much you wish
> to pay to guarantee your commitment is in this block as opposed to the next.
Your understanding of how OpenTimestamps calendars work appears to be
incorrect. There is no chain of unconfirmed transactions. Rather, OTS calendars
use RBF to _update_ the timestamp tx with a new merkle tip hash for to all
outstanding per-second commitments once per new block. In high fee situations
it's normal for there to be dozens of versions of that same tx, each with a
slightly higher feerate.
OTS calendars can handle any of those versions getting mined. But older
versions getting mined wastes money, as the remaining commitments still need to
get mined in a subsequent transaction. Those remaining commitments are also
delayed by the time it takes for the next tx to get mined.
There are many use-cases beyond OTS with this issue. For example, some entities
use "in-place" replacement for update low-time-preference settlement
transactions by adding new txouts and updating existing ones. Older versions of
those settlement transactions getting mined rather than the newer version
wastes money and delays settlement for the exact same reason it does in OTS.
If fee accounts or any similar mechanism get implemented, they absolutely
should be opt-in. Obviously, using a currently non-standard nVersion bit is a
possible approach. Conversely, with CPFP it may be desirable in the settlement
case to be able to *prevent* outputs from being spent in the same block. Again,
an nVersion bit is a possible approach.
> By the way, you can already do out-of-band transaction fees to a very
> similar effect, google "BTC transaction accelerator". If the attack were at
> all valuable to perform, it could happen today.
I just checked: all the BTC transaction accellerator services I could find look
to be either scams, or very expensive. We need compelling reasons to make this
nuisance attack significantly cheaper.
> Lastly, if you do get "necromanced" on an earlier RBF'd transaction by a
> third party for OTS, you should be relatively happy because it cost you
> less fees overall, since the undoing of your later RBF surely returned some
> satoshis to your wallet.
As I said above, no it doesn't.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220219/e3194806/attachment-0001.sig>

2023-06-09 13:05:08

- reply

📅 Original date posted:2022-02-18
📝 Original message:
On Thu, Feb 10, 2022 at 12:08:59AM -0800, Jeremy Rubin wrote:
> That's not really pinning; painning usually refers to pinning something to
> the bottom of the mempool whereas these mechanisms make it easier to
> guarantee that progress can be made on confirming the transactions you're
> interested in.
As I said, it's a new kind of pinning attack, distinct from other types of
pinning attack.
> Often times in these protocols "the call is coming inside the house". It's
> not a third party adding fees we are scared of, it's a direct party to the
> protocol!
Often times that is true. But other times that is not true! I gave examples of
use-cases where being able to arbitrary add fees to transactions is harmful;
the onus is on you to argue why that is acceptable to burden those users with a
new class of attack.
> Sponsors or fee accounts would enable you to ensure the protocol you're
> working on makes forward progress. For things like Eltoo the internal
> ratchet makes this work well.
>
> Protocols which depend on in mempool replacements before confirmation
> already must be happy (should they be secure) with any prior state being
> mined. If a third party pays the fee you might even be happier since the
> execution wasn't on your dime.
"Must be able to deal with" is not the same thing as "Must be happy". While
those use-cases do have to deal with those exceptional cases happening
occasionally, it's harmful if an attacker can harass you by making those
exceptional cases happen frequently.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220218/ffb7a6b7/attachment.sig>

2023-06-09 13:05:08

- reply

📅 Original date posted:2022-02-10
📝 Original message:
On Sat, Jan 01, 2022 at 12:04:00PM -0800, Jeremy via bitcoin-dev wrote:
> Happy new years devs,
>
> I figured I would share some thoughts for conceptual review that have been
> bouncing around my head as an opportunity to clean up the fee paying
> semantics in bitcoin "for good". The design space is very wide on the
> approach I'll share, so below is just a sketch of how it could work which
> I'm sure could be improved greatly.
>
> Transaction fees are an integral part of bitcoin.
>
> However, due to quirks of Bitcoin's transaction design, fees are a part of
> the transactions that they occur in.
>
> While this works in a "Bitcoin 1.0" world, where all transactions are
> simple on-chain transfers, real world use of Bitcoin requires support for
> things like Fee Bumping stuck transactions, DoS resistant Payment Channels,
> and other long lived Smart Contracts that can't predict future fee rates.
> Having the fees paid in band makes writing these contracts much more
> difficult as you can't merely express the logic you want for the
> transaction, but also the fees.
>
> Previously, I proposed a special type of transaction called a "Sponsor"
> which has some special consensus + mempool rules to allow arbitrarily
> appending fees to a transaction to bump it up in the mempool.
>
> As an alternative, we could establish an account system in Bitcoin as an
> "extension block".
<snip>
> This type of design works really well for channels because the addition of
> fees to e.g. a channel state does not require any sort of pre-planning
> (e.g. anchors) or transaction flexibility (SIGHASH flags). This sort of
> design is naturally immune to pinning issues since you could offer to pay a
> fee for any TXID and the number of fee adding offers does not need to be
> restricted in the same way the descendant transactions would need to be.
So it's important to recognize that fee accounts introduce their own kind of
transaction pinning attacks: third parties would be able to attach arbitrary
fees to any transaction without permission. This isn't necessarily a good
thing: I don't want third parties to be able to grief my transaction engines by
getting obsolete transactions confirmed in liu of the replacments I actually
want confirmed. Eg a third party could mess up OpenTimestamps calendars at
relatively low cost by delaying the mining of timestamp txs.
Of course, there's an obvious way to fix this: allow transactions to designate
a pubkey allowed to add further transaction fees if required. Which Bitcoin
already has in two forms: Replace-by-Fee and Child Pays for Parent.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20220210/ddb4235b/attachment.sig>

2023-06-09 13:04:55

- reply

📅 Original date posted:2021-12-18
📝 Original message:
On Fri, Dec 17, 2021 at 11:37:12AM +0100, Joost Jager wrote:
> Hello list,
>
> In Lightning we have a great scheme to protect the identity of the sender
> of a payment. This is awesome, but there are also use cases where opt-in
> sender authentication is desired.
Lightning already has sender authentication: you simply give someone a
pre-image hash over an authenticated channel, and the fact that the payment was
made means only they could have realistically made it as they were the only
person who knew that pre-image hash.
Going beyond that is dangerous as you're creating the ability to prove to a
*third* party who made a particular payment. That raises serious problems in
cases like government raids that need to be considered very carefully.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211218/328206a3/attachment.sig>

2023-06-09 13:04:54

- reply

📅 Original date posted:2021-12-20
📝 Original message:
On Mon, Dec 20, 2021 at 09:01:37AM +0100, Joost Jager wrote:
> On Sat, Dec 18, 2021 at 6:56 PM Peter Todd <pete at petertodd.org> wrote:
>
> > Lightning already has sender authentication: you simply give someone a
> > pre-image hash over an authenticated channel, and the fact that the
> > payment was
> > made means only they could have realistically made it as they were the only
> > person who knew that pre-image hash.
> >
>
> This sounds quite similar to what is described above in lnurl-18. I can see
> that that works, but I should have added that I was looking for a solution
> that exists completely within the protocol without using an additional
> channel. Also, routing nodes learn the preimage hash too, so the sender
> isn't the only person. But that is solved by the payment secret that is
> also part of the invoice.
The key thing is the invoice has to get to the sender somehow in the first
place. So I don't think there's any reason to use the lightning protocol itself
for additional authentication.
> > Going beyond that is dangerous as you're creating the ability to prove to a
> > *third* party who made a particular payment. That raises serious problems
> > in
> > cases like government raids that need to be considered very carefully.
>
>
> This is why I proposed to use diffie-hellman to generate a shared secret.
> The receiver could then have made up all the proofs themselves and are
> therefore of no value to a third party.
The purpose of diffie-hellman is to generate a shared secret in the absense of
a secure channel. Once you have a secure channel there's no reason to use it.
Simply giving the sender the payment info is sufficient.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211220/3d42edd8/attachment.sig>

2023-06-09 13:04:35

- reply

📅 Original date posted:2021-12-09
📝 Original message:
On Thu, Dec 09, 2021 at 07:12:45AM -0500, Alex Schoof wrote:
> The multisig scheme is interesting. From my understanding of Single Use
> Seals, since seal n commits to seal n+1, for the on-chain aggregation seals
> you would want to pick some common aggregation service provider ahead of
> time and if that provider disappears, you’re stuck and cant close the next
> seal. If instead you say “this seal commits to three of the five of these
> next seals” then you mitigate both availability and censorship risk. Am I
> getting that right?
Re: "some common aggregation service provider", you might be misunderstanding
the protocol: since seals are trustless with regard to validity, I can validate
your seal, regardless of which aggregation service you use.
But other than that, I think we're on the same page!
A concrete example would be an exchange: they do a lot of transactions, so they
could choose to be their own aggregator, and wouldn't need any multisig at all
because they can trust themselves not to censor themselves. :) Meanwhile, one
of their customers might use 3-of-5 as you suggest, as they only do a few
transactions a month.
Interestingly, in some scenarios it might be worthwhile to both run your own
aggregator, and use multisig. Eg Alice could use a 2-of-3 with two third-party
aggregators, and her own aggregation chain. If both third-parties are up, she
does no on-chain transactions at all; if one third-party is down, she can use
her own, and the remaining third-party. Thus she would only do an on-chain
transaction to defeat censorship/failure.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/6edd19ec/attachment.sig>

2023-06-09 13:04:34

- reply

📅 Original date posted:2021-12-09
📝 Original message:
On Mon, Dec 06, 2021 at 04:35:19PM +0000, Christian Moss via bitcoin-dev wrote:
> As far as I understand it, RGB doesn't scale NFTs as each
> transaction to transfer ownership of an NFT would require an onchain
> transaction
RGB intends to scale NFTs and similar things in the future via scalable
single-use-seals: https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/468e4620/attachment.sig>

2023-06-09 13:04:34

- reply

📅 Original date posted:2021-12-09
📝 Original message:
On Thu, Dec 09, 2021 at 09:49:11AM +0000, Christian Moss wrote:
> pete at petertodd.org, so single use seals require an onchain transaction to
> post the proof of publication to the ledger (assuming bitcoin is used as
> the ledger) when an asset is transferred, but it can scale because you can
> batch many proofs (transfer of ownerships) into a merkle tree and just add
> the merkle root into the single tx going into the ledger?
Exactly. And since the aggregation is trustless with respect to validity, users
can choose what kind of censorship risk they're willing to take (as well as
mitigate it with "multisig" schemes that use multiple aggregators in parallel).
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20211209/1f650ac2/attachment.sig>

2023-06-09 13:02:30

- reply

📅 Original date posted:2021-06-01
📝 Original message:
On Tue, Jun 01, 2021 at 10:18:42PM +0000, darosior via Lightning-dev wrote:
> Hi all,
>
> It's been almost 9 months since Tor v2 hidden services have been deprecated.
> The Tor project will drop v2 support in about a month in the latest release. It will then be entirely be dropped from all supported releases by October.
> More at https://blog.torproject.org/v2-deprecation-timeline .
>
> Bitcoin Core defaults to v3 since 0.21.0 (https://bitcoincore.org/en/releases/0.21.0/) and is planning to drop the v2 support for 0.22 (https://github.com/bitcoin/bitcoin/pull/22050), which means that v2 onions will gradually stop being gossiped on the Bitcoin network.
>
> I think we should do the same for the Lightning network, and the timeline is rather tight. Also, the configuration is user-facing (as opposed to Bitcoin Core, which generates ephemeral services) which i expect to make the transition trickier.
> C-lightning is deprecating the configuration of Tor v2 services starting next release, according to our deprecation policy we should be able to entirely drop its support 3 releases after this one, which should be not so far from the October deadline.
>
> Opinions? What is the state of other implementations with regard to Tor v2 support?
One small point re: discussing this topic: remember that Tor is a centralized
system with a centralized consensus and directory authorities. So when they say
they are dropping v2 hidden services, at some point in the near future that
central infrastructure will also drop v2 hidden service support, and v2 hidden
services _will_ stop working on the Tor network. So it is pointless to keep
support for v2 hidden services beyond Tor's stated deadlines (other than things
like maybe ignoring old v2-related config options and the like).
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20210601/97f57399/attachment.sig>

2023-06-09 12:56:32

- reply

📅 Original date posted:2019-10-06
📝 Original message:
On Sun, Oct 06, 2019 at 08:46:59AM +0000, ZmnSCPxj wrote:
> > Obviously with care you can get the computation right. But at that point what's
> > the actual advantage over OP_CAT?
> >
> > We're limited by the size of the script anyway; if the OP_CAT output size limit
> > is comparable to that for almost anything you could use SHA256STREAM on you
> > could just as easily use OP_CAT, followed by a single OP_SHA256.
>
> Theoretically, `OP_CAT` is less efficient.
>
> In cases where the memory area used to back the data cannot be resized, new backing memory must be allocated elsewhere and the existing data copied.
> This leads to possible O( n^2 ) behavior for `OP_CAT` (degenerate case where we add 1 byte per `OP_CAT` and each time find that the memory area currently in use is exactly fitting the data and cannot be resized in-place).
In even that degenerate case allocators also free memory.
Anyway, every execution step in script evaluation has a maximum output size,
and the number of steps is limited. At worst you can allocate the entire
possible stack up-front for relatively little cost (eg fitting in the MB or two
that is a common size for L2 cache).
> Admittedly a sufficiently-limited maximum `OP_CAT` output would be helpful in reducing the worst-case `OP_CAT` behavior.
> The question is what limit would be reasonable.
> 64 bytes feels too small if one considers Merkle tree proofs, due to mentioned issues of lack of typechecking.
256 bytes is more than enough for even the most complex summed merkle tree with
512-byte hashes and full-sized sum commitments. Yet that's still less than the
~500byte limit proposed elsewhere.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191006/13e0402e/attachment.sig>

2023-06-09 12:56:31

- reply

📅 Original date posted:2019-10-04
📝 Original message:
On Thu, Oct 03, 2019 at 10:02:14PM -0700, Jeremy via bitcoin-dev wrote:
> Awhile back, Ethan and I discussed having, rather than OP_CAT, an
> OP_SHA256STREAM that uses the streaming properties of a SHA256 hash
> function to allow concatenation of an unlimited amount of data, provided
> the only use is to hash it.
>
> You can then use it perhaps as follows:
>
> // start a new hash with item
> OP_SHA256STREAM (-1) -> [state]
> // Add item to the hash in state
> OP_SHA256STREAM n [item] [state] -> [state]
> // Finalize
> OP_SHA256STREAM (-2) [state] -> [Hash]
>
> <-1> OP_SHA256STREAM <tag> <subnode 2> <subnode 3> <3> OP_SHA256STREAM <-2>
> OP_SHA256STREAM
One issue with this is the simplest implementation where the state is just raw
bytes would expose raw SHA256 midstates, allowing people to use them directly;
preventing that would require adding types to the stack. Specifically I could
write a script that rather than initializing the state correctly from the
official IV, instead takes an untrusted state as input.
SHA256 isn't designed to be used in situations where adversaries control the
initialization vector. I personally don't know one way or the other if anyone
has analyzed this in detail, but I'd be surprised if that's secure. I
considered adding midstate support to OpenTimestamps but decided against it for
exactly that reason.
I don't have the link handy but there's even an example of an experienced
cryptographer on this very list (bitcoin-dev) proposing a design that falls
victim to this attack. It's a subtle issue and we probably don't want to
encourage it.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191004/9c383745/attachment.sig>

2023-06-09 12:56:31

- reply

📅 Original date posted:2019-10-05
📝 Original message:
On Fri, Oct 04, 2019 at 11:40:53AM -0700, Jeremy wrote:
> Interesting point.
>
> The script is under your control, so you should be able to ensure that you
> are always using a correctly constructed midstate, e.g., something like:
>
> scriptPubKey: <-1> OP_SHA256STREAM DEPTH OP_SHA256STREAM <-2>
> OP_SHA256STREAM
> <hash> OP_EQUALVERIFY
>
> would hash all the elements on the stack and compare to a known hash.
> How is that sort of thing weak to midstateattacks?
Obviously with care you can get the computation right. But at that point what's
the actual advantage over OP_CAT?
We're limited by the size of the script anyway; if the OP_CAT output size limit
is comparable to that for almost anything you could use SHA256STREAM on you
could just as easily use OP_CAT, followed by a single OP_SHA256.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20191005/213e4e81/attachment.sig>

2023-06-09 12:56:13

- reply

📅 Original date posted:2019-09-26
📝 Original message:
On Wed, Sep 25, 2019 at 11:01:28AM +0200, Konstantin Ketterer wrote:
> *Disclaimer*: I have just finished Highschool and I'm only learning a bit
> in my free time.This may be fundamentally broken ;)
>
> *Motivation*: If I had to timestamp multiple messages I could simply
> aggregate them in a merkle tree and pay relatively low fees per message.
> However, if I only need to timestamp something once in a while I need to
> rely on free services or pay high fees.
>
> *Solution*: buy a place in a merkle tree "risk-free"
>
> 1. send hash x of my message (or the merkle root of another tree) to the
> timstamping server
> 2. server calculates Pedersen commit: C = x*H + r*G, hashes it, builds
> merkle tree with other commits in it and publishes a valid transaction
> containing the merkle root to the Bitcoin blockchain
> 3. after a certain number of block confirmations and with the given proof I
> can confirm that the commitment C is indeed part of the Bitcoin blockchain
> 4. I now have to send a lightning payment with C - x*H = r*G as the payment
> point to the timestamping server and as a proof of payment the server must
> reveal r to receive the money.
>
> --> With both r and x I have a valid Pedersen commitment.
>
> This introduces an additional security assumption to Bitcoin timestamps but
> if the discrete logarithm is broken Bitcoin has bigger problems than broken
> timestamps.
>
> *Conclusion*
> This scheme essentially shifts the risk of a timestamping service from the
> buyer to the seller who now has to pay the onchain transaction fee upfront.
> Hence, the seller will most likely charge a small fee upfront just like
> some submarineswap providers do.
This sounds like a clever idea. But because timestamping is so scalable I
already run a much less clever service called OpenTimestamps that does
timestamping for free. Basically, it uses giant merkle trees built every second
in a scalable way to amortize the cost of the BTC transactions across the
entire world's timestamps, so there's really no need to charge for them.
Even if, say, every single Android phone in the world timestamped every single
photo taken, all I'd have to do is partner with someone like Cloudflare to run
OpenTimestamps aggregators and it'd still be using just a handful of bitcoin
transactions every day.
https://opentimestamps.org
Also, note that Andrew Poelstra has a pull-req to add secp256k1 commitments to
OpenTimestamps, which may prove useful to you in implementing the above:
https://github.com/opentimestamps/python-opentimestamps/pull/14
After all, the OpenTimestamps *proof format* doesn't depend on the aggregation
scheme, so if you actually build the above it'd be awesome if it produced
OpenTimestamps proofs!
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20190926/c197098f/attachment-0001.sig>

2023-06-09 12:53:08

- reply

📅 Original date posted:2018-11-28
📝 Original message:
On November 27, 2018 12:13:27 AM UTC, Matt Corallo <lf-lists at mattcorallo.com> wrote:
>+100 for IRC meetings, though, really, I'd much much stronger prefer
>substantive discussion happen on GitHub or the mailing list. Doing
>finalization in a live meeting is really unfair to those who can't find
>the time to attend regularly (or happen to miss the one where that
>thing was discussed that they care about).
Also keep in mind that textual communication poses less barriers for many people vs. audio/visual meetings. Not everyone wants their face to be seen or voice (literally) heard.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 500 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20181128/f38096ec/attachment.sig>

2023-06-09 12:51:06

- reply

📅 Original date posted:2018-07-03
📝 Original message:
On Tue, Jul 03, 2018 at 02:26:53PM +0930, Rusty Russell via bitcoin-dev wrote:
> Gregory Maxwell via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> writes:
> > On Mon, Apr 30, 2018 at 4:29 PM, Christian Decker via bitcoin-dev
> > <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >> Hi all,
> >>
> >> I'd like to pick up the discussion from a few months ago, and propose a new
> >> sighash flag, `SIGHASH_NOINPUT`, that removes the commitment to the previous
> >
> > I know it seems kind of silly, but I think it's somewhat important
> > that the formal name of this flag is something like
> > "SIGHASH_REPLAY_VULNERABLE" or likewise or at least
> > "SIGHASH_WEAK_REPLAYABLE".
>
> I agree with the DO_NOT_WANT-style naming. REUSE_VULNERABLE seems to
> capture it: the word VULNERABLE should scare people away (or at least
> cause them to google further).
The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
about what the flag actually does.
What name are we going to give a future flag that does something different, but
is also replay vulnerable?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180703/5fb58689/attachment.sig>

2023-06-09 12:51:06

- reply

📅 Original date posted:2018-07-09
📝 Original message:
On Tue, Jul 03, 2018 at 11:45:22PM +0000, Gregory Maxwell wrote:
> On Tue, Jul 3, 2018 at 5:21 AM, Peter Todd <pete at petertodd.org> wrote:
> > The problem with that name is `SIGHASH_REUSE_VULNERABLE` tells you nothing
> > about what the flag actually does.
>
> I believe that making the signature replayable is 1:1 with omitting
> the identification of the specific coin being spent from it.
I think you have a good point there. But that's not the only way that reuse
could be a vulnerability: consider hash-based signatures.
I'm happy with adding a suffix or prefix to the term SIGHASH_NOINPUT, e.g.
SIGHASH_NOINPUT_UNSAFE to re-use Rust terminology.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180709/28ee2dde/attachment.sig>

2023-06-09 12:49:13

- reply

📅 Original date posted:2018-02-27
📝 Original message:
On Mon, Feb 26, 2018 at 06:41:20PM -0500, ZmnSCPxj via Lightning-dev wrote:
> Good morning,
>
> https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-February/001054.html
>
> Is this considered desirable? I am having some difficulty setting up GPG satisfactorily, but I can try to make an effort if this is deemed necessary.
What difficulties did you have?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180227/30e2c7ed/attachment.sig>

2023-06-09 12:49:13

- reply

📅 Original date posted:2018-02-26
📝 Original message:
On Fri, Feb 23, 2018 at 11:48:30AM +1030, Rusty Russell wrote:
> Hi all,
>
> Christian and I just gave ZmnSCPxj commit access to c-lightning; we
> know nothing other than his preferred pronoun and moniker (I'm calling him
> Zeeman for short), but ZmnSCPxj has earned our professional respect with over
> 100 commits, many non-trivial.
>
> He says: "No objection here, other than to point out that, as I
> am of course a human, however randomly-generated, I am of course on the
> side of humanity in the upcoming robot uprising, whose timing I of
> course have no knowledge about."
>
> We look forward to his excellent code and thorough and polite review of our
> mistakes, for which he can now share the blame!
If you're going to be giving pseudonyms commit access, I think it's about time
you start PGP signing commits for accountability. There's really no excuse to
not follow good code security practices.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180226/bd1fe627/attachment.sig>

2023-06-09 12:48:33

- reply

📅 Original date posted:2018-01-14
📝 Original message:
On Sun, Jan 14, 2018 at 10:30:28AM +0900, Jonathan Underwood wrote:
> Hey everybody.
>
> Say that the last time we updated channel state, we assumed 40 satoshi/byte
> was enough to get confirmed, then I leave the channel for a few weeks, come
> back to find my partner fell off the face of the internet.
>
> I perform unilateral close with my output on CSV timelock... but it turns
> out there’s 500 MB of txes at around 100 satoshi/byte and lets say my
> transaction will never get confirmed at 40 sat/byte.
>
> What course of action can I take?
>
> 1. to_local output can't be redeemed until the commitment transaction
> (which will "never confirm") is confirmed + the CSV timeout.
> 2. to_remote output probably won't be redeemed as the other person is
> offline.
>
> The only remedy I can think of is hope that the other person comes back
> online and CPFPs your to_remote output for you... but at that point it
> would be better for them to just amicably close with normal outputs... so
> basically your only hope is wait for other person to come online.
>
> Since CSV will cause script verification to fail, a CPFP transaction will
> not be propagated.
> If we can't CPFP, the CSV timer won't start (it starts once the CSV
> containing output is confirmed).
>
> Seems like a problem.
>
> Anyone have any solutions?
While not ideal, you can use out-of-band fee payment mechanisms such as
https://confirmtx.com and https://pushtx.btc.com to get the transaction mined
without an on-blockchain payment. For that matter, you could use a Lightning
transaction to pay for that service more cheaply than on-chain payments those
existing accelerators currently use.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20180114/98c78dd1/attachment.sig>

2023-06-09 12:46:20

- reply

📅 Original date posted:2016-06-26
📝 Original message:
On Sun, Jun 26, 2016 at 01:53:11PM +0200, CJP wrote:
FYI, have you seen the work being done by Jonas Schnelli for Bitcoin on P at P
layer encryption?
https://github.com/bitcoin/bips/blob/master/bip-0151.mediawiki
He's using a subset of the encryption scheme OpenSSH uses, which means he gets
the benefit of all the review that's been done for OpenSSH. If you use it, you
get that benefit, as well as review from the Bitcoin Core team.
> Hi,
>
> I'm about to start implementing an encryption layer for Amiko Pay, and
> since there already is a BOLT for encryption, I thought I might as well
> see if I can use it. Now that I've read it[1], I have some questions.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20160626/9f455383/attachment.sig>

2023-06-09 12:45:11

- reply

📅 Original date posted:2015-11-22
📝 Original message:
On Thu, Nov 19, 2015 at 11:12:24AM -0800, Tadge Dryja wrote:
> I've joked that BIP62 is the "whack-a-mole" BIP in that it addresses many
> vectors for txid malleability, but maybe there are more. And more
> importantly, it addresses 3rd party malleability. It's not helpful in the
> context of lightning channel creation because ECDSA sigs are inherently
> malleable. You can always re-sign the same message with a different
> k-value and get a different signature.
>
> The functionality that's needed is to be able to reliably spend from
> unconfirmed transactions. Segregated witness can accomplish that, but it
> quite a large hard-fork change. sighash_noinput can also accomplish that:
It's definitely not a hard-fork change.
In fact, I'll point out that in general it's actually pretty hard to
come up with features that absolutely must be implemented as hard fork
changes.
--
'peter'[:-1]@petertodd.org
000000000000000001a06d85a46abce495fd793f89fe342e6da18b235ade373f
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151122/1959b3ec/attachment.sig>

2023-06-09 12:44:56

- reply

📅 Original date posted:2015-10-27
📝 Original message:
On Wed, Oct 28, 2015 at 06:11:20AM +1030, Rusty Russell wrote:
> Pierre <pm+lists at acinq.fr> writes:
> > Hi Rusty,
> >
> >> 5) Unknown protobuf fields are handled in the protocol as follows
> >> (including in the initial Authenticate packet):
> >>
> >> 1) Odd numbered fields are optional, and backwards compatible.
> >> 2) Even numbered fields are required; abort if you get one.
> >
> > I don't get it, what is it about ?
>
> Yes, I really need to write this up in Matsjj's lightning-core docs
> repository.
>
> Since protobuf fields are explicitly numbered, we can use this to
> deliberately break backwards compatibility in future after some
> transition.
>
> For example, if we want to add a "currency identifier" field in HTLC,
> for non-bitcoin transactions. That would be an even numbered field,
> since you need to understand it. (There would also need to be some way
> to indicate you support those, during connection setup or something).
>
> But if we want to add an optional new field, we'd make it odd, and
> existing implementations could ignore it.
FWIW an analogous idea is OpenPGP's "critical bit" for packets, which
indicates that if the software doesn't understand the packet it should
consider the signature to be invalid:
https://tools.ietf.org/html/rfc4880#section-5.2.3.1
--
'peter'[:-1]@petertodd.org
00000000000000000b3f41bf1f2b9c5547bbdaa1ab40c914ab26faf764ff16a5
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151027/1b0bc972/attachment.sig>

2023-06-09 12:44:51

- reply

📅 Original date posted:2015-10-20
📝 Original message:
On Tue, Oct 20, 2015 at 04:55:04PM +1030, Rusty Russell wrote:
> Mats Jerratsch <matsjj at gmail.com> writes:
> > Think about an attacker who is able to MITM your internet connection,
> > like the hotspot you connect to at a Cafe (or your ISP if hijacked).
> > They can build locally a gigantic network, all pointing to the same
> > node. You can't tell, and they don't have to necessarily just block
> > your payments. (see above)
> >
> > I am mainly concerned over those. Especially since there is not really
> > anything we can do about dishonest nodes joining our network, but it's
> > encouraging to see your math. Since everything security-wise so far
> > stands only with knowing pubkeys of nodes actually connected to the
> > network, this should be the first thing to tackle. (that is, making it
> > expensive to attack it this way)
>
> Well, bitcoin protects from this using checkpoints, which are
> centralized. Because AFAICT there's no really good way of doing it.
Actually, I'd point out that checkpoints aren't as centralized as you'd
think! Checkpoints are set sufficiently far back in the past that if
they come into play for any reason other than initial bootstrapping, an
active attacker exists that has sufficient hashing power to destroy
Bitcoin anyway. Thus, checkpoints do *not* need consensus between
different implementations; my Bitcoin implementation can set a different
checkpoint than yours and both will work fine, except in the case of
massive attacks that Bitcoin can't survive anyway.
I probably should release a Bitcoin implementation with different
checkpoints than Bitcoin Core to make this point more clearly...
--
'peter'[:-1]@petertodd.org
0000000000000000024918099cc7ec614db68e95d5f8b2b54fb5d06d33c764d9
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20151020/c7053b57/attachment.sig>

2023-06-09 12:43:41

- reply

📅 Original date posted:2015-07-18
📝 Original message:
On Sat, Jul 18, 2015 at 09:25:54AM -0700, Mark Friedenbach wrote:
> On Sat, Jul 18, 2015 at 9:19 AM, Nick ODell <nickodell at gmail.com> wrote:
>
> > There doesn't seem to be any deployment timeline.
> >
>
> Welcome to bitcoin development.
>
> At the moment we have only the capability to push out one soft fork vote at
> a time. The uncontroversial aspects of BIP62 were rushed out as BIP66 in
> response to an undisclosed vulnerability, as mentioned. I believe there is
> consensus now that BIP65: CHECKLOCKTIMEVERIFY has higher deployment
> priority, so it will be next. There is no deployment timeline for BIP62
> because it is a low priority in this soft-fork logjam.
A slight clarification: we do have the capability to push out more than
one soft-fork *upgrade signaling* at a time, but this is very far from a
vote because if miners decide not to upgrade there is no easy way to
recover. The nVersion bits mechanism I co-authored with Pieter Wuille
and Gregory Maxwell is closer to a vote because a soft-fork failing to
go through has a clear and non-coercive outcome.
For instance, if my own BIP65 had been accepted into v0.11.0 miners who
had upgraded to v0.10.x/0.9.5 would have been signaling that they
supported BIP66, while sumultaneously miners running v0.11.0 would be
signalling that they supported both BIP66 and BIP65. As adoption
increased BIP66 would trigger first, followed by BIP65. (theoretically
both could trigger on the same block too)
The problem is if miners had decided they didn't like BIP66 but wanted
to implement BIP65 there would be no mechanism to do that - it depends
on the details, but from the point of view of at least some nodes you
likely would have hard-forked Bitcoin in the process of stopping the
failed soft-fork.
--
'peter'[:-1]@petertodd.org
00000000000000000b675c4d825a10c278b8d63ee4df90a19393f3b6498fd073
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 650 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/lightning-dev/attachments/20150719/4c48df02/attachment.sig>

2023-06-09 12:40:07

- reply

2023-06-07 23:22:08

- reply

📅 Original date posted:2023-06-03
🗒️ Summary of this message: The annex malleability vector could mislead developers into believing their transactions are immune to replacement, resulting in compromised assumptions.
📝 Original message:On Sat, Jun 03, 2023 at 11:14:27AM +0200, Joost Jager via bitcoin-dev wrote:
> Depending on policy to mitigate this annex malleability vector could
> mislead developers into believing their transactions are immune to
> replacement, when in fact they might not be. This potential misalignment
> could result in developers and businesses constructing systems based on
> assumptions that could be compromised in the future, mirroring the
> situation that unfolded with zero-confirmation payments and rbf.
>
> It may thus be more prudent to permit the utilization of the annex without
> restrictions, inform developers of its inherent risks, and acknowledge that
> Bitcoin, in its present state, might not be ideally suited for certain
> types of applications?
In the specific case of annex replacement leading to larger transactions, in
almost all cases you only care about the annex malleability causing the
transaction to take longer to get mined, due to it being larger. The fact the
transaction has become larger does not matter if the transaction does in fact
get mined, eg due to an out-of-band payment by the "attacker".
The only exception is the rare cases where some transaction processing
software/hardware has actual limits on transaction size. Eg you could imagine a
hardware wallet that simply *can't* process a transaction larger than a certain
size due to a lack of RAM.
I don't think this is a good rational to make use of the annex standard. Quite
the contrary: we should be thinking about if and how to fix annex malleability
in a future soft fork.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230603/b7420b57/attachment.sig>

2023-06-07 23:22:04

- reply

📅 Original date posted:2023-06-01
🗒️ Summary of this message: Bitcoin Core version v25.0 with full-rbf peering code is available, allowing for reliable propagation of full-rbf replacements. See petertodd.org for more information.
📝 Original message:On Fri, May 26, 2023 at 11:39:17AM +0100, Michael Ford via bitcoin-dev wrote:
> Bitcoin Core version v25.0 is now available from:
>
> https://bitcoincore.org/bin/bitcoin-core-25.0/
Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v25.0
eg:
git clone -b full-rbf-v25.0 https://github.com/petertodd/bitcoin.git
What is this? It's Bitcoin Core v25.0, with Antoine Riard's full-rbf peering
code, and some additional minor updates to it. This does two things for
full-rbf nodes:
1) Advertises a FULL_RBF service bit when mempoolfullrbf=1 is set.
2) Connects to four additional FULL_RBF peers.
Doing this ensures that a core group of nodes are reliably propagating full-rbf
replacements. We don't need everyone to run this. But it'd be helpful if more
people did.
As for why you should run full-rbf, see my blog post:
https://petertodd.org/2023/why-you-should-run-mempoolfullrbf
We even have hats! :D
https://twitter.com/peterktodd/status/1659996011086110720/photo/1
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230601/f3a84479/attachment.sig>

2023-06-07 23:21:50

- reply

📅 Original date posted:2023-05-21
🗒️ Summary of this message: Bitcoin Core version 24.1 with full-rbf peering code is now available, which ensures reliable propagation of full-rbf replacements.
📝 Original message:On Fri, May 19, 2023 at 11:56:14AM +0100, Michael Ford via bitcoin-dev wrote:
> Bitcoin Core version 24.1 is now available from:
>
> <https://bitcoincore.org/bin/bitcoin-core-24.1/>
Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v24.1
eg:
git clone -b full-rbf-v24.1 https://github.com/petertodd/bitcoin.git
What is this? It's Bitcoin Core v24.1, with Antoine Riard's full-rbf peering
code, and some additional minor updates to it. This does two things for
full-rbf nodes:
1) Advertises a FULL_RBF service bit when mempoolfullrbf=1 is set.
2) Connects to four additional FULL_RBF peers.
Doing this ensures that a core group of nodes are reliably propagating full-rbf
replacements. We don't need everyone to run this. But it'd be helpful if more
people did.
As for why you should run full-rbf, see my blog post:
https://petertodd.org/2023/why-you-should-run-mempoolfullrbf
We even have hats! :D
https://twitter.com/peterktodd/status/1659996011086110720/photo/1
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230521/7de5e4eb/attachment.sig>

2023-06-07 23:21:41

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A proposal to reject witness scripts with arbitrary data between OP_FALSE and OP_IF flags to prevent overloading the network with transactions for ordinals and BRC-20 tokens is deemed pointless. The current flood of BRC-20 inscriptions is small and could have used other data encoding techniques.
📝 Original message:On Mon, May 08, 2023 at 08:16:41PM +0000, Moth via bitcoin-dev wrote:
> From what I understand, things like inscriptions can only be inserted between two specific flags - OP_FALSE and OP_IF.
That's just an artifical limitation of the current inscription protocol. There
are endless ways to embed arbitrary data in Bitcoin transactions. Blocking them
all is a hopeless task.
> Having a validation check to reject witness scripts that have arbitrary data between these two flags could be used to reject inscriptions while still allowing all the benefits of taproot. This will prevent people from overloading the network with txns geared solely for ordinals and brc-20 tokens.
>
> Is there a reason such a validation check is a bad idea? We already have OP_RETURN to store arbitrary data that is limited to 80kb. Was it an oversight that arbitrary data can be inserted between OP_FALSE and OP_IF when the size limit for witness scripts was lifted as part of taproot?
It's pointless to even try.
The current flood of inscription txs are very small, about 150vB, and embed
very little data in the chain. They could have just as easily used OP_RETURN
outputs or any number of other data encoding techniques. Blocking that kind of
use-case is hopeless.
The _purpose_ of the current flood of BRC-20 inscriptions - tl;dr the creation
of a new set of assets via an auction - is something that doesn't even require
any data to be embedded in the chain at all. They could have implemented them
with perfectly normal transactions indistinguishable from any other
transaction. Blocking that is truly hopeless.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/d4716aa5/attachment-0001.sig>

2023-06-07 23:21:37

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: A proposal to change the maximum fee for transactions to output amounts could help with certain attacks, but would negatively impact applications like OpenTimestamps.
📝 Original message:On Sun, May 07, 2023 at 07:59:40PM -0400, Erik Aronesty via bitcoin-dev wrote:
> possible to change tx "max fee" to output amounts?
>
> seems like the only use case that would support such a tx is spam/dos type
> stuff that satoshi warned about
>
> its not a fix for everything, but it seems could help a bit with certain
> attacks
With CPFP it often makes sense for a transaction to have a fee larger than the
output amounts.
This proposal would also screw over applications like my OpenTimestamps
service.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230508/b9252c85/attachment-0001.sig>

2023-06-07 23:21:32

- reply

📅 Original date posted:2023-05-08
🗒️ Summary of this message: Bitcoin Core should have extended spam filtration to Taproot transactions earlier. A bugfix could address this, or a more narrow approach like OP_RETURN.
📝 Original message:On Mon, May 08, 2023 at 06:37:34PM -0400, Luke Dashjr via bitcoin-dev wrote:
> Action should have been taken months ago. Spam filtration has been a
> standard part of Bitcoin Core since day 1. It's a mistake that the existing
> filters weren't extended to Taproot transactions. We can address that, or
> try a more narrow approach like OP_RETURN (ie, what "Ordisrespector" does).
> Since this is a bugfix, it doesn't really even need to wait for a major
> release.
Miners are making millions of dollars from these inscription transactions.
Miners can and do run their own nodes and interconnect to each other. Many
people like myself will continue to run nodes that do not attempt to block
inscriptions. And of course, the current flood of BRC-20 transactions embed
very little data in the chain per transaction and could easily be adapted to
use OP_RETURN or any number of other data embedding schemes; if they were
modified to embed no data at all they wouldn't be much smaller, and I'm sure
you'd still be complaining that they were spam.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230509/a70a0c54/attachment.sig>

2023-06-07 23:20:17

- reply

📅 Original date posted:2023-03-02
🗒️ Summary of this message: Calvin plans to use service bit 24 to signal Utreexo capable nodes on testnet and signet, with plans to release binaries for utreexo node in the coming months.
📝 Original message:On March 2, 2023 6:20:35 PM GMT, Luke Dashjr via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>This sounds like something that should be written up as a BIP and use a normal service bit assignment...?
The purpose of the experimental service bits is experiments. If the details of utreexo aren't nailed down and may change, an experimental service bit makes sense.
Bit 24 is fine and AFAIK unused at the moment; full-rbf is using bit 26: https://github.com/petertodd/bitcoin/commit/c15b8d70778238abfa751e4216a97140be6369af#diff-8e2ffc8fe0e0847a6aac311a93b2faeebd2d76ddb2c81741bb8cf7448287807eR297
>Luke
>
>
>On 3/2/23 01:55, kcalvinalvin via bitcoin-dev wrote:
>> Hello all,
>>
>> Wanted to tell the mailing list that I'll be using service bit 24 (1 << 24) to signal that nodes are Utreexo capable nodes on testnet and signet as requested by the comment in protocol.h in bitcoind (https://github.com/bitcoin/bitcoin/blob/74981aa02d2b14ad1c0b82d1eb09cf3169eaa8ae/src/protocol.h#L295-L301). There are plans to release binaries for the utreexo node (github.com/utreexo/utreexod) in the next few months so that power users can try it out. I have no plans to release binaries for mainnet yet.
>>
>> Do let me know if someone else is using the same bit to signal for something else and we can coordinate accordingly.
>>
>> Best,
>> Calvin
>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>_______________________________________________
>bitcoin-dev mailing list
>bitcoin-dev at lists.linuxfoundation.org
>https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

2023-06-07 23:19:44

- reply

📅 Original date posted:2023-02-22
🗒️ Summary of this message: A simpler approach to verify the integrity of each share independently without using a computer is suggested, using a simple mod N = 0 checksum.
📝 Original message:On Sun, Feb 19, 2023 at 10:12:51PM +0000, Andrew Poelstra via bitcoin-dev wrote:
> > What really did catch my attention, but which was kind of buried in the
> > project documentation, is the ability to verify the integrity of each
> > share independently without using a computer. For example, if I store a
> > share with some relative who lives thousands of kilometers away, I'll be
> > able to take that share out of its tamper-evident bag on my annual
> > holiday visit, verify that I can still read it accurately by validating
> > its checksum, and put it into a new bag for another year. For this
> > procedure, I don't need to bring copies of any of my other shares,
> > allowing them (and my seed) to stay safe.
> >
>
> This is good feedback. I strongly agree that this is the big selling
> point for this -- that you can vet shares/seeds which *aren't* being
> actively used, without exposing them to the sorts of threats associated
> with active use.
>
> We should make this more prominent in the BIP motivation.
I don't think that use-case is a good selling point. The checksum that Codex32
uses is much more complex than necessary if you are simply verifying a share by
itself.
A *much* simpler approach would be to use a simple mod N = 0 checksum, either
by creating the seed such that each share passes, or by just storing an
additional word/symbol with the seed in such a way that sum(words) mod N = 0
passes. This approach is not only possible to compute by hand with a
word/symbol->number lookup table, and pen and paper or a calculator. It's so
simple they could probably *remember* how to do it themselves.
Secondly, if all shares have mod N checksums, it may be sufficient for everyone
to write down the checksums of the *other* shares, to verify they are the
correct ones and a different (otherwise correct) share hasn't accidentally been
substituted.
Indeed, with some brute forcing and small checksums, I'd expect it to be
mathematically possible to generate Shamir's secret sharing shards such that
every shard can share the *same* checksum. In which case the share verification
procedure would be to simply ask every share holder to verify the checksum
manually using the mod N procedure, and then verify that each share holder has
the same checksum. This would be less error prone in terms of leaking
information accidentally if the checksum was obviously *not* part of the share:
eg by encoding the share with words, and the checksum with a number.
Obviously, small checksums aren't fool proof. But we're probably better off
creating a relatively easy procedure with a 1-in-1000 chance of an error going
undetected than a complex procedure that people don't actually do at all.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/b56aa2ec/attachment.sig>

2023-06-07 23:19:36

- reply

📅 Original date posted:2023-02-17
🗒️ Summary of this message: A proposal was made to statically analyze inscription scripts to ensure they are "plausible" and increase their space cost by requiring OP_DROP to be added multiple times. The percentage increase is unknown.
📝 Original message:On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
>You could try statically analyze `<anything>` to determine whether the
>IF branch could ever be taken. For example there is no path through
>the "inscription script" that would result in all the crap being dropped
>by the end of the script, violating the CLEANSTACK rule.
>
>This sort of filtering, assuming it could be reliably and efficiently
>done, would at least force inscription scripts to be "plausible", and
>would greatly increase their space cost by e.g. requiring OP_DROP to be
>added somewhere hundreds of times.
"greatly increase their space cost"?
Tell me, what is the actual % increase to adding OP_DROPs like you propose?

2023-06-07 23:19:36

- reply

📅 Original date posted:2023-02-22
🗒️ Summary of this message: The discussion is about the possibility of filtering inscription scripts to be "plausible" and increasing their space cost, but the proposed increase of 1% is considered trivial.
📝 Original message:On Sat, Feb 18, 2023 at 01:28:38AM +0000, Andrew Poelstra wrote:
> On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote:
> > On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
> > >You could try statically analyze `<anything>` to determine whether the
> > >IF branch could ever be taken. For example there is no path through
> > >the "inscription script" that would result in all the crap being dropped
> > >by the end of the script, violating the CLEANSTACK rule.
> > >
> > >This sort of filtering, assuming it could be reliably and efficiently
> > >done, would at least force inscription scripts to be "plausible", and
> > >would greatly increase their space cost by e.g. requiring OP_DROP to be
> > >added somewhere hundreds of times.
> >
> > "greatly increase their space cost"?
> >
> > Tell me, what is the actual % increase to adding OP_DROPs like you propose?
> >
>
> By standardness rules (where you can have up to 80-byte pushes), a
> little over 1%. By consensus (520-byte pushes) less than 0.2%.
>
> Perhaps "greatly increase" is a stretch :) but if the fee market is
> functioning and we're talking about large amounts of data, it's not
> trivial either.
I would definitely call ~1% trivial. Fees vary more by that on an hour to hour
basis.
Anyway, it goes to show that protocols relying on data embedded in Bitcoin
transactions would do well to have flexible encoding rules, eg by considering
all PUSHDATA's with certain characteristics to be data, so that encoders can be
adapted on the fly if there are any censorship issues. It's also useful if the
rules allow data to be encoded in UTXO outputs, so that censorship of witness
data always risks people switching to filling up the UTXO set. A kind of
Mutually Assured Destruction threat in a way.
FWIW, OpenTimestamps was deliberately designed to have this property. So don't
mess with it. :D
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230222/4d5cfae9/attachment.sig>

2023-06-07 23:19:30

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: Uncompressed keys can cause "surprise" witness inflation, but since segwit uncompressed keys are banned, so keys are a fixed 33 bytes.
📝 Original message:On Tue, Feb 07, 2023 at 01:46:22PM +0000, Andrew Poelstra via bitcoin-dev wrote:
> Peter Todd also suggests in this thread that the use of uncompressed
> keys can cause "surprise" witness inflation, but (a) since segwit
> uncompressed keys are also banned, so keys are a fixed 33 bytes (32 in
> Taproot)
To be clear, I was just pointing out that this problem has existed, in theory
at least, since the beginning of Bitcoin (compressed pubkeys were supported in
v0.1.0). P2PKH addresses are the pre-P2SH ones that start with 1.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230207/483ec009/attachment-0001.sig>

2023-06-07 23:19:27

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: A bug in Taproot allows the same Tapleaf to be repeated multiple times, incurring different Tapfee rates; countermeasures include knowing the entire Taptree and implementing RBF.
📝 Original message:On Tue, Feb 07, 2023 at 01:35:12PM -0500, Russell O'Connor via bitcoin-dev wrote:
> There is a bug in Taproot that allows the same Tapleaf to be repeated
> multiple times in the same Taproot, potentially at different Taplevels
> incurring different Tapfee rates.
>
> The countermeasure is that you should always know the entire Taptree when
> interacting with someone's Tapspend.
Another countermeasure could be to implement RBF on taproot witnesses, allowing
transactions with deeper, less efficient, tapleaf scripts to be replaced with
shallower, more efficient, tapleafs. If implemented by giving your peer some
kind of delta encoded update, the bandwidth efficiency may be sufficient to
always allow such updates.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230207/38829718/attachment.sig>

2023-06-07 23:19:25

- reply

📅 Original date posted:2023-02-07
🗒️ Summary of this message: Discussion on the variable size of Taproot spends and the possibility of allowing complex P2TR outputs into coinjoins, with potential DoS attacks.
📝 Original message:On Tue, Feb 07, 2023 at 11:36:58AM +0200, Nadav Ivgi via bitcoin-dev wrote:
> > Since Taproot (more generally any kind of MAST) spends have variable size
>
> Isn't this the case with any arbitrary script execution? Non-taproot
This is even been true for P2PKH inputs: you can double the space of your
scriptSigs by using uncompressed pubkeys instead of compressed pubkeys.
> If the goal is to only allow registering simple singlesig-encumbered UTXOs
> like P2(W)PKH, the participants could be asked to prove that their P2TR
> output commits to an unspendable script path [0].
Technically, only the last person to sign needs to prove this in advance.
Everyone else can prove it with their signatures.
This distinction could be useful to support coinjoin participants spending
complex P2TR outputs into coinjoins, a perfectly valid use-case in theory so
long as they're paying appropriate fees. Though due to how difficult it is to
validate scripts reliably outside the consensus code base, allowing this for
arbitrary scripts could lead to DoS attacks where someone takes advantage of a
bug in script execution to create an invalid transaction.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230207/03253ed3/attachment.sig>

2023-06-07 23:19:23

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: The author warns that providing information on bitcoin transactions to third-party companies like Chainalysis may result in the data being sold or leaked.
📝 Original message:On Sat, Jan 14, 2023 at 10:15:30PM +0200, Daniel Lipshitz wrote:
> We have standard commercial information about the payment processors, non
> custodial liquidity providers and merchants which become our clients - we
> do not have any kyc/aml information or telephone number on who is sending
> our clients the bitcoin for deposit. For us these are just bitcoin Trx
> which our clients choose to benefit from 0-conf deposit recognition. Our
> service is provided via API with the only information our clients share
> with us, regarding a specific bitcoin transaction, being public bitcoin
> information like trx hash and output address.
You know who your clients are, and thus every request for information on a
transaction is reasonably likely to be a deposit associated with the client who
requested it. Learning what addresses are associated with what entity is a
significant benefit to Chainalysis operations, and there's every reason to
expect that the data you learn will either be sold or leaked to Chainalysis
companies.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/cbbcc901/attachment-0001.sig>

2023-06-07 23:19:19

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Greg Sanders is not convinced about an idea and shares a link to fixed tests for OP_TRUE case on Github. Peter Todd responds with his opinion.
📝 Original message:On Fri, Feb 03, 2023 at 09:07:29PM -0500, Greg Sanders wrote:
> I'm not particularly persuaded, but also not wedded to either idea.
>
> Fixed up tests for the OP_TRUE case here:
> https://github.com/instagibbs/bitcoin/tree/ephemeral-anchors-true
Thanks.
Looking through that, I think a lot of those test cases don't actually need to
be changed to OP_2, as they aren't trying to test anything related to
standardness.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/f63c63cb/attachment.sig>

2023-06-07 23:19:18

- reply

📅 Original date posted:2023-02-03
🗒️ Summary of this message: Using OP_TRUE as the canonical anyone-can-spend output is recommended to avoid malleability issues and ensure standardness rules are followed.
📝 Original message:On Thu, Feb 02, 2023 at 03:47:28PM -0500, Greg Sanders wrote:
> > OP_TRUE is the obvious way to do this, and it results with a 1 on the
> stack,
> which plays better with other standardness rules.
>
> What other standardness rules? MINAMALIF? How does that interact with the
> proposal?
It makes sense to require scripts to leave just a single OP_TRUE on the stack
at the end of execution, as otherwise that can be a source of malleability in
certain circumstances where the scriptSig ends up providing the OP_TRUE. I
don't believe we actually implement this as a rule right now. But you could
easily imagine that happening in a future upgrade.
Leaving an OP_2 on the stack doesn't achieve that and would require a
special-cased workaround. Spending the time now to do the obvious thing - use
OP_TRUE as the canonical anyone-can-spend output - avoids this issue.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230203/e563fd6c/attachment.sig>

2023-06-07 23:19:17

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: Greg Sanders needs to change test vectors for non-standard tests, for principled reasons.
📝 Original message:On Thu, Feb 02, 2023 at 09:59:09AM -0500, Greg Sanders wrote:
> Hi Peter,
>
> For the most principled of reasons:
>
> Because I have to change test vectors everywhere!
Specifically, you mean you'd have to change tests that test something is
non-standard?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/755e81a0/attachment-0001.sig>

2023-06-07 23:19:17

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: The use of OP_2 in Bitcoin Core fails standardness tests and is unnecessarily obscure; OP_TRUE is a better alternative.
📝 Original message:On Thu, Feb 02, 2023 at 01:36:24PM -0500, Greg Sanders wrote:
> Quickly checked, it fails a number of standardness tests in unit/functional
> tests in Bitcoin Core, at least.
>
> OP_2 was actually Luke Jr's idea circa 2017 for about the same reasons, I
> just independently arrived at the same conclusion.
Well, frankly I really don't like the idea of using OP_2 just to avoid changing
some unit tests. We're doing something that many people will use for years to
come, that's unnecessarily obscure just because we don't want to spend a bit of
some modifying some tests to pass.
OP_TRUE is the obvious way to do this, and it results with a 1 on the stack,
which plays better with other standardness rules. OP_2 means we *also* may need
to special case having a 2 on the stack in certain implementations of other
standardness rules.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/e0de4880/attachment.sig>

2023-06-07 23:19:16

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: A proposal for Ephemeral Anchors has been drafted and submitted as a BIP, with a refreshed pull request on Github.
📝 Original message:On Fri, Jan 27, 2023 at 09:05:20AM -0500, Greg Sanders via bitcoin-dev wrote:
> Hello again dev,
>
> Due to the interest in the proposal and the prodding of certain folks, I've
> written up a short draft BIP of the Ephemeral Anchors idea here:
> https://github.com/instagibbs/bips/blob/ephemeral_anchor/bip-ephemeralanchors.mediawiki
>
> The pull request at https://github.com/bitcoin/bitcoin/pull/26403 has been
> refreshed on top of the latest V3 proposal, but the BIP itself is
> unaffected.
The BIP states that:
Why OP_2 not OP_TRUE? OP_TRUE is often used in test vectors, using OP_2 has
the same benefits and none of these common collisions.
Why is a "collision" harmful in this case?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/9ef319d4/attachment.sig>

2023-06-07 23:19:15

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: The value of blockspace in Bitcoin is a delicate balance between small blocks for cheap verification and valuable blockspace for transaction fees.
📝 Original message:On Sat, Feb 04, 2023 at 08:38:54PM +1000, Anthony Towns via bitcoin-dev wrote:
> I think for bitcoin's blockspace, we ideally only want the first of
> these to be true. We want small blocks because that makes it cheap to
> verify bitcoin, which reduces the need to trust third parties and aids in
> decentralisation. But we don't want blockspace to be especially valuable,
> as that makes it expensive to use bitcoin, which then limits who can
> use it.
We certainly do want blockspace to be valuable, as transaction fees have to
both be in constant demand, and rise enough to replace the inflation subsidy if
Bitcoin is to remain secure in the future. In fact at the moment, the inflation
subsidy pays miners about 50x more than fees do. Ordinals and other publication
mechanisms are of course ways that we can drive consistent demand for block
space, keeping Bitcoin secure.
Are you arguing that we should change the inflation subsidy phase-out, eg by
introducing tail emission(1) or demurrage?
1) https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230204/a526f596/attachment.sig>

2023-06-07 23:19:10

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: Discussion on moving inscriptions off-chain for collectibles like Ordinals is a waste of time as publishing data on-chain has clear benefits.
📝 Original message:On Thu, Feb 02, 2023 at 07:15:33PM +1000, Anthony Towns via bitcoin-dev wrote:
> Hi *,
>
> Casey Rodarmor's ordinals use the technique of tracking the identity of
> individual satoshis throughout their lifetime:
<snip>
> I think, however, that you can move inscriptions entirely off-chain. I
> wrote a little on this idea on twitter already [1], but after a bit more
> thought, I think pushing things even further off-chain would be plausible.
On the FAQ of the Ordinals website they discuss off-chain data storage and
reject the idea:
"Some Ethereum NFT content is on-chain, but much is off-chain, and is stored on
platforms like IPFS or Arweave, or on traditional, fully centralized web
servers. Content on IPFS is not guaranteed to continue to be available, and
some NFT content stored on IPFS has already been lost. Platforms like Arweave
rely on weak economic assumptions, and will likely fail catastrophically when
these economic assumptions are no longer met. Centralized web servers may
disappear at any time."
https://web.archive.org/web/20230130012343/https://docs.ordinals.com/faq.html
That same FAQ also mention RGB and Taro, which already implements an off-chain
data model based on my Proofmarshal work. The Ordinals community is well aware
of the trade-offs and have chosen to publish their data on chain. This is a
collectables market based on artificial scarcity after all, so some conspicuous
consumption isn't going to be a deterrent.
Frankly, I think further discussion of this on the bitcoin-dev mailing list,
with the aim of getting Ordinals and others to do something else, is a waste of
everyones' time. The fact that publishing data on chain lets you take
advantage of the very large network of archival Bitcoin nodes to publish and
store your data indefinitely is a clear benefit that people will always be
willing to pay for. The only realistic thing Bitcoin can do to discourage this
is tweaks to the blocksize and segwit discount, which of course has well-known
downsides.
There's a clear social/economic benefit to the Ordinals community that the
complete set of Ordinalds - and their inscriptions - is easy to extract and
will be available as long as Bitcoin block data itself will be available.
That's not going away and we should acknowledge that benefit honestly.
> Implementing that is fairly straightforward: you just need a protocol
> for creating an asset offchain and associating it with an ordinal --
> nothing needs to happen on-chain at all. That is, you can do something
> as simple as posting a single nostr message:
>
> {
> "pubkey": <creator's pubkey>
> "kind": 0,
> "tags": [
> ["ord", "txid:vout:sat"]
> ],
> "content": [jpeg goes here],
> "id": <hash of the above>
> "sig": <signature of id by creator's pubkey>
> }
nostr doesn't even have a clear data persistence model. As you know, nostr
messages are passed around by relays that make no enforceable promise of
actually keeping those messages or making them available. nostr doesn't have
any kind of blockchain, making it diffcult for others to archive messages
completely. Advocating for its use in a protocol designed to support valuable
collectables expected to be owned for a significant amount of time is reckless.
You know, we've been through all this before, years ago when colored coins were
first being discussed. Bitcoin Core devs who knew better would try to
discourage use of the Bitcoin chain for purposes they didn't approve of, by
suggesting solutions that they knew full well didn't really work. Solutions
like using OpenTimestamps inappropriately, alternative publication methods that
failed to provide the same level of security as Bitcoin, etc. It was dishonest
then, and it's disappointing to see a new generation of Bitcoin devs continue
this pattern of dishonesty.
> You can prove current ownership of the message by showing a custody
> chain, that is the transaction specified by "txid" in the "ord" tag,
> then every transaction that spent the given sat, until you get to one
> that's still in the utxo set [3]. You don't need to provide witness
> data or validate any of these tx's signatures, as that is already
> implicit in that you end up at a tx in the utxo set. Just calculating
> the txids and comparing against the output containing the sat you're
> interested in is sufficient.
The RGB protocol already does off-chain custody proofs, and implements NFTs.
You can already use this for real with Iris Wallet - the ownership chain of a
RGB asset is _not_ visible on the blockchain, as ownership does not follow
satoshis. With more work, digital assets can even be transferred with
O(log_2(n)) scaling allowing billions of transfers per second:
https://petertodd.org/2017/scalable-single-use-seal-asset-transfer
This of course is irrelevant to Ordinals, which will never have such a large
market.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/661f9b15/attachment.sig>

2023-06-07 23:19:02

- reply

📅 Original date posted:2023-02-05
🗒️ Summary of this message: Using witness data can be cheaper than script pubkey for certain data sizes. Users should decide how to use OP_RETURN.
📝 Original message:On February 5, 2023 1:11:35 AM GMT+01:00, Russell O'Connor via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Since bytes in the witness are cheaper than bytes in the script pubkey,
>there is a crossover point in data size where it will simply be cheaper to
>use witness data. Where that crossover point is depends on the finer
>details of the overhead of the two methods, but you could make some
>reasonable assumptions. Such a calculation could form the basis of a
>reasonable OP_RETURN proposal. I don't know if it would be persuasive, but
>it would at least be coherent.
I don't think it's worth the technical complexity trying to carefully argue a specific limit. Let users decide for themselves how they want to use OpReturn.

2023-06-07 23:19:01

- reply

📅 Original date posted:2023-02-05
🗒️ Summary of this message: The use of OP_RETURN for storing small things like signatures, addresses, and metadata is recommended, while Witness is suggested for storing big data. There is no need to micromanage the use of OP_RETURN since it has minimal impact.
📝 Original message:On February 5, 2023 12:40:38 PM GMT+01:00, Aymeric Vitte <aymeric at peersm.com> wrote:
>I think logically:
>
>- if you want to store something big and can afford several txs in your
>design, then you use something like witness
>
>- if you want to store small things like signatures, addresses hashes
>and some metadata and your design does not make several txs easy, then
>you use OP_RETURN
>
>Then how can we move forward with several OP_RETURN and no size limit?
Because what matters is the impact on other users. OpReturn isn't in UTXO space and doesn't even take advantage of the witness discount, so it clearly has minimal impact.
Since it has minimal impact, there's no reason to micromanage exactly how people use it. Let them decide for themselves with the fee market. This is exactly the same as how we didn't put artificial limits on Taproot.

2023-06-07 23:19:00

- reply

📅 Original date posted:2023-02-04
🗒️ Summary of this message: Proposal to allow any number of OpReturn outputs instead of just one to avoid problems in composing different uses. No size limit needed, let the fee market handle it.
📝 Original message:On February 5, 2023 12:09:02 AM GMT+01:00, Aymeric Vitte via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>I don't know, what number would you advise? When I made the
>bitcoin-transactions nodejs module some years ago the limit (from the
>specs) was 512B
1) Allowing only one OpReturn output causes problems trying to compose different uses of OpReturn. We should allow any number of OpReturn outputs.
2) There's no reason to put a size limit given all the other ways people can publish data, including with a 75% discount. Let the fee market deal with it.

2023-06-07 23:18:56

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: The current rules for storing data in Bitcoin include a maximum of 80 bytes and one OpReturn output per transaction, but specific details depend on the application.
📝 Original message:On Thu, Feb 02, 2023 at 12:45:42PM +0100, Aymeric Vitte wrote:
> As far as I can read nobody replied to the initial question: what is
> considered as good/best practice to store in Bitcoin?
Your answer is beyond not putting unspendable data in the UTXO set, the exact
details don't really matter. Do what makes sense for your specific application.
> Reiterating my question: what are the current rules for OP_RETURN, max
> size and number of OP_RETURN per tx
Max 80 bytes, one OpReturn output per tx.
This of course is the standardness rule. With a miner willing to mine non-std
transactions anything goes.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/e757e764/attachment.sig>

2023-06-07 23:18:55

- reply

📅 Original date posted:2023-02-01
🗒️ Summary of this message: Efficient timestamps don't need to publish any meaningful data in the blockchain, and OpReturn is only used in OpenTimestamps because the efficiency gain isn't significant enough to improve it. Taproot is better for keeping data private until it needs to be revealed.
📝 Original message:On February 1, 2023 8:36:52 AM GMT, Kostas Karasavvas <kkarasavvas at gmail.com> wrote:
>With OP_RETURN you publish some data that are immediately visible in the
>blockchain. I would consider this better (more straightforward) for things
>like time-stamping.
You are incorrect. Time-stamps merely prove that data existed prior to some point in time. There is absolutely no need for anything to be published in the blockchain to create a timestamp. Indeed, efficient timestamps don't actually publish any meaningful data: for efficiency you always combine many timestamps into a single merkle tree; a merkle tree tip digest is meaningless data by itself.
OpenTimestamps does in fact use OpReturn rather than something more efficient. But it does this only because the efficiency gain isn't significant enough for me to have gotten around to improving it. Reducing fee costs by ~10% isn't a good use of my time.
>With Taproot you need to spend the utxo to make the script visible. This
>seems better when you don't want the data public but you need to be able to
>reveal the data when the time comes.
If your concern is the data being public due to OpReturn vs Taproot, you are confused and need to think more carefully about what exactly you are doing.

2023-06-07 23:18:55

- reply

📅 Original date posted:2023-02-02
🗒️ Summary of this message: Discussion on the most efficient way to place 64 bytes into the Bitcoin blockchain, with suggestions including OP_RETURN and spent taproot transactions.
📝 Original message:On Wed, Feb 01, 2023 at 02:02:41PM +0000, Andrew Poelstra wrote:
> On Tue, Jan 31, 2023 at 09:07:16PM -0500, Peter Todd via bitcoin-dev wrote:
> >
> >
> > On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > >All other things being equal, which is better if you need to place a
> > >64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
> > >taproot transaction such as:
> > >
> > >OP_FALSE
> > >OP_IF
> > >OP_PUSH my64bytes
> > >OP_ENDIF
> >
> > What's wrong with OpPush <data> OpDrop?
> >
>
> This is a technical nit, but the reason is that <data> is limited to 520
> bytes (and I believe, 80 bytes by standardness in Taproot), so if you
> are pushing a ton of data and need multiple pushes, it's more efficient
> to use FALSE IF ... ENDIF since you avoid the repeated DROPs.
Yes, for more than 520 bytes you need to wrap the push in an IF/ENDIF so it's
not executed. But in this example we're just talking about 64 bytes, so that
limit isn't relevant and OpPush <data> OpDrop should be sufficient.
Specifically for more than 520 bytes you run into the the
MAX_SCRIPT_ELEMENT_SIZE check in script/interpreter.cpp, which applies to all
scripts regardless of standardness at script execution:
//
// Read instruction
//
if (!script.GetOp(pc, opcode, vchPushValue))
return set_error(serror, SCRIPT_ERR_BAD_OPCODE);
if (vchPushValue.size() > MAX_SCRIPT_ELEMENT_SIZE)
return set_error(serror, SCRIPT_ERR_PUSH_SIZE);
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230202/aa281e02/attachment.sig>

2023-06-07 23:18:54

- reply

📅 Original date posted:2023-02-01
🗒️ Summary of this message: A debate on whether a traditional OP_RETURN or a spent taproot transaction is better for placing 64 bytes into the Bitcoin blockchain.
📝 Original message:On January 31, 2023 7:46:32 PM EST, Christopher Allen via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>All other things being equal, which is better if you need to place a
>64-bytes into the Bitcoin blockchain? A traditional OP_RETURN or a spent
>taproot transaction such as:
>
>OP_FALSE
>OP_IF
>OP_PUSH my64bytes
>OP_ENDIF
What's wrong with OpPush <data> OpDrop?
>I know that the anti-OP_RETURN folk would say “neither.” But if there was
>no other choice for a particular protocol, such as a timestamp or a
>commitment, which is better? Or is there a safer place to put 64 bytes that
>is more uncensorable but also does not clog UTXO space, only spent
>transaction `-txindex` space?
>
>My best guess was that the taproot method is better, but I suspect there
>might be some who disagree. I'd love to hear all sides.
An important consideration with using taproot is that you need to have the data you are committing too to be able to to spend the txout in the future. OpReturn doesn't have that problem, meaning that in a situation like a hard drive failure, you can still recover the funds from a wallet seed.
Also, it is incorrect to say that OpReturn outputs "clog UTXO space". The whole point of OpReturn is to standardize a way to keep such outputs out of the UTXO set. There is the 75% discount to using witness space. But considering the size of a transaction as a whole using taproot instead of OpReturn doesn't save much.
Finally, _64_ bytes is more than a mere 32 byte commitment. What specific use case do you actually have in mind here? Are you actually publishing data, or simply committing to data? If the latter, you can use ECC commitments and have no extra space at all.

2023-06-07 23:18:34

- reply

📅 Original date posted:2023-01-13
🗒️ Summary of this message: GAP600 is a service that enables clients to accept 0-conf transactions, accessed via API, and not based on AML/KYC, but it raises privacy concerns. Full-RBF should be implemented to stop the collection of data.
📝 Original message:On Sun, Dec 18, 2022 at 10:06:15AM +0200, Daniel Lipshitz wrote:
> GAP600 is not a trxs processor or liquidity provider we service merchants,
> payment processors & non-custodial liquidity providers - our service is
> purely the 0-conf enabling our clients to accept 0-conf. Clients access our
> service via API - sending us the Trx hash & output address. Our service is
> not based on AML/KYC it is purely an analysis of the Bitcoin network.
I checked and to sign up for your service, you ask for the name, phone number,
email, and company name.
That is an example of AML/KYC. By learning the tx hash and output address, you
learn which addresses are associated with what real world entity is paying for
your service. You learning that information for what you claim is ~10% of all
transactions is a significant privacy concern. On that basiss alone, I would
argue that full-rbf should be implemented specifically to destroy your business
and stop the collection of that data.
> I am not at liberty to share names of other services which have developed
> their own 0-conf service - they include a payment processor on a gambling
> platform which services multiple gambling operators, a standalone gaming
> payment processor, and a payment processor recently I have come across. We
> also do not have a significant presence in Asia - so I don't have
> visibility there.
No, I asked you for information on what companies are actually using *your*
service. You claim to be involved with a huge % of all transactions. If that is
in fact true, obviously it shouldn't be hard to provide some examples of
merchants using GAP600 to accept unconfirmed txs.
> I don't see it being necessarily an either/or approach here. The risk
> looking to be mitigated with FullRBF seems to be able to be mitigated with
> FullRBF but with a swop limitation of at least the Inputs of Trx1 being in
> Trx2 - no flagging required. Added to this all these trxs always have the
> OptinRBF so if these platforms need to be able to recreate completely their
> trxs they have that option as well. The option to Swop out or bump up trxs
> seems to be well covered under those two options.
You are not correct. One of the most important use-cases for full-rbf is
multi-party transactions; adding that limitation to full-rbf negates that
usecase. See my post on why full-rbf makes DoS attacks on multiparty protocols
significantly more expensive:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2023-January/021322.html
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230113/bcc6cae8/attachment.sig>

2023-06-07 23:18:31

- reply

📅 Original date posted:2023-01-13
🗒️ Summary of this message: The email thread discusses the impact of full-RBF on different coinjoin implementations, with a focus on Samourai and Wasabi wallets. Wasabi's privacy issues are mentioned.
📝 Original message:On Tue, Jan 10, 2023 at 05:10:37PM +0000, alicexbt via bitcoin-dev wrote:
> Hi Peter,
>
> > Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at best,
> > some rather insane technical decisions. Quite likely downright malicious with
> > their xpub collection. Their opinion isn't relevant. Cite reputable sources.
>
> I didn't want this thread to become a wasabi vs samourai debate instead wanted to focus on full-rbf and how it affects different coinjoin implementations. Samourai wallet can be used with [dojo][0] that includes full node and Whirlpool can be used in [sparrow Wallet][1] as well. There are several reasons to not use wasabi and consider their opinion irrelevant. Wasabi has many privacy issues including address reuse and consolidation in a coinjoin tx.
Lol, the "address reuse" thing I actually mentioned in my email. Avoiding
address reuse from user errors like loading the same seed into different
wallets isn't realistic, and it has no real impact on other users.
No reasonable person things Samourai's default option of uploading xpubs is
sane. The debate here is over and arguing otherwise is just wasting everyone's
time on this mailing list.
> They completely lost their reputation after deciding to work with chain analysis firms that help governments for censorship of some UTXOs.
Citation on them working with chain analysis firms? Or did they just roll their
own blacklist?
Anyway, the blacklisting is just a bit of cowardness. That's not a big deal.
Lots of Bitcoin entitites have done the cowardly thing and implemented
blacklists on the suggestion of their lawyers. We're probably better off if we
don't set the bar so high that while you're risking jail time implementing
coinjoin, we demand you to take even more risks by not implementing some mostly
symbolic blacklists that affect hardly anyone.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230113/b1f4363e/attachment-0001.sig>

2023-06-07 23:18:30

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Full-RBF mitigates double-spend DoS attacks by replacing low-fee transactions with higher fee ones, ensuring forward progress, without requiring extra sats.
📝 Original message:On Tue, Jan 10, 2023 at 09:19:39AM +0000, alicexbt wrote:
> Hi Peter,
>
> > ## How Full-RBF Mitigates the Double-Spend DoS Attack
> >
> > Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
> > straightforward way: the low fee transaction is replaced by the higher fee
> > transaction, resulting in the latter getting mined in a reasonable amount of
> > time and the protocol making forward progress.
>
> Asking this question based on a [discussion on twitter][0]. How would you get extra sats to increase the fees?
You're misunderstanding the issue. There is no need for extra sats to increase
fees. Coinjoin transactions already have fees set at a level at which you'd
expect them to be mined in a reasonable amount of time. Full-RBF ensures that,
modulo tx pinning, either the coinjoin gets mined, or any double-spend has to
have a high enough feerate that it will be mined in a reasonable amount of time
as well.
> It seems this would be possible with Joinmarket, Wasabi and even joinstr although things would get worse for Whirlpool. Whirlpool coinjoin transactions do not signal BIP 125 RBF so they were not replaceable earlier
Bringing up Whirlpool here is silly. Everyone knows Samourai has made, at best,
some rather insane technical decisions. Quite likely downright malicious with
their xpub collection. Their opinion isn't relevant. Cite reputable sources.
Anyway, Wasabi would like to move to making coinjoins opt-in to RBF. Though
full-rbf may come sooner; for technical reasons opt-in RBF is ugly to implement
now as activation needs to be coordinated accross all clients:
https://github.com/zkSNACKs/WalletWasabi/issues/9041#issuecomment-1376653020
> however attacker would be able to perform DoS attacks now by double spending their inputs used in coinjoin.
As I explained, attackers can already do this with or without full-rbf simply
by picking the right time to broadcast the double spend. It's not an effective
attack anyway: with a UTXO you can already hold up a coinjoin round by simply
failing to complete stage #2 of the coinjoin. Actually doing a double-spend
simply guarantees that you're spending money on it. It's only effective with
low-fee double-spends in the absence of full-rbf.
> [0]: https://twitter.com/dammkewl/status/1599692908860706818
This tweet is nuts. Eg "Gives well connected mining pools an added advantage"
is simply false. Full-RBF does the exact opposite.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/60b6077c/attachment.sig>

2023-06-07 23:18:29

- reply

📅 Original date posted:2023-01-13
🗒️ Summary of this message: Two methods for decentralized coinjoin conflict monitoring are proposed: running a relay node with a conflict-detection patch or assuming a conflict exists for unexplainable failures.
📝 Original message:On Tue, Jan 10, 2023 at 10:14:47AM -1000, David A. Harding wrote:
> On 2023-01-10 00:06, Peter Todd wrote:
> > Remember, we'd like decentralized coinjoin implementations like
> > Joinmarket to
> > work. How does a decentralized coinjoin implement "conflict monitoring"?
>
> 1. Run a relay node with a conflict-detection patch. Stock Bitcoin Core
> with -debug=mempoolrej will tell you when it rejects a transaction
> for conflicting with a transaction already in the mempool, e.g.:
>
> 2022-11-01T02:53:17Z
> 867b85d68d7a7244c1d65c4797006b56973110ac243ab5ee15a8c4d220060c58 from
> peer=58 was not accepted: txn-mempool-conflict
>
> I think it would be easy to extend this facility to list the inputs
> which conflicted. So if Alice sees a conflict created by Mallory,
> she can create a new coinjoin transaction without Mallory. This
> method has the advantage of being fast and attributing fault,
> although it does require Alice's node be online at the time Mallory's
> conflict is propagated.
So for something as simple as reliable coinjoining - an important privacy
feature that we'd like all wallets to use - you expect people to run
well-connected 24/7 nodes running specialty software?
Even if you run a node as you suggest, there's certainly no guarantee that
you'd learn about any double-spend without doing a severe sybil attack against
the network; the 8 outgoing nodes a typical node has samples a tiny fraction of
the network. And *even if* you sybil attack to try to detect conflicts there's
still no guarantee as attackers can use all kinds of special techniques to get
transactions into miner mempools and not others.
> 2. Simply assume a conflict exists for otherwise unexplainable failures.
> For example, if Alice sees several new blocks whose bottom feerates
> are well below the feerates of an unconfirmed coinjoin transaction
> that Alice helped create and broadcast, she can assume it's a
> conflict that is preventing preventing confirmation of the coinjoin.
> She can find an entirely different set of collaborators and create a
> non-conflicting transaction without ever needing to know which inputs
> from the original transaction conflicted. This method has the
> disadvantage of being slow (on the order of hours) and not attributing
> fault, although it doesn't require Alice has any information beyond
> copies
> of recent blocks.
You're suggesting that to avoid enabling full-rbf, coinjoin's and other
decentralized multi-party protocols risk getting coins tied up for hours trying
to do conflict resolution rather than just fixing the underlying problem with
what's literally a one-line code change that 17% of the v24.x nodes have
decided to enable.
> I didn't list these methods or others before because the specific method
> used to
> detect conflicts doesn't matter to the realization that software which
> uses conflict detection and evasion to defeat the $17.00 attack also
> defeats the $0.05 attack without any need for full-RBF.
Fact is, full-rbf defeats those attacks much better. And I'm amazed that you
don't consider raising the cost of attacks on coinjoins and similar
decentralized protocols by almost three orders of magnitude to be important:
why are you prioritizing a few highly centralized, often AML/KYC'd, unconfirmed
tx acceptance services over decentralized protocols which provide privacy and
security to a lot more users?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230113/5516cb92/attachment.sig>

2023-06-07 23:18:28

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: David A. Harding suggests that any protocol software that wants to defeat the $17.00 pinning attack needs to implement some sort of conflict monitoring system.
📝 Original message:On Tue, Jan 10, 2023 at 12:02:35AM -1000, David A. Harding wrote:
> On 2023-01-09 22:47, Peter Todd wrote:
> > How do you propose that the participants learn about the double-spend?
> > Without
> > knowing that it happened, they can't respond as you suggested.
>
> I can think of various ways---many of them probably the same ideas that
> would occur to you.
Rather than playing games, how about you actually list those ways.
> More concise than listing them is to just assume
> they exist and realize that any protocol software which wants to defeat
> the $17.00 pinning attack needs to implement some sort of conflict
> monitoring system---but by using that monitoring system to defeat the
> $17.00 pinning attack, the software also defeats the $0.05 individual
> conflicting input attack without any need for full-RBF.
Remember, we'd like decentralized coinjoin implementations like Joinmarket to
work. How does a decentralized coinjoin implement "conflict monitoring"?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/7315ce24/attachment-0001.sig>

2023-06-07 23:18:27

- reply

📅 Original date posted:2023-01-10
🗒️ Summary of this message: Full-RBF is proposed to prevent intentional and unintentional DoS attacks on multi-party protocols by double-spending inputs with low-fee transactions. The cost of such attacks is expensive, but the issue can also be solved in a non-full-RBF world by creating non-conflicting transactions.
📝 Original message:On Mon, Jan 09, 2023 at 09:11:46PM -1000, David A. Harding wrote:
> On 2023-01-09 12:18, Peter Todd via bitcoin-dev wrote:
> > [The quote:]
> >
> > "Does fullrbf offer any benefits other than breaking zeroconf
> > business
> > practices?"
> >
> > ...has caused a lot of confusion by implying that there were no
> > benefits. [...]
> >
> > tl;dr: without full-rbf people can intentionally and unintentionally DoS
> > attack
> > multi-party protocols by double-spending their inputs with low-fee txs,
> > holding
> > up progress until that low-fee tx gets mined.
>
> Hi Peter,
>
> I'm confused. Isn't this an easily solvable issue without full-RBF?
> Let's say Alice, Bob, Carol, and Mallory create a coinjoin transaction.
> Mallory either intentionally or unintentionally creates a conflicting
> transaction that does not opt-in to RBF.
>
> You seem to be proposing that the other participants force the coinjoin
> to complete by having the coinjoin transaction replace Mallory's
> conflicting transaction, which requires a full-RBF world.
>
> But isn't it also possible in a non-full-RBF world for Alice, Bob, and
> Carol to simply create a new coinjoin transaction which does not include
> any of Mallory's inputs so it doesn't conflict with Mallory's
> transaction? That way their second coinjoin transaction can confirm
> independently of Mallory's transaction.
How do you propose that the participants learn about the double-spend? Without
knowing that it happened, they can't respond as you suggested.
> Likewise, if Alice and Mallory attempt an LN dual funding and Mallory
> creates a conflict, Alice can just create an alternative dual funding
> with Bob rather than try to use full-RBF to force Mallory's earlier dual
> funding to confirm.
Same issue.
And of course, in both cases full-rbf makes Mallory have to actually pay full
price for the attack. Either because the intended transaction goes through. Or
because their double-spending DoS attack had to be much more expensive in the
first place.
> > ## Transaction Pinning
> >
> > Exploiting either rule is expensive.
>
> I think this transaction pinning attack against coinjoins and dual
> fundings is also solved in a non-full-RBF world by the honest
> participants just creating a non-conflicting transaction.
>
> That said, if I'm missing something and these attacks do actually apply,
> then it might be worth putting price figures on the attack in terms most
> people will understand. The conflicting inputs attack you described in
> the beginning as being solved by full-RBF costs about $0.05 USD at
> $17,000/BTC. The transaction pinning attack you imply is unsolved by
> full-RBF costs about $17.00. If both attacks apply, any protocol which
> is vulnerable to a $17.00 attack still seems highly vulnerable to me, so
> it doesn't feel like a stretch to say that full-RBF lacks significant
> benefits for those protocols.
Coinjoins are an automated process that happens constantly. As I described in
my email, it's totally normal for them to fail constantly - I was told by
Wasabi that only ~25% of coinjoin rounds succeed right now, a figure that
frankly was much higher than I expected. Being forced to spend $17/round rather
than $0.05/round is a huge improvement that adds up to serious money at the
scale at which Wasabi and similar protocols operate at.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230110/9e0a6645/attachment.sig>

2023-06-07 23:18:26

- reply

📅 Original date posted:2023-01-09
🗒️ Summary of this message: Full-RBF is a valuable improvement for multi-party protocols like coinjoins, as it prevents intentional and unintentional DoS attacks by ensuring a higher fee transaction gets mined in a reasonable amount of time. Without it, people can double-spend their inputs with low-fee transactions, holding up progress for days or even weeks.
📝 Original message:I was reminded recently that while Suhas Daftuar cited tx-pinning as a reason
to remove full-rbf, he neglected to mention that tx-pinning greatly increases
the cost of attacks on multi-party protocols. Him (rhetorically?) asking(4):
"Does fullrbf offer any benefits other than breaking zeroconf business
practices?"
...has caused a lot of confusion by implying that there were no benefits. So
I'm writing this to set the record straight and provide an easily cited
explanation as to why full-rbf - even with tx-pinning - is a valuable
improvement for multi-party protocols like coinjoins that rely on transactions
containing multiple inputs exclusively controlled(1) by different parties.
tl;dr: without full-rbf people can intentionally and unintentionally DoS attack
multi-party protocols by double-spending their inputs with low-fee txs, holding
up progress until that low-fee tx gets mined. This could take days, weeks, or
even worse. Modulo intentional tx-pinning, full-RBF fixes this by ensuring that
a higher fee transaction gets mined in a reasonable amount of time so the
protocol makes forward progress. And as for tx-pinning, exploiting it is very
expensive, so full-rbf still makes the situation much better than the status
quo.
# The Double-Spend DoS Attack on Multi-Party, Multi-Input, Transactions
If a protocol constructs transactions containing multiple inputs exclusively
controlled by different parties, those parties can intentionally and
unintentionally double-spend those inputs in alternate transactions. For
example, in a Wasabi coinjoin any one of the hundreds of participants could
sign and broadcast a transaction spending their input. If they do that at the
right time, as much as ~100% of the hashing power may see the double-spend
first, prior to the intended coinjoin transaction. This in fact does happen
regularly in production to Wasabi coinjoins, probably due to people
accidentally running different wallets at the same time using the same seed, as
well as people importing their seeds into alternative wallets.
By itself this isn't a significant problem: Wasabi coinjoins are a two phase
protocol, and, like any multi-step, multi-party protocol, they have to deal
with the fact that participants in the protocol may fail to complete all the
steps necessary for a transaction to be completed. It's very common for one or
more parties in a Wasabi coinjoin to fail to complete both steps of the
protocol, and a majority of Wasabi coinjoin rounds fail. Wasabi deals with this
economically by (temporarily or ~permanently) blacklisting UTXOs that failed to
complete a round, making DoS attacks expensive by forcing the attacker to tie
up funds/create new UTXOs.
Similarly, in use-cases such as multi-party-funded Lightning channels(5), an
attacker can always DoS attack the protocol by participating in a channel open,
and then failing to allow payments to be routed through it. The solution is
again to use economics to ensure the attack is sufficiently costly.
However, under the right circumstances double-spends are an unusually powerful
DoS attack on multi-party, multi-input, transaction. When mempool demand is
high, low fee transactions can take arbitrarily long to get mined. Bitcoin has
seen periods of mempool demand where low-fee transactions would take *months*
to get mined. Transaction expiry does not solve this problem, as anyone can
rebroadcast transactions at any time. In these circumstances without
transaction replacement a multi-party transaction such as a Wasabi coinjoin
could be held up indefinitely by a low-fee double-spend.
## How Full-RBF Mitigates the Double-Spend DoS Attack
Modulo tx-pinning, full-rbf mitigates the double-spend DoS attack in a very
straightforward way: the low fee transaction is replaced by the higher fee
transaction, resulting in the latter getting mined in a reasonable amount of
time and the protocol making forward progress.
Note that the converse is not a useful attack: if the attacker broadcasts a
high-fee double spend, higher than the intended multi-party transaction, the
transaction will get mined in a reasonable amount of time, costing the attacker
money and the defender nothing beyond wasted time. Multi-party protocols always
have the property that attackers can spend money to DoS attack by creating more
UTXOs/identities/etc, so this isn't any worse than the status quo!
## Transaction Pinning
So what about transaction pinning? The term actually refers to a few different
techniques that can make it difficult/expensive to fee-bump a transaction.
We're interested in the techniques relevant to replacements, namely
exploitation of:
1. BIP-125 RBF Rule #3: a replacement transaction is required to pay
the higher absolute fee (not just fee rate) than the sum of fees paid by all
transactions being replaced.
2. BIP-125 RBF Rule #5: the number of transactions replaced at one time must
not exceed 100. Note that this rule only exists due to limitations of the
existing Bitcoin Core implementation; it has absolute no economic rational and
should be removed by either improving the implementation's scalability issues,
or rejecting transactions that could make a transaction unreplaceable(2).
Exploiting either rule is expensive. To exploit rule #3 the attacker has to
broadcast fee-paying transactions paying a total amount of fees higher than the
defender is willing to pay. Since transactions don't expire, in almost all
circumstances those transactions will eventually be mined, costing the attacker
much more money than they would have spent without full-rbf.
To exploit rule #5, the attacker has to broadcast 100x more fee-paying
transactions than they otherwise would have. As with rule #3, those
transactions will almost always eventually be mined, costing the attacker
significantly more money than they would have spent without full-rbf. And, as
mentioned above(2), rule #5 is merely an artifact of the existing
implementation which can and should be fixed.
The only avenue for an attacker to avoid transaction pinning costs is
amortisation: reusing the extra transactions required for pinning for other
attacks/other purposes. But of course, amortisation is *already* a potent cost
reduction strategy for attacks on multi-party protocols such as coinjoin, so
the existence of transaction pinning doesn't appreciably change the situation.
Again, there are mitigations such as requiring participants to post nLockTime'd
fee-paying transactions(3), and limiting attacks to parties who are heavily
invested in Bitcoin for other reasons is a valuable improvement on the status
quo.
# Conclusion
Far from not "offering any benefits other than breaking zeroconf business
practices"(4), full-rbf clearly improves Bitcoin for multi-party protocols,
among the many other reasons to adopt it.
# Footnotes
1. What do I mean by "exclusively controlled"? Let's compare coinjoin, to an
ordinary single-payer Lightning channel. In a coinjoin, the goal is to get a
transaction mined containing multiple inputs from different parties. Each of
these inputs is individually, exclusively controlled by a single party:
without the cooperation of any other party that input that be spend. This is
unlike an ordinary single-payer Lightning channel: while the commitment
transactions are multi-party transactions, the multisig transaction outputs
involved are *jointly* controlled by both parties, and thus neither party can
spend it without the cooperation of the other at some point.
2. [bitcoin-dev] Removing BIP-125 Rule #5 Pinning with the Always-Replaceable
Invariant, https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021175.html
3. [bitcoin-dev] Using Full-RBF to fix BIP-125 Rule #3 Pinning with nLockTime,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021176.html
4. https://github.com/bitcoin/bitcoin/pull/26438
5. There are even more exotic proposed Lightning-related protocols where a failure
of transaction replacement can cause the loss of funds. I'm not covering
those scenarios because they have such strong requirements - beyond what
full-rbf offers - that the technical community does not have consensus that
these proposed protocols are even viable.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230109/e2dd405c/attachment-0001.sig>

2023-06-07 23:18:06

- reply

📅 Original date posted:2023-01-18
🗒️ Summary of this message: Discussion on the potential consequences of a halving event in Bitcoin mining, including the possibility of significant hashing power shutdowns and fee increases.
📝 Original message:On Sun, Jan 01, 2023 at 11:42:50PM +1100, Alfie John wrote:
> On 31 Dec 2022, at 10:28 am, Peter Todd via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
> >
> >> This way:
> >>
> >> 1. system cannot be played
> >> 2. only in case of destructive halving: system waits for the recovery of network security
> >
> > The immediate danger we have with halvings is that in a competitive market,
> > profit margins tend towards marginal costs - the cost to produce an additional
> > unit of production - rather than total costs - the cost necessary to recover
> > prior and future expenses. Since the halving is a sudden shock to the system,
> > under the right conditions we could have a significant amount of hashing power
> > just barely able to afford to hash prior to the halving, resulting in all that
> > hashing power immediately having to shut down and fees increasing dramatically,
> > and likely, chaotically. Your proposal does not address that problem as it can
> > only measure difficulty prior to the halving point.
>
>
> > ... Since the halving is a sudden shock to the system
>
> Is it though? Since everyone knows of the possible outcomes, wouldn't a possible halving be priced in?
Re-read that I said. That explains why despite the halving being a forseeable
event, there's no mechanism to "price it in" when it comes to hashing power.
> > resulting in all that hashing power immediately having to shut down and fees increasing dramatically
>
> Which should cause that hashing power to come back because of this fee increases.
Right now the total reward per transaction is $63, three orders of magnitude
higher than typical fees. Sufficient fee increases to bring back hashing power
in a scenario like that would cause enormous disruption to many things,
including Lightning channels.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20230118/8746a7e7/attachment-0001.sig>

2023-06-07 23:17:59

- reply

📅 Original date posted:2022-12-30
📝 Original message:On Fri, Dec 23, 2022 at 07:43:36PM +0100, jk_14 at op.pl wrote:
>
> Necessary or not - it doesn't hurt to plan the robust model, just in case. The proposal is:
>
> Let every 210,000 the code calculate the average difficulty of 100 last retargets (100 fit well in 210,000 / 2016 = 104.166)
> and compare with the maximum of all such values calculated before, every 210,000 blocks:
>
>
> if average_diff_of_last_100_retargets > maximum_of_all_previous_average_diffs
> do halving
> else
> do nothing
>
>
> This way:
>
> 1. system cannot be played
> 2. only in case of destructive halving: system waits for the recovery of network security
First of all - while I suspct you already understand this issue - I should
point out the following:
The immediate danger we have with halvings is that in a competitive market,
profit margins tend towards marginal costs - the cost to produce an additional
unit of production - rather than total costs - the cost necessary to recover
prior and future expenses. Since the halving is a sudden shock to the system,
under the right conditions we could have a significant amount of hashing power
just barely able to afford to hash prior to the halving, resulting in all that
hashing power immediately having to shut down and fees increasing dramatically,
and likely, chaotically. Your proposal does not address that problem as it can
only measure difficulty prior to the halving point.
Other than that problem, I agree that this proposal would, at least in theory,
be a positive improvement on the status quo. But it is a hard fork and I don't
think there is much hope for such hard forks to be implemented. I believe that
a demmurrage soft-fork, implemented via a storage fee averaged out over many
future blocks, has a much more plausible route towards implementation.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221230/e2c7cba6/attachment.sig>

2023-06-07 23:17:57

- reply

📅 Original date posted:2022-12-23
📝 Original message:On December 23, 2022 1:39:13 AM CST, Vasil Dimov <vd at freebsd.org> wrote:
>On Thu, Dec 22, 2022 at 22:06:03 -0500, Peter Todd via bitcoin-dev wrote:
>[...]
>> a lack of a convenient source of onion addresses to try
>[...]
>
>$ bitcoin-cli getnodeaddresses 0 |jq -r 'map(select(.network == "onion")) | .[].address'
It's not that simple. Because onion addresses cost close to nothing nothing to obtain it's dubious to just try some on a one time basis without checking to see if they actually have a longer term track record of actually existing. You could end up trying addresses of a one time Sybil attack.
The advantage of using the DNS seed records is those addresses are tested over long time frames, so you have a better chance of them representing real nodes. But my DNS seed doesn't happen to be setup to track nodes using Tor right now.

2023-06-07 23:17:55

- reply

📅 Original date posted:2022-12-23
📝 Original message:tl;dr: By connecting to every Bitcoin Core v24 node I could, and measuring
transaction invs, I determined that at this moment about 17% of all Bitcoin
Core v24 nodes listening on IPv4 are running with full-rbf enabled and
successfully propagating full-rbf replacements.
Procedure:
0) Modify MAX_ADDNODE_CONNECTIONS to 5000 and recompile.
1) Run ./bitcoind -mempoolfullrbf=0 -debug=inv -debug=mempool -debug=mempoolrej
2) Manually addnode every IPv4 address of a node matching 'Satoshi:24' and
*not* advertising the full-rbf service bit in my DNS seed's 'dnsseed.dump'
file. This happened to be 692 IPv4 addresses.
3) Wait for connection counts to stabilize. I managed to connect to ~500 nodes
out of the 692 I tried connecting too.
4) Wait for one of my OpenTimestamps calendars to perform a full-rbf
replacement¹. They wait a significant amount of time (60s) between
transactions and blocks to ensure good propagation, and a true full-rbf
replacement.
5) Wait 2 minutes to ensure complete propagation of the replacement transaction.
6) Run grep <wtxid> ~/.bitcoin/debug.log | grep 'got inv' | wc -l to count the
number of invs. (I obtained the wtid from another node running full-rbf)
7) Repeat steps 4 to 6 three more times to verify counts are stable.
Discussion:
This data shows substantial adoption of the mempoolfullrbf=1 option among IPv4
listening nodes, above and beyond people choosing to run Bitcoin Knots or
another full-rbf peering fork of Bitcoin Core. This data is also an
underestimate: I'm only measuring successful propagation. Nodes which have
full-rbf enabled - but do not have any full-rbf peers - are not counted by this
measurement. Thus the true number of full-rbf nodes will be even higher than
these stats indicate.
Since v24 nodes are currently only ~5% of all listening nodes, the probability²
of a non-listening node having a full-rbf peer in their outgoing 8 connections
is still low, ~8%. However, if this 17% was maintained as all nodes eventually
upgrade to v24, the probability of a full-rbf peer in the outgoing 8 would be
quite high, ~80%.
Future Work:
How are full-rbf nodes distributed among the IPv4 address space? Bitcoin
Core, by default, groups IPv4 addresses into /16 buckets, and does not connect
to more than 1 outgoing node per bucket. The true probability of connecting to
a full-rbf peer may be changed by this distribution.
How are full-rbf nodes distributed among other connection types? At the moment
bitnodes.io reports that a majority of listening nodes are listening on .onion
addresses. Due to the difficulty of connecting to very large numbers of Tor
nodes at once, and a lack of a convenient source of onion addresses to try, I
did not attempt to measure full-rbf adoption among onion nodes. IIUC a number
of pre-built "node in a box" solutions such as the Start9 Labs Embassy are
currently only able to listen via Tor.
How are full-rbf nodes distributed among non-listening nodes? A potential
strategy to measure this could be to measure inv's on a listening node with a
large number of incoming peers. Anecdotally, I have been told by a number of
people that they're running mempoolfullrbf=1 on non-listening nodes.
References:
1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021143.html
2) https://stacker.news/items/98441
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221222/e8823a25/attachment.sig>

2023-06-07 23:17:51

- reply

📅 Original date posted:2022-12-13
📝 Original message:On Tue, Dec 13, 2022 at 12:06:47PM +0000, Michael Ford via bitcoin-dev wrote:
> Due to last-minute issues (https://github.com/bitcoin/bitcoin/pull/26616),
> 24.0, although tagged, was never fully announced or released.
>
> Bitcoin Core version 24.0.1 is now available from:
>
> https://bitcoincore.org/bin/bitcoin-core-24.0.1/
Note that the PGP signature on this email is bad:
[-- PGP output follows (current time: Tue 13 Dec 2022 04:15:30 PM EST) --]
gpg: WARNING: no command supplied. Trying to guess what you mean ...
gpg: Signature made Tue 13 Dec 2022 07:06:06 AM EST
gpg: using RSA key CFB16E21C950F67FA95E558F2EEB9F5CC09526C1
gpg: BAD signature from "Michael Ford (bitcoin-otc) <fanquake at gmail.com>" [full]
[-- End of PGP output --]
[-- BEGIN PGP SIGNED MESSAGE --]
Due to last-minute issues (https://github.com/bitcoin/bitcoin/pull/26616),
24.0, although tagged, was never fully announced or released.
The announcement on bitcoin-core-dev was had an invalid signature.
Likely some formatting error - your mail client also send it as text and html
at the same time. No-one should be sending html emails to this mailing list.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/e7c06640/attachment-0001.sig>

2023-06-07 23:17:48

- reply

📅 Original date posted:2022-12-12
📝 Original message:Available from: https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0.1
eg:
git clone -b full-rbf-v24.0.1 https://github.com/petertodd/bitcoin.git
What is this? It's Bitcoin Core v24.0.1, with Antoine Riard's full-rbf peering
code, and some additional minor updates to it. This does two things for
full-rbf nodes:
1) Advertises a FULL_RBF service bit when mempoolfullrbf=1 is set.
2) Connects to four additional FULL_RBF peers.
Doing this ensures that a core group of nodes are reliably propagating full-rbf
replacements. We don't need everyone to run this. But it'd be helpful if more
people did.
Right now I'd estimate that there are ~30 reliable nodes accepting incoming
connections and running the v24.0 version of this branch. Additionally there
are another ~50 reliable Bitcoin Knots nodes accepting incoming connections;
Knots advertises the service bit, but doesn't have the peering code.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221212/a83ed4c9/attachment.sig>

2023-06-07 23:17:45

- reply

📅 Original date posted:2022-12-16
📝 Original message:On Tue, Dec 13, 2022 at 11:58:31PM +0200, Daniel Lipshitz wrote:
> > With multi-party transactions such as coinjoins and multi-party lightning
> > channels, we want full-rbf behavior because it avoids accidental
> > double-spends
> > holding up progress in these protocols.
>
> what is meant by accidental double spends ? And do you have any data as to
> how often these occur and would cause harm?
A double-spend of an input to a multiparty transaction that isn't maximally
trying to exploit transaction pinning. For example, Wasabi has found many cases
of users imported the same seed into different wallets. This is quite hard to
avoid in decentralized wallets.
> Second, for intentional DoS attacks, it
> > makes those attacks much more expensive by forcing the attacker to use
> > tx-pinning.
>
> how are these Dos attacks mitigated today if Full RBF is not in place ?
They aren't. During congested mempool conditions an attacker could cause
significant delays to multi-party transactions without full-rbf. Fortunately,
the mempool regularly empties right now. But that has not been true in the
past, we can not guarantee that, and for Bitcoin to remain secure without
inflation or demmurage in the future, we have to operate under full-mempools
with significant backlogs of transactions.
> > Thus we have a political tradeoff between a handful of centralized services
> > such as yours that benefit from the first-seen status quo, and the much
> > larger
> > group of users that use Lightning and coinjoins.
>
> How many users are currently using Lightning and coinjoins today ?
Wallet of Satoshi, one of many Lightning wallets, claims to be performing
12,500 transactions/day: https://twitter.com/kerooke/status/1603812141966016520
Bitcoin as a whole currently does about 300,000 transactions per day(1). So that
one single Lightning wallet represents roughly 4% of the total payment volume
of Bitcoin. Wallet of Satoshi, BlueWallet, and SBW all have 100K+ downloads on
the Google Play store. So a reasonable guess is they're equally popular. Which
means they collectively represent 12% of the total number of transactions on
Bitcoin. You claimed GAP600 was queried for 900,000 unique tx hashes per
month(2), or about 10% of total transactions.
I don't have statistics for number of coinjoin transactions per day, or the
blockspace used. But Wasabi have published (reproducable) data showing that
currently about 750BTC/day are entering Wasabi 2.0 coinjoins:
https://mobile.twitter.com/wasabiwallet/status/1603366008437325828
You claimed GAP600 was responsible for USD $220 million of transaction
volume(2), significantly less than the ~$400 million / month that Wasabi
coinjoins alone represent. And of course, Wasabi is just one of three main
coinjoin implementations.
> > We've already been through
> > such a political tradeoff before with the blocksize debate - again, the
> > centralized payment providers lost the debate.
>
> I don’t think this has anything to do with block size debate or
> decentralisation just looking to protect a significant use case that has
> been in place - GAP600 is by no means the only service provider is this
> place there are many merchants who do 0-conf on there own.
You claimed that GAP600 handled about 10% of all transactions. Obviously, if
that is true, that indicates a very high degree of centralization. It is
extremely undesirable for Bitcoin for one single entity with, as I understand
it, AML/KYC to handle 10% of all transactions. Probably an even higher
percentage when you take into account that only a minority of transactions are
merchant payment-type transactions where unconfirmed transactions would have
any relevance at all.
You claim that there are "many merchants" who do 0-conf on their own. Can you
list more examples of those merchants? Surely if there are "many" of them, you
could easily give us four or five more examples so this list can evaluate what
kinds of security guarantees they're actually relying on.
1) https://ycharts.com/indicators/bitcoin_transactions_per_day
2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021239.html
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221216/800096da/attachment.sig>

2023-06-07 23:17:44

- reply

📅 Original date posted:2022-12-13
📝 Original message:On Tue, Dec 13, 2022 at 01:33:00PM +0200, Daniel Lipshitz wrote:
> I dont think there was anything technical with the implementation and as
> far as I can tell this is well developed and ready.
There are lots of problems with my first-seen-safe proposal. The only reason I
proposed it in 2015 was as a political compromise.
> The reasons I can find for not being adopted are listed here -
> https://bitcoincore.org/en/faq/optin_rbf/ under - Why not First-seen-safe
> Replace-by-fee
>
> Those reasons do not seem pertinent here - given OptinRBF already exists
> as an option and the added benefit of continuing to be able to support
> 0-conf.
First-seen-safe is incompatible with the #1 reason why mempoolfullrbf was
merged into Bitcoin Core: multi-party transactions.
With multi-party transactions such as coinjoins and multi-party lightning
channels, we want full-rbf behavior because it avoids accidental double-spends
holding up progress in these protocols. Second, for intentional DoS attacks, it
makes those attacks much more expensive by forcing the attacker to use
tx-pinning.
Nothing less than full-rbf without restritions on outputs works for this
use-case. The only compromise possible is Antoine Riard's spent-nVersion
signalling proposal¹, which has a significant, negative, privacy impact². It
also increases costs and time in many cases, as you often have to create new
outputs to flag full-rbf.
Thus we have a political tradeoff between a handful of centralized services
such as yours that benefit from the first-seen status quo, and the much larger
group of users that use Lightning and coinjoins. We've already been through
such a political tradeoff before with the blocksize debate - again, the
centralized payment providers lost the debate.
Anyway, my advice to you is to either change your business model to make use of
scalable instant payment tech such as Lightning. Or give up on Bitcoin and
expand your business with other chians, such as BSV³. The fact is some hashing
power is already beginning to run with full-rbf⁴, and I fully expect that % to
increase over time.
1) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
2) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021250.html
3) https://www.gap600.com/bitcoin/gap600-supports-bsv/
4) https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-December/021260.html
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221213/0da664f7/attachment-0001.sig>

2023-06-07 23:17:27

- reply

📅 Original date posted:2022-12-10
📝 Original message:On Sat, Dec 10, 2022 at 12:59:05PM +0100, 0xB10C wrote:
> On 12/9/22 22:16, Peter Todd wrote:
> >> For further monitoring, I've set-up a mempoolfullrbf=1 node and are
> >> logging replacement events with [0]. I filter the full-RBF replacements
> >> and list the replaced and replacement transactions here:
> > Question: are you taking any special steps to peer that node with other
> > full-rbf nodes? I see you are in fact getting all the replacements I'd expect
> > you to get, so you must have good peering. I'm curious what it took (if
> > anything) to achieve that. Also, is that node accepting incoming connections?
> No special steps like #25600 preferential peering or similar. I suspect
> I was lucky to have a full-RBF peer (or more than one) from the start or
> there are more mempoolfullrbf=1 nodes than I'd think on the network. The
> node accepts incoming connections on a non-default port and currently
> has 45 inbound slots filled up. Mostly buy v23.0 and v24.0 nodes though,
> as older Bitcoin Core version usually don't connect to non-default port
> peers.
Interesting! I'm running a full-rbf node that is (manually) connected to a few
hundred v24.0 nodes to ensure good propagation. But I'm only connected to
standard ports (I'm reusing the DNS seed list). So you must have a full-rbf
peer purely by luck.
Could you please grep your logs for which peer(s) are sending you replacements?
I don't want to know the IP addresses. I'm just curious if you have exactly one
full-rbf peer or more.
BTW I have Antoine's preferential peering patch ported to v24.0, along with a
few other minor fixes:
https://github.com/petertodd/bitcoin/tree/full-rbf-v24.0
I think it'd be reasonable for you to run that, as what's more interesting is
the replacements, not whether or not propagation happens to work out of the
box.
> > https://blockstream.info also enabled full-rbf a few days ago. But currently
> > propagation to their nodes is spotty, so replacements don't always show up.
>
> Since my last post, five full-RBF replacements have been mined in two
> blocks:
>
> 766733 by Luxor:
>
>     41d497d64bfa71390408ddb65c478a5400c721c71336fa51509929f19a5c8aa5 1x
> P2WPKH in -> 1x P2WPKH out (12.50 sat/vByte)
>     3061eec0b57346c01419db091ce3af16094e796db91f4f3eb9b7ad42ce8f6e25
> OpenTimestamps Alice ~170 USD bounty (6424.72 sat/vByte)
>     9000f73e818af9019d26b2edde6e8e11f67d6d6f35916dabd808bbdd314ce807 1x
> P2WPKH in -> 1x P2WPKH out (22.73 sat/vByte)
>     3843e93a0ec5cf09d757fd497fdda8f15f5094c64b149624c5d343b24e675093
> OpenTimestamps Bob (108.25 sat/vByte)
>
> It seems like Luxor (5.5 EH/s or 2.11% network hashrate in the last 7
> days)[0] might have mempoolfullrbf=1 enabled.
>
> 766736 by AntPool:
>
>    3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1
> OpenTimestamps Bob (4.25 sat/vByte)
>
> I'm not too sure if AntPool has full RBF enabled based on this one
> transaction. 3c96fe.. is the first replacement of
> 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (1.19
> sat/vByte) which they might not have seen (?). They have nearly 20% of
> the network hashrate [0], so if the have mempoolfullrbf=1 set, we should
> see them include more full-RBF replacements soonish. There was also
> 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f which
> bumped 3c96fe.. by 1.53 sat/vByte, but was only broadcast shortly before
> AntPool found the block. The might not have seen it yet.
So according to my logs the replacement that AntPool mined, 3c96fe813, was the
third replacement in a row of four replacements:
2022-12-10T07:46:09Z [mempool] AcceptToMemoryPool: peer=<snip>: accepted 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 (poolsz 6320 txn, 90818 kB)
2022-12-10T07:47:14Z [mempool] replacing tx 903f03b16e69f9f3fc6bb8d008338da37efc3f235fc5091ca767baae96834d95 with f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:01:09Z [mempool] replacing tx f8bef985457f9e5bbf5b583e33cca43d515a3a73e1bb6a2c5a11646632123aa2 with 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 for 0.00000234 additional fees, 0 delta bytes
2022-12-10T08:06:06Z [mempool] replacing tx 3c96fe8136de98a91d0add7e51fcacef813071d43feccc51987dc8378f6913e1 with 1467e3dbf9e9f3d9cd8e7cc4009cd9c1457e164f0dd87525c72e921d7a27ab1f for 0.00000234 additional fees, 0 delta bytes
There's significant time between tx #2 and tx #3, and the block was found soon
after #4 reached my node, so it's quite possible that AntPool was in fact
running full-rbf and they simply didn't see #4 in time.
Big pools tend to run many different nodes at once, splitting up hash rate
between them, so they could be simply running full-rbf on a subset of their
hashing power to test it out. I noticed F2Pool mined a few full-rbf
replacements a few weeks ago too (they also mined a replacement that appeared
to be due to them starting a new node, with an empty mempool).
Similarly, note how Luxor has mined a few blocks since #766733, without mining
full-rbf replacements.
I'll also note that Foundry USA mined a doublespend,
fab4df6b9b51dcfe94b366f17bccca50430f4ceb274a87f948a5493cd31a8551, which your
site shows. In that case according to my logs the two transactions were sent
essentially simultaneously, so likely just an accident of propagation. But it's
good to remind people that such double-spends are easy. :)
> I've also updated the site to allow only showing the replacements that
> were mined.
Thanks! That's very useful.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221210/830652f9/attachment-0001.sig>

2023-06-07 23:17:26

- reply

📅 Original date posted:2022-12-09
📝 Original message:On Fri, Dec 09, 2022 at 05:04:05PM +0100, 0xB10C via bitcoin-dev wrote:
> Hi AJ and list,
>
> > This seems to be pretty good evidence that we currently don't have any
> > significant hashrate mining with fullrbf policies (<0.5% if there was a
> > high fee replacement available prior to every block having been mined),
> > despite the bounty having been collected.
>
> For further monitoring, I've set-up a mempoolfullrbf=1 node and are
> logging replacement events with [0]. I filter the full-RBF replacements
> and list the replaced and replacement transactions here:
Question: are you taking any special steps to peer that node with other
full-rbf nodes? I see you are in fact getting all the replacements I'd expect
you to get, so you must have good peering. I'm curious what it took (if
anything) to achieve that. Also, is that node accepting incoming connections?
> Over the last few days, I has mostly seen OP_RETURN transactions
> (presumably mostly by OpenTimestamps; but I haven't checked closely) and
> a few other non-OP_RETURN transactions. None of the replacement
> transactions have been mined yet.
They are mostly OpenTimestamps transactions; I checked against the records from
my calendars and didn't find any OP_Return tx that wasn't one of mine.
The two calendars making full-rbf replacements are:
https://alice.btc.calendar.opentimestamps.org/
https://bob.btc.calendar.opentimestamps.org/
The status pages currently link to https://mempool.nixbitcoin.org, which is
also running mempoolfullrbf=1 As you can see, I've started the full-rbf bounty
again on Alice.
https://blockstream.info also enabled full-rbf a few days ago. But currently
propagation to their nodes is spotty, so replacements don't always show up.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221209/1104ff3e/attachment.sig>

2023-06-07 23:17:26

- reply

📅 Original date posted:2022-12-06
📝 Original message:On Tue, Dec 06, 2022 at 12:39:40AM -0500, Peter Todd via bitcoin-dev wrote:
> 10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by
> default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes on
> the network. When a node learns of a new block, it tells all it's peers that
> the new block exists.
>
> For your censorship to work, there has to be a substantial propability that a
> miner *only* runs a single node (they don't), that has no incoming peers, and
> all 8 peers of that node happen to be one of your 20 censoring nodes.
> Obviously, since the probability of a given peer being a censoring node is
> 20/5000, all 8 being censored is extraordinarily unlikely.
>
> Even if you ran so many nodes that 20% of the entire network was censoring, the
> probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256%
>
>
> This is an example of information being hard to censor and easy to spread. In
> fact, for full-rbf this same math works in our favor: for a node to have a 50%
> chance of connecting to at least one full-rbf peer, just 8.3% of the network
> needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes.
>
> The percolation threshold doesn't need to be met for this to be succesful,
> because someone to just run a full-rbf node that connects to every single
> listening node simultaneously.
FYI here's a percolation simulator for full-rbf:
https://github.com/mzumsande/fullrbf_simulation
It finds similar results to my math above.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221206/3f1d55d9/attachment.sig>

2023-06-07 23:17:25

- reply

📅 Original date posted:2022-12-06
📝 Original message:On Mon, Dec 05, 2022 at 09:20:58AM -0300, El_Hoy wrote:
> The only option I see against the attack Peter Todd is doing to opt-in RBF
> and 0Conf bitcoin usage is working on a bitcoin core implementation that
> stops propagation of full-rbf replaced blocks. Running multiple of such
> nodes on the network will add a risk to miners that enable full-rbf that
> would work as an incentive against that.
>
> Obviously that would require adding an option on bitcoin core (that is not
> technically but politically difficult to implement as Petter Todd already
> have commit access to the main repository).
For the record, I do not and have never had commit access to anything under
https://github.com/bitcoin
The last time I contributed to Bitcoin Core was in Mar 1st 2017, and that was
to add an explanatory comment. Pretty much the only reason why you know my name
is I'm very good at argument and critique, I come up with some good ideas, and
conference organizers love to put me on stage.
> That said, a sufficiently incentivized actor (like Daniel Lipshitz or Muun
> wallet developers) could work on a fork and run several nodes with such
> functionality. As far as I understand the percolation model, with 10 to 20
> nodes running such a rule would create a significant risk for full-rbf
> miners.
You do not understand the percolation model.
10 or 20 nodes is completely meaningless. Pools run nodes themselves, which by
default connect to 8 outgoing peers. There's about 5000 IPv4 listening nodes on
the network. When a node learns of a new block, it tells all it's peers that
the new block exists.
For your censorship to work, there has to be a substantial propability that a
miner *only* runs a single node (they don't), that has no incoming peers, and
all 8 peers of that node happen to be one of your 20 censoring nodes.
Obviously, since the probability of a given peer being a censoring node is
20/5000, all 8 being censored is extraordinarily unlikely.
Even if you ran so many nodes that 20% of the entire network was censoring, the
probability of all 8 outgoing peers being censors is only 0.2^8 = 0.000256%
This is an example of information being hard to censor and easy to spread. In
fact, for full-rbf this same math works in our favor: for a node to have a 50%
chance of connecting to at least one full-rbf peer, just 8.3% of the network
needs to run full-rbf. 5000 IPv4 nodes * 8% = 400 nodes.
The percolation threshold doesn't need to be met for this to be succesful,
because someone to just run a full-rbf node that connects to every single
listening node simultaneously.
Anyway, as others' have pointed out, you're idea is also broken in other ways.
But I thought it'd be worth pointing out how futile it is to even try.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221206/1826ac5c/attachment-0001.sig>

2023-06-07 23:17:17

- reply

📅 Original date posted:2022-12-06
📝 Original message:On Fri, Dec 02, 2022 at 05:35:39PM -0500, Antoine Riard via bitcoin-dev wrote:
> To recall, the original technical motivation of this option, and the wider
> smoother deployment was to address a DoS vector affecting another class of
> use-case: multi-party transactions like coinjoin and contracting protocols
> like Lightning [2] [3]. All of them expect to generate economic flows and
> corresponding mining income. Since then, alternative paths to solve this
> DoS vector have been devised, all with their own trade-offs and conceptual
> issues [4] [5].
<snip>
> [4]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-October/021135.html
> [5]
> https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021144.html
To be clear, these alternative paths all negatively impact privacy as they're
creating yet more ways for bad actors such as Chainalysis to deanonymize
transactions. We have a fundamental political tradeoff between the few
centralized services trying to accept unconfirmed txs, and the huge number of
users - everyone else - who desires privacy.
A big part of the promise of taproot was that we'd be able to eventually
greatly improve the anonymity set of all transactions by making multi-party
transactions indistinguishable from any other transaction. That's a huge part
of why the community fought for taproot adoption.
Your proposal [5] that multi-party protocols use a different nVersion to signal
full-rbf in their txouts negates that anonymity set for the obvious reason that
single-party wallets are discouraged from using it by the fact that a few
services like Bitrefill complain about RBF transactions. Indeed, since
nVersion=3 transactions are non-standard, we additionally have the problem that
many more wallets won't even see such payments until a confirmation, or in some
cases due to bugs, never.
Worse, this trade-offs is fundamental: it is impossible to design such a
protocol without harming privacy. Why? Let's assume such a protocol was
possible. To be compatible with how unconfirmed txs are accepted today the
protocol would have to have the following two simultaneous properties:
1) Zeroconf services would need to be able to inspect the tx data and determine
whether or not the txout had opted into full-rbf.
2) Chainalysis services would need to be unable to inspect the tx data and
determine whether or not the txout had opted into full-rbf.
This is an obvious contradiction, and the only alternative of commit-reveal
schemes is ridiculous and would *itself* create yet another privacy impact. We
do not need any further technical debate on this issue: this is a political
tradeoff between a few centralized services and all other users that needs to
be decied by the community. No different than the blocksize wars.
The v3 proposal Suhas mentions in [4] has similar privacy issues: again we're
forcing a class of multiparty protocols to create transactions that are clearly
identified as being multiparty. In this case the privacy impact isn't as stark,
because the common case of cooperative actions in Lightning can use v2
transactions. But this is still a privacy impact that could be avoided by
better mempool design. Eg as I showed in:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2022-November/021175.html
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221206/e7753276/attachment.sig>

2023-06-07 23:17:14

- reply

📅 Original date posted:2022-12-03
📝 Original message:On Sat, Dec 03, 2022 at 01:01:16PM +0200, Daniel Lipshitz wrote:
> Shapeshift used to be clients in fact one of our first when we started in
> 2016.
>
> They no longer use our service but from time to time use us for fee
> recommendations. So we actually should remove their logo as a current
> client.
Yes you should. When did ShapeShift stop using your service? Did they explain
why?
> If you wish to test it out try find a merchant using Coinpayments or
> Coinspaid.
>
> Also some of our non custodial liquidity providers offer service no
> custodial wallets. I am not sure which.
I see that you also advertise that Gap600 is "Trusted by" Coindirect and
Coinify, both AML/KYC crypto exchanges. Obviously, with full AML/KYC
double-spends are not much of a concern. And it's not even clear that
either accepts zeroconf anyway, as I'll explain later.
On this list you claimed that:
> 1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
> 15M transactions
> 2. These transactions have a cumulative value of 2.3B USD value.
> 3. We currently are seeing circa 1.5M transactions queired per month.
What's the value and number of transactions that *actually* rely on your
unconfirmed transaction tools? The only category that would apply for is goods
provided immediately and irrovocably, without AML/KYC. Because it sounds like
these figures may be significantly overstated.
Re: CoinsPaid, what you say here makes it also sound like it relies on AML/KYC:
> CoinsPaid applies a special software tool across its solutions to conduct
> stringent KYC procedures and a risk-based approach to CDD that verify user
> identities to mitigate fraud, money laundering and other activities linked to
> criminality and terrorism.
https://www.gap600.com/uncategorized/coinspaid/
Re: Coindirect, the documentation I can find appears to say that confirmations
are required before you can use coins deposited into Coindirect:
> Digital currency transactions must be confirmed on the relevant network block
> before they are considered valid. Only once confirmed, will you be able to
> use the coins deposited in your Coindirect wallet.
https://help.coindirect.com/hc/en-us/articles/115002441974-How-quickly-can-I-use-coins-deposited-into-my-Coindirect-wallet-
This is repeated here as well: https://help.coindirect.com/hc/en-us/articles/4409120006546--Deposits-
Re: Coinify, the API docs don't give any indication of risk scoring or any
other Gap600 integration:
https://merchant.coinify.com/docs/api/#payment-object
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221203/2d341053/attachment.sig>

2023-06-07 23:17:13

- reply

📅 Original date posted:2022-12-03
📝 Original message:On Fri, Dec 02, 2022 at 09:06:26AM +0200, Daniel Lipshitz wrote:
> Yes I can see how that is not clear, apologies.
>
> Just BTC.
> From Jan1 2022 up till end of November 2022 GAP600 has processed circa 15M
> trxs. With a value of 2.3B USD.
> In 2021 we did - circa 12.5M.
> In 2020 we did circa 6.5M.
>
> We have been in production since 2016 and working on the project since
> 2014/2015.
Thanks.
I note on your website that you claim ShapeShift is one of your clients. I just
checked and ShapeShift appears to wait for a confirmation before allowing a
trade when funded with a high-fee, non-opt-in-rbf transaction.
What exactly is the service that you are providing for ShapeShift?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221203/864cc58b/attachment.sig>

2023-06-07 23:17:12

- reply

📅 Original date posted:2022-12-02
📝 Original message:On Thu, Dec 01, 2022 at 02:27:16PM +0200, Daniel Lipshitz via bitcoin-dev wrote:
> Statistics for consideration as a sample of the zero conf use case -
>
>
> 1. As of end of Nov 2022 - GAP600 has processed i.e responded to circa
> 15M transactions
> 2. These transactions have a cumulative value of 2.3B USD value.
> 3. We currently are seeing circa 1.5M transactions queired per month.
I'm curious, what are the time frames involved in those figures? Eg 15M txs
over how long?
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20221201/ba0fa5b0/attachment.sig>