<unnamed>

Public Key

npub1m230cem2yh3mtdzkg32qhj73uytgkyg5ylxsu083n3tpjnajxx4qqa2np2

Profile Code

nprofile1qqsd4ghuva4ztca4k3tyg4qte0g7z95tzy2z0ngw8ncec4sef7err2spz3mhxue69uhhyetvv9ujuerpd46hxtnfduqs6amnwvaz7tmwdaejumr0ds3yundj

Publishing to

relay.damus.io

nos.lol

Last Notes

2023-08-05 23:58:15 CEST

- 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-02 12:19:21 CEST

- 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 17:59:57 CEST

- 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-09 15:08:57 CEST

- 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 15:05:09 CEST

- 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 15:05:08 CEST

- 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 15:05:08 CEST

- 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 15:04:34 CEST

- 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 14:56:13 CEST

- 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-08 01:19:27 CEST

- 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-08 01:19:25 CEST

- 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-08 01:19:18 CEST

- 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-08 01:19:17 CEST

- 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-08 01:19:17 CEST

- 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-08 01:19:16 CEST

- 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-08 01:18:56 CEST

- 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-08 01:18:55 CEST

- 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-08 01:18:55 CEST

- 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-08 01:18:54 CEST

- 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-08 01:18:34 CEST

- 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-08 01:17:26 CEST

- 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-08 01:17:25 CEST

- 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-08 01:17:12 CEST

- 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-08 01:16:53 CEST

- 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-08 01:16:18 CEST

- 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-08 01:14:46 CEST

- 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-08 01:14:45 CEST

- 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-08 01:14:31 CEST

- 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-08 01:14:26 CEST

- 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-08 01:14:26 CEST

- 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-08 01:12:21 CEST

- 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-08 01:12:21 CEST

- 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-08 01:11:43 CEST

- 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-08 01:11:42 CEST

- 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-08 01:11:42 CEST

- 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-08 01:11:42 CEST

- 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-08 01:11:36 CEST

- 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-08 01:11:28 CEST

- 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-08 01:11:25 CEST

- 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-08 01:11:24 CEST

- 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-08 01:11:24 CEST

- 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-08 01:11:23 CEST

- 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-08 01:11:12 CEST

- 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-08 01:10:53 CEST

- 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-08 01:10:42 CEST

- 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-08 01:10:34 CEST

- 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-08 01:10:05 CEST

- 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-08 01:10:04 CEST

- 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-08 01:01:36 CEST

- 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 20:20:57 CEST

- 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 20:20:57 CEST

- 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 20:20:08 CEST

- 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 20:17:24 CEST

- 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 20:14:16 CEST

- 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 20:14:02 CEST

- 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 20:13:58 CEST

- 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 20:12:10 CEST

- 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 20:11:56 CEST

- 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 20:11:55 CEST

- 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 20:10:24 CEST

- 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 20:09:58 CEST

- 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 20:09:56 CEST

- 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 20:09:31 CEST

- 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 20:09:27 CEST

- 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 20:09:27 CEST

- 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 20:07:24 CEST

- 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 20:06:36 CEST

- 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 20:06:28 CEST

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

2023-06-07 20:06:23 CEST

- reply

📅 Original date posted:2017-09-28
📝 Original message:On Thu, Sep 28, 2017 at 12:58:30AM +0000, Gregory Maxwell wrote:
> On Wed, Sep 27, 2017 at 4:06 PM, Peter Todd via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Re-use of old addresses is a major problem, not only for privacy, but also
> > operationally: services like exchanges frequently have problems with users
> > sending funds to addresses whose private keys have been lost or stolen; there
>
> When Pieter and I were working on Bech32 we specifically designed for
> error correcting codes that had good performance for longer lengths
> than we technically needed specifically to incorporate things like
> dates and explicit amounts.
>
> (explicit amounts so that typos and bit flips in amounts displayed or
> in memory couldn't result in sending the wrong amount)
>
> But we also thought that also adding those features at the same time
> would retard adoption-- both due to debating over the encodings and
> because handling would result in different software requirements and
> layering, so you couldn't just drop them in.
Notably, even something as simple as adding a new type of confirmation window
that might be needed is a big chance to UI logic.
> Doubly unfortunately, people have even deployed BIP173 already (prior
> to it even having much peer review or being adopted by its own
> authors), so I think a rethink now wouldn't be timely (I mean as a
> replacement to BIP173 rather than an additional format). :(
Yeah, I just noticed Pieter Wuille's BIP173-including segwit pull-req - that's
a lot of code that would get touched by this proposal, so it's likely too late
in the process.
> But I do support the idea.
>
> One thing to keep in mind is that address format linked fields are
> most efficient if they're multiples of 5 bits. Perhaps use 1 bit to
> indicate an embedded amount and 19 bits of 1 day precision, resulting
> in a 1435 year span.
What do you mean by "an embedded amount"?
> Keep in mind that high precision of the expiration times is asking the
> sender to have a higher precision of idea of the time, date only is
> kinda nice. I think shorter expiration times are unlikely to be
> useful due to clock skew-- you can't assume a signer has any access to
> the Bitcoin network at all.
I'm inclined to agree as well. Also, Bitcoin payments themselves are inherently
imprecise, because blocks aren't found on a regular interval - Coinbase's "10
minute" payment expiry window is odd from that point of view.
Having said that, you'd want a resolution more precise than what you'd expect
timeouts to be set at, to avoid UI "fencepost" oddity; if I want to set a 1 day
timeout, users shouldn't see either 1 or 2 days depending on exactly which way
it happened to be rounded that particular time..
--
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/04ab3f7f/attachment.sig>

2023-06-07 20:06:23 CEST

- reply

📅 Original date posted:2017-09-27
📝 Original message:On Wed, Sep 27, 2017 at 12:06:54PM -0400, Peter Todd via bitcoin-dev wrote:
> Being just an expiration time, seconds-level resolution is unnecessary, and
> may give the wrong impression. I'd suggest either:
>
> 1) Hour resolution - 2^24 hours = 1914 years
> 2) Month resolution - 2^16 months = 5458 years
Just remembered: it's notable how Coinbase has a 10 minute timeout on their
payment window, which is in effect a 10 minute expiry time for the address.
Presumably they'd make use of this feature if it existed.
--
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/20170927/95cbee53/attachment.sig>

2023-06-07 20:06:20 CEST

- reply

📅 Original date posted:2017-09-27
📝 Original message:On Wed, Sep 27, 2017 at 12:03:44PM -0700, Mark Friedenbach wrote:
> While there is a lot that I would like to comment on, for the moment I will just mention that you should consider using the 17 bit relative time format used in CSV as an offset from the birthdate of the address, a field all addresses should also have.
Why should addresses have a birthdate? I don't see why that information would
be relevant to the person sending funds, and it could pose a privacy risk.
--
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/20170927/b77a85ef/attachment.sig>

2023-06-07 20:06:19 CEST

- reply

📅 Original date posted:2017-09-27
📝 Original message:Re-use of old addresses is a major problem, not only for privacy, but also
operationally: services like exchanges frequently have problems with users
sending funds to addresses whose private keys have been lost or stolen; there
are multiple examples of exchanges getting hacked, with users continuing to
lose funds well after the actual hack has occured due to continuing deposits.
This also makes it difficult operationally to rotate private keys. I personally
have even lost funds in the past due to people sending me BTC to addresses that
I gave them long ago for different reasons, rather than asking me for fresh
one.
To help combat this problem, I suggest that we add a UI-level expiration time
to the new BIP173 address format. Wallets would be expected to consider
addresses as invalid as a destination for funds after the expiration time is
reached.
Unfortunately, this proposal inevitably will raise a lot of UI and terminology
questions. Notably, the entire notion of addresses is flawed from a user point
of view: their experience with them should be more like "payment codes", with a
code being valid for payment for a short period of time; wallets should not be
displaying addresses as actually associated with specific funds. I suspect
we'll see users thinking that an expired address risks the funds themselves;
some thought needs to be put into terminology.
Being just an expiration time, seconds-level resolution is unnecessary, and
may give the wrong impression. I'd suggest either:
1) Hour resolution - 2^24 hours = 1914 years
2) Month resolution - 2^16 months = 5458 years
Both options have the advantage of working well at the UI level regardless of
timezone: the former is sufficiently short that UI's can simply display an
"exact" time (though note different leap second interpretations), while the
latter is long enough that rounding off to the nearest day in the local
timezone is fine.
Supporting hour-level (or just seconds) precision has the advantage of making
it easy for services like exchanges to use addresses with relatively short
validity periods, to reduce the risks of losses after a hack. Also, using at
least hour-level ensures we don't have any year 2038 problems.
Thoughts?
--
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/20170927/7f7c4bfb/attachment.sig>

