Re: [bitcoin-dev] Small Nodes: A Better Alternative to Pruned Nodes

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

Re: [bitcoin-dev] Per-block non-interactive Schnorr signature aggregation

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

Re: [bitcoin-dev] hypothetical: Could soft-forks be prevented?

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

Re: [bitcoin-dev] Updates on Confidential Transactions efficiency

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

Re: [bitcoin-dev] Should Graftroot be optional?

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

Re: [bitcoin-dev] Should Graftroot be optional?

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

Re: [bitcoin-dev] Should Graftroot be optional?

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

Re: [bitcoin-dev] Schnorr signatures BIP

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

Re: [bitcoin-dev] Schnorr signatures BIP

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.

Re: [bitcoin-dev] Taproot: Privacy preserving switchable scripting

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

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

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

Re: [bitcoin-dev] Schnorr signatures BIP

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 >

Re: [bitcoin-dev] Schnorr signatures BIP

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

[bitcoin-dev] BIP174 / PSBT extensions

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

Re: [bitcoin-dev] Timelocks and Lightning on MimbleWimble

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

Re: [bitcoin-dev] [Lightning-dev] OP_CAT was Re: Continuing the discussion about noinput / anyprevout

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

Re: [bitcoin-dev] New PSBT version proposal

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

Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements

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

Re: [bitcoin-dev] BIP-0322 (generic signmessage) improvements

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

Re: [bitcoin-dev] New PSBT version proposal

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

[bitcoin-dev] BIP-0322 (generic signmessage) improvements

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

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

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

Re: [bitcoin-dev] PSA: Taproot loss of quantum protections

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

Re: [bitcoin-dev] Provisions (was: PSA: Taproot loss of quantum protections)

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

Re: [bitcoin-dev] BIP - limiting OP_RETURN / HF

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

Re: [bitcoin-dev] Update on "Speedy" Trial: The circus rolls on

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 >

Re: [bitcoin-dev] Is there a tool like Ethereum EVM at present for Bitcoin script?

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

Re: [bitcoin-dev] Compressed Bitcoin Transactions

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

Re: [bitcoin-dev] Compressed Bitcoin Transactions

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

Re: [bitcoin-dev] Proposed BIP for OP_CAT

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.

Re: [bitcoin-dev] Proposed BIP for OP_CAT

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

Re: [bitcoin-dev] Ordinals BIP PR

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

Re: [bitcoin-dev] Ordinals BIP PR

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

Re: [bitcoin-dev] Proposed BIP for OP_CAT

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

Re: [bitcoin-dev] Proposed BIP for OP_CAT

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

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

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

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

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,

Re: [bitcoin-dev] Wallet policies for descriptor wallets

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,

Re: [bitcoin-dev] Ordinal Inscription Size Limits

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

Re: [bitcoin-dev] Codex32

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 "

Re: [bitcoin-dev] Codex32

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:

Re: [bitcoin-dev] Codex32

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

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

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.

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

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 >

Re: [bitcoin-dev] Testing censorship resistance of bitcoin p2p network

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 >

Re: [bitcoin-dev] Seeking concept ACKs for transaction terminology BIP

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

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

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

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

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

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

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 >

Re: [bitcoin-dev] Unenforceable fee obligations in multiparty protocols with Taproot inputs

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

Re: [bitcoin-dev] Debate: 64 bytes in OP_RETURN VS taproot OP_FALSE OP_IF OP_PUSH

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

Re: [bitcoin-dev] Blinded 2-party Musig2

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

Re: [bitcoin-dev] segwit naming ambiguity

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

Re: [bitcoin-dev] Compressed Bitcoin Transactions

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