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:
>
> https://merkl
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
capa
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 followin
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
>
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
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 inflat
is. Just encode the index 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 <
> bitco
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 h
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 abo
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
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 exi
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
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 a
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
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 use
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 unless
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
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 b
>
> 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
>
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,
Gloria Zhao wrote:
>
> This post discusses limitations of current Bitcoin Core RBF policy and
> attempts to start a conversation about how we can improve it,
> summarizing some ideas that have been discussed. Please reply if you
> have any new input on issues to be solved and ideas for improvement
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 specif
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
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 a
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 capa
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 gene
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
on
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 wha
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 wrote:
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 kno
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 e
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
Graftr
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
f
On Mon, Mar 26, 2018 at 11:34 PM, Anthony Towns 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 there should be a 'real'
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 later
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 i
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 chu
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 th
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 u
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" band
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, Grego
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 giv
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 h
On Sat, Apr 1, 2017 at 6:58 PM, praxeology_guy <
praxeology_...@protonmail.com> wrote:
> Bram Cohen,
>
> In R&D: 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
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 talk
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
late
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 [(TX_f
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
> you did
> this, you
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 n
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 a
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 weighted
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 ma
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 thing
On Tue, Mar 7, 2017 at 1:28 PM, praxeology_guy via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> merkle tree hashes:
> - array of "piece count" leaf hashes, hashing the balance pieces
> - array of "(child layer count + 1)/2" node hashes, hashing pairs of child
> hashes, or copyin
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 just their
> own coins, inste
On Tue, Feb 28, 2017 at 8:43 AM, G. Andrew Stone
wrote:
>
> But since transactions' prevouts are not specified by [block height, tx
> index, output index] or by TXO index, I don't understand how an insertion
> ordered TXO tree can result in efficient lookups. Can you help me
> understand this?
>
On Fri, Feb 24, 2017 at 8:12 PM, Peter Todd wrote:
>
> 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!
>
I'm not 'proposing' this, I'm saying it could be done simply but I'm
skepti
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?
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
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", obviously to be merkelized
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 done, but apples to appl
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 current state
> of an
> out
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
> are
>
> In what way d
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 c
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 c
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. Equally, it's not
> requ
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 form
On Sun, Dec 11, 2016 at 1:40 PM, t. khan via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Block75 is not exponential scaling. It's true the max theoretical increase
> in the first year would be 7x, but the next year would be a max of 2x, and
> the next could only increase by 50%
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
int
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, we’
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 convenient! I didn't
On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd 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. Computing utxo commitments takes a
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 considered a similar t
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 UTXO set,
> > which is
On Wed, Jun 15, 2016 at 5:10 PM, Peter Todd 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 only proposing TXO c
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
(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
https://medium.com/@bramcohen/how-wallets-can-handle-transaction-f
76 matches
Mail list logo