2023-06-07 20:05:33 CEST

- reply

📅 Original date posted:2017-09-07
📝 Original message:On Thu, Sep 07, 2017 at 09:47:16AM -0700, Jonas Schnelli via bitcoin-dev wrote:
> Thanks for the proposal.
>
> Three points it could see as possible improvements:
>
> 1.
> From what I know, the exact birthday in seconds doesn’t matter that much therefore it may be possible to just use 13 or 16bits to create a representation in week from 2009-01-09 00:00 UTC. 13bits would give you 157 years.
> Always round down to the beginning of the week when the key was created.
> But not sure if it’s worth to save ~two bytes for that.
> Also not sure if the key-birthday in seconds could have a security or privacy implication (week maybe better).
Note how private key birthday is a potential privacy issue in certain cases.
Rare of course, because usually you don't release your private keys! But users
will on occasion have those keys be compromised.
Personally, I'd advocate rounding down to month-level resolution, as that
should be both enough to handle any likely reorg scenario, and it's still a
precision that won't add much extra scanning ot any reasonably old (~1yr)
wallet.
Note also how if transactions created with private keys in a seed use
nLockTime, you can ensure coins won't exist in a block older than the seed
birthday by simply ensuring that nLockTime is set to a more recent date then
that birthday under all circumstances.
--
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/20170907/08ad4b1a/attachment.sig>

2023-06-07 20:03:24 CEST

- reply

📅 Original date posted:2017-06-19
📝 Original message:On Tue, Jun 20, 2017 at 02:01:45AM +0800, Wang Chun via bitcoin-dev wrote:
> There has been proposal to change the PoW in case of potential 51% attacks
> from malicious miners during a fork. But such a change in PoW renders
> multi-billion-dollar of ASIC into worthless. which hurts economy so much
> and the average innocent mining users. I would propose, instead of PoW
> change, we could change the system to the same double sha256 PoW but mix it
> with PoS features. Such a PoW+PoS system has several advantages:
You have to specify what you mean by "PoS" - there's dozens of variations.
Equally, existing pure PoS schemes probably don't make sense as a "bolt-on"
add-on, as once you introduce PoW to it you should design something that uses
the capabilities of both systems.
FWIW, I've heard that the Ethereum guys are leaning towards abandoning pure PoS
and are now trying to design a PoW + staking system instead.
> * It protects existing multi-billion dollar investments from innocent
> mining users,
To be clear, you mean such a scheme would protect the multi-billion dollar
investments non-malicious miners have made in SHA256^2 hardware by ensuring it
remains useful, right?
> * A malicious miner cannot launch attacks and rewrite the blockchain with
> 51% or even more hashrate,
> * If we insert 4 PoS blocks between 2 PoW blocks, we'll have 2-minute block
> time span, that solves the long confirmation time problem,
Note that if those PoS blocks are *pure* PoS, you'll create a significant risk
of double-spend attacks, as there's zero inherent cost to creating a pure-PoS
block. Such blocks can't be relied on for confirmations; even "slasher" schemes
have significant problems with sybil attacks.
> * We'll suddenly have 5 times of block space, that solves the scaling
> problem,
The scaling problem is one of scalability; PoS does nothing to improve
scalability (though many in the ETH community have been making dishonest
statements to the contrary).
> * The PoS blocks only mine transaction fees, so the 21M cap remains,
> * With careful design, the PoW+PoS transition _might_ be able to deploy
> with a soft fork.
As a sidechain yes, but in what you propose above the extra blocks wouldn't
contain transactions that non-PoS-aware nodes could understand in a
backwards-compatible way.
All the above aside, I don't think it's inherently wrong to look at adding PoS
block *approval* mechanisms, where a block isn't considered valid without some
kind of coin owner approval. While pure-PoS is fundamentally broken in a
decentralized setting, it may be possible to mitigate the reasons it's broken
with PoW and get a system that has a stronger security model than PoW alone.
FWIW there's some early discussions by myself and others about this type of
approach on the #bitcoin-wizards IRC channels, IIRC from around 2014 or so.
--
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/20170619/9c314d95/attachment.sig>

2023-06-07 20:01:20 CEST

- reply

📅 Original date posted:2017-05-22
📝 Original message:On Mon, May 22, 2017 at 10:41:40AM -0400, Ethan Heilman wrote:
> >It'd help your case if you gave us some examples of such scripts being
> used.
>
> I want OP_CAT so that I can securely and compactly verify many hashes and
> hash preimages. This would shrink offchain Tumblebit transactions
> significantly.
>
> For instance if I want a transaction TxA which checks that a transaction
> TxB releases preimages x1,x2,...,x10 such that
> y1=H(x1), y2=H(x2),...,y10=H(x10). Currently I just put y1,...y10 and check
> that the preimahes hash correctly. With OP_CAT I would only have to store
> one hash in TxA, yhash
>
> ytotal = H(OP_CAT(H(OP_CAT(y1, y2)),y3)...y10)
>
> TxA could then just hash all the preimages supplied by TxB and confirm they
> hash to TxA. This would reduce the size of TxA from approx 10*32B to
> 32+10*16B. I have a version which improves this further but it is more
> complex.
>
> Most of the math OP codes aren't particularly helpful due to their 32bit
> nature and their strange overflow behavior.
Great! That's exactly the type of justifying use-case we need for a BIP.
An OP_CAT will have to have limits on maximum output size; how big an output
does your application need?
--
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/20170522/5c5d8739/attachment.sig>

2023-06-07 20:01:09 CEST

- reply

📅 Original date posted:2017-05-13
📝 Original message:On Sat, May 13, 2017 at 12:49:33AM +0000, Luke Dashjr wrote:
> On Friday 12 May 2017 10:22:14 PM Peter Todd wrote:
> > nVersion signaling is already technically unenforceable, in the sense that
> > we don't have good ways of ensuring miners actually adopt the rules
> > they're claiming to signal. Equally, it's users who ultimately adopt
> > rules, not miners, and attempting to pay miners to signal certain bits
> > will further confuse this point.
>
> This BIP doesn't change that. Enforcement remains primarily by users.
I'm not arguing that it changes that; I'm arguing that it further confuses the
situation.
> > Quite likely the outcome of users trying to anonymously pay anonymous
> > miners to signal certain bits will be the complete breakdown of the
> > honesty of the nVersion signalling system, currently enforced only by
> > "gentlemans agreement".
>
> You assume users will pay for signalling of softforks prematurely. So long as
> it waits until deployment of the softfork is widespread, this risk is minimal.
> At worst, it creates risks similar to a UASF. So long as UASF is the
> alternative, this way seems strictly better.
I think you're assuming that the users paying for soft-fork signalling will
represent an economic majority; that's not necessarily the case.
For example, if miners decide there's no downside to false signalling, they may
take the extra fees provided by 1% of the users paying to signal a fork, while
the other 99% don't participate, resulting in a situation where we have blocks
violating the nVersion protocol, and an unknown % of that 99% rejecting those
blocks. At best that'd be no worse than a UASF, and at wost you're wrecked the
validity of the nVersion "gentlemans agreement"
> > Also, as an aside, this "specification" again shows the inadequacy and
> > unreadability of English language specifications. I'd strongly suggest you
> > delete it and instead mark the "reference implementation" as the
> > specification.
>
> How so?
Just read it: you have ten separate lines of dense English text describing
something that could have been specified instead by ten lines of much more
formally defined C++. In particular, note how many of those lines of English
text refer to C++ code anyway, like the sentence "minimal-length 40-bit
CScriptNum"
I don't want to have to learn another language - formally defined English that
still fails to be formally defined - just to read Bitcoin's specification.
--
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/20170513/b4e84f6e/attachment-0001.sig>

