Re: [bitcoin-dev] BIP 174 thoughts on graphics

this is intended to fix the graphics * as not scaleable bitmap/png * with broken capitalization * not easy editable plaintext for git have a view[1] on the suggestion for an example[0]. [0]: https://github.com/bitcoin/bips/blob/master/bip-0174/coinjoin-workflow.png [1]:

Re: [bitcoin-dev] BIP 174 thoughts

On Wed, Jul 11, 2018 at 6:27 PM, Pieter Wuille via bitcoin-dev wrote: > I don't think that's a particularly useful policy, but certainly > Signers are allowed to implement any policy they like about what they > accept in signing. Do we really want the specification to permit conforming

Re: [bitcoin-dev] BIP 174 thoughts

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

[bitcoin-dev] BIP 174 thoughts

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 consumption by > others. If this were an issue, it would be an

Re: [bitcoin-dev] BIP 174 thoughts

I have another concern with the format. (my original bip comment for some context: [1]) It looks like the one of the reasons I was confused is because you can only parse the format properly by first deserializing the transaction. Since there is no "length" field for the key-value map arrays,

Re: [bitcoin-dev] BIP 174 thoughts

Has there been any thought to standardizing file names used when creating .psbt files? Maybe something that gives some reliability of being collision resistant and descriptive. For example: [8 char trim of hash of unsigned tx]+[Role that created file (Ex: Signer)]+[4 char trim of hash of data

[bitcoin-dev] BIP 174 thoughts

On 4.7.2018 20:35, Achow101 wrote: > You cannot simply reject PSBTs for having conflicting values for the same > key. Especially > for the Partial Signatures, you can have two signatures for the same pubkey > that are both (...) > order to avoid the conflict. That complicates things and is

Re: [bitcoin-dev] BIP 174 thoughts

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

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 in the overall talk about format. * Choosing from duplicate

Re: [bitcoin-dev] BIP 174 thoughts

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

Hi,​ On July 4, 2018 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

Re: [bitcoin-dev] BIP 174 thoughts

... > I believe that this discussion has become bikeshedding and is really no > longer constructive. ... Thanks for saying this Andrew! I agree with your point of view, and personally I'm ready to lock this BIP down ... or at least move it to the next level of approval. ... > I propose to

Re: [bitcoin-dev] BIP 174 thoughts

Hi, I do not think that protobuf is the way to go for this. Not only is it another dependency which many wallets do not want to add (e.g. Armory has not added BIP 70 support because of its dependency on protobuf), but it is a more drastic change than the currently proposed changes. The point

[bitcoin-dev] BIP 174 thoughts

Short version: - I propose that conflicting "values" for the same "key" are considered invalid. - Let's not optimize for invalid data. - Given that, there's an open question on how to handle invalid data when encountered In general, I don't think it's possible to enforce correctness at the

Re: [bitcoin-dev] BIP 174 thoughts

Hello Folks, Thanks for expediting this debate, I understand some still disagree about how this final spec should look like. 1. Coldcard's plugin for Electrum using the original BIP spec is ready, https://github.com/spesmilo/electrum/pull/4470

Re: [bitcoin-dev] BIP 174 thoughts

Hi,​ On June 26, 2018 11:09 PM, William Casarin wrote: > ​​ > > Hey Andrew, > > If I'm reading the spec right: the way it is designed right now, you > > could create hundreds of thousands of zero bytes in the input or output > > key-value arrays. As far as I can tell this would be

Re: [bitcoin-dev] BIP 174 thoughts

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

hello, On 26.6.2018 18:58, William Casarin wrote: > as a data point, I was able to build a simple serializer[1] in about an > afternoon. I would much prefer to use this lib in say, clightning (my > original goal), without having to have the larger protobuf dependency. To drive my point home,

Re: [bitcoin-dev] BIP 174 thoughts

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 don't understand them. If you >> have a usecase in mind,

Re: [bitcoin-dev] BIP 174 thoughts

Hi William, Andrew, list, As noted by William there are some types missing in the global-types definition, because the number of each map for I/O must be known to the parser in order to use the correct definitions for the types. At the moment a parser reading a key-value record does not know

Re: [bitcoin-dev] BIP 174 thoughts

Hey Andrew, If I'm reading the spec right: the way it is designed right now, you could create hundreds of thousands of zero bytes in the input or output key-value arrays. As far as I can tell this would be considered valid, as it is simply a large array of empty dictionaries. Is this right? I'm

Re: [bitcoin-dev] BIP 174 thoughts

Hi, On June 26, 2018 8:33 AM, matejcik via bitcoin-dev wrote: > ​​ > > hello, > > in general, I agree with my colleague Tomas, the proposed changes are > > good and achieve the most important things that we wanted. We'll review > > the proposal in more detail later. > > For now a couple

Re: [bitcoin-dev] BIP 174 thoughts

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] BIP 174 thoughts

