<unnamed>

Public Key

npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2

Profile Code

nprofile1qqsd4ghuva4ztca4k3tyg4qte0g7z95tzy2z0ngw8ncec4sef7err2spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds3yundj

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-09-07 11:52:35 UTC

- 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-05 21:58:15 UTC

- 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-05 21:58:15 UTC

- 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-04 20:19:32 UTC

- 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-02 10:19:21 UTC

- 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 UTC

- 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-06-19 18:19:51 UTC

- 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-09 13:08:57 UTC

- 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:05:10 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:34 UTC

- 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 12:56:13 UTC

- 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:48:33 UTC

- 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-07 23:19:27 UTC

- 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 UTC

- 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:18 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:18:56 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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 UTC

- 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:28 UTC

- 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 UTC

- 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:06 UTC

- 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:26 UTC

- 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 UTC

- 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:13 UTC

- 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 UTC

- 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>

2023-06-07 23:16:53 UTC

- reply

📅 Original date posted:2022-11-09
📝 Original message:On Tue, Nov 08, 2022 at 03:34:32PM -0800, Bram Cohen via bitcoin-dev wrote:
> Another probably unhelpful bit of feedback I have is that Bitcoin should
> probably be taking verkle trees seriously because those can have
> substantially lower size/cost/weight than merkle trees. That doesn't just
> apply to this proposal, but to Bitcoin in general, which doesn't seem to
> have any serious verkle tree proposals to date.
Verkle trees only reduce proof sizes by a factor of 6-8, and they introduce
significant implementation complexity and new cryptographic assumptions. Better
to let other crypto-systems get a few more years of experience with them before
adding them to Bitcoin. Particularly since even having merkle trees in Bitcoin
is arguably a mistake: they allow for degenerate, weak, security modes like SPV
that aren't clearly good for Bitcoin as a whole.
--
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/20221109/affdcd02/attachment.sig>

2023-06-07 23:16:46 UTC

- reply

📅 Original date posted:2022-11-07
📝 Original message:On Mon, Nov 07, 2022 at 03:17:29PM -0500, Peter Todd via bitcoin-dev wrote:
> tl;dr: We can remove the problem of Rule #5 pinning by ensuring that all
> transactions in the mempool are always replaceable.
With Rule #5 solved, let's look at the other pinning attack on multi-party
transactions: BIP-125 Rule #3
tl;dr: In conjunction with full-RBF, nLockTime'd, pre-signed, transactions can
ensure that one party is not forced to pay for all the cost of a rule #3
replacement.
# What is the problem?
When a transaction contains inputs from multiple parties, each party can lock
up funds from the other party by spending their input with a transaction that
is difficult/expensive to replace. Obviously, the clearest example of "difficult to
replace" is a non-BIP-125 (Opt-in-RBF) transaction. But here, we'll assume that
full-rbf is implemented and all transactions are replaceable.
BIP-125 Rule #3 states that:
The replacement transaction pays an absolute fee of at least the sum paid
by the original transactions.
The attack is that the malicious party, who we'll call Mallory, broadcasts a
transaction spending their input(s) with a low fee rate transaction that's
potentially quite large, during a time of high mempool demand. Due to the low
fee rate this transaction will take a significant amount of time to mine. The
other parties to the transaction - who we'll collectively call Alice - are now
unable to spend their inputs unless they broadcast a transaction "paying for"
Mallory's.
This attack works because Mallory doesn't expect the conflicting tx to actually
get mined: he assumes it'll either expire, or Alice will get frustrated and
have to double spend it. By simple tying up money, Mallory has caused Alice to
actually lose money.
# Fixing the problem with nLockTime
Conversely, in the case of an honest multi-party transaction, whose parties
we'll call Alice and Bob, the parties genuinely intend for one of two outcomes:
1) The multi-party transaction to get mined within N blocks.
2) The transaction to be cancelled (most likely by spending one of the inputs).
We can ensure with high probability that the transaction can be cancelled/mined
at some point after N blocks by pre-signing a transaction, with nLockTime set
sufficiently far into the future, spending one or more inputs of the
transaction with a sufficiently high fee that it would replace transaction(s)
attempting to exploit Rule #3 pinning (note how the package limits in Bitcoin
Core help here).
There's a few different ways to implement this, and exactly which one makes
sense will depend on the specifics of the multi-party protocol. But the general
approach is to defeat the attack by ensuring that Mallory will have to pay the
cost of getting the multi-party transaction unstuck, at some point in the
future.
For example, in a two party transaction where there's a clearly more reputable
party (Alice), and an untrusted party (Mallory), Alice could simply require
Mallory to provide a nLockTime'd transaction spending only his input to fees,
multiple days into the future. In the unlikely event that Mallory holds up the
protocol, he will be severely punished. Meanwhile, Alice can always cancel at
no cost.
In a many party transaction where both parties are equally (un)trustworthy the
protocol could simply have both parties sign a series of transactions,
nLockTimed at decreasingly far into a future, paying a decreasingly amount of
fees. If either party holds up the transaction intentionally, they'll both pay
a high cost. But again, at some point Mallory will have paid the full price for
his attack. This approach also has the beneficial side effect of implementing
fee discovery with rbf. This approach is easier as the number of parties
increases, eg the Wasabi/Joinmarket transactions with hundreds of inputs and
outputs: they collectively already have to pay a significant fee to get the
transaction mined, making the extra poential cost needed to defeat pinning
minimal.
# Coordinator Spent Bonds with Package Relay/Replacement
For schemes with a central semi-trusted coordinator, such as Wasabi coinjoins,
with package relay/replacement we can use a two party punishment transaction
consisting of:
tx1 - spends Mallory's input to a txout spendable by:
IF
<coordinator> CheckSig
Else
<delay> CheckSequenceVerify
<mallory> CheckSig
EndIf
tx2 - spends tx1 output to as much fees as needed
Whether or not Mallory cheated with a double-spend is provable to third
parties; the second transaction ensures that Mallory can't simply release tx1
on their own to frame the coordinator. The use of CheckSequenceVerify ensures
that if mallory did try to frame the coordinator, they don't have to do
anything to return the funds to Mallory.
--
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/20221107/59ee60a8/attachment.sig>

2023-06-07 23:16:18 UTC

- reply

📅 Original date posted:2022-11-07
📝 Original message:On November 3, 2022 5:06:52 PM AST, yancy via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>AJ/Antoine et al
>
>> What should folks wanting to do coinjoins/dualfunding/dlcs/etc do to
>> solve that problem if they have only opt-in RBF available?
>
>Assuming Alice is a well funded advisory, with enough resources to spam the network so that enough nodes see her malicious transaction first, how does full-rbf solve this vs. opt-in rbf?
First of all, to make things clear, remember that the attacks were talking about are aimed at _preventing_ a transaction from getting mined. Alice wants to cheaply broadcast something with low fees that won't get mined soon (if ever), that prevents a protocol from making forward progress.
With full-rbf, who saw what transaction first doesn't matter: the higher fee paying transaction will always(*) replace the lower fee one. With opt-in RBF, spamming the network can beat out the alternative.
*) So what's the catch? Well, due to limitations in today's mempool implementation, sometimes we can't fully evaluate which tx pays the higher fee. For example, if Alice spams the network with very _large_ numbers transactions spending that input, the current mempool code doesn't even try to figure out if a replacement is better.
But those limitations are likely to be fixable. And even right now, without fixing them, Alice still has to use a lot more money to pull off these attacks with full-rbf. So full-rbf definitely improves the situation even if it doesn't solve the problem completely.

2023-06-07 23:16:12 UTC

- reply

📅 Original date posted:2022-11-02
📝 Original message:On Tue, Nov 01, 2022 at 10:21:59PM -0400, Antoine Riard via bitcoin-dev wrote:
> Hi list,
>
> Reading Suhas's post on mempool policy consistency rules, and the grounded
> suggestion that as protocol developers we should work on special policy
> rules to support each reasonable use case on the network rather to arbiter
> between class of use-cases in the design of an
> unified set of rules, reminded me there is another solution to solve
> multi-party funding pinning rather than wide deployment of fullrbf. This
> was communicated to me a while back, and it was originally dismissed
> because of the privacy trade-offs (and potential slight fees overhead
> cost). However, if widely adopted, they might sound acceptable to
> contracting protocol developers and operators.
Strong NACK.
Zeroconf is, at best, a very marginal usecase. The only services that have
spoken up in support of it are Bitrefill and Muun, and the latter says they're
working to get rid of their vulnerability to it. People attempting to make it
secure have repeatedly done sybil attacks against the network in attempts to
measure transaction propagation. And of course, if transaction fees and full
mempools are in our near future - as is widely expected - mempool consistency
will even further diminish making zeroconf even harder to achieve.
Incurring a bunch of engineering costs and harming privacy for the sake of
continuing this nonsense is ridiculous.
If anything, we should be moving to full-RBF so we can undo the privacy cost
that is opt-in-RBF: right now 30% of transactions are having to harm their
privacy by signalling support for it. Full-RBF will allow that wallet
distinguisher to be eliminated.
--
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/20221102/57de210a/attachment.sig>

2023-06-07 23:15:58 UTC

- reply

📅 Original date posted:2022-10-27
📝 Original message:On Thu, Oct 27, 2022 at 09:49:48AM -0400, Greg Sanders via bitcoin-dev wrote:
> So there is some precedence to including an option that protocol devs don't
> find useful, then removing it N years later to make sure it doesn't impact
> compact blocks.
I think the lesson there is we're willing to remove options that are
ridiculous. Replacements are widely used, and downright essential in high-fee
situations.
> Peering into the "precedence" lense, I think this does lend itself to the
> theory that the transition should be as uniform as possible to avoid
> degradation of fast block propagation. If not removing options(which is
> deemed user hostile by a number of folks including me), then at least for a
> flag day switchover.
Re: compact blocks, note that RBF is a special case: for the sake of
reconstruction, it'd make sense to temporarily cache transactions have have
been replaced rather than discarding them entirely, in case a prior version
gets mined. Irregardless of policy this will happen occasionally simple due to
propagation delays. Equally, if we cached transactions that we rejected due to
policy, that'd help with reconstruction success in the event that policy is
changing.
Anyway, since the compact blocks implementation efficiently deals with the case
where miners have policy that differs from most nodes, by immediately
forwarding missing transactions, I don't think the occasional full-rbf
replacement is going to have much impact. The nodes that had full-rbf disabled
will forward the tx to their peers directly, and then the subset of full-rbf
disabled peers will do the same again. So long as the network has a mix of both
types, and they're interconnected rather than in clusters, the latency impact
should be minimal.
--
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/20221027/9719c3e0/attachment.sig>

2023-06-07 23:14:46 UTC

- reply

📅 Original date posted:2022-10-21
📝 Original message:On Thu, Oct 20, 2022 at 12:05:33AM -0400, Peter Todd wrote:
> ...and I checked this with Electrum on Android, which has a handy "Cancel
> Transaction" feature in the UI to easily cancel a payment. Which I did. You
> should have a pending payment from this email, and unsurprisingly I don't have
> my gift card. :)
FYI I asked around and in addition to Electrum, BlueWallet, Simple Bitcoin
Wallet, and Specter Wallet all implement tx cancelation. Probably more.
--
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/bitcoin-dev/attachments/20221021/8b2bd524/attachment.sig>

2023-06-07 23:14:45 UTC

- reply