2023-06-07 20:01:07 CEST

- reply

📅 Original date posted:2017-05-12
📝 Original message:On Fri, May 12, 2017 at 07:22:56PM +0000, Luke Dashjr via bitcoin-dev wrote:
> I've written a new BIP draft for OP_CHECKBLOCKVERSION to allow the community
> to put economic pressure on miners to deploy softforks without the extreme of
> a UASF.
>
> https://github.com/luke-jr/bips/blob/bip-cbv/bip-cbv.mediawiki
I strongly disagree with this proposal.
nVersion signaling is already technically unenforceable, in the sense that we
don't have good ways of ensuring miners actually adopt the rules they're
claiming to signal. Equally, it's users who ultimately adopt rules, not miners,
and attempting to pay miners to signal certain bits will further confuse this
point.
Quite likely the outcome of users trying to anonymously pay anonymous miners to
signal certain bits will be the complete breakdown of the honesty of the
nVersion signalling system, currently enforced only by "gentlemans agreement".
A more productive direction would be a direct coin-owner signalling process,
with users taking action based on what provable coin-ownership has signalled.
Also, as an aside, this "specification" again shows the inadequacy and
unreadability of English language specifications. I'd strongly suggest you
delete it and instead mark the "reference implementation" as the specification.
--
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/20170512/ff3215fe/attachment.sig>

2023-06-07 19:59:18 CEST

- reply

📅 Original date posted:2017-04-06
📝 Original message:On Wed, Apr 05, 2017 at 11:11:53PM -0400, Erik Aronesty wrote:
> If the primary purpose of pow is to destroy value, then a masked proof of
> burn to an expanded address that assigns the private key holder the right
You're talking about proof-of-stake here.
At best it's very difficult for such a "proof-of-burn" to _actually_ be a
proof, as the burn only happens if the consensus mechanism ultimately includes
that burn. Contrast that to proof-of-work's incredibly simple proof: you _know_
energy was destroyed to find a PoW solution, regardless of what consensus is
ultimately reached.
It's the difference between a computer secured from hackers with an anti-virus
scanner, and a computer secured by the fact that it's not connected to the
internet at all.
--
https://petertodd.org 'peter'[:-1]@petertodd.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 455 bytes
Desc: Digital signature
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170405/6a415f35/attachment.sig>

2023-06-07 19:56:45 CEST

- reply

📅 Original date posted:2017-02-25
📝 Original message:On Sat, Feb 25, 2017 at 12:42:56PM -0800, Watson Ladd wrote:
> On Sat, Feb 25, 2017 at 11:12 AM, Peter Todd via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > On Sat, Feb 25, 2017 at 11:10:02AM -0500, Ethan Heilman via bitcoin-dev wrote:
> >> >SHA1 is insecure because the SHA1 algorithm is insecure, not because
> >> 160bits isn't enough.
> >>
> >> I would argue that 160-bits isn't enough for collision resistance. Assuming
> >> RIPEMD-160(SHA-256(msg)) has no flaws (i.e. is a random oracle), collisions
> >
> > That's something that we're well aware of; there have been a few discussions on
> > this list about how P2SH's 160-bits is insufficient in certain use-cases such
> > as multisig.
> >
> > However, remember that a 160-bit *security level* is sufficient, and RIPEMD160
> > has 160-bit security against preimage attacks. Thus things like
> > pay-to-pubkey-hash are perfectly secure: sure you could generate two pubkeys
> > that have the same RIPEMD160(SHA256()) digest, but if someone does that it
> > doesn't cause the Bitcoin network itself any harm, and doing so is something
> > you choose to do to yourself.
>
> P2SH is not secure against collision. I could write two scripts with
> the same hash, one of which is an escrow script and the other which
> pays it to me, have someone pay to the escrow script, and then get the
> payment. Some formal analysis tools would ignore the unused
> instructions even if human analysis would not.
That's what I said: "P2SH's 160-bits is insufficient in certain use-cases such
as multisig"
Obviously any usecase where multiple people are creating a P2SH redeemScript
collaboratively is potentially vulnerable. Use-cases where the redeemScript was
created by a single-party however are _not_ vulnerable, as that party has
complete control over whether or not collisions are possible, by virtue of the
fact that they're the ones who have to make the collision happen!
Similarly, even in the multisig case, commit-reveal techniques can mitigate the
vulnerability, by forcing parties to commit to what pubkeys/hashlocks/etc.
they'll use for the script prior to pubkeys/hashlocks/etc. being revealed.
Though a better long-term approach is to use a 256-bit digest size, as segwit
does.
--
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/20170225/5ab478f4/attachment.sig>

2023-06-07 19:56:45 CEST

- reply

📅 Original date posted:2017-02-25
📝 Original message:On Sat, Feb 25, 2017 at 03:34:33PM -0600, Steve Davis wrote:
> Yea, well. I don’t think it is ethical to post instructions without an associated remediation (BIP) if you don’t see the potential attack.
I can't agree with you at all there: we're still at the point where the
computational costs of such attacks limit their real-world impact, which is
exactly when you want the *maximum* exposure to what they are and what the
risks are, so that people develop mitigations.
Keeping details secret tends to keep the attacks out of public view, which
might be a good trade-off in a situation where the attacks are immediately
practical and the need to deploy a fix is well understood. But we're in the
exact opposite situation.
> I was rather hoping that we could have a fuller discussion of what the best practical response would be to such an issue?
Deploying segwit's 256-bit digests is a response that's already fully coded and
ready to deploy, with the one exception of a new address format. That address
format is being actively worked on, and could be deployed relatively quickly if
needed.
--
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/20170225/5ef5ac64/attachment.sig>

2023-06-07 19:56:40 CEST

- reply

📅 Original date posted:2017-02-24
📝 Original message:On Fri, Feb 24, 2017 at 05:49:36PM -0600, Steve Davis via bitcoin-dev wrote:
> If the 20 byte SHA1 is now considered insecure (with good reason), what about RIPEMD-160 which is the foundation of Bitcoin addresses?
SHA1 is insecure because the SHA1 algorithm is insecure, not because 160bits isn't enough.
AFAIK there aren't any known weaknesses in RIPEMD160, but it also hasn't been
as closely studied as more common hash algorithms. That said, Bitcoin uses
RIPEMD160(SHA256(msg)), which may make creating collisions harder if an attack
is found than if it used RIPEMD160 alone.
--
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/20170224/85794f98/attachment.sig>

2023-06-07 19:56:37 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:Worth noting: the impact of the SHA1 collison attack on Git is *not* limited
only to maintainers making maliciously colliding Git commits, but also
third-party's submitting pull-reqs containing commits, trees, and especially
files for which collisions have been found. This is likely to be exploitable in
practice with binary files, as reviewers aren't going to necessarily notice
garbage at the end of a file needed for the attack; if the attack can be
extended to constricted character sets like unicode or ASCII, we're in trouble
in general.
Concretely, I could prepare a pair of files with the same SHA1 hash, taking
into account the header that Git prepends when hashing files. I'd then submit
that pull-req to a project with the "clean" version of that file. Once the
maintainer merges my pull-req, possibly PGP signing the git commit, I then take
that signature and distribute the same repo, but with the "clean" version
replaced by the malicious version of the file.
--
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/20170223/fe8c9937/attachment.sig>