On Tue, Jun 26, 2018 at 6:58 PM, William Casarin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > seems a bit overkill for how simple the format is, and pulling in a > large dependency just for this is a bit silly. Although making it > protobuf-compatible is an interesting idea,

Re: [bitcoin-dev] BIP 174 thoughts

matejcik via bitcoin-dev writes: > BIP174 is a ad-hoc format, simple to parse by hand; but that results > in _having to_ parse it by hand. In contrast, protobuf has a huge > collection of implementations that will do the job of sorting record > types into relevant struct fields, proper

Re: [bitcoin-dev] BIP 174 thoughts

hello, in general, I agree with my colleague Tomas, the proposed changes are good and achieve the most important things that we wanted. We'll review the proposal in more detail later. For now a couple minor things I have run into: - valid test vector 2 ("one P2PKH input and one P2SH-P2WPKH

Re: [bitcoin-dev] BIP 174 thoughts

Hi, On June 25, 2018 12:47 PM, Tomas Susanka via bitcoin-dev wrote: > From my perspective those are exactly the points I have felt strongly > about. I still think "typed records" would be a better choice, but it's > something I'm willing to compromise on. As I'm looking at the draft, we >

Re: [bitcoin-dev] BIP 174 thoughts

Hi > As was partially brought up by William, shouldn't we consider using > bech32? It doesn't break on double-click and it is a dependency for > native Segwit addresses anyway, so wallets might already support it or > they will at some point. But we should probably run some numbers on this >

Re: [bitcoin-dev] BIP 174 thoughts

Hi, this is great. On 23.6.2018 00:28, Achow101 via bitcoin-dev wrote: > Hi all, > > After reading the comments here about BIP 174, I would like to propose the > following changes: From my perspective those are exactly the points I have felt strongly about. I still think "typed records" would

Re: [bitcoin-dev] BIP 174 thoughts

Keeping it for future extensions is a good point, my understanding was that since we always need exactly one transaction it could be part of the definition of PSBT instead of being a key-value (although it is more of a breaking change). Cheers, Andrea. ​​ ‐‐‐ Original Message ‐‐‐

Re: [bitcoin-dev] BIP 174 thoughts

Hi, I think in the revised spec we can remove completely the "global types" as a map or even as typed record. Since there is only one type (the transaction) and it's compulsory to have one (and only one) we could just drop the definition of global type and the key associated with it, simply

Re: [bitcoin-dev] BIP 174 thoughts

I disagree with the idea that global types can be removed. Firstly, it is less of a breaking change to leave it there than to remove it entirely. Secondly, there may be a point in the future where global types would be useful/necessary. By having it still be there, we allow for future

Re: [bitcoin-dev] BIP 174 thoughts

On Fri, Jun 22, 2018 at 06:28:33PM -0400, Achow101 wrote: > After reading the comments here about BIP 174, I would like to propose the > following changes: > > - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to > per-input and per-output data ... I like this. I agree it's

Re: [bitcoin-dev] BIP 174 thoughts

On 06/23/2018 10:00 AM, William Casarin wrote: > Since we're still considering the encoding, I wonder if it would be a > good idea to have a human-readible part like lightning invoices[1]? I don't think that is necessary. > Then perhaps you could drop the magic code as well? The magic is still

Re: [bitcoin-dev] BIP 174 thoughts

Achow101 via bitcoin-dev writes: > I have decided that PSBTs should either be in binary or encoded as a > Base64 string. For the latter, several Bitcoin clients already support > Base64 encoding of data (for signed messages) so this will not add any > extra dependencies like Z85 would. Since

Re: [bitcoin-dev] BIP 174 thoughts

Hi all, After reading the comments here about BIP 174, I would like to propose the following changes: - Moving redeemScripts, witnessScripts, and BIP 32 derivation paths to per-input and per-output data I think that by moving these three fields into input and output specific maps, the format

