Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

2021-12-12 Thread Pieter Wuille via bitcoin-dev
On Sunday, December 12th, 2021 at 9:23 AM, Aymeric Vitte via bitcoin-dev wrote: > Using the Tor network to bypass censorship for bitcoin can work but is a very > poor solution, the Tor network is very centralized, very small, watched and > controlled, with plenty of features that do not apply

Re: [bitcoin-dev] Rebroadcast mechanism in Bitcoin P2P network

2021-12-11 Thread Pieter Wuille via bitcoin-dev
> It is that the solution to privacy is to use privacy-enhancing network > communications, such as TOR. I am not against a mechanism to rebroadcast > transactions more robustly if the mempool of adjoining nodes has > forgotten about them, but the truth is, all transactions originate from > some

Re: [bitcoin-dev] Taproot Fields for PSBT

2021-11-24 Thread Pieter Wuille via bitcoin-dev
On Wednesday, November 24th, 2021 at 7:44 AM, Sjors Provoost via bitcoin-dev wrote: > Hi Andrew, > > I'm confused why PSBT_IN_TAP_BIP32_DERIVATION and > PSBT_OUT_TAP_BIP32_DERIVATION > contain not just the derivation path for the xonlypubkey, but also the > tapleaf merkle path. > > First I

Re: [bitcoin-dev] bitcoinj fork with Taproot support

2021-11-17 Thread Pieter Wuille via bitcoin-dev
On Wednesday, November 17th, 2021 at 1:07 PM, Andrew Chow via bitcoin-dev wrote: > Prior to 0.19.0, creating outputs with an unknown witness version was > considered non-standard. This was a violation of BIP 173 and was fixed for > 0.19.0+ in PR #15846. That's correct, but I think OP's

[bitcoin-dev] BIP341 test vectors for wallet implementations

2021-11-01 Thread Pieter Wuille via bitcoin-dev
Hi all, I wanted to bring some attention to a set of test vectors I'm proposing to add to BIP341 in https://github.com/bitcoin/bips/pull/1225. These are focused on wallet implementations, covering Merkle root / tweak / scriptPubKey computation from key/scripts, sigmsg/sighash/signature

Re: [bitcoin-dev] death to the mempool, long live the mempool

2021-10-26 Thread Pieter Wuille via bitcoin-dev
On Monday, October 25th, 2021 at 10:56 PM, lisa neigut via bitcoin-dev wrote: > Hi all, > > In a recent conversation with @glozow, I had the realization that the mempool > is obsolete and should be eliminated. Hi Lisa, I see where this idea is coming from, especially as it relates to

Re: [bitcoin-dev] bitcoin.org missing bitcoin core version 22.0

2021-10-20 Thread Pieter Wuille via bitcoin-dev
On Wednesday, October 20th, 2021 at 3:20 PM, Owen Gunden via bitcoin-dev wrote: > I also notice that, as of 22.0, Wladimir is no longer signing the > releases, and I have no trust in my gpg network of the people who seem > to have replaced him. This is not correct. Here are Wladimir's

Re: [bitcoin-dev] Taproot testnet wallet

2021-10-09 Thread Pieter Wuille via bitcoin-dev
On Oct 9, 2021, 11:36, Andreas Schildbach via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I'm trying to finish off bitcoinj's implementation for sending to taproot addresses. For this, I'd like to test against a wallet that can receive to P2TR and spend back. > I've been

Re: [bitcoin-dev] [Lightning-dev] Removing the Dust Limit

2021-10-01 Thread Pieter Wuille via bitcoin-dev
Jumping in late to this thread. I very much agree with how David Harding presents things, with a few comments inline. ‐‐‐ Original Message ‐‐‐ On Sunday, August 8th, 2021 at 5:51 PM, David A. Harding via bitcoin-dev wrote: > > 1. it's not our business what outputs people want to

Re: [bitcoin-dev] Test cases for Taproot signature message

2021-09-16 Thread Pieter Wuille via bitcoin-dev
On Thursday, September 16th, 2021 at 5:36 PM, Giacomo Caironi via bitcoin-dev wrote: > Hi, > recently I have worked on a python implementation of bitcoin signature > messages, and I have found that there was way better documentation about > Segwit signature message than Taproot. > > 1) Segwit

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

2021-08-29 Thread Pieter Wuille via bitcoin-dev
On Thursday, August 19th, 2021 at 1:02 PM, ts via bitcoin-dev wrote: > > In any case --- the last 5 characters of a bech32 string are already a > > human-readable 5-digit code, with fairly good properties, why is it not > > usable for this case? Side note: it's actually the last six

Re: [bitcoin-dev] Using transaction version number in different projects

2021-08-29 Thread Pieter Wuille via bitcoin-dev
On Sunday, August 29th, 2021 at 5:32 AM, Prayank via bitcoin-dev wrote: > Wanted to know if others think we should allow more numbers in transaction > version by considering such transaction standard. I have shared an example > how transaction version can be used to bet on something that