2023-06-07 19:56:37 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:On Thu, Feb 23, 2017 at 01:14:09PM -0500, Peter Todd via bitcoin-dev wrote:
> Worth noting: the impact of the SHA1 collison attack on Git is *not* limited
> only to maintainers making maliciously colliding Git commits, but also
> third-party's submitting pull-reqs containing commits, trees, and especially
> files for which collisions have been found. This is likely to be exploitable in
> practice with binary files, as reviewers aren't going to necessarily notice
> garbage at the end of a file needed for the attack; if the attack can be
> extended to constricted character sets like unicode or ASCII, we're in trouble
> in general.
>
> Concretely, I could prepare a pair of files with the same SHA1 hash, taking
> into account the header that Git prepends when hashing files. I'd then submit
> that pull-req to a project with the "clean" version of that file. Once the
> maintainer merges my pull-req, possibly PGP signing the git commit, I then take
> that signature and distribute the same repo, but with the "clean" version
> replaced by the malicious version of the file.
Thinking about this a bit more, the most concerning avenue of attack is likely
to be tree objects, as I'll bet you you can construct tree objs with garbage at
the end that many review tools don't pick up on. :(
--
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/20170223/29fe50b5/attachment-0001.sig>

2023-06-07 19:56:35 CEST

- reply

📅 Original date posted:2017-02-25
📝 Original message:On Fri, Feb 24, 2017 at 02:20:19PM -0800, Bram Cohen wrote:
> So your idea is to cluster entries by entry time because newer things are
> more likely to leave and updating multiple things near each other is
> cheaper?
Yes, exactly.
> That can be done with my tool. Instead of using hashes for the values being
> stored, you use position entries. The first entry gets a value of all
> zeros, the next one a one followed by all zeros, then the next two
> correspond to the first two with the second bit flipped to one, then the
> next four the first four with the third bit flipped to one, etc. It
> probably performs a little bit better to do it two bits at a time instead
> of one so that the entries are 00, 01, 10, 11, 0001, 0010, 0011, 0101,
> 0110, 0111, 1001, etc. If you were to really use this you'd probably want
> to to add some optimizations to use the fact that the terminals fit in 64
> bits instead of 256, but it mostly works unchanged, and gets whatever
So to be clear, what you're proposing there is to use the insertion order as
the index - once you go that far you've almost entirely re-invented my
proposal!
In fact, when I was working my proofchains/proofmarshal libraries I put some
thought into whether or not I could leave out the MMR merkelized list
implementation and use only the key-value map I also wrote. I decided to
include both as they aren't quite the same datastructure - using a list for a
list has advantages.
> benefits there are to this clustering plus the high performance
> implementation tricks I've built which I keep complaining that nobody's
> giving feedback on.
Your merkle-set implementation is 1500 lines of densely written Python with
almost no comments, and less than a 100 lines of (also uncommented) tests. By
comparison, my Python MMR implementation is 300 lines of very readable Python
with lots of comments, a 200 line explanation at the top, and 200 lines of
(commented) tests. Yet no-one is taking the (still considerable) effort to
understand and comment on my implementation. :)
Fact is, what you've written is really daunting to review, and given it's not
in the final language anyway, it's unclear what basis to review it on anyway. I
suspect you'd get more feedback if the codebase was better commented, in a
production language, and you have actual real-world benchmarks and performance
figures.
In particular, while at the top of merkle_set.py you have a list of advantages,
and a bunch of TODO's, you don't explain *why* the code has any of these
advantages. To figure that out, I'd have to read and understand 1500 lines of
densely written Python. Without a human-readable pitch, not many people are
going to do that, myself included.
> I'm not sold on this being a win: The empirical access patterns are
> unknown,
Lost coins alone guarantees that access patterns will be biased towards new
coins being more likely to be spent. That basis alone is sufficient to justify
an insertion-ordered data structure. Additionally, people have done graphs of
the average age of UTXO's when spent, and that data clearly shows that newer
coins are more likely to be spent than older coins.
> unknown, it requires an extra cache miss per lookup to find the entry
> number,
Like I mentioned in the email you're replying to, that extra lookup can be
easily avoided with a change to how transactions/blocks are serialized; if all
your peers support TXO commitments you can even discard the lookup database
entirely, as it's only a backwards compatibility measure.
> it may be that everything is optimized well enough without it for
> there to be no meaningful gains, and it's a bunch of extra complexity. What
Optimization is itself extra complexity. If you're data structure has worse
inherent performance, and you have to make up the different with a highly
optimized implementation, that's likely to lead to more overall complexity than
using a data structure with better inherent performance.
Your current merkle-set implementation definitely _is_ very complex. An
apples-to-apples comparison is with my merkelized key:value tree(1), also a
patricia tree, which like the MMR is only about 300 lines of well-commented and
straight-forward code.
1) https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/merbinnertree.py
> should be done is that a plain vanilla UTXO set solution is optimized as
> well as it can be first, and then the insertion ordering trick is tried as
> an optimization to see if it's an improvement. Without that baseline
> there's no meaningful basis for comparison, and I'm quite confident that a
> naive implementation which just allocates individual nodes will
> underperform the thing I've come up with, even without adding optimizations
> related to fitting in 64 bits.
To be clear, "insertion ordering" isn't a simple trick, it's a fundamental
change to what the data structure is. Once you do that, you're talking about my
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/20170224/9ad10e61/attachment-0001.sig>

2023-06-07 19:56:34 CEST

- reply

📅 Original date posted:2017-02-24
📝 Original message:On Thu, Feb 23, 2017 at 07:32:43PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 7:15 PM, Peter Todd <pete at petertodd.org> wrote:
>
> >
> > Glad we're on the same page with regard to what's possible in TXO
> > commitments.
> >
> > Secondly, am I correct in saying your UTXO commitments scheme requires
> > random
> > access? While you describe it as a "merkle set", obviously to be merkelized
> > it'll have to have an ordering of some kind. What do you propose that
> > ordering
> > to be?
> >
>
> The ordering is by the bits in the hash. Technically it's a Patricia Trie.
> I'm using 'merkle tree' to refer to basically anything with a hash root.
The hash of what? The values in the set?
> > Maybe more specifically, what exact values do you propose to be in the set?
> >
> >
> That is unspecified in the implementation, it just takes a 256 bit value
> which is presumably a hash of something. The intention is to nail down a
> simple format and demonstrate good performance and leave those semantics to
> a higher layer. The simplest thing would be to hash together the txid and
> output number.
Ok, so let's assume the values in the set are the unspent outpoints.
Since we're ordering by the hash of the values in the set, outpoints will be
distributed uniformly in the set, and thus the access pattern of data in the
set is uniform.
Now let's fast-forward 10 years. For the sake of argument, assume that for
every 1 UTXO in the set that corresponds to funds in someone's wallet that are
likely to be spent, there are 2^12 = 4096 UTXO's that have been permanently
lost (and/or created in spam attacks) and thus will never be spent.
Since lost UTXO's are *also* uniformly distributed, if I'm processing a new
block that spends 2^12 = 4096 UTXO's, on average for each UTXO spent, I'll
have to update log2(4096) = 12 more digests than I would have had those "dead"
UTXO's not existed.
Concretely, imagine our UTXO set had just 8 values in it, and we were updating
two of them:
#
/ \
/ \
/ \
/ \
/ \
# #
/ \ / \
/ \ / \
# . . #
/ \ / \ / \ / \
. X . . . . X .
To mark two coins as spent, we've had to update 5 inner nodes.
Now let's look at what happens in an insertion-ordered TXO commitment scheme.
For sake of argument, let's assume the best possible case, where every UTXO
spent in that same block was recently created. Since the UTXO's are recently
created, chances are almost every single one of those "dead" UTXO's will have
been created in the past. Thus, since this is an insertion-ordered data
structure, those UTXO's exist in an older part of the data structure that our
new block doesn't need to modify at all.
Concretely, again let's imagine a TXO commitment with 8 values in it, and two
of them being spent:
#
/ \
/ \
/ \
/ \
/ \
. #
/ \ / \
/ \ / \
. . . #
/ \ / \ / \ / \
. . . . . . X X
To mark two coins as spent, we've only had to update 3 inner nodes; while our
tree is higher with those lost coins, those extra inner nodes are amortised
across all the coins we have to update.
The situation gets even better when we look at the *new* UTXO's that our block
creates. Suppose our UTXO set has size n. To mark a single coin as spent, we
have to update log2(n) inner nodes. We do get to amortise this a bit at the top
levels in the tree, but even if we assume the amortisation is totally free,
we're updating at least log2(n) - log2(m) inner nodes "under" the amortised
nodes at the top of the tree for *each* new node.
Meanwhile with an insertion-ordered TXO commitment, each new UTXO added to the
data set goes in the same place - the end. So almost none of the existing data
needs to be touched to add the new UTXOs. Equally, the hashing required for the
new UTXO's can be done in an incremental fashion that's very L1/L2 cache
friendly.
tl;dr: Precisely because access patterns in TXO commitments are *not* uniform,
I think we'll find that from a L1/L2/etc cache perspective alone, TXO
commitments will result in better performance than UTXO commitments.
Now it is true that Bitcoin's current design means we'll need a map of
confirmed outpoints to TXO insertion order indexes. But it's not particularly
hard to add that "metadata" to transactions on the P2P layer in the same way
that segwit added witnesses to transactions without modifying how txids were
calculated; if you only connect to peers who provide you with TXO index
information in blocks and transactions, you don't need to keep that map
yourself.
Finally, note how this makes transactions *smaller* in many circumstances: it's
just a 8-byte max index rather than a 40 byte outpoint.
--
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/20170223/6a611ba3/attachment.sig>