Re: [bitcoin-dev] BIP 174 thoughts

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

On Thu, Jun 21, 2018 at 7:56 PM, Peter D. Gray via bitcoin-dev wrote: > PSBT is something we need, and has been missing from the ecosystem > for a long time. Let's push this out and start talking about future > versions after we learn from this one. When you implement proposals that have little

Re: [bitcoin-dev] BIP 174 thoughts

On Tue, Jun 19, 2018 at 05:20:34PM +0200, Jonas Schnelli wrote: ... > > I don’t see any reasons why space would be an issue. > > HWWs probably can’t handle PBST natively since it is not optimised for > presenting various informations in a signing-verification. The Coldcard hardware wallet is

Re: [bitcoin-dev] BIP 174 thoughts

On Thu, Jun 21, 2018 at 04:32:07PM +0200, Tomas Susanka wrote: ... > First of all, let me thank you for all the hard work you and others have > put into this. > > On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote: > > While I agree that the BIP itself should be revised to reflect these > >

Re: [bitcoin-dev] BIP 174 thoughts

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

>Hmm, upon further reflection, maybe it's not even worth including *any* per-output data, aside from what the original transaction contains. >The output redeem script is either: - unknown, because we have received only an address from the receiver - or it is known, because it is ours and in that

Re: [bitcoin-dev] BIP 174 thoughts

Hello, First of all, let me thank you for all the hard work you and others have put into this. On 21.6.2018 02:39, Achow101 via bitcoin-dev wrote: > While I agree that the BIP itself should be revised to reflect these > suggestions, I fear that it may be too late. I know of a few other

Re: [bitcoin-dev] BIP 174 thoughts

Hi, On 19.6.2018 19:16, Pieter Wuille via bitcoin-dev wrote: > Yes, the reason is address reuse. It may be discouraged, but it still > happens in practice (and unfortunately it's very hard to prevent > people from sending to the same address twice). > > It's certainly possible to make them

Re: [bitcoin-dev] BIP 174 thoughts

On 19.6.2018 19:16, Pieter Wuille wrote: >> 1) Why isn't the global type 0x03 (BIP-32 path) per-input? How do we >> know, which BIP-32 path goes to which input? The only idea that comes to >> my mind is that we should match the input's scriptPubKey's pubkey to >> this 0x03's key (the public key).

Re: [bitcoin-dev] BIP 174 thoughts

Hi, On June 15, 2018 4:34 PM, Pieter Wuille via bitcoin-dev wrote: > > 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

Re: [bitcoin-dev] BIP 174 thoughts

On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote: ... > 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 subject to change. A response of "this is way too late" is > perfectly fine.

Re: [bitcoin-dev] BIP 174 thoughts

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

Re: [bitcoin-dev] BIP 174 thoughts

I agree with matejcik’s point 1 to 3 and especially with point 4. The mandatory flag (or optional-flag) makes much sense to me. > --- > > In general, the standard is trying to be very space-conservative, > however is that really necessary? We would argue for clarity and ease of > use

Re: [bitcoin-dev] BIP 174 thoughts

hello, this is our second e-mail with replies to Pieter's suggestions. On 16.6.2018 01:34, pieter.wuille at gmail.com (Pieter Wuille) wrote: > * Key-value map model or set model. > > This was suggested in this thread: > https://twitter.com/matejcik/status/1002618633472892929 > > The motivation

Re: [bitcoin-dev] BIP 174 thoughts

Hello, First of all, we'd like to apologize for such a late feedback, since there is a PR for this already. We've come up with a few more notes on this, so we are introducing those in this message and replying on Pieter's points in another one. 1) Why isn't the global type 0x03 (BIP-32 path)

Re: [bitcoin-dev] BIP 174 thoughts

> * Key-value map model or set model. > * Ability for Combiners to verify two PSBT are for the same transaction > * Optional signing > * Derivation from xpub or fingerprint > * Generic key offset derivation > * Hex encoding? I think all of Pieters points are valid and reasonable thought, though

Re: [bitcoin-dev] BIP 174 thoughts

On Fri, Jun 15, 2018 at 04:34:40PM -0700, Pieter Wuille wrote: ... > 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 subject to change. A response of "this is way too late" is > perfectly fine.

[bitcoin-dev] BIP 174 thoughts

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