Re: [bitcoin-dev] Human readable checksum (verification code) to avoid errors on BTC public addresses

2021-08-29 Thread Pieter Wuille via bitcoin-dev
On Saturday, August 28th, 2021 at 5:17 PM, ts via bitcoin-dev wrote: > Following up on my original proposal, I would like to get some more feedback > of the community > > to see if this could be realized at some point. Also, any recommendations as > to who to contact > > to get things

Re: [bitcoin-dev] An idea to block invalid addresses from reaching the peers.dat buckets

2021-07-12 Thread Pieter Wuille via bitcoin-dev
> This is an interesting read: https://bitcointalk.org/index.php?topic=5348856.0 > > So according to this, somebody is spamming the bitcoin network with addr > message pointing to invalid addresses and ports, which bloats the peers.dat > and corresponding structure in memory. The peers.dat file

Re: [bitcoin-dev] Proposal to stop processing of unrequested transactions in Bitcoin Core

2021-02-11 Thread Pieter Wuille via bitcoin-dev
> I'm not sure of the existing behavior is of when we issue a getdata request, > but noting that there could be a privacy implication of this sort of change. > Could you (or someone else) expand on why this is not a concern here? What kind of privacy concern are you talking about? I'm not sure

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

2021-02-11 Thread Pieter Wuille via bitcoin-dev
‐‐‐ Original Message ‐‐‐ On Thursday, February 11, 2021 6:38 AM, Dr Maxim Orlovsky wrote: > Thank you very much for all the clarifications; it’s good to have them sorted > out and clearly structured. From what you wrote it follows that we still need > to reserve a dedicated purpose

Re: [bitcoin-dev] BIP32/43-based standard for Schnorr signatures & decentralized identity

2021-02-05 Thread Pieter Wuille via bitcoin-dev
On Friday, February 5, 2021 9:51 AM, Dr Maxim Orlovsky via bitcoin-dev wrote: > Hi, > > Background > > > > Had a discussion last night in Bitcoin Core IRC with Peter Wuille on > different topics regarding key derivations, security, key tweaks in context > of Schnorr