2023-06-07 19:56:33 CEST

- reply

📅 Original date posted:2017-02-24
📝 Original message:On Thu, Feb 23, 2017 at 07:02:36PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 6:58 PM, Peter Todd <pete at petertodd.org> wrote:
>
> >
> > So to be clear, do you agree or disagree with me that you *can* extract a
> > compact proof from a MMR that a given output is unspent?
> >
>
> After wading through your logic on how updates are done, I agree that that
> can be done, but apples to apples compact proofs can also be done in a utxo
> commitment, and proofs of the validity of updates can be done in a utxo
> commitment, so there isn't any performance advantage to all that extra
> complexity.
Glad we're on the same page with regard to what's possible in TXO commitments.
Secondly, am I correct in saying your UTXO commitments scheme requires random
access? While you describe it as a "merkle set", obviously to be merkelized
it'll have to have an ordering of some kind. What do you propose that ordering
to be?
Maybe more specifically, what exact values do you propose to be in the set?
--
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/20170223/4f1075da/attachment-0001.sig>

2023-06-07 19:56:33 CEST

- reply

📅 Original date posted:2017-02-24
📝 Original message:On Thu, Feb 23, 2017 at 06:50:10PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd <pete at petertodd.org> wrote:
>
> > I think you've misunderstood what TXO commitments are. From my article:
> >
> > "A merkle tree committing to the state of all transaction outputs, both
> > spent
> > and unspent, can provide a method of compactly proving the current state
> > of an
> > output."
> > -https://petertodd.org/2016/delayed-txo-commitments#txo-commitments:
> >
>
> The proposal on that page is of a tree which does require random access
> updates, it just positions entries in the order they happened to be added
> instead of sorting by their hash. Once you start updating it to indicate
> spent status all the exact same issues of TXO size and cache coherence on
> updates show up again, but now you're using a more complex bespoke data
> structure instead of a basic fundamental one.
Sorry, but I was replying to your statement:
> What you can't do with MMRs or the blockchain is make a compact proof that
> something is still in the utxo set, which is the whole point of utxo
> commitments.
So to be clear, do you agree or disagree with me that you *can* extract a
compact proof from a MMR that a given output is unspent?
I just want to make sure we're on the same page here before we discuss
performance characteristics.
--
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/20170223/5d17c853/attachment.sig>

2023-06-07 19:56:32 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:On Thu, Feb 23, 2017 at 04:49:01PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 3:51 PM, Peter Todd <pete at petertodd.org> wrote:
>
> > On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote:
> > >
> > > I can't speak to MMRs (they look a bit redundant with the actual
> > blockchain
> > > history to my eye) but circling back to utxo commitments, the benefits
> > are
> >
> > In what way do you see MMRs as redundant?
> >
>
> You can readily prove something is in the TXO or STXO set using the actual
> blockchain, and the proofs will be nice and compact because even light
> nodes are expected to already have all the historical headers.
>
> What you can't do with MMRs or the blockchain is make a compact proof that
> something is still in the utxo set, which is the whole point of utxo
> commitments.
I think you've misunderstood what TXO commitments are. From my article:
"A merkle tree committing to the state of all transaction outputs, both spent
and unspent, can provide a method of compactly proving the current state of an
output."
-https://petertodd.org/2016/delayed-txo-commitments#txo-commitments:
I'm proposing that we commit to not just the set of transaction outputs, but
also the current *state* of those outputs, with the same commitment structure.
Concretely, each leaf node in the TXO commitment tree needs to commit to - at
minimum - the outpoint (txid:n) and spent/unspent status (possibly structurally
as mentioned elsewhere in this thread). It's probably also valuable to commit
to the scriptPubKey, nValue, as well, though technically that's redundant as
the txid already commits to that (there's some implementation options here).
> It's totally reasonable for full nodes to independently update and
> recalculate the utxo set as part of their validation process. The same
> can't be done for a balanced version of the txo set because it's too big.
Why would you commit to a balanced version of the TXO set? I'm proposing
committing to an insertion-ordered list, indexed by txout #.
> Relying on proofs as a crutch for using the full txo set would badly
> exacerbate the already extant problem of miners doing spv mining, and
> increase the bandwidth a full validating node had to use by a multiple.
>
> This whole conversation is badly sidetracked. If people have comments on my
> merkle set I'd like to engage further with them, but mmrs need to be argued
> independently on their own merits before being used as a counterpoint to
> utxo commitments.
Hmm? That's exactly what I'm doing. Also, as per the above, I think you've
misunderstood what my TXO commitment proposal is.
--
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/20170223/6b0f13f2/attachment.sig>

2023-06-07 19:56:31 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:On Thu, Feb 23, 2017 at 01:28:18PM -0500, G. Andrew Stone wrote:
> Can an insertion ordered MMR allow an efficient nonexistence proof?
Why do you want a non-existance proof?
It supports an efficient *spentness* proof, which is sufficient for what we
need in Bitcoin, and much more scalable.
--
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/20170223/74acf29d/attachment.sig>

2023-06-07 19:56:31 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:On Thu, Feb 23, 2017 at 03:13:43PM -0800, Bram Cohen wrote:
> On Thu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> >
> > What problem does this try to solve, and what does it have to do with
> > bitcoin?
> >
>
> I can't speak to MMRs (they look a bit redundant with the actual blockchain
> history to my eye) but circling back to utxo commitments, the benefits are
In what way do you see MMRs as redundant?
Remember that with UTXO commitments because access patterns are uniform, you'll
over time have a lot more "redundancy" in the form of lost-coins evenly spread
out across the whole keyspace.
> that it enables actual proofs of non-fraud: You can prove the validity of a
> block based on just the previous block (and maybe some previous headers
> because of mining rewards) and can prove to a light node that a utxo hasn't
> been spent yet.
>
> A major factor in the way of getting utxo commitments in blocks is
> performance. The txo set is of course vastly larger and more unwieldy. If
That statement is incorrect with pruning: you can maintain a commitment to the
TXO set, without actually storing the entire TXO set, because you don't need to
store anything for nodes that have already been spent.
Concretely, this can be done with nothing more than adding a FullySpent node
type to the MMR definition I published earlier, with the rule being that only a
left or right child of an inner node be a FullySpent node, not both; if both
sides are spent, the inner node itself becomes FullySpent. Equally, I think you
can re-use the Empty node for this, but I need to think a little about the
implications re: partial inner nodes.
Regardless, with a generalized commitment scheme, the serialization/commitment
to an Empty node is simply '0', the encoding of an unspent txout surrounded by
spent txouts will be similar in size to a position integer followed by the
txout...
A subtlety of this construction is that you can only prove that a specific
txout # is unspent, but that's actually sufficient, as you can also prove what
# a txout txid corresponds too with a previous version of the MMR.
> you make the utxo commitments trail by a small fixed number of blocks
> (between 2 and 5) their latency problems shouldn't be a big deal as long as
> the overall performance is good enough. My thesis is that with appropriate
> format and implementation tricks it's possible to get performance good
> enough to no longer be a gating factor to deployment.
>
> Disappointingly there hasn't been any feedback about my implementation,
> just discussion about merkle sets generally.
Well, I think at this point there's still discussion over whether or not a UTXO
set commitment is the right approach to begin with; if it's not your
implementation isn't relevant.
--
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/20170223/7dfb1ea7/attachment.sig>