📅 Original date posted:2022-10-20
📝 Original message:On Wed, Oct 19, 2022 at 04:29:57PM +0200, Sergej Kotliar via bitcoin-dev wrote:
> Hi all,
>
> Chiming in on this thread as I feel like the real dangers of RBF as default
> policy aren't sufficiently elaborated here. It's not only about the
> zero-conf (I'll get to that) but there is an even bigger danger called the
> american call option, which risks endangering the entirety of BIP21 "Scan
> this QR code with your wallet to buy this product" model that I believe
> we've all come to appreciate. Specifically, in a scenario with high
> volatility and many transactions in the mempools (which is where RBF would
> come in handy), a user can make a low-fee transaction and then wait for
> hours, days or even longer, and see whether BTCUSD moves. If BTCUSD moves
> up, user can cancel his transaction and make a new - cheaper one. The
I just checked this, and Bitrefill accepts transactions with RBF enabled.
> biggest risk in accepting bitcoin payments is in fact not zeroconf risk
> (it's actually quite easily managed), it's FX risk as the merchant must
> commit to a certain BTCUSD rate ahead of time for a purchase. Over time
> some transactions lose money to FX and others earn money - that evens out
> in the end. But if there is an _easily accessible in the wallet_ feature to
> "cancel transaction" that means it will eventually get systematically
...and I checked this with Electrum on Android, which has a handy "Cancel
Transaction" feature in the UI to easily cancel a payment. Which I did. You
should have a pending payment from this email, and unsurprisingly I don't have
my gift card. :)
The ship has already sailed on this. I'd suggest accepting Lightning, which
drastically shortens the time window involved.
FWIW, fixedfloat.com already deals with this call option risk by charging a
higher fee (1% vs 0.5%) for conversions where the exact destination amount has
been locked in; the default is for the exact destination amount to be picked at
the moment of confirmation.
> abused. A risk of X% loss on many payments that's easy to systematically
> Bitrefill currently processes 1500-2000 onchain payments every day. For us,
> a world where bitcoin becomes de facto RBF by default, means that we would
Electrum is RBF by default. So does Green Wallet, and many other wallets, as
well as many exchanges. Most of those wallets/exchanges don't even have a way
to send a transaction without RBF. This ship has sailed.
--
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/bitcoin-dev/attachments/20221020/1496e29c/attachment.sig>

2023-06-07 23:14:31 UTC

- reply

📅 Original date posted:2022-10-14
📝 Original message:On Fri, Oct 14, 2022 at 12:03:21PM +0200, John Carvalho via bitcoin-dev wrote:
> In support of Dario's concern, I feel like there is a degree of gaslighting
> happening with the advancement of RBF somehow being okay, while merchants
> wanting to manage their own 0conf risk better being not okay.
The way merchants try to manage 0conf risk is quite harmful to Bitcoin.
Connecting to large numbers of nodes to try to risk-manage propagation _is_ an
attack, albeit a mild one. Everyone doing that is very harmful; only a few
merchants being able to do it is very unfair/centralized.
...and of course, in the past this has lead to merchants trying to make deals
with miners directly, even going as far as to suggest reorging out
double-spends. I don't need to explain why that is obviously extremely harmful.
--
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/20221014/7127d8c2/attachment.sig>

2023-06-07 23:14:30 UTC

- reply

📅 Original date posted:2022-10-14
📝 Original message:On Fri, Oct 14, 2022 at 02:44:04AM +0000, alicexbt via bitcoin-dev wrote:
> > Relay of fullrbf transactions works reasonable well
> > already, unless you get unlucky with your selected peers. The only
> > missing piece is a few percent of hashrate that will accept fullrbf
> > replacement transactions.
>
> I don't believe relay of fullrbf transactions works well right now. The missing piece you mentioned is important and a real need for all full node users to try fullrbf.
Relay of full-rbf transactions works well right now precisely because a few
implementations exist of preferential rbf peering. I'm personally running four
nodes with it enabled, two using my own custom patches, and another two using
ariad's patch:
https://github.com/bitcoin/bitcoin/pull/25600
I haven't seen a lot of non-opt-in doublespends get mined. But I have seen a
few now via my Alice OTS calendar. This can of course increase dramatically as
miners turn on full-rbf.
--
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/20221014/7d612ef5/attachment.sig>

2023-06-07 23:14:26 UTC

- reply

📅 Original date posted:2022-10-20
📝 Original message:On Tue, Oct 18, 2022 at 05:00:45PM +1000, Anthony Towns via bitcoin-dev wrote:
> For what it's worth, my guess is that releasing core with full rbf
> support and having you and Murch and others advocating for people to
> try it out, will mean that full RBF is usable on mainnet within two
> or three months, supported by perhaps 5%-20% hashpower, but probably
> still requiring special effort to actually find a peer that can relay
> full rbf txs to that hashpower (probably doing an addnode, despite the
> privacy implications). Even if that happens, I'm not super confident
> that it would mean people would actively steal from zeroconf businesses
> in any volume, though. It's not something I'd risk happening to me,
> but accepting zeroconf from strangers isn't something I'd risk anyway.
FWIW I'm not aware of any zeroconf accepting businesses where exploiting double
spends can be done without significant legal risk. Bitrefill has significant
legal risk, because pretty much everything you buy with Bitrefill can be traced
to your real world identity. ATMs have less risk. But I haven't seen an ATM
that accepts BTC without a confirmation in many years. Nor have I found a
non-KYC/AML in-person currency exchange service that would accept funds without a
confirmation (yes, I've had to wait 30 mins to get my cash before!). And all
the anonymous crypto-exchange websites like FixedFloat require a confirmation.
I have found AML/KYC in-person currency exchange services that would accept
zero conf. But of course, they had sufficient details on me to just call the
police if I double-spent them.
In practice, there are very few people who are actually affected by zeroconf
going away.
--
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/bitcoin-dev/attachments/20221020/3fd904e1/attachment.sig>

2023-06-07 23:14:26 UTC

- reply

📅 Original date posted:2022-10-20
📝 Original message:On Wed, Oct 19, 2022 at 03:17:51AM +0000, alicexbt via bitcoin-dev wrote:
> > And the
> > impression I got from the PR review club discussion more seemed like
> > devs making assumptions about businesses rather than having talked to
> > them (eg "[I] think there are fewer and fewer businesses who absolutely
> > cannot survive without relying on zeroconf. Or at least hope so").
>
> Even I noticed this since I don't recall the developers of the 3 main coinjoin implementations that are claimed to be impacted by opt-in RBF making any remarks.
FYI I personally asked Max Hillebrand from Wasabi about full-rbf last night.
He gave me permission to republish our conversation:
> Hey, I wanted to know if you had any comments on full-rbf re: wasabi?
Doesn't really affect us, afaik
The cj doesn't signal rbf right now
And I guess it's a DoS vector if any input double spent will be relayed after successful signing
But we have way bigger / cheaper DoS vectors that don't get "exploited"
So probably doesn't matter
Wasabi client handles replacements / reorgs gracefully, so should be alright
We don't yet "use" rbf in the sense of fee bumping tx, but we should / will eventually
I haven't asked Joinmarket yet. But the impact on their implementation should
be very similar.
--
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/bitcoin-dev/attachments/20221020/f687b805/attachment-0001.sig>

2023-06-07 23:12:21 UTC

- reply

📅 Original date posted:2022-08-01
📝 Original message:On Mon, Aug 01, 2022 at 01:19:05PM +0000, aliashraf.btc At protonmail wrote:
> > On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
> > like a hashcash-based alternative broadcast scheme.
> Hi Peter,
> I've been mulling the idea of attaching work to low fee txns, both as a compensation (e.g., in a sidechain, or an alt), and/or as a spam proof. Unfortunately, both suffer from ASICs:
> For spam proof case, the adversary can easily buy a used/obsolete device to produce lots of spam txns very cheaply, unless you put the bar very high, making it almost impossible for average users to even try.
> The compensation scenario is pretty off-topic, still, interesting enough for 1 min read:
> Wallets commit to the latest blockchain state in the transaction AND attach work.
> It is considered contribution to the security (illegitimate chains can't include the txn), hence isrewarded by fee discount/exemption depending on the offset of the state they've committed to (the closer, the better) and the amount of work attached.
> For this to work, block difficulty is calculated inclusive with the work embedded in the txns, it contains. Sophisticated and consequential, yet not infeasible per se.
>
> Unfortunately, this scheme is hard to balance with ASICs in the scene too, for instance, you can't subsidize wallets for their work like with a leverge, because miners can easily do it locally, seizing the subsidies for themselves, long story, not relevant just ignore it.
We're not talking about a consensus system here. Just a way to rate-limit
access to a broadcast network used by a small minority of nodes. It's
completely ok to simply change the PoW algorithm in the _highly_ unlikely event
someone bothers to build an ASIC for it. Since this isn't a consensu system,
it's totally ok if multiple versions of the scheme run 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/bitcoin-dev/attachments/20220801/e69f3291/attachment.sig>

2023-06-07 23:12:21 UTC

- reply

📅 Original date posted:2022-08-01
📝 Original message:On Sat, Jul 30, 2022 at 05:24:35PM +0000, alicexbt via bitcoin-dev wrote:
> However, I think developers should not make any changes in the default minimum fee rate required for relay. If there are incentives for users and miners to change it, they should use non-default value. In case, miners want to experiment with lower fee rate and see if this increases revenue they could try using it on odd dates (even dates remain default) for a month. We all could analyze how this worked for different mining pools and non-default value (lower or higher) could become normal in the future.
Without a way for lower-fee-rate transactions to get to those miners,
experiments like that are pointless.
If you want to propose things like this, propose a way to get non-standard txs
to miners, like a hashcash-based alternative broadcast scheme.
--
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/20220801/1fa155de/attachment.sig>

2023-06-07 23:11:45 UTC

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Tue, Jul 12, 2022 at 02:01:09AM +0200, James MacWhyte wrote:
> On Tue, Jul 12, 2022 at 12:26 AM Peter Todd <pete at petertodd.org> wrote:
>
> > Anyway, designing protocols for "price go up forever" hopium is a bad idea.
> >
>
> I'm quite disappointed that this is what you've reduced my argument to. The
> price doesn't need hopium; if it stays between where it is now and the all
> time high, that is enough to make mining rewards appealing.
>
> Anyway, once the LA dinner rush ends at 8PM it is already noon in Tokyo.
> The Pacific is big, but not *that* big.
>
> Certainly we should be designing protocols in anticipation of increased
> adoption, and not assuming the world will always be exactly as it is today?
We should design protocols that do reasonably well in *both* scenarios. Because
the future is unknown. Hell, I won't be surprised if further developments come
along that reduce demand for on-chain txs even further.
The fact is basing security budget in part on the total value of the coin being
secured very cleanly solves the problem of ensuring that there is sufficient
mining reward. Similarly, we also have to plan for the potential environment
where fee demand is very high. And we've done a good job of that, including
Lightning, replace-by-fee, etc.
--
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/20220711/4918b612/attachment-0001.sig>

2023-06-07 23:11:44 UTC

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Tue, Jul 12, 2022 at 12:19:06AM +0200, James MacWhyte via bitcoin-dev wrote:
> I think many of these discussions about the loss of the mining reward are
> fatally shortsighted.
>
> It's always daytime somewhere--when you talk about volume dropping at
> night, that simply means there is not enough activity outside the US. If
> Bitcoin continues its rise in price, mining rewards will still be
> substantial for decades to come. Given another 10 years, I'm fairly
> confident there will be enough adoption worldwide to make mining profitable
> around the clock, even if the mining reward were minimal.
Earth's population is extremely uneven over the earths surface, and the pacific
ocean is enormous and sparsely populated:
https://earthsky.org/earth/99-percent-worlds-population-receive-sunlight/
Anyway, designing protocols for "price go up forever" hopium is a bad idea.
--
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/20220711/cc885f97/attachment.sig>

2023-06-07 23:11:43 UTC

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 11:12:52AM -0700, Bram Cohen via bitcoin-dev wrote:
> If transaction fees came in at an even rate over time all at the exact same
> level then they work fine for security, acting similarly to fixed block
> rewards. Unfortunately that isn't how it works in the real world. There's a
> very well established day/night cycle with fees going to zero overnight and
> even longer gaps on weekends and holidays. If in the future Bitcoin is
> entirely dependent on fees for security (scheduled very strongly) and this
> pattern keeps up (overwhelmingly likely) then this is going to become a
> serious problem.
>
> What's likely to happen is that at first there will simply be no or very
> few blocks mined overnight. There are likely to be some, as miners at first
> turn off their mining rigs completely overnight then adopt the more
> sophisticated strategy of waiting until there are enough fees in the
> mempool to warrant attempting to make a block and only then doing it.
> Unfortunately the gaming doesn't end there. Eventually the miners with
> lower costs of operation will figure out that they can collectively reorg
> the last hour (or some time period) of the day overnight and this will be
> profitable. That's likely to cause the miners with more expensive
> operations to stop attempting mining the last hour of the day preemptively.
>
> What happens after that I'm not sure. There are a small enough number of
> miners with a quirky enough distribution of costs of operation and
> profitability that the dynamic is heavily dependent on those specifics, but
> the beginnings of a slippery slope to a mining cabal which reorgs everyone
> else out of existence and eventually 51% attacks the whole thing have
> begun. It even gets worse than that because once there's a cabal
> aggressively reorging anyone else out when they make a block other miners
> will shut down and rapidly lose the ability to quickly spin up again, so
> the threshold needed for that 51% attack will keep going down.
>
> In short, relying completely on transaction fees for security is likely to
> be a disaster. What we can say from existing experience is that having
> transaction fees be about 10% of rewards on average works well. It's enough
> to incentivize collecting fees but not so much that it makes incentives get
> all weird. 90% transaction fees is probably very bad. 50% works but runs
> the risk of spikes getting too high.
>
> There are a few possible approaches to fixes. One would be to drag most of
> east asia eastward to a later time zone thus smoothing out the day/night
> cycle but that's probably unrealistic. Another would be to hard fork in
> fixed rewards in perpetuity, which is slightly less unrealistic but still
> extremely problematic.
>
> Much more actionable are measures which smooth out fees over time.
Note that a tricky thing here is that smoothing out fees is made difficult by
the fact that users can by-pass the fee system by including anyone-can-spend
outputs in their transactions. Or worse, by simply paying large miners
out-of-band to get their txs confirmed. So any smothing scheme that tries to
smooth the market-based fees we already have will fail.
The only type of fee-smoothing scheme that is feasible is to smooth an entirely
separate category of fees that are made mandatory. For example, you could
achieve the economic impact of inflation by having a fixed value*time based fee
that goes to timelocked anyone-can-spend outputs in the coinbase to push the
fee forward to other miners.
Doing this is of course a gigantic accounting headache, and problematic for
existing L2 protocols, because you are reducing the value of txouts as they age
(demurrage). But at least it's a soft-fork.
Interestingly, if you look at transaction fees in blocks right now, people
regularly pay far higher transaction fees than necessary. There seem to be a
bunch of high value users, eg $1 million txs, without terrible fee estimation.
And I suspect the reason why this happens is simply that for a $1 million tx,
overpaying 100x with a $100 tx fee is irrelevant. Of course, this is also a
problem from the re-org point of view...
> Having
> wallets opportunistically collect their dust during times of low
> transaction fees would help and would save users on fees.
You're assuming wallets will even have dust to collect. With widespread use of
Lightning that will likely not be true. Indeed, with sufficiently efficient L2
solutions it's really unclear as to how much demand there will be for block
space.
--
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/20220711/6626ac18/attachment.sig>

2023-06-07 23:11:42 UTC

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via bitcoin-dev wrote:
> > What happens after that I'm not sure.
> >
>
> Miners will learn to create anyone-can-spend outputs to bribe other miners
> to build on their block rather than reorg it. (Due to the coinbase
> maturity, this will require some amount of floating capital.)
...and that's a disaster for mining centralization, because the smaller miners
need to pay larger bribes than larger miners. Not to mention having to keep
capital around to do 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/bitcoin-dev/attachments/20220711/d84b815b/attachment.sig>

2023-06-07 23:11:42 UTC

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 08:21:40PM -0400, Russell O'Connor via bitcoin-dev wrote:
> Oops, you are right. We need the bribe to be the output of the coinbase,
> but due to the maturity rule, it isn't really a bribe.
>
> Too bad coinbases cannot take other coinbase outputs as inputs to bypass
> the maturity rule.
>
> I guess that means the bribe has to be by leaving transactions in the
> mempool.
...and that's hardly a bribe. That's just being unable to mine competitively
because your operation is too small.
Anyway, I think all this is a good example of how mining being dependent on
fee-income makes mining much more complex, and harder to do as a small player.
Not good.
> Also your point about centralization pressure is well taken.
Thanks
--
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/20220711/bde354fc/attachment.sig>

2023-06-07 23:11:42 UTC

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 05:36:52PM -0400, Peter Todd via bitcoin-dev wrote:
> On Mon, Jul 11, 2022 at 04:35:02PM -0400, Russell O'Connor via bitcoin-dev wrote:
> > > What happens after that I'm not sure.
> > >
> >
> > Miners will learn to create anyone-can-spend outputs to bribe other miners
> > to build on their block rather than reorg it. (Due to the coinbase
> > maturity, this will require some amount of floating capital.)
>
> ...and that's a disaster for mining centralization, because the smaller miners
> need to pay larger bribes than larger miners. Not to mention having to keep
> capital around to do it.
Also, note how from a practical point of view, we'll need to add a new type of
tx that's only valid in a specific block, or other miners will just reorg those
anyone-can-spend outputs to steal them. It's not all that trivial to actually
do that... you'd have to have a signature that commits to the non-segwit part
of the coinbase outputs. Ugh.
--
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/20220711/bc25b2ad/attachment.sig>

2023-06-07 23:11:36 UTC

- reply

📅 Original date posted:2022-07-11
📝 Original message:On Mon, Jul 11, 2022 at 12:32:47PM +1000, Anthony Towns wrote:
> This isn't necessarily true: if the losses are due to a common cause,
> then they'll be heavily correlated rather than independent; for example
> losses could be caused by a bug in a popular wallet/exchange software
> that sends funds to invalid addresses, or by a war or natural disaster
> that damages key storage hardware. They're also not independent over
> time -- people improve their key storage habits over time; eg switching
> to less buggy wallets/exchanges, validating addresses before using them,
> using distributed multisig to prevent a localised disaster from being
> catastrophic.
People clearly continue to make downright irrational decisions about coin
security, doing things putting their entire crypto savings at risk for claimed
5% returns.
Even if people were rational, the coin loss rate would clearly reach a floor
because as the probability of coin loss goes down, bothering to spend extra
effort to decrease that already small chance is pointless. You mentioning black
swan events actually strengthens my point: at low coin loss rates the true loss
rate is dominated by black swan events. So it's pointless to go to extra effort
to prevent them.
Finally, you're forgetting that coin loss also includes *intentional* losses
from proof-of-sacrifice protocols. There are a number of examples on Bitcoin.
Again, they put a floor on how much coin loss could diminish.
> loss rate. If that's the case, then the rate at which funds are lost will
> vary chaotically, leading to "inflationary" periods in between events,
> and comparatively strong deflationary shocks when these events occur.
Give me an example of an *actual* inflation rate you expect to see, given a
disaster of a given magnitude.
If you actually do the numbers on this, you'll realize it takes absolutely
catastrophic black swan events that make WW2 look like a minor conflict to make
even insignificant inflation rate changes due to changes in lost coins.
--
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/20220711/9822e234/attachment.sig>

2023-06-07 23:11:28 UTC

- reply

📅 Original date posted:2022-07-10
📝 Original message:On Sun, Jul 10, 2022 at 02:17:36PM +0000, alicexbt via bitcoin-dev wrote:
> Hi ZmnSCPxj,
>
>
> > Thus, we should instead prepare for a future where the block subsidy must be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> > Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
>
> `consensus.nSubsidyHalvingInterval` for mainnet in [chainparams.cpp][1] can be decreased to 195000. This will reduce the number of halvings from 34 to 14 and subsidy will be 0 when it becomes less than 0.01 although not sure if this will be a soft fork.
What exactly would the benefit be of going through all the political headache
of a soft fork for what I assume you are thinking would be an insignificant
change in total miner revenue?
Or do you think total transaction fees at that point would be less than
0.01BTC?
--
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/20220710/c4acd405/attachment.sig>

2023-06-07 23:11:28 UTC

- reply

📅 Original date posted:2022-07-10
📝 Original message:On Sat, Jul 09, 2022 at 09:59:06PM +0000, ZmnSCPxj wrote:
> Good morning e, and list,
>
> > Yet you posted several links which made that specific correlation, to which I was responding.
> >
> > Math cannot prove how much coin is “lost”, and even if it was provable that the amount of coin lost converges to the amount produced, it is of no consequence - for the reasons I’ve already pointed out. The amount of market production has no impact on market price, just as it does not with any other good.
> >
> > The reason to object to perpetual issuance is the impact on censorship resistance, not on price.
>
> To clarify about censorship resistance and perpetual issuance ("tail emission"):
>
> * Suppose I have two blockchains, one with a constant block subsidy, and one which *had* a block subsidy but the block subsidy has become negligible or zero.
> * Now consider a censoring miner.
> * If the miner rejects particular transactions (i.e. "censors") the miner loses out on the fees of those transactions.
> * Presumably, the miner does this because it gains other benefits from the censorship, economically equal or better to the earnings lost.
> * If the blockchain had a block subsidy, then the loss the miner incurs is small relative to the total earnings of each block.
> * If the blockchain had 0 block subsidy, then the loss the miner incurs is large relative to the total earnings of each block.
> * Thus, in the latter situation, the external benefit the miner gains from the censorship has to be proportionately larger than in the first situation.
Now let's look at an actual, real-world, attempt to censor Bitcoin via mining:
https://petertodd.org/2016/mit-chainanchor-bribing-miners-to-regulate-bitcoin
The Chain Anchor model was to simply straight up bribe and coerce miners into
only accepting compliant transactions. That's only effective when a large % of
miners actually do that - if a small % do the effect on confirmation time is
miniscule. Obviously, censoring transactions is a significant threat to the
value of Bitcoin - and thus all your Bitcoin-only hashing equipment.
So how do you make a Chain Anchor attack cheaper? By reducing total mining
reward, and making it tied to transaction volume rather than the value of
Bitcoin as a whole.
> Basically, the block subsidy is a market distortion: the block subsidy erodes the value of held coins to pay for the security of coins being moved.
The block subsidy directly ties miner revenue to the total value of Bitcoin:
that's exactly how you want to incentivise a service that keeps Bitcoin secure.
> But the block subsidy is still issued whether or not coins being moved are censored or not censored.
> Thus, there is no incentive, considering *only* the block subsidy, to not censor coin movements.
> Only per-transaction fees have an incentive to not censor coin movements.
The strongest incentive not to censor is because it'll keep Bitcoin valuable.
Not some piddling transaction fees.
> Thus, we should instead prepare for a future where the block subsidy *must* be removed, possibly before the existing schedule removes it, in case a majority coalition of miner ever decides to censor particular transactions without community consensus.
> Fortunately forcing the block subsidy to 0 is a softfork and thus easier to deploy.
Absolutely not.
The historical reality of transaction fees is they've had huge swings, about
10x more volatile than total miner revenue. In the past three years they've
ranged from $8.4 million USD/30-day-average to as little as $140k/30-day-avg,
with the current amount being $370k/30-day-avg. That's a 60x difference.
Meanwhile miner revenue has ranged from $60 million/30-day-avg to $9
million/30-day-avg, a 7x difference.
https://www.blockchain.com/charts/fees-usd-per-transaction
We want mining to be is a boring, predictable, business that anyone can do,
with as little reward as possible to larger scale miners. That's what you need
for maximal decentralization. Making mining a sophisticated business reduces
the pool of entities that can profitably compete in it, and increases their
visibility to government regulation.
Additionally, we want mining to be predictable to avoid having large gluts of
unprofitable mining equipment laying around: mining equipment that could be
used to attack Bitcoin. Fee revenue is obviously doing a much worse job of
achieving that goal than subsidy revenue.
If transaction-fee-only mining was such a good idea, why hasn't any other coin
done 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/bitcoin-dev/attachments/20220710/ae1fdb12/attachment.sig>

2023-06-07 23:11:25 UTC

- reply

📅 Original date posted:2022-07-09
📝 Original message:On Sat, Jul 09, 2022 at 04:57:57PM +0200, John Tromp via bitcoin-dev wrote:
> > New blog post:
> > https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
>
> A Tail Emission is best described as disinflationary; the yearly
> supply inflation steadily decreases toward zero.
_Apparently_ inflation. True monetary inflation includes lost coins - both
intentionally and accidentally lost. It's quite possible that even with tail
emission Monero is currently a monetarily deflationary coin, as the lost coin
rate might be higher than the 0.8% apparent tail emission rate.
We just don't know. Doubly so in the case of monero where its privacy features
hide coin activity.
> > If an existing coin decides to implement tail emission as a means to fund security, choosing an appropriate emission rate is simple: decide on the maximum amount of inflation you are willing to have in the worst case, and set the tail emission accordingly.
>
> Any coin without a premine starts with infinite inflation. Bitcoin in
> its first 4 years had yearly inflation rates of inf, 100%, 50%, and
> 33%. So deciding on a maximum amount of inflation is deciding on a
> premine.
Hence why I specified an *existing* coin.
> While in the long term, a capped supply doesn't meaningfully differ
> from un uncapped supply [1], the 21M limit is central to Bitcoin's
> identity, and removing this limit results in something that can no
> longer be called Bitcoin.
Personally I think basing your identity on a technical point that isn't even
correct is stupid. And I suspect than when push comes to shove, if in ~10 years
or whatever Bitcoin turns out to be unstable without a reward, the market as a
whole will be happy to redefine Bitcoin to remove the 21M limit. Whether or not
it can do that fast enough to avoid Bitcoin dying first is an open question.
--
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/20220709/4c36e63b/attachment.sig>

2023-06-07 23:11:24 UTC

- reply

📅 Original date posted:2022-07-09
📝 Original message:On Sat, Jul 09, 2022 at 09:43:49PM +0400, naman naman wrote:
> Hi,
>
> This approach raises the obvious question : If someone hasn't had access to
> their coins in a long time (yrs, decades, however you want to define it) -
> and they wish to access/move them after such a time - isn't your proposal
> simply taking away their ability to do so? Some might call it : stealing
> their coins.
>
> How does one conclusively prove that "lost" coins are "lost forever"?
Re-read the article: https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
It has nothing to do with re-assigning ownership of coins.
--
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/20220709/5fcea1ad/attachment-0001.sig>

2023-06-07 23:11:24 UTC

- reply

📅 Original date posted:2022-07-09
📝 Original message:On Sat, Jul 09, 2022 at 08:24:51AM -0700, Eric Voskuil wrote:
> To clarify, price inflation is not caused by market production. Attributing the observed lack of inflation (eg fee %) to loss is an assumed relation.
My article is a mathematical proof that has nothing to do with observations of
inflation.
What I did is prove that if there is tail emission/fixed supply, the coin
supply will converge towards a fixed amount because the coin supply dependant
rate of coin loss balances out the fixed rate of coin production.
That proof has nothing to do with market dynamics and would happen in any
system, economic or not, with similar underlying dynamics.
--
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/20220709/c7521b4f/attachment-0001.sig>

2023-06-07 23:11:23 UTC

- reply

📅 Original date posted:2022-07-09
📝 Original message:On Sat, Jul 09, 2022 at 07:26:22AM -0700, Eric Voskuil wrote:
> > Due to lost coins, a tail emission/fixed reward actually results in a stable money supply. Not an (monetarily) inflationary supply.
>
> This observation is not a proof of lost coins, that is an assumption.
To be clear, are you claiming that there is no proof that coins are lost?
--
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/20220709/d3a4c87c/attachment.sig>

2023-06-07 23:11:21 UTC

- reply

📅 Original date posted:2022-07-09
📝 Original message:New blog post:
https://petertodd.org/2022/surprisingly-tail-emission-is-not-inflationary
tl;dr: Due to lost coins, a tail emission/fixed reward actually results in a
stable money supply. Not an (monetarily) inflationary supply.
...and for the purposes of reply/discussion, attached is the article itself in
markdown format:
---
layout: post
title: "Surprisingly, Tail Emission Is Not Inflationary"
date: 2022-07-09
tags:
- bitcoin
- monero
---
At present, all notable proof-of-work currencies reward miners with both a block
reward, and transaction fees. With most currencies (including Bitcoin) phasing
out block rewards over time. However in no currency have transaction fees
consistently been more than 5% to 10% of the total mining
reward[^fee-in-reward], with the exception of Ethereum, from June 2020 to Aug 2021.
To date no proof-of-work currency has ever operated solely on transaction
fees[^pow-tweet], and academic analysis has found that in this condition block
generation is unstable.[^instability-without-block-reward] To paraphrase Andrew
Poelstra, it's a scary phase change that no other coin has gone through.[^apoelstra-quote]
[^pow-tweet]: [I asked on Twitter](https://twitter.com/peterktodd/status/1543231264597090304) and no-one replied with counter-examples.
[^fee-in-reward]: [Average Fee Percentage in Total Block Reward](https://bitinfocharts.com/comparison/fee_to_reward-btc-eth-bch-ltc-doge-xmr-bsv-dash-zec.html#alltime)
[^instability-without-block-reward]: [On the Instability of Bitcoin Without the Block Reward](https://www.cs.princeton.edu/~arvindn/publications/mining_CCS.pdf)
[^apoelstra-quote]: [From a panel at TABConf 2021](https://twitter.com/peterktodd/status/1457066946898317316)
Monero has chosen to implement what they call [tail
emission](https://www.getmonero.org/resources/moneropedia/tail-emission.html):
a fixed reward per block that continues indefinitely. Dogecoin also has a fixed
reward, which they widely - and incorrectly - refer to as an "abundant" supply[^dogecoin-abundant].
[^dogecoin-abundant]: Googling "dogecoin abundant" returns dozens of hits.
This article will show that a fixed block reward does **not** lead to an
abundant supply. In fact, due to the inevitability of lost coins, a fixed
reward converges to a **stable** monetary supply that is neither inflationary
nor deflationary, with the total supply proportional to rate of tail emission
and probability of coin loss.
Credit where credit is due: after writing the bulk of this article I found out
that Monero developer [smooth_xmr](https://www.reddit.com/user/smooth_xmr/)
also observed that tail emission results in a stable coin supply
[a few years ago](https://www.reddit.com/r/Monero/comments/4z0azk/maam_28_monero_ask_anything_monday/d6sixyi/).
There's probably others too: it's a pretty obvious result.
<div markdown="1" class="post-toc">
# Contents
{:.no_toc}
0. TOC
{:toc}
</div>
## Modeling the Fixed-Reward Monetary Supply
Since the number of blocks is large, we can model the monetary supply as a
continuous function $$N(t)$$, where $$t$$ is a given moment in time. If the
block reward is fixed we can model the reward as a slope $$k$$ added to an
initial supply $$N_0$$:
$$
N(t) = N_0 + kt
$$
Of course, this isn't realistic as coins are constantly being lost due to
deaths, forgotten passphrases, boating accidents, etc. These losses are
independent: I'm not any more or less likely to forget my passphrase because
you recently lost your coins in a boating accident — an accident I probably
don't even know happened. Since the number of individual coins (and their
owners) is large — as with the number of blocks — we can model this loss as
though it happens continuously.
Since coins can only be lost once, the *rate* of coin loss at time $$t$$ is
proportional to the total supply *at that moment* in time. So let's look at the
*first derivative* of our fixed-reward coin supply:
$$
\frac{dN(t)}{dt} = k
$$
...and subtract from it the lost coins, using $$\lambda$$ as our [coin loss
constant](https://en.wikipedia.org/wiki/Exponential_decay):
$$
\frac{dN(t)}{dt} = k - \lambda N(t)
$$
That's a first-order differential equation, which can be easily solved with
separation of variables to get:
$$
N(t) = \frac{k}{\lambda} - Ce^{-\lambda t}
$$
To remove the integration constant $$C$$, let's look at $$t = 0$$, where the
coin supply is $$N_0$$:
$$
\begin{align}
N_0 &= \frac{k}{\lambda} - Ce^{-\lambda 0} = \frac{k}{\lambda} - C \\
C &= \frac{k}{\lambda} - N_0
\end{align}
$$
Thus:
$$
\begin{align}
N(t) &= \frac{k}{\lambda} - \left(\frac{k}{\lambda} - N_0 \right)e^{-\lambda t} \\
&= \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda} \right)e^{-\lambda t}
\end{align}
$$
## Long Term Coin Supply
It's easy to see that in the long run, the second half of the coin supply
equation goes to zero because $$\lim_{t \to \infty} e^{-\lambda t} = 0$$:
$$
\begin{align}
\lim_{t \to \infty} N(t) &= \lim_{t \to \infty} \left[ \frac{k}{\lambda} + \left(N_0 - \frac{k}{\lambda} \right)e^{-\lambda t} \right ] = \frac{k}{\lambda} \\
N(\infty) &= \frac{k}{\lambda}
\end{align}
$$
An intuitive explanation for this result is that in the long run, the initial
supply $$N_0$$ doesn't matter, because approximately all of those coins will
eventually be lost. Thus in the long run, the coin supply will converge towards
$$\frac{k}{\lambda}$$, the point where coins are created just as fast as they
are lost.
## Short Term Dynamics and Economic Considerations
Of course, the intuitive explanation for why supply converges to
$$\frac{k}{\lambda}$$, also tells us that supply must converge fairly slowly:
if 1% of something is lost per year, after 100 years 37% of the initial supply
remains. It's not clear what the rate of lost coins actually is in a mature,
valuable, coin. But 1%/year is likely to be a good guess — quite possibly less.
In the case of Monero, they've introduced tail emission at a point where it
represents a 0.9% apparent monetary inflation rate[^p2pool-tail]. Since the number of
previously lost coins, and the current rate of coin loss, is
unknown[^unknowable] it's not possible to know exactly what the true monetary
inflation rate is right now. But regardless, the rate will only converge
towards zero going forward.
[^unknowable]: Being a privacy coin with [shielded amounts](https://localmonero.co/blocks/richlist), it's not even possible to get an estimate of the total amount of XMR in active circulation.
[^p2pool-tail]: P2Pool operates [a page with real-time date figures](https://p2pool.io/tail.html).
If an existing coin decides to implement tail emission as a means to fund
security, choosing an appropriate emission rate is simple: decide on the
maximum amount of inflation you are willing to have in the worst case, and set
the tail emission accordingly. In reality monetary inflation will be even lower
on day zero due to lost coins, and in the long run, it will converge towards
zero.
The fact is, economic volatility dwarfs the effect of small amounts of
inflation. Even a 0.5% inflation rate over 50 years only leads to a 22% drop.
Meanwhile at the time of writing, Bitcoin has dropped 36% in the past year, and
gained 993% over the past 5 years. While this discussion is a nice excuse to
use some mildly interesting math, in the end it's totally pedantic.
## Could Bitcoin Add Tail Emission?
...and why could Monero?
Adding tail emission to Bitcoin would be a hard fork: a incompatible rule
change that existing Bitcoin nodes would reject as invalid. While Monero was
able to get sufficiently broad consensus in the community to implement tail
emission, it's unclear at best if it would ever be possible to achieve that for
the much larger[^btc-vs-xmr-market-cap] Bitcoin. Additionally, Monero has a
culture of frequent hard forks that simply does not exist in Bitcoin.
[^btc-vs-xmr-market-cap]: [As of writing](https://web.archive.org/web/20220708143920/https://www.coingecko.com/), the apparent market cap of Bitcoin is $409 billion, almost 200x larger than Monero's $2.3 billion.
Ultimately, as long as a substantial fraction of the Bitcoin community continue
to run full nodes, the only way tail emission could ever be added to Bitcoin is
by convincing that same community that it is a good idea.
## Footnotes
-------------- 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/20220709/7f1a65d7/attachment.sig>

2023-06-07 23:11:12 UTC

- reply

📅 Original date posted:2022-07-08
📝 Original message:On Tue, Jul 05, 2022 at 08:46:51PM +0000, alicexbt wrote:
> Hi Peter,
>
> > Note that Wasabi already has a DoS attack vector in that a participant can stop
> > participating after the first phase of the round, with the result that the
> > coinjoin fails. Wasabi mitigates that by punishing participating in future
> > rounds. Double-spends only create additional types of DoS attack that need to
> > be detected and punished as well - they don't create a fundamentally new
> > vulerability.
>
> I agree some DoS vectors are already mitigated however punishment in this case will be difficult because the transaction is broadcasted after signing and before coinjoin tx broadcast.
>
> Inputs are already checked multiple times for double spend during coinjoin round: https://github.com/zkSNACKs/WalletWasabi/pull/6460
>
> If all the inputs in the coinjoin transaction that failed to relay are checked and one or more are found to be spent later, what will be punished and how does this affect the attacker with thousands of UTXOs or normal users?
Point is, the attacker is thousands of UTXOs can also DoS rounds by simply
failing to complete the round. In fact, the double-spend DoS attack requires
more resources, because for a double-spend to be succesful, BTC has to be spent
on fees.
It's just a fact of life that a motivated attacker can DoS attack Wasabi by
spending money. That's a design choice that's serving them well so far.
--
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/20220708/99636bb4/attachment.sig>

2023-06-07 23:11:01 UTC

- reply

📅 Original date posted:2022-07-07
📝 Original message:On Thu, Jul 07, 2022 at 02:24:39PM +0100, John Carvalho via bitcoin-dev wrote:
> Billy,
>
> Proof of work and the difficulty adjustment function solve literally
> everything you are talking about already.
Unfortunately you are quite wrong: the difficulty adjustment function merely
adjusts for changes in the amount of observable, non-51%-attacking, hashing
power. In the event of a chain split, the difficulty adjustment function does
nothing; against a 51% attacker, the difficulty adjustment does nothing;
against a censor, the difficulty adjustment does nothing.
We should not imbue real technology with magical qualities.
> Bitcoin does not need active economic governanance by devs or meddlers.
Yes, active governance would definitely be an exploitable mechanism. On the
other hand, the status quo of the block reward eventually going away entirely
is obviously a risky state change too.
> > > There is also zero agreement on how much security would constitute such
> > an optimum.
> >
> > This is really step 1. We need to generate consensus on this long before
> > the block subsidy becomes too small. Probably in the next 10-15 years. I
> > wrote a paper
The fact of the matter is that the present amount of security is about 1.7% of
the total coin supply/year, and Bitcoin seems to be working fine. 1.7% is also
already an amount low enough that it's much smaller than economic volatility.
Obviously 0% is too small.
There's zero reason to stress about finding an "optimal" amount. An amount low
enough to be easily affordable, but non-zero, is fine. 1% would be fine; 0.5%
would probably be fine; 0.1% would probably be fine.
Over a lifetime - 75 years - 0.5% yearly inflation works out to be a 31% tax on
savings; 0.1% works out to be 7.2%
These are all amounts that are likely to be dwarfed by economic shifts.
--
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/20220707/22617f6b/attachment.sig>

2023-06-07 23:10:53 UTC

- reply

📅 Original date posted:2022-07-03
📝 Original message:On Wed, Jun 29, 2022 at 12:44:11PM +0200, Kate Salazar via bitcoin-dev wrote:
> > On an idealistic level, I agree with Keagan that it would make sense to
> > have "a balance of fees to that effect". I think doing that would be
> > technically/economically optimal. However, I think there is an enormous
> > benefit to having a cultural aversion to monetary inflation and the
> > consequences of convincing the bitcoin community that inflation is ok could
> > have unintended negative consequences (not to mention how difficult
> > convincing the community would be in the first place). There's also the
> > economic distortion that inflation causes that has a negative effect which
> > should also be considered. The idea of decaying utxo value is interesting
> > to consider, but it would not solve the economic distortion that
> > monetary inflation causes, because that distortion is a result of monetary
> > devaluation (which decaying utxos would be a form of). Then again, maybe in
> > this case the distortion of inflation would actually be a correction -
> > correcting for the externality of benefit received by holders. I'm
> > stream-of-consciousnessing a bit, but anyways, I suspect its not worth the
> > trouble to perfect the distribution of bitcoin blockchain security costs to
> > include holders. Tho, if I were to go back in time and influence how
> > bitcoin was designed, I might advocate for it.
> >
>
> Pool operators are free to request larger fees from older utxos, or from
> all utxos, or from newer utxos, at their judgement, looking at the
> blockspace demand census and at what the other pool operators are doing.
> This is not consensus, it's policy. It's not a technology problem, it's
> solved above in the social layer.
If pool operators can easily collude like you are proposing, we have a serious
problem with pool centralization.
What you would actually expect in a healthy Bitcoin ecosystem is for some pool
operators to defect, and them winding up mining those transactions for
market-based fees, eventually forcing the pool operators who are trying to
charge a discriminatory premium to give 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/20220703/dde11afb/attachment.sig>

2023-06-07 23:10:42 UTC

- reply

📅 Original date posted:2022-06-14
📝 Original message:On Tue, Jun 14, 2022 at 08:45:43AM -0400, Undiscussed Horrific Abuse, One Victim of Many via bitcoin-dev wrote:
> > The basic service that a timestamp service provides is “this content (or at
> > least a digest of this content) existed at least as early as this
> > timestamp.” It says nothing about how long before the timestamp the content
>
> OTS needlessly adds the requirement that the user publicize their .ots
> files to everybody who will make use of the timestamp.
>
> This does not provide the service you describe. It would be trivial to
> include enough cryptographic information in the original OP_RETURN, so
> as to obviate the need for publicizing the .ots file.
That approach does not scale. Via merkle trees, the OpenTimestamps system
routinely timestamps tens of thousands of messages with a single transaction:
https://petertodd.org/2016/opentimestamps-announcement#scalability-through-aggregation
Client-side validated .ots files are a necessary requirement to achieve this
scalability.
FWIW the most I've personally done is timestamped 750 million items from the
Internet Archive with a single transaction.
> If I send my .ots file to another party, a 4th party can replace it
> with their own, because there is no cryptographic pinning ensuring its
> contents. This changes the timestamp to one later, no longer proving
> the earliness of the data.
They can also simply delete their copy of the data, making it impossible to
prove anything about it.
--
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/bitcoin-dev/attachments/20220614/b7ea831b/attachment-0001.sig>

2023-06-07 23:10:39 UTC

- 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/bitcoin-dev/attachments/20220614/569cfb2a/attachment.sig>

2023-06-07 23:10:34 UTC

- reply

📅 Original date posted:2022-06-19
📝 Original message:On Fri, Jun 17, 2022 at 04:54:11AM +0000, alicexbt via bitcoin-dev wrote:
> > If they'reparties interested in implementing more RBF policy options in Bitcoin Core, I think they're free to propose suchchanges and invest the engineering effort to do so. If you're interested in advancing the state ofpolicy options in Bitcoin Core, there are a lot of interestingresourcesavailable and communities toencourage you in the learning process to contribute to the codebase [6].
>
> Thanks for sharing the link. I would love to see 5 RBF policies available to use in bitcoin core. I have already tried experimenting with a few on regtest and will try to open pull request if there are enough people interested to test it on other chains (testnet3, signet, mainnet)
I don't think more RBF policies in Bitcoin Core helps much. RBF policies aren't
very useful in isolation: unless you're getting your txs to other nodes/miners
via special peering efforts, the only reason to run an uncommon RBF policy is
to accomodate local software with obsolete expectations about mempool behavior.
That's why my full-RBF patch advertised a special service bit, and did
preferential peering with other nodes advertising that service bit.
Bitcoin Core isn't going to do that for every RBF policy. So there's no reason
we should try to accomodate a bunch of them.
I can understand a -fullrbf flag from a political point of view, in the process
of enabling full-RBF all the time. But there's no reason to go beyond that.
--
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/bitcoin-dev/attachments/20220619/e61b93ad/attachment.sig>

2023-06-07 23:10:28 UTC

- reply

📅 Original date posted:2022-06-15
📝 Original message:On Wed, Jun 15, 2022 at 02:53:58AM +0000, Luke Dashjr wrote:
> Bitcoin Knots still uses this service bit, FWIW (though due to a bug in some
> older versions, it wasn't signalled by default). There are probably at least
> 100 nodes with full RBF already.
Right. However it looks like you do not add NODE_REPLACE_BY_FEE to the list
returned by GetDesirableServiceFlags, so those nodes won't preferentially peer
with each other.
Also, if NODE_REPLACE_BY_FEE is added to the desirable service flags, it
ideally needs to be supported by the DNS seeds too. Currently it is not.
--
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/bitcoin-dev/attachments/20220614/db13f666/attachment-0001.sig>

2023-06-07 23:10:27 UTC

- reply

📅 Original date posted:2022-06-14
📝 Original message:On Mon, Jun 13, 2022 at 08:25:11PM -0400, Antoine Riard via bitcoin-dev wrote:
> If you're a node operator curious to play with full-rbf, feel free to
> connect to this node or spawn up a toy, public node yourself. There is a
> ##uafrbf libera chat if you would like information on the settings or
> looking for full-rbf friends (though that step could be automated in the
> future by setting up a dedicated network bit and reserving a few outbound
> slots for them).
I previously maintained a Bitcoin Core fork that did just that, using nServices
bit 26:
https://github.com/petertodd/bitcoin/commit/1cc1a46a633535c42394380b656d681258a111ac
IIRC I was using the code written to prefer segwit peers; I have no idea if a
similar approach is still easy to implement as I haven't worked on the Bitcoin
Core codebase for years.
--
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/bitcoin-dev/attachments/20220614/1f57403a/attachment.sig>

2023-06-07 23:10:05 UTC

- reply

📅 Original date posted:2022-06-19
📝 Original message:On Sun, Jun 12, 2022 at 07:16:49PM +0000, alicexbt wrote:
> Hi Peter,
>
> > Only because the block reward goes away. If it was made to continue
> > indefinitely - most likely with an inflation hard fork - demand for block space
> > would not be critical to Bitcoin's security.
>
>
> I am not completely against your proposal although 100% sure this will not have "consensus" to be implemented. I think if bitcoin doesn't have enough demand for block space, it should die. I will be sad if bitcoin doesn't exist but it should be a lesson for all the people opposing soft forks based on drama and politics instead of technical review.
>
> I don't see anything wrong with users paying 100x fees for opening and closing LN channels.
The PoW security of Bitcoin benefits all Bitcoin users, proportional to the
value of BTC they hold; if Bitcoin blocks aren't reliably created the value of
*all* BTC goes down. It doesn't make sense for the entire cost of that security
to be paid for on a per-tx basis. And there's a high chance paying for it on a
per-tx basis won't work anyway due to lack of consistent demand.
It would be extremely unfortunate if one of the very few decentralized ways to
store value died simply because we couldn't find a way to pay to keep it
secure.
--
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/bitcoin-dev/attachments/20220619/925b89c6/attachment.sig>

2023-06-07 23:10:04 UTC

- reply

📅 Original date posted:2022-06-12
📝 Original message:On Mon, Jun 06, 2022 at 09:02:18AM -0400, Erik Aronesty via bitcoin-dev wrote:
> Maintaining the security of the protocol is squarely the responsibility of
> the Bitcoin software and the core developers
>
> Continued demand for block space is critical for Bitcoin's security.
Only because the block reward goes away. If it was made to continue
indefinitely - most likely with an inflation hard fork - demand for block space
would not be critical to Bitcoin's security.
--
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/bitcoin-dev/attachments/20220611/af80f0d7/attachment.sig>

2023-06-07 23:07:52 UTC

- reply

📅 Original date posted:2022-04-24
📝 Original message:On April 22, 2022 11:03:51 AM GMT+02:00, Zac Greenwood via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>I like the maxim of Peter Todd: any change of Bitcoin must benefit *all*
>users. This means that every change must have well-defined and transparent
>benefits. Personally I believe that the only additions to the protocol that
>would still be acceptable are those that clearly benefit layer 2 solutions
>such as LN *and* do not carry the dangerous potential of getting abused by
>freeloaders selling commercial services on top of “free” eternal storage on
>the blockchain.
To strengthen your point: benefiting "all users" can only be done by benefiting layer 2 solutions in some way, because it's inevitable that the vast majority of users will use layer 2 because that's the only known way that Bitcoin can scale.

2023-06-07 23:04:39 UTC

- reply

📅 Original date posted:2022-02-18
📝 Original message:On Tue, Jan 18, 2022 at 02:57:30AM +0100, Prayank wrote:
> Hi Peter,
>
> > that current lacks compelling use-cases clearly beneficial to all users
>
> All the use cases shared in below links look compelling enough to me and we can do anything that a programmer could think of using such restrictions:
>
> https://utxos.org/uses/
>
> https://rubin.io/archive/
Again, what I said was "compelling use-cases _clearly_ beneficial to _all_
users", not just a small subset. I neither think the use-cases in those links
are clearly compelling in the current form, and they of course, don't benefit
all users. Indeed, the Drivechains use-case arguably *harms* all users, as
Drivechains is arguably harmful to the security of Bitcoin as a whole.
Similarly, the various new uses for on-chain transactions mentioned as a
use-case arguably harms all existing users by competing for scarce blockchain
space - note how ETH has quite high on chain fees for basic transactions,
because there are so many use-cases where the per-tx value can afford much
higher fees. That kind of expansion of use-case also arguably harms Bitcoin as
a whole by providing more fuel for a future contentious blocksize debate.
Bitcoin is an almost $1 trillion dollar system. We have to very carefully weigh
the benefits of making core consensus changes to that system against the risks.
Both for each proposal in isolation, as well as the precedent making that
change sets.
--
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/20220218/6499c346/attachment.sig>

2023-06-07 23:01:36 UTC

- reply

📅 Original date posted:2021-12-18
📝 Original message:On Sat, Dec 18, 2021 at 08:51:46AM -0800, Jeremy via bitcoin-dev wrote:
> Small idea:
>
> ease into getting rid of full-rbf by keeping the flag working, but make
> enforcement of non-replaceability something that happens n seconds after
> first seen.
>
> this reduces the ability to partition the mempools by broadcasting
> irreplaceable conflicts all at once, and slowly eases clients off of
> relying on non-RBF.
>
> we might start with 60 seconds, and then double every release till we get
> to 600 at which point we disable it.
Making replacability turn on _after_ an expiry time is reached has been
suggested before, IIRC by Matt Corallo. However I believe the approach of
enabling full-rbf _until_ a time is reached is clever and novel.
I'd suggest doing both at once. Long-running txs are certainly useful. But if a
tx hasn't been mined in a few blocks, it certainly can't be relied on for
zeroconf.
--
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/20211218/4f6f02f0/attachment-0001.sig>

2023-06-07 23:00:22 UTC

- reply

📅 Original date posted:2021-10-27
📝 Original message:On Tue, Oct 26, 2021 at 07:44:45PM -0400, Antoine Riard via bitcoin-dev wrote:
> Such a list of endpoints couldn't be static otherwise it's an artificial
> barrier to enter in the mining competition, and as such a centralization
> vector. Dynamic, trust-minimized discovery of the mining endpoints assumes
> an address-relay network, of which the robustness must be high enough
> against sophisticated sybil attacks. One current defense mechanism in core
> to achieve that is selecting outbound peers based in different /16 subnets
> as it's harder for an attacker to obtain IP addresses. Replicating this
> mechanism for the mining endpoints binds the mining topology to the
> Internet one, which is downgrading the mining competition.
I think a really simple way to put it is if we didn't have the mempool, it'd be
good to create a free service that got transactions to miners in an equal
opportunity, decentralized, way. A simple flood fill scheme would be a great
way to do that... at which point you've re-invented the mempool.
Nothing wrong with people running nodes that opt-out of transaction
broadcasting, and it may even make sense for such nodes to preferentially peer
with each other. But there's always going to be a need for a scheme like the
existing mempool, so might as well just keep it.
--
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/bitcoin-dev/attachments/20211027/237114b0/attachment.sig>

2023-06-07 18:20:57 UTC

- 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/bitcoin-dev/attachments/20191005/213e4e81/attachment.sig>

2023-06-07 18:20:57 UTC

- 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/bitcoin-dev/attachments/20191006/13e0402e/attachment.sig>

2023-06-07 18:20:19 UTC

- reply

📅 Original date posted:2019-08-16
📝 Original message:On Fri, Aug 16, 2019 at 11:23:37AM -0400, John Newbery via bitcoin-dev wrote:
> Once a consensus change has been activated and buried by sufficient work,
> we consider the height of that change to be historic fact. The exact
> activation method is no longer of practical interest. In some cases the
> cause of activation is not even decidable. For example, we know that segwit
> activated at height 481,824 but it's debatable whether that was due to BIP
> 9 version bits signaling, BIP 148 UASF, or a combination of the two.
I just wanted to elaborate on this excellent point:
This is debatable because Bitcoin is a decentralized, soft-forks are backwards
compatible, and it's very difficult if not impossible to measure the
preferences of economically significant nodes. Both the BIP9 version bits
signalling and the BIP 148 UASF had the same basic effect: enforce segwit.
Furthermore, the BIP 148 UASF rejected blocks that didn't signal via the BIP9
version bits.
We can observe the fact that 100% of known blocks produced after Aug 1st 2017
have complied with segwit rules, and the BIP9 signalling protocol for segwit.
But strictly speaking we don't really know why that happened. It's possible
that miners were running the BIP9 signalling Bitcoin Core release around that
time. It's also possible that miners were running UASF enforcing software.
It's possible there was a combination of both. Or even entirely different
software - remember that some miners produced segwit-valid blocks, but didn't
actually mine segwit transactions. Each scenario leads to the same externally
observable outcome.
Furthermore there's the question as to why miners were producing
segwit-compliant blocks: perhaps they thought the vast majority of economically
significant nodes would reject their blocks? Perhaps they just wanted to
enforce segwit?
These are all questions that have plausible answers, backed by evidence and
argument. But because Bitcoin is a decentralized network no authority can tell
you what the answers are.
--
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/bitcoin-dev/attachments/20190816/88afef25/attachment.sig>

2023-06-07 18:20:08 UTC

- reply

📅 Original date posted:2019-08-12
📝 Original message:On Wed, Aug 07, 2019 at 08:48:06AM -0500, Bryan Bishop via bitcoin-dev wrote:
> Hi,
>
> I have a proposal for implementing bitcoin vaults in a way that does not
> require any soft-forks or other software upgrades, although it could benefit
> from SIGHASH_NOINPUT which I'll describe later.
>
> I call them pre-signed vaults.
>
> Vault definition
> ================
>
> Here, a vault is defined as a transaction setup scheme that binds both the user
> and the attacker to always using a public observation and delay period before a
> weakly-secured hot key is allowed to arbitrarily spend coins. This is the same
> definition previously used[1]. During the delay period, there is an opportunity
> to initiate recovery/clawback which can either trigger deeper cold storage
> parameters or at least reset the delay period to start over again for the same
> keys.
So, I'll point out that I'd describe this a little bit differently:
The vault is a tx setup scheme that binds coins in such a way that they can
only be spent via a proof-of-publication *notification*, followed by a delay
period, during which coins can be recovered/clawed back.
The key difference being it's not important that this be a *public*
notification: that the public can see just happens to be an (unfortunate)
implementation detail. For example, you could imagine a system where the
"prepare to spend" tx is indistinguishable from any other transaction.
> One of the important components of this is the delete-the-key pre-signed
> transaction concept, where only a single transaction is (pre)signed before
> deleting the key. This is basically an emulation of a covenant and enforces a
> certain outcome.
It's important to note the reason this is possible is because any coin bound by
a convenant simply isn't a coin in the normal sense of the word, and is only
acceptable as payment directly if the receiver chooses to accept it.
To use an analogy many others have used, if you owe me $100, it's not
acceptable for you to pay me that $100 by dumping a time-locked safe on my
front lawn containing that $100 unless I've agreed to accept payment that way.
> * Nuclear abort key: Also unnecessary. This is a key for which only a single
> signed transaction will ever exist, and that single transaction will spend to a
> proof-of-burn key like 0x00. This key must be extremely secure, and if there
So to be clear, you're spending to a proof-of-burn _key_ because of the use of
adapter signatures for multisig? I'm not sure where the 0x00 is coming from
here.
Obviously normally to provably destroy coins you'd spend to an OP_RETURN
output, or if miner censorship was an issue, a pay-to-script-hash of an
OP_RETURN <nonce> script.
> Delete the key (for pre-signed transactions)
> ============================================
>
> The delete-the-key trick is simple. The idea is to pre-sign at least one
> transaction and then delete the private key, thus locking in that course of
> action.
>
> Unfortunately, delete-the-key doesn't really work for multisig scenarios
> because nobody would trust that anyone else in the scheme has actually deleted
> the secret. If they haven't deleted the secret, then they have full unilateral
> control to sign anything in that branch of the transaction tree. The only time
> that delete-the-key might be appropriate would be where the user who deletes
> the key and controls the key during the setup process is also the sole
> beneficiary of the entire setup with the multisig participants.
>
> Alternative fee rates are easier to deal with using delete-the-key, compared to
> a technique where the private key never existed which can only be used to sign
> one fee rate per public key, requiring an entirely new vault subtree for each
> alternative fee rate. With delete-the-key, the alternative fee rates are signed
> with the private key before the private key is deleted.
I think this could use a bit more analysis here: why can't delete the *keys*
work, with each party deleting a separate private key that's used in an m-of-n
fashion? So long as at least n-m+1 parties actually deleted their keys IIUC it
should be secure.
> Multisig gated by ECDSA pubkey recovery for provably-unknown keys
> =================================================================
>
> A group can participate in a multisig scheme with provably-unknown ECDSA keys.
> Instead of deleting the key, the idea is to agree on a blockheight and then
> select the blockhash (or some function of the chosen blockhash like
> H(H(H(blockhash)))) as the signature. Next, the group agrees on a transaction
> and they recover the public key from the signature using ECDSA pubkey recovery.
Could you explain in more detail why you're deriving this from a blockhash?
> Deploying exceedingly large scripts
> ===================================
>
> A brief interlude to share a somewhat obvious construction. I haven't seen this
> written down yet.
>
> Suppose there is a bitcoin script that someone is interested in using, but it
> far exceeds the size limits and sigop limits. To fix this, they would split up
> the script into usable chunks, and then use the delete-the-key mechanism (or
> the other one) to create an OR branch that is signable by a single key for
> which only a single signature is known. That new pre-signed transaction would
> spend to a script that has the output with the remainder of the script of
> interest. Re-vaulting or clawback clauses can be added to that output as well,
> but spending back to the original root script will only work by generating new
> scripts and keys (since the final hash isn't known until the whole tree is
> constructed, it's a dependency loop).
Clever!
--
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/bitcoin-dev/attachments/20190812/804c7e86/attachment.sig>

2023-06-07 18:17:24 UTC

- reply

📅 Original date posted:2019-04-13
📝 Original message:On Wed, Apr 03, 2019 at 02:39:32PM -0700, Dave Scotese via bitcoin-dev wrote:
> Every block's hash is smaller than the difficulty at that time. Block
> 569927's hash was VERY small (started with 21 zeros). The ratio of block
> hash to difficulty requirement (0xffffffff - difficulty, I think) could be
> used to identify blocks as "special," thus providing the opportunity to
> popularize unimportant but memorable-and-therefore-useful details. How can
> they be useful if they are unimportant? They are useful for sanity
> checking. For example, if the drunken bishop walk (or some other popular
> randomart) produced by block 569927's hash looked like a face, that would
> be memorable: "The block with the smallest hash in 2019 (maybe ever?) looks
> like a face after the drunken bishop walk."
As hashest smaller than the target have no significance to the Bitcoin
consensus I'd suggest not basing any features on that property. It's just as
arbitrary as picking whole decimal number block heights, yet has the additional
downsides of being harder to compute, and being likely to confuse people as to
how the Bitcoin consensus works.
--
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/bitcoin-dev/attachments/20190413/3b7d1bdd/attachment.sig>

2023-06-07 18:14:16 UTC

- reply

📅 Original date posted:2018-08-30
📝 Original message:On Thu, Aug 30, 2018 at 12:58:42PM +0530, shiva sitamraju via bitcoin-dev wrote:
> Hi,
>
> Testnet is now 1411795 blocks and a full sync is taking atleast 48 hours.
>
> Is a testnet reset scheduled in the next release or any reason not to do a
> reset ?
>
> Fast onboarding/lower disk overheads would be very much appreicated for
> testing purposes
Actually I'd advocate the opposite: I'd want testnet to be a *larger*
blockchain than mainnet to find size-related issues first.
Note that for testing regtest is often a better alternative, and you can setup
private regtest blockchains fairly easily and with good control over exactly
when and how blocks are created.
--
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/20180830/1e4ab762/attachment.sig>

2023-06-07 18:14:02 UTC

- reply

📅 Original date posted:2018-08-15
📝 Original message:On August 15, 2018 8:33:43 PM UTC, "Jorge Timón via bitcoin-dev" <bitcoin-dev at lists.linuxfoundation.org> wrote:
>op_return outputs can be pruned because they are not spendable.
>putting a hash on in the witness script data won't make things better
>(it would actually make them worse) and it definitely doesn't help
>"block size bloat".
>I think I'm missing some context, but if you're using op_return purely
>for timestamping I would recommend using pay 2 contract instead.
If you're *actually* just doing timestamping you're better off using OpenTimestamps. But many times people think they're just doing timestamping in reality mere timestamps are insufficient for the task.
Notably, this is something the Satoshi Bitcoin white paper gets wrong, incorrectly describing Bitcoin as a timestamping system: timestamping is insufficient to prevent double-spends.
--
https://petertodd.org 'peter'[:-1]@petertodd.org

2023-06-07 18:13:58 UTC

- reply

📅 Original date posted:2018-08-05
📝 Original message:On August 5, 2018 9:11:26 PM UTC, Lautaro Dragan via bitcoin-dev <bitcoin-dev at lists.linuxfoundation.org> wrote:
>Hi everyone,
>
>My name's Lautaro and I'm currently acting as Tech Lead of Po.et
><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>. At Po.et we
>use
>colored coins
><https://github.com/poetapp/node/blob/3c905bc5dbd3722ad39ac68041d9f2a099e5e84c/src/BlockchainWriter/ClaimController.ts#L101-L110>
>to
>store data on the Bitcoin blockchain with prefix "POET".
>
>I've read in an old version of the OP_RETURN entry of the bitcoin wiki
><https://en.bitcoin.it/w/index.php?title=OP_RETURN&oldid=62560> that
>*protocols
>wishing to claim OP_RETURN prefixes should use the standard Bitcoin
>Improvement Proposals process*.
>
>That entry seems to have changed recently
><https://en.bitcoin.it/wiki/OP_RETURN#OP_RETURN_prefixes>, no longer
>stating that we should follow the BIP process, and I haven't been able
>to
>find any existing BIP claiming an OP_RETURN prexif, but for the sake of
>thoroughness I'd like to ask for your help or confirmation here.
>
>Should we actually be using the BIP process to claim a prefix?
It's better if you don't use a prefix at all from a censorship resistance and anonymity perspective; you're application should not require a prefix for technical reasons.
--
https://petertodd.org 'peter'[:-1]@petertodd.org

2023-06-07 18:12:10 UTC

- reply

📅 Original date posted:2018-05-17
📝 Original message:On Thu, May 17, 2018 at 11:25:12AM -0400, Matt Corallo via bitcoin-dev wrote:
> BIP 158 currently includes the following in the "basic" filter: 1)
> txids, 2) output scripts, 3) input prevouts.
>
> I believe (1) could be skipped entirely - there is almost no reason why
> you'd not be able to filter for, eg, the set of output scripts in a
> transaction you know about and (2) and (3) may want to be split out -
> many wallets may wish to just find transactions paying to them, as
> transactions spending from their outputs should generally be things
> they've created.
So I think we have two cases where wallets want to find txs spending from their
outputs:
1) Waiting for a confirmation
2) Detecting theft
The former can be turned off once there are no expected unconfirmed
transactions.
As for the latter, this is probably a valuable thing for wallets to do. Modulo
reorgs, reducing the frequency that you check for stolen funds doesn't decrease
total bandwidth cost - it's one filter match per block regardless - but perhaps
the real-world bandwidth cost can be reduced by, say, waiting for a wifi
connection rather than using cellular 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/20180517/7732ad90/attachment-0001.sig>

2023-06-07 18:11:59 UTC

- reply

📅 Original date posted:2018-05-21
📝 Original message:On Mon, May 21, 2018 at 01:14:06PM +0930, Rusty Russell via bitcoin-dev wrote:
> Jim Posen <jim.posen at gmail.com> writes:
> > I believe OP_CSV with a relative locktime of 0 could be used to enforce RBF
> > on the spending tx?
>
> Marco points out that if the parent is RBF, this child inherits it, so
> we're actually good here.
>
> However, Matt Corallo points out that you can block RBF will a
> large-but-lowball tx, as BIP 125 points out:
>
> will be replaced by a new transaction...:
>
> 3. The replacement transaction pays an absolute fee of at least the sum
> paid by the original transactions.
>
> I understand implementing a single mempool requires these kind of
> up-front decisions on which tx is "better", but I wonder about the
> consequences of dropping this heuristic? Peter?
We've discussed this before: that rule prevents bandwidth usage DoS attacks on
the mempool; it's not a "heuristic". If you drop it, an attacker can repeatedly
broadcast and replace a series of transactions to use up tx relay bandwidth for
significantly lower cost than otherwise.
Though these days with relatively high minimum fees that may not matter.
--
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/bitcoin-dev/attachments/20180520/838d855d/attachment.sig>

2023-06-07 18:11:56 UTC

- reply

📅 Original date posted:2018-05-09
📝 Original message:On Thu, May 10, 2018 at 04:19:31AM +0800, Johnson Lau wrote:
>
>
> > On 10 May 2018, at 3:27 AM, Peter Todd <pete at petertodd.org> wrote:
> >
> > On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote:
> >> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
> >>
> >> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change.
> >>
> >> In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
> >
> > I don't think that will work, as a zero-fee tx won't get relayed even with
> > CPFP, due to the fact that we haven't yet implemented package-based tx
> > relaying.
> >
> > --
> > https://petertodd.org 'peter'[:-1]@petertodd.org
>
> My only concern is UTXO pollution. There could be a “CPFP anchor” softfork that outputs with empty scriptPubKey and 0 value are spendable only in the same block. If not spent immediately, they become invalid and are removed from UTXO. But I still think the best solution is a more flexible SIGHASH system, which doesn’t need CPFP at all.
I don't see any reason why UTXO pollution would be a special concern so long as
those outputs are subject to the same dust rules as any other output is.
--
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/bitcoin-dev/attachments/20180509/17714285/attachment.sig>

2023-06-07 18:11:55 UTC

- reply

📅 Original date posted:2018-05-09
📝 Original message:On Thu, May 10, 2018 at 01:56:46AM +0800, Johnson Lau via bitcoin-dev wrote:
> You should make a “0 fee tx with exactly one OP_TRUE output” standard, but nothing else. This makes sure CPFP will always be needed, so the OP_TRUE output won’t pollute the UTXO set
>
> Instead, would you consider to use ANYONECANPAY to sign the tx, so it is possible add more inputs for fees? The total tx size is bigger than the OP_TRUE approach, but you don’t need to ask for any protocol change.
>
> In long-term, I think the right way is to have a more flexible SIGHASH system to allow people to add more inputs and outputs easily.
I don't think that will work, as a zero-fee tx won't get relayed even with
CPFP, due to the fact that we haven't yet implemented package-based tx
relaying.
--
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/bitcoin-dev/attachments/20180509/dbad045c/attachment.sig>

2023-06-07 18:10:24 UTC

- reply

📅 Original date posted:2018-01-30
📝 Original message:On Mon, Jan 29, 2018 at 09:54:23PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> If times need to be accurate Bitcoin would need to use a rather
> different design (e.g. each block would commit to the observation time
> of the prior N blocks, and an iterative algorithm would solve for each
> blocks time and each miners local offset).
>
> IIRC open-timestamp calendar servers provide more precise
> time-stamping under the assumption that the calendar server is
> behaving correctly.
That is incorrect. The OpenTimestamps servers are specifically designed not to
be trusted, and thus do not make any cryptographically verifiable attestations
as to when timestamps were created.
In the future I expect to add a trusted timestamping scheme via disposable keys
to the OpenTimestamps protocol, but that work isn't yet complete:
https://lists.opentimestamps.org/pipermail/ots-dev/2017-May/000001.html
--
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/bitcoin-dev/attachments/20180130/ebd74375/attachment.sig>

2023-06-07 18:10:00 UTC

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Tue, Jan 23, 2018 at 09:31:00PM +0000, Gregory Maxwell wrote:
> On Mon, Jan 22, 2018 at 8:00 PM, Peter Todd via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Most transactions don't have change?! Under what circumstance? For most
> > use-cases the reverse is true: almost all all transactions have change, because
> > it's rare for the inputs to exactly math the requested payment.
>
> It's quite easy to get no change with a not-dumb algorithm selecting
> coins if you have a decent number of outputs well under the value
> you're paying.
>
> The number of ways n choose m combines grows exponentially, and you
> only need to get close enough over the right value so that you're
> paying excess fees equal or less than the cost of the change (which
> should include the current cost output itself as well as estimated
> cost of the future signature to spend it).
>
> Achow101 and Murch have code to implement an efficient algorithm for
> finding these solutions for Bitcoin core which will hopefully get in
> soon.
Oh, Bitcoin Core doesn't already do that? I though that was what the (rather
complex) knapsack code was supposed to be doing.
In any case, you're assuming that there actually are a large number of outputs.
That's not likely to be the case in most "consumer-like" use-cases where the
number of deposits into the wallet is relatively low compared to the number of
withdrawls as coins are spent in smaller amounts; that's the pattern most of my
Bitcoin usage follows, particularly as I keep the amount of funds in my hot
wallets low.
Having said that, Rhavar's usage patterns could easily be different; I'd be
completely wrong in the case of a payment service for instance where a large
number of deposits are aggregated into a smaller number of payments; that
use-case happens to be a particularly interesting one for using tx replacement
to add outputs, so my criticism was definitely premature.
--
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/bitcoin-dev/attachments/20180124/e656471f/attachment.sig>

2023-06-07 18:09:58 UTC

- reply

📅 Original date posted:2018-01-24
📝 Original message:On Tue, Jan 23, 2018 at 10:49:34PM +0000, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Jan 23, 2018 at 10:19 PM, Rhavar via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Interesting. I didn't think about this before, but it seems like bip125 is
> > rather incentive incompatible right now? If we're assuming a competitive
> > mempool, it really doesn't seem generally rational to accept a replacement
> > transaction of a lower fee rate.
>
> BIP125 replacement requires that the fee rate increases. The text of
> the BIP document is written in a confusing way that doesn't make this
> clear.
In fact I considered only requiring an increase in fee rate, based on the
theory that if absolute fee went down, the transaction must be smaller and thus
miners could overall earn more from the additional transactions they could fit
into their block. But to do that properly requires considering whether or not
that's actually true in the particular state the mempool as a whole happens to
be in, so I ditched that idea early on for the much simpler criteria of both a
feerate and absolute fee increase.
--
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/bitcoin-dev/attachments/20180124/473f7652/attachment.sig>

2023-06-07 18:09:56 UTC

- reply

📅 Original date posted:2018-01-22
📝 Original message:On Mon, Jan 22, 2018 at 12:40:31PM -0500, Rhavar via bitcoin-dev wrote:
> So my half-baked idea is very simple:
>
> Allow users to merge multiple unconfirmed transactions, stripping extraneous inputs and change as they go.
>
> This is currently not possible because of the bip125 rule:
> "The replacement transaction pays an absolute fee of at least the sum paid by the original transactions."
>
> Because the size of the merged transaction is smaller than the original transactions, unless there is a considerable feerate bump, this rule isn't possible to observe.
>
> I my question is: is it possible or reasonable to relax this rule? If this rule was removed in its entirety, does it introduce any DoS vectors? Or can it be changed to allow my use-case?
It would definitely introduce DoS vectors by making it much cheaper to use
relay bandwidth. You'd also be able to push others' txs out of the mempool.
> ---
> Full backstory: I have been trying to use bip125 (Opt-in Full Replace-by-Fee) to do "transaction merging" on the fly. Let's say that I owe John 1 bitcoin, and have promised to pay him immediately: Instead of creating a whole new transaction if I have an in-flight (unconfirmed) transaction, I can follow the rules of bip125 to create a replacement that accomplishes this goal.
>
> From a "coin selection" point of view, this was significantly easier than
> I had anticipated. I was able to encode the rules in my linear model and
> feed in all my unspent and in-flight transactions and it can solve it without difficulty.
>
> However, the real problem is tracking the mess. Consider this sequence of events:
> 1) I have unconfirmed transaction A
> 2) I replace it with B, which pays John 1 BTC
> 3) Transaction A gets confirmed
>
> So now I still owe John 1 BTC, however it's not immediately clear if
> it's safe to send to him without waiting $n transactions. However even
> for a small $n, this breaks my promise to pay him immediately.
>
> One possible solution is to only consider a transaction "replaceable" if it has change, so if the original transaction confirms -- payments can immediately be made that source the change, and provide safety in a reorg.
>
> However, this will only work <50% of the time for me (most transactions
> don't have change) and opens a pandora's box of complexity.
Most transactions don't have change?! Under what circumstance? For most
use-cases the reverse is true: almost all all transactions have change, because
it's rare for the inputs to exactly math the requested payment.
--
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/bitcoin-dev/attachments/20180122/84f99d15/attachment-0001.sig>

2023-06-07 18:09:31 UTC

- reply

📅 Original date posted:2018-01-12
📝 Original message:On Tue, Jan 09, 2018 at 12:43:48PM +0000, Perry Gibson wrote:
> >Trezor's "plausible deniability" scheme could very well result in you going to
> >jail for lying to border security, because it's so easy for them to simply
> >brute force alternate passwords based on your seeds. With that, they have proof
> >that you lied to customs, a serious offense.
> The passphrase scheme as I understand it allows a maximum of 50 characters
> to be used. Surely even with the HD seed, that search space is too large to
> brute force. Or is there a weakness in the scheme I haven't clocked?
While passphrases *can* be long, most user's aren't going to understand the
risk. For example, Trezors blog(1) doesn't make it clear that the passphrases
could be bruteforced and used as evidence against you, and even suggests the
contrary:
Since the passphrase is never saved on the device, this means that there is no
wrong passphrase. The device does not know which one you have chosen, and
therefore all of them are correct! Given the same seed, for each and every
letter combination used as a passphrase, a different wallet will be generated.
and:
Since there is no way to prove that there is any wallet beyond the ones
that you have admitted to, the “attacker” will have to be satisfied with
the revealed ones.
Also note how this blog doesn't mention anti-forensics: the wallet software
itself may leave traces of the other wallets on the computer. Have they really
audited it sufficiently to be sure this isn't the case?
1) https://blog.trezor.io/hide-your-trezor-wallets-with-multiple-passphrases-f2e0834026eb
--
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/bitcoin-dev/attachments/20180112/a6ee71b2/attachment.sig>

2023-06-07 18:09:29 UTC

- reply

📅 Original date posted:2018-01-08
📝 Original message:On Mon, Jan 08, 2018 at 07:40:38PM -0500, Rhavar via bitcoin-dev wrote:
> I think you're under-appreciating how useful the "plausible deniability". Someone I know was (solo) traveling to the United States when a border agent asked her to unlocked her phone; thumbed through her apps, ended up finding tinder and went through all her recent conversations to make sure she wasn't involved in any "pay for sex things".
>
> In the same light, I travel frequently and constantly have my trezor on me. If I am asked to unlock it, I will have no problems doing so (as refusal will no doubt lead to deportation) and showing my personal wallet (which sadly hasn't had much use since fees became ridiculous).
Trezor's "plausible deniability" scheme could very well result in you going to
jail for lying to border security, because it's so easy for them to simply
brute force alternate passwords based on your seeds. With that, they have proof
that you lied to customs, a serious offense.
I would strongly advise you not to use it in that situation.
--
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/bitcoin-dev/attachments/20180108/8bcd1aad/attachment.sig>

2023-06-07 18:09:27 UTC

- reply

📅 Original date posted:2018-01-08
📝 Original message:On Mon, Jan 08, 2018 at 02:00:17PM +0100, Pavol Rusnak wrote:
> On 08/01/18 13:45, Peter Todd wrote:
> > Can you explain _exactly_ what scenario the "plausible deniability" feature
> > refers to?
>
>
> https://doc.satoshilabs.com/trezor-user/advanced_settings.html#multi-passphrase-encryption-hidden-wallets
This sounds very dangerous. As Gregory Maxwell pointed out, the key derivation
function is weak enough that passphrases could be easily brute forced, at which
point the bad guys have cryptographic proof that you tried to lie to them and
cover up funds.
What model of human memory are you assuming here? What specifically are you
assuming is easy to remember, and hard to remember? What psychology research
backs up your assumptions?
--
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/bitcoin-dev/attachments/20180108/d27b5300/attachment.sig>

2023-06-07 18:09:27 UTC

- reply

📅 Original date posted:2018-01-08
📝 Original message:On Tue, Jan 09, 2018 at 09:26:17AM +1100, Ben Kloester wrote:
> > This sounds very dangerous. As Gregory Maxwell pointed out, the key
> derivation
> > function is weak enough that passphrases could be easily brute forced
>
> So you are essentially imagining that a perpetrator will combine the
> crypto-nerd fantasy (brute forcing the passphrase) *with* the 5-dollar
> wrench attack, merging both panes of Randall Munroe's comic? Seems
> vanishingly unlikely to me - attackers are generally either the wrench
> type, or the crypto-nerd type.
We're talking about seeds here, not hardware wallets.
For a hardware wallet theft scenario, if you're worried about muggers you can
make the hardware have secret accounts with different seeds, *without* risking
user funds getting lost - a much more likely scenario - due to mistyped
passwords.
In any case, even if you were to do this type of design, a much better idea is
to use a checksum by default to reject invalid passwords, while having an
advanced-use-only option to override that checksum. The virtual file encryption
filesystem encfs does exactly this with its --anykey flag. This allows advanced
users to do their thing, while protecting the majority of users for whome this
feature is dangerous.
--
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/bitcoin-dev/attachments/20180108/32a295b0/attachment-0001.sig>

2023-06-07 18:09:26 UTC

- reply

📅 Original date posted:2018-01-08
📝 Original message:On Mon, Jan 08, 2018 at 01:39:20PM +0100, Pavol Rusnak via bitcoin-dev wrote:
> > The construction also
> > will silently result in the user getting a different private key if
> > they enter the wrong passphrase-- which could lead to funds loss.
>
> Again, this is by design and it is main point why plausible deniability
> is achieved both in BIP39 and SLIP39. If we used a different
> construction we'd loose plausible deniability.
Can you explain _exactly_ what scenario the "plausible deniability" feature
refers to?
--
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/bitcoin-dev/attachments/20180108/a83273e6/attachment.sig>

2023-06-07 18:07:24 UTC

- reply

📅 Original date posted:2017-11-06
📝 Original message:On Wed, Nov 01, 2017 at 05:48:27AM +0000, Devrandom via bitcoin-dev wrote:
Some quick thoughts...
> Hi all,
>
> Feedback is welcome on the draft below. In particular, I want to see if
> there is interest in further development of the idea and also interested in
> any attack vectors or undesirable dynamics.
>
> (Formatted version available here:
> https://github.com/devrandom/btc-papers/blob/master/aux-pow.md )
>
> # Soft-fork Introduction of a New POW
First of all, I don't think you can really call this a soft-fork; I'd call it a
"pseudo-soft-fork"
My reasoning being that after implementation, a chain with less total work than
the main chain - but more total SHA256^2 work than the main chain - might be
followed by non-supporting clients. It's got some properties of a soft-fork,
but it's security model is definitely different.
> ### Aux POW intermediate block
>
> Auxiliary POW blocks are introduced between normal blocks - i.e. the chain
> alternates between the two POWs.
> Each aux-POW block points to the previous normal block and contains
> transactions just like a normal block.
> Each normal block points to the previous aux-POW block and must contain all
> transactions from the aux-POW block.
Note how you're basically proposing for the block interval to be decreased,
which has security implications due to increased orphan rates.
> ### Heaviest chain rule change
>
> This is a semi-hard change, because non-upgraded nodes can get on the wrong
> chain in case of attack. However,
Exactly! Not really a 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: 488 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20171106/daf2333b/attachment-0001.sig>

2023-06-07 18:06:36 UTC

- reply

📅 Original date posted:2017-09-29
📝 Original message:On Thu, Sep 28, 2017 at 07:45:02PM -0700, Mark Friedenbach wrote:
>
>
> > On Sep 28, 2017, at 7:02 PM, Peter Todd <pete at petertodd.org> wrote:
> >
> >> On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote:
> >> Unlike other proposed fixes to the fee model, this is not trivially
> >> broken by paying the miner out of band. If you pay out of band fee
> >> instead of regular fee, then your transaction cannot be included with
> >> other regular fee paying transactions without the miner giving up all
> >> regular fee income. Any transaction paying less fee in-band than the
> >> otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate
> >> difference fee to make up for that lost income. So out of band fee is
> >> only realistically considered when it pays on top of a regular feerate
> >> paying transaction that would have been included in the block anyway.
> >> And what would be the point of that?
> >
> > This proposed fix is itself broken, because the miner can easily include *only*
> > transactions paying out-of-band, at which point the fee can be anything.
>
> And in doing so either reduce the claimable income from other transactions (miner won’t do that), or require paying more non-rebateable fee than is needed to get in the block (why would the user do that?)
>
> This is specifically addressed in the text you quoted.
I specifically outlined a scenario where that text isn't relevant: *all*
transaction in a block can be paying out of band.
> > Equally, miners can provide fee *rebates*, forcing up prices for everyone else
> > while still allowing them to make deals.
>
> Discounted by the fact rebates would not be honored by other miners. The rebate would have to be higher than what they could get from straight fee collection, making it less profitable than doing nothing.
You're making the incorrect assumption that all transactions have to be
broadcast publicly; they don't.
> > Also, remember that you can pay fees via anyone-can-spend outputs, as miners
> > have full ability to control what transactions end up spending those outputs.
>
> You’d still have to pay the minimum fee rate of the other transactions or you’d bring down the miners income. Otherwise this is nearly the same cost as the rebate fee, since they both involve explicit outputs claimed by the miner, but the rebate goes back to you. So why would you not want to do that instead?
>
> A different way of looking at this proposal is that it creates a penalty for out of band payments.
It certainly does not. It simply adds another level of complexity and overhead
to the out-of-band payment situation, which is not desirable. If we can't
eliminate out of band payments entirely, we do not want to make the playing
field of them even more unbalanced than it already is.
This is a typical academic proposal that only considers first order effects
while ignoring second order effects.
--
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/bitcoin-dev/attachments/20170928/830d78cd/attachment.sig>

2023-06-07 18:06:35 UTC

- reply

📅 Original date posted:2017-09-28
📝 Original message:On Thu, Sep 28, 2017 at 06:06:29PM -0700, Mark Friedenbach via bitcoin-dev wrote:
> Unlike other proposed fixes to the fee model, this is not trivially
> broken by paying the miner out of band. If you pay out of band fee
> instead of regular fee, then your transaction cannot be included with
> other regular fee paying transactions without the miner giving up all
> regular fee income. Any transaction paying less fee in-band than the
> otherwise minimum fee rate needs to also provide ~1Mvbyte * fee rate
> difference fee to make up for that lost income. So out of band fee is
> only realistically considered when it pays on top of a regular feerate
> paying transaction that would have been included in the block anyway.
> And what would be the point of that?
This proposed fix is itself broken, because the miner can easily include *only*
transactions paying out-of-band, at which point the fee can be anything.
Equally, miners can provide fee *rebates*, forcing up prices for everyone else
while still allowing them to make deals.
Also, remember that you can pay fees via anyone-can-spend outputs, as miners
have full ability to control what transactions end up spending those outputs.
The fact these countermeasures are all likely to be implemented - all of which
harm the overall ecosystem by reducing visibility of fees and making it harder
to compete with centralized miners - makes me very dubious about that proposal.
--
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/bitcoin-dev/attachments/20170928/84259421/attachment.sig>

2023-06-07 18:06:34 UTC

- reply

📅 Original date posted:2017-09-28
📝 Original message:On Fri, Sep 29, 2017 at 01:53:55AM +0000, Matt Corallo via bitcoin-dev wrote:
> I'm somewhat curious what the authors envisioned the real-world implications of this model to be. While blindly asking users to enter what they're willing to pay always works in theory, I'd imagine in such a world the fee selection UX would be similar to what it is today - users are provided a list of options with feerates and expected confirmation times from which to select. Indeed, in a world where users pay a lower fee if they paid more than necessary fee estimation could be more willing to overshoot and the UX around RBF and CPFP could be simplified greatly, but I'm not actually convinced that it would result in higher overall mining revenue.
Note too that the fee users are willing to pay often changes over time.
My OpenTimestamps service is a perfect example: getting a timestamp confirmed
within 10 minutes of the previous one has little value to me, but if the
previous completed timestamp was 24 hours ago I'm willing to pay significantly
more money because the time delay is getting significant enough to affect the
trustworthyness of the entire service. So the fee selection mechanism is
nothing more than a RBF-using loop that bumps the fee every time a block gets
mined w/o confirming my latest transaction.
This kind of time sensitivity is probably true of a majority of Bitcoin
use-cases, with the caveat that often the slope will be negative eventually:
after a point in time completing the transaction has no value.
--
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/bitcoin-dev/attachments/20170928/054c801c/attachment.sig>

2023-06-07 18:06:28 UTC

- reply

📅 Original date posted:2017-09-28
📝 Original message:On Thu, Sep 28, 2017 at 03:43:05PM +0300, Sjors Provoost via bitcoin-dev wrote:
> Andreas Schildbach wrote:
> > This feels redundant to me; the payment protocol already has an
> > expiration time.
>
> The BIP-70 payment protocol has significant overhead and most importantly requires back and forth. Emailing a bitcoin address or printing it on an invoice is much easier, so I would expect people to keep doing that.
The BIP-70 payment protocol used via BIP-72 URI's is insecure, as payment qr
codes don't cryptographically commit to the identity of the merchant, which
means a MITM attacker can redirect the payment if they can obtain a SSL cert
that the wallet accepts.
For example, if I have a wallet on my phone and go to pay a
merchant, a BIP-72 URI will look like the following(1):
bitcoin:mq7se9wy2egettFxPbmn99cK8v5AFq55Lx?amount=0.11&r=https://merchant.com/pay.php?h%3D2a8628fc2fbe
A wallet following the BIP-72 standard will "ignore the bitcoin
address/amount/label/message in the URI and instead fetch a PaymentRequest
message and then follow the payment protocol, as described in BIP 70."
So my phone will make a second connection - likely on a second network with a
totally different set of MITM attackers - to https://merchant.com
In short, while my browser may have gotten the correct URL with the correct
Bitcoin address, by using the payment protocol my wallet is discarding that
information and giving MITM attackers a second chance at redirecting my payment
to them. That wallet is also likely using an off-the-shelf SSL library, with
nothing other than an infrequently updated set of root certificates to use to
verify the certificate; your browser has access to a whole host of better
technologies, such as HSTS pinning, certificate transparency, and frequently
updated root certificate lists with proper revocation (see Symantec).
As an ad-hoc, unstandardized, extension Android Wallet for Bitcoin at least
supports a h= parameter with a hash commitment to what the payment request
should be, and will reject the MITM attacker if that hash doesn't match. But
that's not actually in the standard itself, and as far as I can tell has never
been made into a BIP.
As-is BIP-72 is very dangerous and should be depreciated, with a new BIP made
to replace it.
1) As an aside, it's absolutely hilarious that this URL taken straight from
BIP-72 has the merchant using PHP, given its truly terrible track record for
security.
--
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/bitcoin-dev/attachments/20170928/09e0db5f/attachment.sig>