Re: [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address

2021-01-19 Thread Pieter Wuille via bitcoin-dev
On Tuesday, January 19, 2021 4:23 PM, nakagat wrote: > Dear. Pieter, > > My idea is exactly what you wrote. > > However, I don't think it is the same as "checksum = hash (hrp, data)". No, it is not the same. But it has the same error-detection properties as just a hash. Hash-based checksums

Re: [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address

2021-01-19 Thread Pieter Wuille via bitcoin-dev
On Sunday, January 17, 2021 9:59 PM, nakagat wrote: > I thought that BECH32M_CONST could be created from hrp and data > instead of constants. > > I thought that the error position would be the same as bech32 by > recalculating the value created from hrp and data. So, bech32 can be written as:

Re: [bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address

2021-01-04 Thread Pieter Wuille via bitcoin-dev
On Monday, January 4, 2021 4:14 PM, Pieter Wuille wrote: > Hello all, > > here is a BIP draft for changing the checksum in native segwit addresses for > v1 and higher, following the discussion in > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018293.html > > Overall,

[bitcoin-dev] Bech32m BIP: new checksum, and usage for segwit address

2021-01-04 Thread Pieter Wuille via bitcoin-dev
Hello all, here is a BIP draft for changing the checksum in native segwit addresses for v1 and higher, following the discussion in https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2020-December/018293.html Overall, the idea is: * Define a new encoding which is a tweaked variant of

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

2020-12-21 Thread Pieter Wuille via bitcoin-dev
On Monday, December 21, 2020 2:57 PM, Pieter Wuille via bitcoin-dev wrote: > On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > Thanks a lot for taking the time to brush up the BIP. For what it's >

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

2020-12-21 Thread Pieter Wuille via bitcoin-dev
On Sunday, December 20, 2020 9:37 PM, Karl-Johan Alm via bitcoin-dev wrote: > Thanks a lot for taking the time to brush up the BIP. For what it's > worth, I am all for these changes, and I see them as clear > improvements all around. > > IIRC Pieter was the one who originally suggested the

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-12-17 Thread Pieter Wuille via bitcoin-dev
On Tuesday, December 8, 2020 9:39 AM, Ryan Grant wrote: > It looks like a good strategy for a bech32 library that is external to > Bitcoin Core would be: > > - Default to the new M, under the same bech32 brand. > - Provide an interface to explicitly use both M=1 and M=0x2bc830a3. > - If

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-12-06 Thread Pieter Wuille via bitcoin-dev
‐‐‐ Original Message ‐‐‐ On Sunday, December 6, 2020 5:04 AM, David A. Harding wrote: > On Sat, Dec 05, 2020 at 11:10:51PM +0000, Pieter Wuille via bitcoin-dev wrote: > > > I think these results really show there is no reason to try to > > maintain the old

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-12-05 Thread Pieter Wuille via bitcoin-dev
> On Wednesday, October 7, 2020 5:21 PM, Rusty Russell via bitcoin-dev > bitcoin-dev@lists.linuxfoundation.org wrote: > > > I propose an alternative to length restrictions suggested by > > Russell in https://github.com/bitcoin/bips/pull/945: use the > >

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-12-05 Thread Pieter Wuille via bitcoin-dev
On Friday, November 6, 2020 11:49 AM, Mike Schmidt via bitcoin-dev wrote: > Well I sure picked a bad couple weeks to volunteer to send a bunch of Bitcoin > test transactions... > > While I tested less than I would have liked, there are some notable results: I think these results really show

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-10-27 Thread Pieter Wuille via bitcoin-dev
On Wednesday, October 7, 2020 5:21 PM, Rusty Russell via bitcoin-dev wrote: > I propose an alternative to length restrictions suggested by > Russell in https://github.com/bitcoin/bips/pull/945: use the > https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb variant, > unless the first

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-10-20 Thread Pieter Wuille via bitcoin-dev
On Tuesday, October 20, 2020 3:29 AM, David A. Harding wrote: > I would guess that some of the failures / stuck transactions might now be > successes if the backend infrastructure has upgraded to Bitcoin Core > = 0.19. Yeah, it would be good to re-test them since a ~year has passed since the

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-10-19 Thread Pieter Wuille via bitcoin-dev
On Sunday, October 18, 2020 5:49 PM, Rusty Russell wrote: > Pieter Wuille bitcoin-...@wuille.net writes: > > > Today, no witness v1 receivers exist. So it seems to me the only question > > is what software/infrastructure exist that supports sending to witness v1, > > and whether they (and their

Re: [bitcoin-dev] Is BIP32's chain code needed?

2020-10-16 Thread Pieter Wuille via bitcoin-dev
On Tuesday, September 29, 2020 10:34 AM, Leonardo Comandini via bitcoin-dev wrote: > Hi all, > > BIP32 [1] says: "In order to prevent these from depending solely on the key > itself, we extend both private and public keys first with an extra 256 bits of > entropy. This extension, called the

Re: [bitcoin-dev] Suggestion: Solve year 2106 problem by taking timestamps mod 2^32

2020-10-16 Thread Pieter Wuille via bitcoin-dev
On Saturday, September 19, 2020 5:36 AM, yanmaani--- via bitcoin-dev wrote: > Currently, Bitcoin's timestamp rules are as follows: > > 1. The block timestamp may not be lower than the median of the last 11 > blocks' > > 2. The block timestamp may not be greater than the current time plus

Re: [bitcoin-dev] Progress on bech32 for future Segwit Versions (BIP-173)

2020-10-16 Thread Pieter Wuille via bitcoin-dev
Hi Rusty, thanks for starting this thread. We definitely should make a decision around this soon. On Wednesday, October 14, 2020 6:40 PM, Rusty Russell via bitcoin-dev wrote: > > > Here's a summary of each proposal: > > > Length restrictions (future segwits must be 10, 13, 16, 20, 23, 26, 29,

Re: [bitcoin-dev] Progress on Miner Withholding - FPNC

2020-10-07 Thread Pieter Wuille via bitcoin-dev
On Wednesday, October 7, 2020 1:31 PM, Mike Brooks via bitcoin-dev wrote: > But first of all, I'd like to say that the idea for FPNC came out of a > conversation with ZmnSCPxj's in regards to re-org stability. When I had > proposed blockchain pointers with the PubRef opcode, he took the time

Re: [bitcoin-dev] Revisiting squaredness tiebreaker for R point in BIP340

2020-08-26 Thread Pieter Wuille via bitcoin-dev
On Friday, August 21, 2020 1:50 AM, John Newbery via bitcoin-dev wrote: > Summary: We should change the proposal and implementation to use even > tie-breakers everywhere. > > John #notoquadraticresiduetiebreakers Newbery Thanks Nadav, Lloyd, John, and those who commented privately, As the

Re: [bitcoin-dev] Revisiting squaredness tiebreaker for R point in BIP340

2020-08-19 Thread Pieter Wuille via bitcoin-dev
On Wednesday, August 12, 2020 11:49 AM, Pieter Wuille wrote: > It is late in the process, but I feel I owe this explanation so that at least > the possibility of changing can be discussed with all information. As the responses have been pretty positive so far, we've gone ahead and made a

[bitcoin-dev] Revisiting squaredness tiebreaker for R point in BIP340

2020-08-12 Thread Pieter Wuille via bitcoin-dev
Hello all, The current BIP340 draft[1] uses two different tiebreakers for conveying the Y coordinate of points: for the R point inside signatures squaredness is used, while for public keys evenness is used. Originally both used squaredness, but it was changed[2] for public keys after observing

Re: [bitcoin-dev] BIP-341: Committing to all scriptPubKeys in the signature message

2020-05-11 Thread Pieter Wuille via bitcoin-dev
Hi all, On Tuesday, May 5, 2020 3:20 AM, Jonas Nick via bitcoin-dev wrote: > This is a reasonable suggestion. Committing to every spent scriptPubKey and > therefore every element of the TxOut instead of just the amount makes sense > conceptually. And it would be a small diff (~4 lines +

Re: [bitcoin-dev] Mitigating Differential Power Analysis in BIP-340

2020-03-24 Thread Pieter Wuille via bitcoin-dev
On Tuesday, March 24, 2020 6:00 AM, Lloyd Fournier via bitcoin-dev wrote: > Hi List, > > I felt this topic deserved it's own thread but it follows on from the mailing > list post [2] announcing a new PR [1] to change BIP-340 in several ways, > including adding random auxiliary data into the

[bitcoin-dev] Overview of anti-covert-channel signing techniques

2020-03-03 Thread Pieter Wuille via bitcoin-dev
Hi all, Given the recent activity and attention [1,2] around anti-covert channel signing schemes, I decided to create this overview of the various techniques that I know of, their trade-offs, and the various issues they protect against. Most of this is based on various schemes by a number of

[bitcoin-dev] BIP 340 updates: even pubkeys, more secure nonce generation

2020-02-23 Thread Pieter Wuille via bitcoin-dev
Hello list, Despite saying earlier that I expected no further semantical changes to BIP 340-342, I've just opened https://github.com/bitcoin/bips/pull/893 to make a number of small changes that I believe are still worth making. 1. Even public keys Only one change affects the validation rules:

Re: [bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

2020-02-18 Thread Pieter Wuille via bitcoin-dev
On Fri, 14 Feb 2020 at 14:37, David A. Harding via bitcoin-dev wrote: > > On Fri, Feb 14, 2020 at 12:07:15PM -0800, Jeremy via bitcoin-dev wrote: > > Is the same if Schnorr + Merkle Branch without Taproot optimization, unless > > I'm missing something in one of the cases? > > That's fair.

Re: [bitcoin-dev] Analysis of Bech32 swap/insert/delete detection and next steps

2019-12-09 Thread Pieter Wuille via bitcoin-dev
> > So my suggestion for the next steps are: > > > > - Update BIP173 to include the insertion weakness as an erratum, and > > the results of this analysis. > > > > To clarify, this step does not modify anything about the implementation of > BIP173, only adds this as an additional erratum

[bitcoin-dev] Analysis of Bech32 swap/insert/delete detection and next steps

2019-12-09 Thread Pieter Wuille via bitcoin-dev
Hi all, I've made a writeup on Bech32's detection abilities, analysing how it behaves in the presence of not just substitution errors, but also swapping of characters, and insertions and deletions: https://gist.github.com/sipa/a9845b37c1b298a7301c33a04090b2eb It shows that the "insert or delete

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

2019-11-12 Thread Pieter Wuille via bitcoin-dev
On Tue, Nov 12, 2019, 21:33 ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good morning all, > > It seems to me that adding the length for checksumming purposes need not > require the length to be *actually* added in the address format. > Indeed! This has the

Re: [bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

2019-11-10 Thread Pieter Wuille via bitcoin-dev
On Thu, Nov 7, 2019, 18:16 David A. Harding wrote: > On Thu, Nov 07, 2019 at 02:35:42PM -0800, Pieter Wuille via bitcoin-dev > wrote: > > In the current draft, witness v1 outputs of length other > > than 32 remain unencumbered, which means that for now such an > > in

[bitcoin-dev] Bech32 weakness and impact on bip-taproot addresses

2019-11-07 Thread Pieter Wuille via bitcoin-dev
Hello all, A while ago it was discovered that bech32 has a mutation weakness (see https://github.com/sipa/bech32/issues/51 for details). Specifically, when a bech32 string ends with a "p", inserting or erasing "q"s right before that "p" does not invalidate it. While insertion/erasure robustness

[bitcoin-dev] Taproot updates

2019-10-09 Thread Pieter Wuille via bitcoin-dev
Hi all, I wanted to give an update on some of the changes we've made to the bip-schnorr/taproot/tapscript drafts following discussions on this list: * The original post: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016914.html and follow-ups * Using 2 or 4 byte indexes:

Re: [bitcoin-dev] Taproot proposal

2019-09-18 Thread Pieter Wuille via bitcoin-dev
On Mon, 16 Sep 2019 at 21:10, ZmnSCPxj via bitcoin-dev wrote: > ‐‐‐ Original Message ‐‐‐ > > I'd prefer to not support P2SH-nested TR. P2SH wrapping was useful for > > segwit > > v0 for compatibility reasons. Most wallets/exchanges/services now support > > sending > > to native segwit

[bitcoin-dev] bip-tapscript resource limits

2019-09-18 Thread Pieter Wuille via bitcoin-dev
Hi all, In the draft for bip-tapscript (see [1], current version [2]), we propose removing the per-block sigops limit for tapscript scripts, and replacing it with a "every script gets a budget of sigops based on its witness size (one per 50 WU)". Since signatures (plus pubkeys) take more WU than

Re: [bitcoin-dev] testing bitcoin nodes

2019-08-21 Thread Pieter Wuille via bitcoin-dev
On Tue, 6 Aug 2019 at 09:57, Niels Thijssen via bitcoin-dev wrote: > > Hi, > > I'm working as (software) test specialist and run private a full bitcoin node > (based upon Raspberry Pi 4). > I've been trying to figure out the tests performed during > installation/upgrade/compilation of the

[bitcoin-dev] Miniscript

2019-08-19 Thread Pieter Wuille via bitcoin-dev
Hi all, Miniscript is a project we've been working on for the past year or so, and is now at a stage where I'd like to get it some more attention. It is joint work with Andrew Poelstra and Sanket Sanjalkar. It's a language for writing (a subset of) Bitcoin Scripts in a structured way, enabling

Re: [bitcoin-dev] Taproot proposal

2019-08-09 Thread Pieter Wuille via bitcoin-dev
On Fri, 9 Aug 2019 at 08:02, Elichai Turkel via bitcoin-dev wrote: > > Hi, Since the idea of implicitly even pubkeys has potentially more general implications, I've started a separate thread [1] about that idea. > I want to add to John Newbery's suggestion of using implicit even/odd only >

[bitcoin-dev] 32-byte public keys in Schnorr and Taproot

2019-08-09 Thread Pieter Wuille via bitcoin-dev
Hello all, It has been suggested [1] to drop the Y oddness bit in the witness program for Taproot outputs. This seems like a worthwhile change, as: * The bit doesn't actually contribute to security. * It avoids Taproot outputs from being more expensive to create than v0 P2WSH. * It doesn't

Re: [bitcoin-dev] PubRef - Script OP Code For Public Data References

2019-07-19 Thread Pieter Wuille via bitcoin-dev
On Fri, Jul 19, 2019, 12:13 William Casarin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > Hello Mike, > > Mike Brooks via bitcoin-dev > writes: > > > Motivation > > > > Giving scripts the ability to refer to data on the blockchain will reduce > > transaction sizes because

Re: [bitcoin-dev] Two questions about segwit implementation

2019-05-27 Thread Pieter Wuille via bitcoin-dev
On Sun, May 26, 2019, 07:07 Aymeric Vitte via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I realized recently that my segwit implementation was not correct, > basically some time ago, wrongly reading the specs (and misleaded by > what follows), I thought that scriptsig would go

Re: [bitcoin-dev] OP_DIFFICULTY to enable difficulty hedges (bets) without an oracle and 3rd party.

2019-05-23 Thread Pieter Wuille via bitcoin-dev
On Thu, 23 May 2019 at 11:33, Tamas Blummer via bitcoin-dev wrote: > > Difficulty change has profound impact on miner’s production thereby introduce > the biggest risk while considering an investment. > Commodity markets offer futures and options to hedge risks on traditional > trading venues.

Re: [bitcoin-dev] Taproot proposal

2019-05-23 Thread Pieter Wuille via bitcoin-dev
On Tue, 21 May 2019 at 10:20, Russell O'Connor wrote: > > Regarding Tapscript, the specification calls for the final value of the stack > being a single non-false value: > >> The tapscript is executed according to the rules in the following section, >> with the initial stack as input >> II.

Re: [bitcoin-dev] Taproot proposal

2019-05-09 Thread Pieter Wuille via bitcoin-dev
Thanks for the comments so far! I'm going to respond to some of the comments here. Things which I plan to address with changes in the BIP I'll leave for later. On Mon, 6 May 2019 at 13:17, Luke Dashjr wrote: > Tagged hashes put the tagging at the start of the hash input. This means >

[bitcoin-dev] Taproot proposal

2019-05-06 Thread Pieter Wuille via bitcoin-dev
Hello everyone, Here are two BIP drafts that specify a proposal for a Taproot softfork. A number of ideas are included: * Taproot to make all outputs and cooperative spends indistinguishable from eachother. * Merkle branches to hide the unexecuted branches in scripts. * Schnorr signatures enable

Re: [bitcoin-dev] IsStandard

2019-05-03 Thread Pieter Wuille via bitcoin-dev
On Thu, 2 May 2019 at 16:28, Aymeric Vitte via bitcoin-dev wrote: > > Thanks for the answer, indeed for the redeem script and someone > attempting a 0/1 of 3, good example > > So to summarize everything is standard as long as it matches P2PKH, > P2SH, P2WPKH or P2WSH , the redeem scripts for the

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2019-02-09 Thread Pieter Wuille via bitcoin-dev
On Wed, 19 Dec 2018 at 18:06, Rusty Russell via bitcoin-dev wrote: > > Meanwhile, both SIGHASH_NOINPUT and OP_MASK have the reuse-is-dangerous > property; with OP_MASK the danger is limited to reuse-on-the-same-script > (ie. if you use the same key for a non-lightning output and a lightning >

Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal

2019-02-08 Thread Pieter Wuille via bitcoin-dev
On Thu, 7 Feb 2019 at 12:19, Tamas Blummer via bitcoin-dev wrote: > I did restart the discussion which I read and participated in at its first > instance because implementing the current proposal taught me how problematic > as is until not committed and because I have not seen a sign to assume

Re: [bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-11-27 Thread Pieter Wuille via bitcoin-dev
On Mon, 19 Nov 2018 at 14:37, Pieter Wuille wrote: > Here is a combined proposal: > * Three new sighash flags are added: SIGHASH_NOINPUT, SIGHASH_NOFEE, and > SIGHASH_SCRIPTMASK. > * A new opcode OP_MASK is added, which acts as a NOP during execution. > * The sighash is computed like in BIP143,

[bitcoin-dev] Safer sighashes and more granular SIGHASH_NOINPUT

2018-11-19 Thread Pieter Wuille via bitcoin-dev
Hello everyone, For future segwit versions, I think it would be good add a few things to the sighash by default that were overlooked in BIP143: * Committing to the absolute transaction fee (in addition to just the amount being spent in each input) would categorically remove concerns about wallets

Re: [bitcoin-dev] Generalised taproot

2018-10-24 Thread Pieter Wuille via bitcoin-dev
On Thu, Jul 12, 2018 at 6:52 PM Anthony Towns via bitcoin-dev wrote: > On Fri, Jan 26, 2018 at 09:34:39PM +, Gregory Maxwell via bitcoin-dev > wrote: > > [pubkey] > > \-[pubkey]& > > \-[fancy script] > > I think it's possible to do recursive taproot in this manner in a >

[bitcoin-dev] Bitcoin Core update notice

2018-09-19 Thread Pieter Wuille via bitcoin-dev
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Hello all, Bitcoin Core 0.16.3 was just released with a fix for CVE-2018-17144: https://bitcoincore.org/en/2018/09/18/release-0.16.3/ We urge all network participants to upgrade to 0.16.3[*] as soon as possible. [*] For those who build from

Re: [bitcoin-dev] Extending BIP174 for HTLCs

2018-09-04 Thread Pieter Wuille via bitcoin-dev
On Tue, Sep 4, 2018, 04:32 Alex Bosworth via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > I've been experimenting with a format tag for BIP 174 to help support > HTLC scripts I've been working with. > I've been thinking about this as well. A useful way to look at it IMHO is to

[bitcoin-dev] Witness serialization in PSBT non-witness UTXOs

2018-08-13 Thread Pieter Wuille via bitcoin-dev
Hello all, BIP174 currently specifies that non-witness UTXOs (the transactions being spent by non-witness inputs) should be serialized in network format. I believe there are two issues with this. 1. Even in case the transaction whose output being spent itself has a witness, this witness is

Re: [bitcoin-dev] Schnorr signatures BIP

2018-07-14 Thread Pieter Wuille via bitcoin-dev
On Sat, Jul 14, 2018 at 8:42 AM, Sjors Provoost wrote: > Questions: > > Regarding verification: why does bytes(P) use compressed key serialization > rather than the implicit Y coordinate used for signing? I understand space > savings don't matter since these values don't end up on the

Re: [bitcoin-dev] BIP 174 thoughts

2018-07-11 Thread Pieter Wuille via bitcoin-dev
On Tue, Jul 10, 2018 at 5:10 AM, matejcik wrote: > On 6.7.2018 00:06, Pieter Wuille wrote:> The only case where "malicious" > conflicting values can occur is when >> one of the Signers produces an invalid signature, or modifies any of >> the other fields already present in the PSBT for

Re: [bitcoin-dev] Multiparty signatures

2018-07-08 Thread Pieter Wuille via bitcoin-dev
On Sun, Jul 8, 2018, 21:29 Erik Aronesty wrote: > Because it's non-interactive, this construction can produce multisig > signatures offline. Each device produces a signature using it's own > k-share and x-share. It's only necessary to interpolate M of n shares. > > There are no round trips.

Re: [bitcoin-dev] Multiparty signatures

2018-07-08 Thread Pieter Wuille via bitcoin-dev
On Sun, Jul 8, 2018, 19:23 Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Pretty sure these non interactive sigs are more secure. > Schnorr signatures are provably secure in the random oracle model assuming the discrete logarithm problem is hard in the used

Re: [bitcoin-dev] Multiparty signatures

2018-07-08 Thread Pieter Wuille via bitcoin-dev
On Sun, Jul 8, 2018, 07:26 Erik Aronesty via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > To save space, start with the wiki terminology on schnorr sigs. > > Consider changing the "e" term in the schnorr algorithm to hash of message > (elligator style) to the power of r, rather

[bitcoin-dev] Schnorr signatures BIP

2018-07-06 Thread Pieter Wuille via bitcoin-dev
Hello everyone, Here is a proposed BIP for 64-byte elliptic curve Schnorr signatures, over the same curve as is currently used in ECDSA: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki It is simply a draft specification of the signature scheme itself. It does not concern

Re: [bitcoin-dev] BIP 174 thoughts

2018-07-05 Thread Pieter Wuille via bitcoin-dev
On Thu, Jul 5, 2018 at 4:52 AM, matejcik wrote: >> Allowing combiners to choose any value also allows for intelligent combiners >> to choose the >> correct values in the case of conflicts. A smart combiner could, when >> combining redeem scripts >> and witness scripts, check that the redeem

Re: [bitcoin-dev] BIP 174 thoughts

2018-07-04 Thread Pieter Wuille via bitcoin-dev
On Wed, Jul 4, 2018 at 6:19 AM, matejcik wrote: > hello, > > we still have some concerns about the BIP as currently proposed - not > about the format or data contents, but more about strictness and > security properties. I have raised some in the previous e-mails, but > they might have been lost

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-27 Thread Pieter Wuille via bitcoin-dev
On Wed, Jun 27, 2018, 07:04 matejcik wrote: > hello, > > On 26.6.2018 22:30, Pieter Wuille wrote: > >> (Moreover, as I wrote previously, the Combiner seems like a weirdly > >> placed role. I still don't see its significance and why is it important > >> to correctly combine PSBTs by agents that

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-26 Thread Pieter Wuille via bitcoin-dev
On Tue, Jun 26, 2018 at 8:33 AM, matejcik via bitcoin-dev wrote: > I'm still going to argue against the key-value model though. > > It's true that this is not significant in terms of space. But I'm more > concerned about human readability, i.e., confusing future implementers. > At this point, the

Re: [bitcoin-dev] New serialization/encoding format for key material

2018-06-23 Thread Pieter Wuille via bitcoin-dev
On Fri, Jun 15, 2018 at 8:54 AM, Russell O'Connor wrote: > >> For codes designed for length 341 (the first length enough to support >> 512 bits of data): >> * correct 1 error = 3 checksum characters >> * correct 2 errors = 7 checksum characters >> * correct 3 errors = 11 checksum characters >> *

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-22 Thread Pieter Wuille via bitcoin-dev
On Thu, Jun 21, 2018 at 12:56 PM, Peter D. Gray via bitcoin-dev wrote: > I have personally implemented this spec on an embedded micro, as > the signer and finalizer roles, and written multiple parsers for > it as well. There is nothing wrong with it, and it perfectly meets > my needs as a

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-21 Thread Pieter Wuille via bitcoin-dev
On Thu, Jun 21, 2018 at 4:29 AM, matejcik wrote: > In the case of everything per-input, the naive Signer can do this: > 1. (in the global section) pre-serialize the transaction > 2. (in each input) find and fill out scriptPubKey from the provided UTXO > 3. (for a given BIP32 path) check if the

Re: [bitcoin-dev] BIP 174 thoughts

2018-06-19 Thread Pieter Wuille via bitcoin-dev
On Tue, Jun 19, 2018 at 7:20 AM, matejcik via bitcoin-dev wrote: Thanks for your comments so far. I'm very happy to see people dig into the details, and consider alternative approaches. > 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we > know, which BIP-32 path goes to

[bitcoin-dev] BIP 174 thoughts

2018-06-15 Thread Pieter Wuille via bitcoin-dev
Hello all, given some recent work and discussions around BIP 174 (Partially Signed Bitcoin Transaction Format) I'd like to bring up a few ideas. First of all, it's unclear to me to what extent projects have already worked on implementations, and thus to what extent the specification is still

Re: [bitcoin-dev] New serialization/encoding format for key material

2018-06-12 Thread Pieter Wuille via bitcoin-dev
On Sun, Jun 3, 2018 at 2:30 PM, Jonas Schnelli wrote: >> If there is interest, I can construct a code + implementation for any >> of these in a few days probably, once the requirements are clear. > > Yes. Please. Here is an example BCH code for base32 data which adds 27 checksum characters, and

Re: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

2018-06-11 Thread Pieter Wuille via bitcoin-dev
On Mon, Jun 11, 2018, 07:37 Bradley Denby via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks for the comments Pieter! > > We can make descriptions for the intended node behaviors more clear in the > BIP. > > Regarding interaction with BIPs 37 and 133, we have found that if >

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

2018-06-06 Thread Pieter Wuille via bitcoin-dev
On Wed, Jun 6, 2018 at 5:48 AM, Tim Ruffing via bitcoin-dev wrote: > On Thu, 2018-05-31 at 17:25 -0700, Pieter Wuille via bitcoin-dev wrote: >> The best argument for why Graftroot does not need to be optional I >> think was how Greg put it: "since the signer(s) could have si

Re: [bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

2018-06-05 Thread Pieter Wuille via bitcoin-dev
On Thu, May 10, 2018 at 5:59 AM, Bradley Denby via bitcoin-dev wrote: > Hi all, > > ... > > This iteration of Dandelion has been tested on our own small network, and we > would like to get the implementation in front of a wider audience. An > updated > BIP document with further details on

Re: [bitcoin-dev] New serialization/encoding format for key material

2018-06-03 Thread Pieter Wuille via bitcoin-dev
On Sun, Jun 3, 2018 at 9:51 AM, Jonas Schnelli via bitcoin-dev wrote: > Hi > > The BIP proposal is now available here: > https://gist.github.com/jonasschnelli/68a2a5a5a5b796dc9992f432e794d719 > > Reference C code is available here: > https://github.com/jonasschnelli/bech32_keys > > Feedback,

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-06-03 Thread Pieter Wuille via bitcoin-dev
On Sat, Jun 2, 2018, 22:56 Tamas Blummer via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Lighter but SPV secure nodes (filter committed) would help the network > (esp. Layer 2) to grow mesh like, but add more user that blindly follow POW. > > On longer term most users' security

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

2018-05-31 Thread Pieter Wuille via bitcoin-dev
On Fri, May 25, 2018 at 3:14 AM, Johnson Lau wrote: > A graftroot design like this is a strict subset of existing signature > checking rules. If this is dangerous, the existing signature checking rules > must be dangerous. While you may be right in this situation, I'm not sure that conclusion

[bitcoin-dev] Minimizing the redundancy in Golomb Coded Sets

2018-05-25 Thread Pieter Wuille via bitcoin-dev
Hi all, I spent some time working out the optimal parameter selection for the Golomb Coded Sets that are proposed in BIP158: https://gist.github.com/sipa/576d5f09c3b86c3b1b75598d799fc845 TL;DR: if we really want an FP rate of exactly 1 in 2^20, the Rice parameter should be 19, not 20. If we

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

2018-05-23 Thread Pieter Wuille via bitcoin-dev
On Tue, May 22, 2018 at 11:17 AM, Pieter Wuille wrote: > Hello all, > > 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

[bitcoin-dev] Should Graftroot be optional?

2018-05-22 Thread Pieter Wuille via bitcoin-dev
Hello all, 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 this would be necessary, but I'd like to hear other people's thoughts. As a

Re: [bitcoin-dev] BIP 158 Flexibility and Filter Size

2018-05-18 Thread Pieter Wuille via bitcoin-dev
On Fri, May 18, 2018, 19:57 Olaoluwa Osuntokun via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Greg wrote: > > What about also making input prevouts filter based on the scriptpubkey > being > > _spent_? Layering wise in the processing it's a bit ugly, but if you > > validated

Re: [bitcoin-dev] {sign|verify}message replacement

2018-03-26 Thread Pieter Wuille via bitcoin-dev
Hello, Thanks for starting a discussion about this idea. A few comments inline: On Wed, Mar 14, 2018 at 1:09 AM, Karl Johan Alm via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hello, > > I am considering writing a replacement for the message signing tools > that are currently

Re: [bitcoin-dev] BIP 117 Feedback

2018-01-09 Thread Pieter Wuille via bitcoin-dev
On Jan 9, 2018 13:41, "Mark Friedenbach via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: The use of the alt stack is a hack for segwit script version 0 which has the clean stack rule. Anticipated future improvements here are to switch to a witness script version, and a new segwit

Re: [bitcoin-dev] BIP - Dead Man's Switch

2017-12-11 Thread Pieter Wuille via bitcoin-dev
On Dec 11, 2017 10:23, "Nick Pudar via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: This topic has come up several times in recent years. While it is well intentioned, it can have devastating outcomes for people that want to save long term. If such a system were implemented, it

Re: [bitcoin-dev] Visually Differentiable - Bitcoin Addresses

2017-10-30 Thread Pieter Wuille via bitcoin-dev
On Oct 30, 2017 15:21, "shiva sitamraju via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> wrote: For example bc1qeklep85ntjz4605drds6aww9u0qr46qzrv5xswd35uhjuj8ahfcqgf6hak in 461e8a4aa0a0e75c06602c505bd7aa06e7116ba5cd98fd6e046e8cbeb00379d6 is 62 bytes ! ... While I get the

Re: [bitcoin-dev] cleanstack alt stack & softfork improvements (Was: Merkle branch verification & tail-call semantics for generalized MAST)

2017-09-22 Thread Pieter Wuille via bitcoin-dev
On Fri, Sep 22, 2017 at 2:54 PM, Sergio Demian Lerner via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > If the variable size increase is only a few bytes, then three > possibilities arise: > > - one should allow signatures to be zero padded (to reach the maximum > size) and

  1   2   >