2023-06-07 19:56:31 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:On Thu, Feb 23, 2017 at 09:53:58AM -0800, Chris Priest wrote:
> On 2/22/17, Peter Todd via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Reposting something that came up recently in a private discussion with some
> > academics:
> >
> > Concretely, let's define a prunable MMR with the following grammar. This
> > definition is an improvement on whats in the python-proofmarshal by
> > committing
> > to the number of items in the tree implicitly; an obvious max-log2(n)-sized
> > proof-of-tree-size can be obtained by following the right-most nodes:
>
> What problem does this try to solve, and what does it have to do with bitcoin?
See the discussion on TXO commitments for how MMR's could be used; a better MMR
makes for a better TXO commitment.
--
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/20170223/8a77c8e5/attachment.sig>

2023-06-07 19:56:30 CEST

- reply

📅 Original date posted:2017-02-23
📝 Original message:On Wed, Feb 22, 2017 at 07:07:08PM -0800, Bram Cohen wrote:
> On Wed, Feb 22, 2017 at 5:15 PM, Peter Todd via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
> >
> > With that, notice how proving the soundness of the proofs becomes trivial:
> > if
> > validation is deterministic, it is obviously impossible to construct two
> > different proofs that prove contradictory statements, because a proof is
> > simply
> > part of the data structure itself. Contradiction would imply that the two
> > proofs are different, but that's easily rejected by simply checking the
> > hash of
> > the data.
> >
>
> My code works this way. Proofs are serialization of a subset of the tree,
> and to validate a proof you ask a single function whether a particular
> value is included in that tree subset, and it answers yes or no, so
> obviously it's impossible for a single value to both validate and not
> validate. The proof code was quite terrifying before I made this change
> (which I did on your suggestion), and it's much cleaner and simpler now. It
> also in principle supports compact proofs of multiple inclusions and
> exclusions in the same serialization of a subset of the tree because the
> upper branches won't have to be repeated. I haven't written code for
> generating those, but the validation code will happily accept them.
That's an improvement, but I think we can do even better if we think of missing
pruned data as analogous to virtual memory: pruned data is the same as a page
that has been swapped to disk, with the magical property that hashing allows us
to swap it back in from an untrusted source.
Thus a proof should actually be whatever data we expect our counterparty to
have flushed, ranging from none at all, to 100% (modulo a root hash). An
implementation should then do operations as normal, using parts of the proof on
an as-needed basis where pruned data is encountered.
Thus if you have a key-value map and do a get() operation, you'd expect the
proof to *not* be what the get operates on, but rather be a *context* argument
to the get() operation. The other way around is actually an example of doing
computations on untrusted data, and bad API design!
> I'm not sure what you mean by MMRs though. Are you talking about MMRs where
> each mountain is a set of diffs to the old things and are periodically
> consolidated? Or do later mountains refer to internals of earlier ones? Or
> do they have 'maybe' values which mean that the earlier mountain should be
> referred to? Are these patricia tries or something flatter and more fixed
> depth?
I'm talking about these MMR's: https://github.com/proofchains/python-proofmarshal/blob/master/proofmarshal/mmr.py
Notably I'm talking about an insertion ordered list, indexed by position, that
supports append and update operations, but *not* insertions; this is different
than what you've recently published re: UTXO commitments. That's a full
key-value map, something MMR's are delibrately are not doing.
Draw out a MMR based on the formal definition you're replying too and you'll
see the new structure.
> My code doesn't keep track of tree size, by the way. It would be trivial to
> add that functionality to the library, and including it in the hashing
> creates complexity and doesn't seem to have any benefit over sending that
> data in a side channel.
Like I say above, you're solving a different problem than MMR's solve.
--
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/20170223/91289920/attachment-0001.sig>

2023-06-07 19:56:29 CEST

- reply

