Thanks Tom.
It looks like you posted a text-scrape of the rendered markdown, which
is hard to read. For posterity here is the full text.
Best
Andrew
=== begin compressed_transactions.md ===
# Compressed Transaction Schema
By (Tom Briar) and (Andrew Poelstra)
## 1. Abstract
With this Transact
On Tue, Oct 24, 2023 at 02:15:49PM +1030, Rusty Russell wrote:
> Andrew Poelstra writes:
> > I had a similar thought. But my feeling is that replacing the stack
> > interpreter data structure is still too invasive to justify the benefit.
> >
> > Also, one of my favorite things about this BIP is th
On Tue, Oct 24, 2023 at 11:18:24AM +1030, Rusty Russell wrote:
> Andrew Poelstra writes:
> >> 3. Should we restrict elsewhere instead? After all, OP_CAT doesn't
> >>change total stack size, which is arguably the real limit?
> >>
> >
> > Interesting thought. Right now the stack size is limite
On Mon, Oct 23, 2023 at 03:35:30PM +, Peter Todd via bitcoin-dev wrote:
>
> I have _not_ requested a BIP for OpenTimestamps, even though it is of much
> wider relevance to Bitcoin users than Ordinals by virtue of the fact that much
> of the commonly used software, including Bitcoin Core, is ti
On Fri, Oct 20, 2023 at 10:38:01PM -0700, Casey Rodarmor via bitcoin-dev wrote:
>
>
>
> There has been much misunderstanding of the nature of the BIP process.
> BIPS, in particular informational BIPs, are a form of technical
> documentation, and their acceptance does not indicate that they will b
On Mon, Oct 23, 2023 at 12:43:10PM +1030, Rusty Russell via bitcoin-dev wrote:
> Ethan Heilman via bitcoin-dev writes:
> > Hi everyone,
> >
> > We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> > https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
>
> Thi
On Sat, Oct 21, 2023 at 01:08:03AM -0400, Ethan Heilman via bitcoin-dev wrote:
> Hi everyone,
>
> We've posted a draft BIP to propose enabling OP_CAT as Tapscript opcode.
> https://github.com/EthanHeilman/op_cat_draft/blob/main/cat.mediawiki
>
> OP_CAT was available in early versions of Bitcoin.
Hi Fabian,
We did consider indexing all txos -- even, amusingly, by using ordinals --
but decided that the extra index requirements for the decompressor (which
otherwise just requires a bit of extra CPU cycles but nothing beyond a
normal Core node).
A while ago we looked into putting the whole UT
On Thu, Aug 31, 2023 at 09:30:16PM +, Tom Briar via bitcoin-dev wrote:
> Hey everyone,
>
> I've been working on a way to compress bitcoin transactions for transmission
> throughsteganography, satellite broadcasting,
> and other low bandwidth channels with high CPU availability on decompressio
On Fri, Aug 11, 2023 at 02:45:57PM +1000, Tobin Harding via bitcoin-dev wrote:
> Question for OG bitcoin API designers please.
>
> If you were to see the following function
>
> `is_segwit()`
>
> would you assume it returns `true` or `false` for a p2tr transaction?
>
>
> Currently we (rust-
On Wed, Jul 26, 2023 at 12:09:41AM -0400, Erik Aronesty via bitcoin-dev wrote:
> personally, i think *any* time a public key is transmitted, it should come
> with a "proof of secret key". it should be baked-in to low level
> protocols so that people don't accidentally create vulns. alt discussio
On Wed, Apr 05, 2023 at 02:54:15PM -0400, Murch via bitcoin-dev wrote:
> Hey everyone,
>
> Over the years, I have participated in a few conversations about various
> aspects of transactions. Often a chunk of the conversation is spent on
> establishing a shared vocabulary. There are many competing
On Wed, Feb 15, 2023 at 09:16:02PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> I've been asked by Dr. Curr and Professor Snead to forward this message to
> this mailing list, as it may be of general interest to Bitcoin users.
>
>
>
I have opened a PR to the BIPs repo for this scheme:
https
On Sun, Feb 19, 2023 at 10:13:33AM -1000, David A. Harding wrote:
> On 2023-02-16 03:49, Andrew Poelstra via bitcoin-dev wrote:
> > the draft lists several benefits over SLIP-0039.
>
> The only benefit over SLIP39 that I see explicitly mentioned in the
> draft BIP is "
On Sat, Feb 18, 2023 at 02:03:15AM +0200, Peter Todd wrote:
> On February 18, 2023 1:35:34 AM GMT+02:00, Andrew Poelstra via bitcoin-dev
> >You could try statically analyze `` to determine whether the
> >IF branch could ever be taken. For example there is no path through
>
On Fri, Feb 17, 2023 at 11:35:34PM +, Andrew Poelstra via bitcoin-dev wrote:
>
> If you ban any of these specific script fragments then spammers will
> just use `IF ENDIF` and provide the `FALSE` as a zero push.
> And banning *this* would ban legitimate use cases.
>
I
On Fri, Feb 17, 2023 at 03:56:31PM +0100, vjudeu via bitcoin-dev wrote:
> > [0]: https://gist.github.com/luke-jr/4c022839584020444915c84bdd825831
>
> I wonder how far should that rule go: SCRIPT_ERR_DISCOURAGE_UPGRADABLE_NOPS.
> Because "OP_FALSE OP_IF OP_ENDIF" is effectively the same as
> "OP
On Thu, Feb 16, 2023 at 12:50:12PM +0100, Pavol Rusnak via bitcoin-dev wrote:
> Hi!
>
> The BIP states that its only advantage over SLIP-0039, which has been used
> in production for nearly three years (in at at least 3 SW/HW wallet
> implementations), is that it aims to be simple enough for hand
On Wed, Feb 08, 2023 at 09:34:57AM +, Michael Folkson wrote:
> Hi Andrew
>
> > 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 tha
Some people highlighted some minor problems with my last email:
On Tue, Feb 07, 2023 at 01:46:22PM +, Andrew Poelstra via bitcoin-dev wrote:
>
>
>
> [1] https://bitcoin.sipa.be/miniscript/
> [2] In Taproot, if you want to prevent signatures migrating to another
>
On Tue, Feb 07, 2023 at 04:49:28AM +0200, Yuval Kogman via bitcoin-dev wrote:
>
> Since Taproot (more generally any kind of MAST) spends have variable size
> which
> depends on the path being used, the last such input to be signed in a
> multiparty
> transaction can always use a larger than esti
On Sat, Feb 04, 2023 at 07:11:35PM -0500, Russell O'Connor via bitcoin-dev
wrote:
> Since bytes in the witness are cheaper than bytes in the script pubkey,
> there is a crossover point in data size where it will simply be cheaper to
> use witness data. Where that crossover point is depends on the
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
> wrote:
> >All other things being equal, which is better if you need to place a
> >64-bytes into the Bitcoin blockchain? A traditional OP_RETU
On Fri, Jan 27, 2023 at 09:44:10AM -0300, Robert Dickinson via bitcoin-dev
wrote:
> I'm curious what opinions exist and what actions might be taken by core
> developers regarding storing unlimited amounts of NFT (or other?) content
> as witness data (https://docs.ordinals.com/inscriptions.html). T
On Mon, Oct 17, 2022 at 07:07:07PM -0500, Bryan Bishop via bitcoin-dev wrote:
>
> Isn't this the same problem but now for copy-pasting pubkeys instead of an
> address?
>
No, as I understand the proposal, the "public key" held by the wallet is simply
a signing key used to authenticate addresses, a
I'm really happy to see this discussion. I don't have any comments on the spec
because I think I'd have to be more in-the-weeds trying to implement a hww to
understand how well it works for realistic use cases. But a strong concept-ACk
from me and thanks to Salvatore for exploring this!
On Mon, M
On Tue, Jun 14, 2022 at 01:15:08PM -0400, Undiscussed Horrific Abuse, One
Victim of Many via bitcoin-dev wrote:
> I'm replying to Peter, skipping the other emails.
>
> I perceive all these emails as disruptive trolling, ignoring the
> importance of real timestamping, while handwaving about things
Simplicity does not compile to Bitcoin Script, and Sapio assumes extensions
to Bitcoin Script that are not currently part of the consensus code.
On Tue, Aug 24, 2021 at 03:36:29PM +0800, Gijs van Dam via bitcoin-dev wrote:
> Hi,
>
>
> Bitcoin does not have a virtual machine. But you do have [M
On Fri, Apr 16, 2021 at 03:34:33PM +, Christopher Gilliard via bitcoin-dev
wrote:
> This sounds like a good justification to remove the legacy multi-signature
> capabilities as well.
>
Doing so would confiscate coins, and also it is impossible to remove
legacy multisignatures in general witho
On Thu, Apr 08, 2021 at 12:40:42PM +0100, Michael Folkson via bitcoin-dev wrote:
>
> All of this makes me extremely uncomfortable and I dread to think what
> individuals and businesses all over the world who have plans to
> utilize and build on Taproot are making of all of this. As an
> individual
On Tue, Mar 16, 2021 at 03:10:21PM +0100, Andrea via bitcoin-dev wrote:
>
> Hi! Sorry for the OT, could you provide some references to ring signatures
> over/for/via taproot (I mean the schema or something like that)? And what is
> "Provisions" (the capital letter makes me think it's a product/tec
On Tue, Mar 16, 2021 at 03:44:25AM +, Luke Dashjr wrote:
> (To reiterate: I do not intend any of this as a NACK of Taproot.)
>
Thanks, although it's still somewhat frustrating to be rehashing this
discussion again after so many years.
> On Monday 15 March 2021 23:12:18 Andrew Poelstra wrote:
On Mon, Mar 15, 2021 at 09:48:15PM +, Luke Dashjr via bitcoin-dev wrote:
> Also, what I didn't know myself until today, is that we do not actually gain
> anything from this: the features proposed to make use of the raw keys being
> public prior to spending can be implemented with hashed keys
On Tue, Dec 22, 2020 at 12:22:37AM +, Pieter Wuille via bitcoin-dev wrote:
>
> Re-reading your proposed text, I'm wondering if the "consensus-only
> validation" extension is intended to replace the
> inconclusive-due-to-consensus-and-standardness-differ state. If so, I don't
> think it does
On Wed, Dec 23, 2020 at 12:30:20AM -0300, fiatjaf via bitcoin-dev wrote:
> Hi Andrew.
>
> I'm just a lurker here and I have not much experience with PSBTs, but still
> let me pose this very obvious question and concern: isn't this change going
> to create a compatibility nightmare, with some sof
On Tue, Dec 22, 2020 at 12:22:37AM +, Pieter Wuille via bitcoin-dev wrote:
>
> Re-reading your proposed text, I'm wondering if the "consensus-only
> validation" extension is intended to replace the
> inconclusive-due-to-consensus-and-standardness-differ state. If so, I don't
> think it does
I have gone over BIP-0322 and substantially rewritten the text.
Everything I did is (I think) simply clarifying the existing
protocol, which felt like it was written by committee and wasn't
easy to follow, EXCEPT:
1. I rewrote the motivation section, which I believe originally
was a paraphrase
On Wed, Dec 09, 2020 at 10:25:37PM +, Andrew Chow via bitcoin-dev wrote:
> Hi All,
>
> I would like to propose a new PSBT version that addresses a few
> deficiencies in the current PSBT v0. As this will be backwards
> incompatible, a new PSBT version will be used, v1.
>
> The primary change
On Thu, Oct 03, 2019 at 11:05:52AM -0400, Ethan Heilman wrote:
> To avoid derailing the NO_INPUT conversation, I have changed the
> subject to OP_CAT.
>
> Responding to:
> """
> * `SIGHASH` flags attached to signatures are a misdesign, sadly
> retained from the original BitCoin 0.1.0 Alpha for Win
On Fri, Sep 20, 2019 at 04:54:34AM +1000, Lloyd Fournier via bitcoin-dev wrote:
> Hi ZmnSCPxj,
>
> I can give some context on the exchange during the talk. I was the "Q" and
> Andrew Polestra was the "A".
>
> I followed up with Andrew after and he indeed knew about the pre-signed
> nlocktime tran
Hi all,
I'd like to start initial discussion about an extension to BIP174 [1] to add
some fields that I've found myself wanting when using PSBT in practice. For
now I'll just list the things that I'd like to see, and if we can come up
with a stable list then I'll try to write up a more formal dra
Hi Erik,
Sorry, you're right - I thought we mentioned m-of-n as a footnote but that was
actually in the earlier pre-MuSig version of our multisig paper.
Threshold signatures -are- mentioned in the BIP which started this thread,
though.
At https://github.com/sipa/bips/blob/bip-schnorr/bip-schnor
On Tue, Sep 11, 2018 at 01:37:59PM -0400, Erik Aronesty via bitcoin-dev wrote:
> - Musig, by being M of M, is inherently prone to loss.
>
It has always been possible to create M-of-N threshold MuSig signatures for any
M, N with 0 < M ≤ N. This is (a) obvious, (b) in our paper, (c) implemented at
On Wed, Sep 05, 2018 at 08:26:14AM -0400, Erik Aronesty wrote:
> Why would you call it FUD? All the weird hemming and hawing about it is
> really strange to me. The more I look into it and speak to professors
> about i, the more it seems "so trivial nobody really talks about it".
>
> 1. Generat
On Wed, Aug 29, 2018 at 08:09:36AM -0400, Erik Aronesty wrote:
> Note:
>
> This spec cannot be used directly with a shamir scheme to produce
> single-round threshold multisigs, because shares of point R would need to
> be broadcast to share participants in order to produce valid single
> signature
I think it's just an oversight. We should specify that we use the standard
encoding from section 2.3 of http://www.secg.org/sec1-v2.pdf except that
we allow only compressed public keys.
Andrew
On Mon, Aug 06, 2018 at 11:12:48PM +0200, Tim Ruffing via bitcoin-dev wrote:
> Is it intentional that
On Thu, May 24, 2018 at 11:44:16AM +0200, Natanael via bitcoin-dev wrote:
>
> As stated above by Wuille this seems to not be a concern for typical P2SH
> uses, but my argument here is simply that in many cases, not all
> stakeholders in a transaction will hold one of the private keys required to
>
On Wed, May 23, 2018 at 01:50:13PM +, Andrew Poelstra via bitcoin-dev wrote:
>
> Graftroot also break blind signature schemes. Consider a protocol such as [1]
> where some party has a bunch of UTXOs all controlled (in part) by the same
> key X. This party produces blind signature
On Tue, May 22, 2018 at 11:17:42AM -0700, Pieter Wuille via bitcoin-dev wrote:
>
> Given the recent discussions about Taproot [1] and Graftroot [2], I
> was wondering if a practical deployment needs a way to explicitly
> enable or disable the Graftroot spending path. I have no strong
> reasons why
On Wed, Mar 21, 2018 at 02:06:18PM +1000, Anthony Towns via bitcoin-dev wrote:
>
> That leads me to think that interactive signature aggregation is going to
> take a lot of time and work, and it would make sense to do a v1-upgrade
> that's "just" Schnorr (and taproot and MAST and re-enabling opcod
On Tue, Jan 23, 2018 at 10:45:06PM +, Gregory Maxwell via bitcoin-dev wrote:
> On Tue, Jan 23, 2018 at 10:22 PM, Anthony Towns wrote:
> > Hmm, at least people can choose not to reuse addresses currently --
> > if everyone were using taproot and that didn't involve hashing the key,
>
> Can you
To follow up on the remarkable work Greg announced from Benedikt Bünz (Stanford)
and Jonathan Bootle (UCL) on Bulletproofs: https://eprint.iacr.org/2017/1066
Summary
=
Over the last couple weeks, along with Jonas Nick, Pieter Wuille, Greg Maxwell
and Peter Dettmann, I've implemented the s
On Fri, Sep 15, 2017 at 10:40:12PM +0200, Simone Bronzini via bitcoin-dev wrote:
> Since a soft-fork is a restriction of the consensus rules, I think the
> only way to have an un-soft-forkable cryptocurrency is creating a
> cryptocurrency where no transaction is valid.
>
Even this can be soft-for
On Tue, May 09, 2017 at 09:59:06PM -0400, Russell O'Connor via bitcoin-dev
wrote:
> I'm a bit amateur at this sort of thing, but let me try to argue that this
> proposal is in fact horribly broken ;)
>
> Suppose Alice has some UTXO with some money Bob wants to steal. Grant me
> that the public k
On Thu, Apr 20, 2017 at 11:46:33AM +0200, Tom Zander via bitcoin-dev wrote:
> On Wednesday, 19 April 2017 19:30:30 CEST David Vorick via bitcoin-dev
> wrote:
> > > I suggested something similar which is a much simpler version;
> > > https://zander.github.io/scaling/Pruning/
>
> > Your proposal ha
55 matches
Mail list logo