Re: [bitcoin-dev] Merkleize All The Things

On Tue, Nov 8, 2022 at 2:13 AM Salvatore Ingala via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I have been working on some notes to describe an approach that uses > covenants in order to enable general smart contracts in bitcoin. You can > find them here: > >

Re: [bitcoin-dev] On a new community process to specify covenants

On Mon, Jul 25, 2022 at 8:21 PM Antoine Riard wrote: > What would be the canonical definition and examples of capabilities in the > Bitcoin context ? > Payments into vaults which can only be accepted by that vault and are guaranteed to be subject to the vault's restrictions (the vault has a

Re: [bitcoin-dev] On a new community process to specify covenants

On Wed, Jul 20, 2022 at 2:46 PM Antoine Riard via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Indeed this range has grown wild. Without aiming to be exhaustive (I'm > certainly missing some interesting proposals lost in the abyss of > bitcointalk.org), we can mention the

Re: [bitcoin-dev] Security problems with relying on transaction fees for security

On Mon, Jul 11, 2022 at 2:53 PM Peter Todd wrote: > > 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

[bitcoin-dev] Security problems with relying on transaction fees for security

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

Re: [bitcoin-dev] Surprisingly, Tail Emission Is Not Inflationary

On Mon, Jul 11, 2022 at 10:00 AM Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > 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

Re: [bitcoin-dev] No Order Mnemonic

dex of permutation used to scramble the > otherwise sorted list. For 12 words you need to store 12! = ~32 bits so 3 > words should be enough. > > Repetitions make this more difficult, though. > > On Thu 7. 7. 2022 at 19:41, Bram Cohen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundat

Re: [bitcoin-dev] No Order Mnemonic

On Thu, Jul 7, 2022 at 7:43 AM Anton Shevchenko via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I made a python implementation for a different mnemonic encoding. The > encoding requires user to remember words but not the order of those words. > The code is open (MIT license) at

Re: [bitcoin-dev] CTV BIP Meeting #9 Notes

On Thu, May 19, 2022 at 9:17 AM alicexbt via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > MEV could be one the issues associated with general covenants. There are > some resources on https://mev.day if anyone interested to read more about > it. > One of the top things to do

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

On Mon, Apr 11, 2022 at 11:21 AM Olaoluwa Osuntokun wrote: > Hi Bram, > > > The witnesses for transactions need to be put into Bitcoin transactions > > even though the Bitcoin layer doesn't understand them > > Is this related to Ruben's comment about invalid state transitions > (published in the

Re: [bitcoin-dev] Taro: A Taproot Asset Representation Overlay

From: Olaoluwa Osuntokun > > > Furthermore, the Taro script is not enforced by Bitcoin, meaning those > who > > control the Bitcoin script can always choose to ignore the Taro script > and > > destroy the Taro assets as a result. > > This is correct, as a result in most contexts, an incentive

Re: [bitcoin-dev] bitcoin scripting and lisp

On Wed, Mar 16, 2022 at 7:54 AM ZmnSCPxj wrote: > My point is that in the past we were willing to discuss the complicated > crypto math around cross-input sigagg in order to save bytes, so it seems > to me that cross-input compression of puzzles/solutions at least merits a > discussion, since it

Re: [bitcoin-dev] bitcoin scripting and lisp

On Thu, Mar 10, 2022 at 8:46 PM Anthony Towns wrote: > Note that PTLCs aren't really Chia-friendly, both because chia doesn't > have secp256k1 operations in the first place, but also because you can't > do a scriptless-script because the information you need to extract > is lost when signatures

Re: [bitcoin-dev] bitcoin scripting and lisp

On Wed, Mar 9, 2022 at 10:47 PM Anthony Towns wrote: > > To redo the singleton pattern in bitcoin's context, I think you'd have > to pass in both the full tx you're spending (to be able to get the > txid of its parent) and the full tx of its parent (to be able to get > the scriptPubKey that your

Re: [bitcoin-dev] bitcoin scripting and lisp

On Wed, Mar 9, 2022 at 6:30 AM ZmnSCPxj wrote: > I am pointing out that: > > * We want to save bytes by having multiple inputs of a transaction use the > same single signature (i.e. sigagg). > > is not much different from: > > * We want to save bytes by having multiple inputs of a transaction

Re: [bitcoin-dev] bitcoin scripting and lisp

On Mon, Mar 7, 2022 at 7:06 PM ZmnSCPxj wrote: > > But cross-input signature aggregation is a nice-to-have we want for > Bitcoin, and, to me, cross-input sigagg is not much different from > cross-input puzzle/solution compression. > Cross-input signature aggregation has a lot of headaches

Re: [bitcoin-dev] bitcoin scripting and lisp

On Mon, Mar 7, 2022 at 2:56 PM ZmnSCPxj wrote: > > > while in the coin set model each puzzle (scriptpubkey) gets run and > either assert fails or returns a list of extra conditions it has, possibly > including timelocks and creating new coins, paying fees, and other things. > > Does this mean it

Re: [bitcoin-dev] bitcoin scripting and lisp

On Mon, Mar 7, 2022 at 5:27 PM Anthony Towns wrote: > One way to match the way bitcoin do things, you could have the "list of > extra conditions" encoded explicitly in the transaction via the annex, > and then check the extra conditions when the script is executed. > The conditions are already

[bitcoin-dev] bitcoin scripting and lisp

> > After looking into it, I actually think chia lisp [1] gets pretty much all > the major design decisions pretty much right. There are obviously a few > changes needed given the differences in design between chia and bitcoin: > > - having secp256k1 signatures (and curve operations), instead of

Re: [bitcoin-dev] Improving RBF policy

On Mon, Jan 31, 2022 at 4:08 PM Eric Voskuil wrote: > > > On Jan 31, 2022, at 15:15, Bram Cohen via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > Is it still verboten to acknowledge that RBF is normal behavior and > disallowing it is the feature,

Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

On Fri, Jan 21, 2022 at 9:32 AM Billy Tetrud wrote: > > Bitcoin doesn't have a strong single concept of a 'parent' > > I'm using the term "parent" loosely in context here to mean a relationship > where an input has constraints applied to an output (or outputs). > Yes and I'm using it more

Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

On Tue, Jan 18, 2022 at 6:25 PM Billy Tetrud wrote: > > 'assert that my parent has a scriptpubkey of X'... That way you can, for > example, have a UTXO which only allows itself to be absorbed by a > transaction also involving a UTXO with a particular capability > > I'm not sure I fully follow. I

Re: [bitcoin-dev] Covenants and capabilities in the UTXO model

On Tue, Jan 18, 2022 at 7:10 AM Billy Tetrud wrote: > > Since scriptpubkeys/scriptsigs continue to run ephemerally at > validation time full turing completeness is much less dangerous than people > fear. > > The covenant proposals I've seen that might give bitcoin turing > completeness require

[bitcoin-dev] Covenants and capabilities in the UTXO model

There are a few different approaches to adding covenants and capabilities to the UTXO model with varying tradeoffs. It turns out that it can be done while making very few but not quite zero compromises to practices Bitcoin has been following so far. First, the good news: Full support for both

Re: [bitcoin-dev] Getting around to fixing the timewarp attack.

This seems like a case where a distinction should be made between soft forks which are likely to cause non-upgraded miners to get orphaned and ones where they are. Of course in this case it's only 1/2016 of all blocks so it doesn't really matter, but it's worth thinking about the principle. In

[bitcoin-dev] BLS library released

BLS signatures have the same aggregation feature as Schnorr signatures but even better because the aggregation can be done non-interactively, at the expense of being a bit slower. We just released a first draft (but fully functional) library for doing BLS signatures based on a construction based

Re: [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible?

Not sure what you're saying here. The block rate can't be particularly increased or decreased in the long run due to the work difficulty adjustment getting you roughly back where you started no matter what. Someone could DOS the system by producing empty blocks, sure, that's a central attack of

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

So are you saying that if fully validating nodes wish to prune they can maintain the ability to validate old transactions by cacheing the number of transactions in each previous block? On Thu, Jun 7, 2018 at 3:20 PM, Peter Todd wrote: > On Thu, Jun 07, 2018 at 02:15:35PM -0700, Bram Cohen

Re: [bitcoin-dev] Trusted merkle tree depth for safe tx inclusion proofs without a soft fork

Are you proposing a soft fork to include the number of transactions in a block in the block headers to compensate for the broken Merkle format? That sounds like a good idea. On Thu, Jun 7, 2018 at 10:13 AM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > It's well

Re: [bitcoin-dev] TXO bitfield size graphs

You compressed something which is truly natively a bitfield using regular compression algorithms? That is expected to get horrible results. Much better would be something which handles it natively, say doing run length encoding on the number of repeated bits and compressing that using elias omega

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

I'm not sure about the best way to approach soft-forking (I've opined on it before, and still find the details mind-numbing) but the end goal seems fairly clearly to be an all of the above: Have aggregatable public keys which support simple signatures, taproot with BIP 114 style taproot, and

Re: [bitcoin-dev] BIP sighash_noinput

A technical point about SIGHASH_NOINPUT: It seems like a more general and technically simpler to implement idea would be to have a boolean specifying whether the inputs listed must be all of them (the way it works normally) or a subset of everything. It feels like a similar boolean should be made

Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

On Mon, Mar 26, 2018 at 11:34 PM, Anthony Towns <a...@erisian.com.au> wrote: > On Wed, Mar 21, 2018 at 05:47:01PM -0700, Bram Cohen via bitcoin-dev wrote: > > [...] Most unused opcodes should be reclaimed as RETURN_VALID, > > but there should still be one OP_NOP and th

Re: [bitcoin-dev] Soft-forks and schnorr signature aggregation

Regarding the proposed segwit v2 with reclaiming most things as RETURN_VALID, the net result for what's being proposed in the near future for supporting aggregated signatures in the not-so-near future is to punt. A number of strategies are possible for how to deal with new opcodes being added

Re: [bitcoin-dev] Height based vs block time based thresholds

On Tue, Jul 4, 2017 at 6:30 PM, shaolinfry via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Some people have criticized BIP9's blocktime based thresholds arguing they > are confusing (the first retarget after threshold). It is also vulnerable > to miners fiddling with timestamps

Re: [bitcoin-dev] A Method for Computing Merkle Roots of Annotated Binary Trees

On Mon, May 22, 2017 at 12:05 AM, Russell O'Connor via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > The SHA256 compression function takes two inputs: > > 1. A 256-bit value for the previous chunk in a chain, or an initial vector > in the case of the first chunk. > 2. A 512-bit

Re: [bitcoin-dev] Properties of an ideal PoW algorithm & implementation

Repeatedly hashing to make it so that lossy implementations just fail sounds like a great idea. Also relying on a single crypto primitive which is as simple as possible is also a great idea, and specifically using blake2b is conservative because not only is it simple but its block size is larger

Re: [bitcoin-dev] A Small Modification to Segwit

On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Perhaps regular, high-consensus POW changes might even be *necessary* as a > part of good maintenance of cryptocurrency in general. Killing the > existing POW, and using an as-yet

Re: [bitcoin-dev] A Small Modification to Segwit

On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Clearly a level-playing field is critical to keeping centralization from > being a "defining feature" of Bitcoin over the long term. I've heard the > term "level playing field"

Re: [bitcoin-dev] Using a storage engine without UTXO-index

Expanding on this question a bit, it's optimized for parallel access, but hard drive access isn't parallel and memory accesses are very fast, so shouldn't the target of optimization be about cramming as much as possible in memory and minimizing disk accesses? On Fri, Apr 7, 2017 at 11:18 AM,

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

On Wed, Apr 5, 2017 at 7:31 PM, Peter Todd via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > While I'm in favour of blocking covert usage of ASICBOOST, there's every > reason > to block non-covert usage of it as well. In a low margin business like > mining, > the advatange it

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

On Sun, Apr 2, 2017 at 1:43 PM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > TL;DR: using spentness bits scales linearly... vs swapping digest leafs > with empties can scale with logorithmically increasing storage > requirements. So if you are using a 32 byte

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

On Sat, Apr 1, 2017 at 6:58 PM, praxeology_guy < praxeology_...@protonmail.com> wrote: > Bram Cohen, > > In R: First its appropriate to explore all interesting ideas, and help > each other improve their ideas. Last, when there is a deadline that needs > to be met, we compare various options and

Re: [bitcoin-dev] Guessing the spentness status of the pruned relatives

On Sat, Apr 1, 2017 at 6:10 PM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > With using the MMR data structure for txo commitments, its preferable that > wallets only keep information pertinent to their own spendable coins. In > previous communication we

[bitcoin-dev] The TXO bitfield

Looking forward in node scaling we can envision a future in which blocks are required to come with proofs of their validity and nodes can be run entirely in memory and never have to hit disk. Ideally we'd like for proofs to be able to be stored in client wallets which plan to spend their utxos

Re: [bitcoin-dev] Refund Excesss Fee Hard Fork Proposal

On Fri, Mar 31, 2017 at 1:29 PM, praxeology_guy via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Change the fee policy to cause all fee/byte in a block to be reduced to > the lowest included fee/byte. Change transactions to specify how/which > outputs get what portions of

Re: [bitcoin-dev] A Better MMR Definition

On Wed, Mar 1, 2017 at 2:31 PM, Peter Todd wrote: > > A better way to present your work would have been to at least explain that > at > the top of the file, and perhaps even better, split the reference > implementation and optimized implementation into two separate files. If

Re: [bitcoin-dev] Hard fork proposal from last week's meeting

On Tue, Mar 28, 2017 at 9:59 AM, Wang Chun via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > The basic idea is, as many of us agree, hard fork is risky and should > be well prepared. We need a long time to deploy it. > Much as it may be appealing to repeal the block size limit

Re: [bitcoin-dev] Fraud proofs for block size/weight

Some questions: Does this require information to be added to blocks, or can it work today on the existing format? Does this count number of transactions or their total length? The block limit is in bytes rather than number of transactions, but transaction number can be a reasonable proxy if you

Re: [bitcoin-dev] Malice Reactive Proof of Work Additions (MR POWA): Protecting Bitcoin from malicious miners

It's possible to switch PoW algorithms with a soft fork rather than a hard fork. You make it so that there are two different PoWs, the old one and the new one, and each old-style block has to reference a new-style block and contain the exact same transactions. The new work rule is that the

Re: [bitcoin-dev] Solution for blockchain congestion and determination of block size by bitcoin network/protocol itself.

Shouldn't there be a FAQ about this? All the blocksize increase proposals going back to the Bitcoin Classic have the same problems and having repeated proposals which move the details around a bit doesn't add anything to the discussion. ___ bitcoin-dev

Re: [bitcoin-dev] A Commitment-suitable UTXO set "Balances" file data structure

On Tue, Mar 7, 2017 at 5:55 PM, bfd--- via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Having a commitment to a "balance" of an "address" (I assume you mean > P2SH/P2PKH script) is extremely expensive to create and validate, does > not scale and is not a particularly useful

Re: [bitcoin-dev] A Better MMR Definition

On Tue, Feb 28, 2017 at 3:24 PM, Pieter Wuille wrote: > > Yes, someone needs to have a lookup table from prevouts to TXO tree > positions. But because an insertion-ordered TXO tree does not rebalance, > that table can be maintained by wallets or service providers for

Re: [bitcoin-dev] A Better MMR Definition

On Thu, Feb 23, 2017 at 7:15 PM, Peter Todd 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",

Re: [bitcoin-dev] A Better MMR Definition

On Thu, Feb 23, 2017 at 6:58 PM, Peter Todd 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

Re: [bitcoin-dev] A Better MMR Definition

On Thu, Feb 23, 2017 at 5:09 PM, Peter Todd 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

Re: [bitcoin-dev] A Better MMR Definition

On Thu, Feb 23, 2017 at 3:51 PM, Peter Todd 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 >

Re: [bitcoin-dev] A Better MMR Definition

On Thu, Feb 23, 2017 at 9:53 AM, Chris Priest via bitcoin-dev < bitcoin-dev@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

Re: [bitcoin-dev] A Better MMR Definition

On Wed, Feb 22, 2017 at 5:15 PM, Peter Todd via bitcoin-dev < bitcoin-dev@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

Re: [bitcoin-dev] Generalized Commitments

On Wed, Feb 22, 2017 at 5:26 PM, Peter Todd wrote: > > A commitment scheme needs only have the property that it's not feasible to > find > two messages m1 and m2 that map to the same commitment; it is *not* > required > that it be difficult to find m given the commitment.

[bitcoin-dev] Proposal for utxo commitment format

Here is a Merkle set data structure, whose format may be useful for utxo commitments in Bitcoin blocks. It may also be useful for any other distributed computation which wants an audit trail: https://github.com/bramcohen/MerkleSet This is a fairly straightforward Patricia Trie, with a simple

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

Miners individually have an incentive to include every transaction they can when they mine a block, but they also sometimes have an incentive to collectively cooperate to reduce throughput to make more money as a group. Under schemes where limits can be adjusted both possibilities must be taken

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

On Mon, Dec 5, 2016 at 7:27 AM, t. khan via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Put another way: let’s stop thinking about what the max block size should > be and start thinking about how full we want the average block to be > regardless of size. Over the last year,

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Sat, Jun 18, 2016 at 4:01 PM, Peter Todd wrote: > > Have you seen how BLAKE2 omits padding when the data to be hashed happens > to be > exactly one block in size? It's significantly faster than SHA256, and > that's a > standard part of the algorithm already. > That's very

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd <p...@petertodd.org> wrote: > On Tue, Jun 14, 2016 at 05:14:23PM -0700, Bram Cohen via bitcoin-dev wrote: > > > The fundamental approach to handling the latency problem is to have the > > utxo commitments trail a bit. Computin

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Thu, Jun 16, 2016 at 9:34 PM, Peter Todd wrote: > So above you said that in merbinner trees each node "hash[es] in a record > of > its depth" That's actually incorrect: each node commits to the prefix that > all > keys below that level start with, not just the depth. I

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Wed, Jun 15, 2016 at 8:26 PM, Peter Todd wrote: > > > > What do you mean by TXO commitments? If you mean that it only records > > insertions rather than deletions, then that can do many of the same > proofs > > but has no way of proving that something is currently in the

Re: [bitcoin-dev] Merkle trees and mountain ranges

On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd <p...@petertodd.org> wrote: > On Tue, Jun 14, 2016 at 05:14:23PM -0700, Bram Cohen via bitcoin-dev wrote: > > > > Peter proposes that there should be both UTXO and STXO commitments, and > > No, that's incorrect - I'm onl

[bitcoin-dev] Merkle trees and mountain ranges

This is in response to Peter Todd's proposal for Merkle Mountain Range commitments in blocks: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html I'm in strong agreement that there's a compelling need to put UTXO commitments in blocks, and that the big barrier to getting

[bitcoin-dev] How wallets can handle real transaction fees

(My apologies for a 'drive-by' posting. I'm not subscribed to this mailing list but this post may be of interest here. If you'd like to make sure I see a response send it to me directly. This post was originally posted to the web at