📅 Original date posted:2017-02-22
📝 Original message:Reposting something that came up recently in a private discussion with some
academics:
Concretely, let's define a prunable MMR with the following grammar. This
definition is an improvement on whats in the python-proofmarshal by committing
to the number of items in the tree implicitly; an obvious max-log2(n)-sized
proof-of-tree-size can be obtained by following the right-most nodes:
Maybe(T) := UNPRUNED <T> | PRUNED <Commitment(T)>
FullNode(0) := <Value>
FullNode(n) := <Maybe(FullNode(n-1)> <Maybe(FullNode(n-1))>
PartialNode(0) := SOME <FullNode(0)> | NONE
PartialNode(n) := <Maybe(FullNode(n-1))> <Maybe(PartialNode(n-1))>
MMR := FULL <N> <FullNode(n)> | PARTIAL <N> <PartialNode(n)>
Basically we define it in four parts. First we define Maybe(T) to represent
pruned and unpruned (hash only) data. Secondly we define full nodes within 2^n
sized trees. Third we define partial nodes. And finally we define the MMR
itself as being either a full or partial node.
First of all, with pruning we can define a rule that if any operation (other
than checking commitment hashes) attempts to access pruned data, it should
immediately fail. In particular, no operation should be able to determine if
data is or isn't pruned. Equally, note how an implementation can keep track of
what data was accessed during any given operation, and prune the rest, which
means a proof is just the parts of the data structure accessed during one or
more operations.
With that, notice how proving the soundness of the proofs becomes trivial: if
validation is deterministic, it is obviously impossible to construct two
different proofs that prove contradictory statements, because a proof is simply
part of the data structure itself. Contradiction would imply that the two
proofs are different, but that's easily rejected by simply checking the hash of
the data.
--
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/20170222/1412af52/attachment.sig>

2023-06-07 19:54:19 CEST

- reply

📅 Original date posted:2016-11-16
📝 Original message:On Wed, Nov 16, 2016 at 09:32:24AM -0500, Alex Morcos via bitcoin-dev wrote:
> I think we are misunderstanding the effect of this change.
> It's still "OK" for a 50k re-org to happen.
> We're just saying that if it does, we will now have potentially introduced
> a hard fork between new client and old clients if the reorg contains
> earlier signaling for the most recent ISM soft fork and then blocks which
> do not conform to that soft fork before the block height encoded activation.
>
> I think the argument is this doesn't substantially add to the confusion or
> usability of the system as its likely that old software won't even handle
> 50k block reorgs cleanly anyway and there will clearly have to be human
> coordination at the time of the event. In the unlikely event that the new
> chain does cause such a hard fork, that coordination can result in everyone
> upgrading to software that supports the new rules anyway.
>
> So no, I don't think we should add a checkpoint. I think we should all
> just agree to a hard fork that only has a very very slim chance of any
> practical effect.
So, conceptually, another way to deal with this is to hardcode a blockhash
where we allow blocks in a chain ending with that blockhash to _not_ follow
BIP65, up until that blockhash, and any blockchain without that blockhash must
respect BIP65 for all blocks in the chain.
This is a softfork: we've only added rules that made otherwise valid chains
invalid, and at the same time we are still accepting large reorgs (albeit under
stricter rules than before).
I'd suggest we call this a exemption hash - we've exempted a particular
blockchains from a soft-forked rule that we would otherwise enforce.
--
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/20161116/eef4afb9/attachment.sig>

2023-06-07 19:53:54 CEST

- reply

📅 Original date posted:2016-10-14
📝 Original message:On Fri, Oct 14, 2016 at 07:38:07AM -0300, Sergio Demian Lerner via bitcoin-dev wrote:
> I read the DPL v1.1 and I find it dangerous for Bitcoin users. Current
> users may be confident they are protected but in fact they are not, as the
> future generations of users can be attacked, making Bitcoin technology
> fully proprietary and less valuable.
Glad to hear you're taking a conservative approach.
So I assume Rootstock is going to do something stronger then, like
Blockstream's DPL + binding patent pledge to only use patents defensively?
https://www.blockstream.com/about/patent_pledge/
Because if not, the DPL is still better than the status quo.
> If you read the DPL v1.1 you will see that companies that join DPL can
> enforce their patents against anyone who has chosen not to join the DPL.
> (http://defensivepatentlicense.org/content/defensive-patent-license)
>
> So basically most users of Bitcoin could be currently under threat of being
> sued by Bitcoin companies and individuals that joined DPL in the same way
> they might be under threat by the remaining companies. And even if they
> joined DPL, they may be asked to pay royalties for the use of the
> inventions prior joining DPL.
>
> DPL changes nothing for most individuals that cannot and will not hire
> patent attorneys to advise them on what the DPL benefits are and what
> rights they are resigning. Remember that patten attorneys fees may be
> prohibitive for individuals in under-developed countries.
>
> Also DPL is revocable by the signers (with only a 180-day notice), so if
> Bitcoin Core ends up using ANY DPL covered patent, the company owning the
> patent can later force all new Bitcoin users to pay royalties.
Indeed. However, you're also free to adopt the DPL irrevocably by additionally
stating that you will never invoke that 180-day notice provision (or more
humorously, make it a 100 year notice period to ensure any patents expire!).
If you're concerned about this problem, I'd suggest that Rootstock do exactly
that.
> Because Bitcoin user base grows all the time with new individuals, the sole
> existence of DPL licensed patents in Bitcoin represents a danger to Bitcoin
> future almost the same as the existence of non-DPL license patents.
To be clear, modulo the revocability provision, it's a danger mainly to those
who are unwilling to adopt the DPL themselves, perhaps because they support
software patents.
> If you're publishing all your ideas and code (public disclosure), you
> cannot later go and file a patent in most of the world except the US, where
> you have a 1 year grace period. So we need to do something specific to
> prevent the publishers filing a US patent.
Again, lets remember that you personally proposed a BIP[1] that had the effect
of aiding your ASICBOOST patent[2] without disclosing that fact in your BIP nor
your pull-req[3]. The simple fact is we can't rely solely on voluntary
disclosure - your own behavior is a perfect example of why not.
[1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
[2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
[3]: Extra nonce pull request: https://github.com/bitcoin/bitcoin/pull/5102
> What we need much more than DPL, we need that every BIP and proposal to the
> Bitcoin mailing list contains a note that grants all Bitcoin users a
> worldwide, royalty-free, no-charge, non-exclusive, irrevocable license for
> the content of the e-mail or BIP.
A serious problem here is the definition of "Bitcoin users". Does Bitcoin
Classic count? Bitcoin Unlimited? What if Bitcoin forks?
Better to grant _everyone_ a irrevocable license.
Along those lines, it'd be reasonable to consider changing the Bitcoin Core
license to something like an Apache2/LGPL3 dual license to ensure the copyright
license also has anti-patent protections.
--
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/20161014/2ecedac8/attachment.sig>

2023-06-07 19:53:42 CEST

- reply

📅 Original date posted:2016-10-02
📝 Original message:On Sun, Oct 02, 2016 at 02:00:01PM -0300, Sergio Demian Lerner wrote:
> Peter, are you really going to try to down vote a decent free and
> open-source proposal that benefits all the Bitcoin community including
> you and your future children because a personal attack to me without any
> logic or basis?
I've suggested a way that you can rectify this situation so we can continue to
collaborate: Have Rootstock adopt a legally binding patent pledge/license. I'd
suggest you do as Blockstream has done and at minimum adopt the Defensive
Patent License (DPL); I personally will be doing so in the next week or two for
my own consulting company (I'm discussing exactly how to do so with my lawyer
right now).
If Rootstock is not planning on getting any patents for offensive purposes,
then there is no issue with doing so - the DPL in particular is designed in a
minimally intrusive way.
Please fix this issue so we can in fact continue to collaborate to improve
Bitcoin.
--
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/20161002/26faa19a/attachment.sig>

2023-06-07 19:53:41 CEST

- reply

📅 Original date posted:2016-10-02
📝 Original message:On Sun, Oct 02, 2016 at 12:49:08PM -0300, Sergio Demian Lerner via bitcoin-dev wrote:
I think your history of patenting(1) Bitcoin consensus relevant technology is
sufficient by itself to be extremely dubious of any proposals coming from you
or your colleagues; patents on Bitcoin consensus technology are a serious
threat to decentralization. Personally, I'm NACKing this proposal on that basis
alone.
You need to rectify this dangerous and unethical behavior in a convincing,
legally binding way. I'd suggest looking into Blockstream's patent pledges as a
way forward:
https://www.blockstream.com/about/patent_pledge/
I see no reason to have any further discussion of your proposal until this is
rectified.
1) "AsicBoost is a patent-pending method to improve the efficiency and cost of Bitcoin mining by approximately 20%"
http://www.asicboost.com/single-post/2016/03/24/AsicBoost-Press-Release
> Since ScalingBitcoin is close, I think this is a good moment to publish our
> proposal on drivechains. This BIP proposed the drivechain we'd like to use
> in RSK (a.k.a. Rootstock) two-way pegged blockchain and see it implemented
--
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/20161002/e1b2f066/attachment.sig>

2023-06-07 19:53:22 CEST

- reply

📅 Original date posted:2016-09-18
📝 Original message:As part of my recent work(1) on OpenTimestamps I've been putting some thought
towards how to interpret the nTime fields in block headers, for the purpose of
timestamping. I'd like to get some peer review on the following scheme I've
come up with.
# Motivation
We want to use the Bitcoin blockchain to provide evidence (the "attestation")
that a message M existed prior to some point in time T. Exactly how we do this
is beyond the scope of this post, but suffice to say we show that some block
header b cryptographically commits to the message, e.g. via a commitment
operation path proof, as implemented by OpenTimestamps.
A valid timestamp is simply one where T is a point in time where the message
did in fact exist. Of course, if a timestamp for time T is valid, all
subsequent T+d are also valid; such timestamps are simply more conservative
versions of the same statement.
A naively approach - as is implemented by most (all?) existing Bitcoin
timestamping schemes - is to assume that the block header's nTime field was
perfectly accurate, and thus M exists prior to the block's nTime. But that
doesn't take into account malicious miners, who may backdate their blocks.
# Threat Model
We assume miners are divided into two categories:
1) Dishonest Miners --- These miners are actively conspiring to create invalid
timestamps for time's prior to when the message existed. A dishonest miner will
set the nTime field in blocks they create to the minimum possible value.
2) Honest Miners --- These miners set nTime in blocks they create to
approximately the current true time. An honest miner may use techniques such as
nTime-rolling. Additionally, all honest miners may be simultaneously affected
by systematic misconfigurations.
## nTime Rolling
Prior to BIP113, reducing a block's nTime from the work given by a pool by even
a second could easily render it invalid, as the pool may have included
nLockTime'd transactions in the block. Thus hashing software was designed to
only roll nTime in the forward direction, not reverse, even though rolling
could be done in the reverse direction, up to the limit of the median-time-past
+ 1.
The Stratum mining protocol doesn't even have a way to tell clients what the
minimum allowed time is, just a single field, nTime, which is defined as "the
current time". Thus Stratum hashers will only ever increase nTime, which can
never result in an invalid timestamp if the original, unrolled, nTime would
have been a valid timestamp.
The getblocktemplate protocol does support telling hashers the minimum time via
the mintime field, which Bitcoin Core sets to the median-time-past. Regardless,
it appears that the pools supporting GBT (Eligius) return a much tighter limit
on mintime than the median-time-past, just 180 seconds, and as of writing,
don't actually declare that the ntime field is mutable anyway.
From an implementation point of view, relying on being able to roll nTime
backwards is unwise anyway, as the amount you can roll it back may be minimal
(e.g. if multiple blocks were recently found).
Since all miners have an incentive for time to move forward to keep difficulty
down it's reasonable to assume that the above observed behavior will continue,
and nTime rolling in the reverse direction will be a minimal effect; we'll
assume no miner rolls nTime backwards more than 1 hour.
## Systematic Errors
1) Botched daylight savings time changes --- While internal clocks should be
unaffected by timezone changes, it's plausible that some kind of mistake
related to daylight savings could result in the time being set incorrectly +- 1
hour. For example, multiple large miners might manually set their clocks, based
on an incorrect understanding of what time it was.
2) Broken NTP servers --- It's reasonable to assume that many miners are using
NTP to set their clocks, and it's plausible that they're using the same NTP
servers. Of course, a broken NTP server could return any time at all! The
Bitcoin protocol considers blocks to be valid if nTime is set up to 2 hours in
the future (from the perspective of the local node) so we'll say instead that
we expect systematic NTP errors to be corrected with high probability if
they're more than 2 hours in magnitude - more than that and the Bitcoin network
is broken in a very visible way anyway.
Thus, we'll assume honest miners always create blocks with nTime greater than
the true time minus two hours, which accounts for both likely daylight savings
time misconfigurations, and likely NTP server misconfigurations. Additionally,
two hours is greater than any expected effects from nTime rolling.
# Proposed Algorithm
For a timestamp anchored at a block of height x we'll define the time T it
represents as:
T = max(block[i].nTime for i in {x, ..., x + N-1}) + max_offset
In short, T is the maximum nTime out of the N blocks that confirmed the
timestamp, including first block that actually committed the timestamp;
max_offset is the maximum nTime offset we expect from a block created by an
honest miner, discussed above.
The dishonest miners can successfully create an invalid timestamp iff all N
blocks are found by them; if any block is found by an honest miner, the nTime
field will be set correctly. Of course T may not be the minimum possible value,
but the timestamp will be at least valid.
So how big should N be? Let q be the ratio of dishonest miners to total hashing
power. The probability that all N blocks are found by dishonest miners is q^N,
and thus the probability P that at least one block is found by an honest miner
is:
P = 1 - q^N => N = log(1 - P)/log(q)
If the dishonest miners have q>0.5, the situation is hopeless, as they can
reject blocks from honest miners entirely; the only limit on them setting nTime
is the median-time-past rule, which only requires blocks timestamps to
increment by one second per block (steady state). Thus we'll assume q=0.5, the
worst possible case where a Bitcoin timestamp can still be meaningful evidence:
P = 97% => N = 5
P = 99% => N = 7
P = 99.9% => N = 10
P = 99.99% => N = 14
P = 99.999% => N = 17
P = 99.9999% => N = 20
The reliability for the higher N is higher than the actual reliability of
Bitcoin itself. On the other hand, there's no known instance where miners have
ever created blocks with nTime's significantly less than true time on a wide
scale; even in the well-known cases where the Bitcoin network has temporarily
failed due to forks, timestamps produced during those times would be valid, if
delayed by a few hours.
Similarly, if we assume a lower q, say a single "rogue" 20% mining pool, we
get:
q = 0.20, P = 99.99% => N = 6
Another way to think about the choice of N is to compare its contribution to
how conservative the timestamp is - T as compared to the true time - to the
effect of the max-honest-miner-offset we choose earlier. For example, 98% of
the time at least 6 blocks will be found within 2 hours, which means that if we
pick N=7, 98% of the time the conservatism added by N will be less than the
contribution of the max offset.
# UI Considerations
One problem with the above algorithm is that it will frequently return
timestamps in the future, from the perspective of the user. A user who sees a
message like the following at 2:00 pm, immediately after their timestamp
confirms, is understandably going to be confused:
Bitcoin: 99% chance that <f> existed prior to 4:00 pm, Jan 1st 2016
A reasonable approach to this problem might just to refrain from displaying
timestamps at all until the local time is after the timestamp; the UI could
describe the timestamp as "Not yet confirmed"
It may also be reasonable to round the timestamp up to the nearest day when
displaying it. However what timezone to use is a tricky issue; people rarely
expect to see timezones specified alongside dates.
Of course, in some cases a less conservative approach to interpreting the
timestamp is reasonable; those users however should be reading and
understanding the calculations in this post!
# References
1) https://petertodd.org/2016/opentimestamps-announcement
--
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/20160918/4552f035/attachment-0001.sig>

2023-06-07 19:53:18 CEST

- reply

📅 Original date posted:2016-09-09
📝 Original message:On Sat, Sep 10, 2016 at 12:42:30AM +0000, Gregory Maxwell via bitcoin-dev wrote:
> The alert system was a centralized facility to allow trusted parties
> to send messages to be displayed in wallet software (and, very early
> on, actually remotely trigger the software to stop transacting).
<snip>
> One of the facilities in the alert system is that you can send a
> maximum sequence alert which cannot be overridden and displays only a
> static key compromise text message and blocks all other alerts. I plan
> to send a triggering alert in the not-distant future (exact time to be
> announced well in advance) feedback on timing would be welcome.
>
> There are likely a few production systems that automatically shut down
> when there is an alert, so this risks some small one-time disruption
> of those services-- but none worse than if an alert were sent to
> advise about a new system upgrade.
>
> At some point after that, I would then plan to disclose this private
> key in public, eliminating any further potential of reputation attacks
> and diminishing the risk of misunderstanding the key as some special
> trusted source of authority.
ACK
Good to do this sooner rather than later, as alert propagation on the P2P
network is going to continue to get less reliable as nodes upgrade to software
that has removed alert functionality; better that the final alert key
retirement message is reliably seen by the remaining software out there in a
predictable way than this be something that happens unpredictably.
--
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/20160910/972d0258/attachment.sig>

2023-06-07 19:53:18 CEST

- reply

📅 Original date posted:2016-09-09
📝 Original message:On Sat, Sep 10, 2016 at 01:48:40AM +0000, Gregory Maxwell wrote:
> On Sat, Sep 10, 2016 at 12:58 AM, Peter Todd <pete at petertodd.org> wrote:
> > Good to do this sooner rather than later, as alert propagation on the P2P
> > network is going to continue to get less reliable as nodes upgrade to software
>
> Yes, this was one of my motivations for doing this soon.
>
> It would only require about 2 LOC to have Bitcoin Core vomit out a
> blob containing the final alert to any old protocol version peers that
> connect. I don't know how other people would feel about that, but I
> wouldn't mind implementing it, and it would greatly improve the
> likelihood that they continue to to get once propagation of it is
> gone. This could be left in the codebase for a couple years or until
> other changes made those old versions p2p incompatible for other
> reasons.
I think that's a good idea, and it's a simple way to document that final alert
as well.
--
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/20160910/3071c2e5/attachment.sig>