BIP 131: "Coalescing Transaction" Specification (wildcard inputs)

[priestc]

I wrote this BIP from getting feedback from the dev mailing list. There is no implementation yet, but that can come after a number has been assigned. I have not included any numbers in this pull request. Once a number has been assigned I'll update this PR with the number.

[luke-jr]

This needs to add a Copyright section and address backward compatibility. If I understand correctly, it is a proposed hardfork?

[jl2012]

With Schnorr signature it is only possible to combine signature of the same public key, but also different public keys, as long as they are signing the same hash. I think it is the plan after BIP141 is deployed

[jonathancross]

Extra "a" in this line:

• the minimum economical value of a spending a UTXO

[luke-jr]

I agree this would make a lot of sense as a SegWit upgrade, but I'm not sure if that's what the Author has in mind as the draft here is too lacking in specification.

[priestc]

@luke-jr I think the best way to describe this change is "non-contentious hard fork". I haven't heard of any serious objections against the change. This change is a "win" for all parties involved: users, miners and nodes. It should be deployed the same way that CLTV was done. I don't think its even possible to make this a softfork.

By the way, what do you men by copyright section? I looked at a bunch of other BIPs and there was no copyright anywhere on any of them. I want this BIP to be public domain. There is no sense in any one person retaining a copyright...

@jl2012 I don't see how this has anything to do with schnorr signatures. I'm not an expert on schnorr signatures, but I assume it's an alternative to ECDSA? The signature verification process occurs inside the scripting language which is self-contained inside an input. If your transaction has 4 inputs, there are 4 different independent script instances. Each script instance has no notion of what other scripts are doing.

Wildcard inputs exists a step above the signature process. Its a change to the transaction. Segwit as I understand it is only a change to the signature process, which is completely contained inside the script. I struggle to understand how you'd reference many other inputs from inside an input.

This change only effects how a signature is interpreted, not how the actual signature is created or verified.

[luke-jr]

@priestc

I think the best way to describe this change is "non-contentious hard fork". I haven't heard of any serious objections against the change. This change is a "win" for all parties involved: users, miners and nodes.

All hardforks, contentious or not, have a serious loss of all security for old nodes that get left behind. With Bitcoin today, I do not think your "win" outweighs this "loss". Furthermore, (as it stands today), I would object on the basis that it encourages address reuse, which is harmful in many ways. That being said...

I don't think its even possible to make this a softfork.

With segregated witness, this becomes possible. You would bump the script version and make a rule that basically allows inputs to share the same witness.

By the way, what do you men by copyright section? I looked at a bunch of other BIPs and there was no copyright anywhere on any of them. I want this BIP to be public domain. There is no sense in any one person retaining a copyright...

BIPs are supposed to all have a section titled Copyright stating what license they are under, or declaring themselves to be public domain. Just add that and I can assign a number and merge this (although I do recommend you reconsider the approach and try to make it a segwit extension that can handle non-address-reuse scenarios using the Scnorr stuff @jl2012 mentioned).

[priestc]

Furthermore, (as it stands today), I would object on the basis that it encourages address reuse, which is harmful in many ways.

I'm glad you brought this up. Someone on the dev mailing list brought this up, and the answer I gave was pretty terrible. Lets hope this time around I can make a better case:

The advice that you shouldn't reuse addresses is not exactly right. The advise should be "never reuse private keys". When you re-use a private key multiple times, you make it easier for other people to figure out your key by analyzing the signatures you publish. If you only ever publish one signature per private key, no one will ever be able to guess your private key.

Before wildcard inputs, re-using addresses inevitably lead to re-using a private key. After wildcard inputs become enabled, re-using address does not necessarily lead to re-using private keys. Someone could send you 100 payments to the same address, but when you spend those payments, you do so with only one signature.

If you want a better argument against Wildcard inputs, one you could use is "wildcard inputs leads to encouraging people to use on-chain microtransactions". This change will make it easier to spend coin given to you via very small amounts. Before wildcard inputs, if 1000 people sent you one cent worth of bitcoin, you would lose most of that money to miner fees. After wildcard inputs, spending all those tiny inputs becomes just as cheap of spending from a single UTXO.

With segregated witness, this becomes possible. You would bump the script version and make a rule that basically allows inputs to share the same witness.

I noticed that the transaction version field has been historically used to denote script version. So far each transaction version bump has been used to denote a change in the way the scripting language works. Segwit as I understand it is a change to the way script works, so it should be implemented with a version bump.

Wildcard inputs on the other hand, have nothing to do with the script language. No change whatsoever is needed in the way signatures are handled. Bumping the transaction version number will not work, hence the need to re-define the transaction version field. Otherwise future script improvements won't be available to the wildcard input version.

The BIP I wrote is really in two parts. The first part describes changing the 8 byte transaction version into two fields. The first 4 bytes is transaction version (used to denote script version) and the second 4 bytes are used to denote "transaction type". This part could actually be split into another BIP.

(although I do recommend you reconsider the approach and try to make it a segwit extension that can handle non-address-reuse scenarios using the Scnorr stuff @jl2012 mentioned).

This specification is already compatible with segregated witness. I'm not sure what I would change about it to make it a "segwit extension".

[luke-jr]

The advice that you shouldn't reuse addresses is not exactly right. The advise should be "never reuse private keys". When you re-use a private key multiple times, you make it easier for other people to figure out your key by analyzing the signatures you publish. If you only ever publish one signature per private key, no one will ever be able to guess your private key.

It also links the UTXOs together so third-parties can determine they are part of the same wallet.

Before wildcard inputs, re-using addresses inevitably lead to re-using a private key. After wildcard inputs become enabled, re-using address does not necessarily lead to re-using private keys. Someone could send you 100 payments to the same address, but when you spend those payments, you do so with only one signature.

What happens when you spend after 100, and then the same person sends a 101st? You can't really say "oh, this address is good for only 100 transactions" - it's unreasonable for them to expect to count. You're in the clear if you say "one only, period", or if you explicitly tell them to reuse it, but an exact count over 1 is just a nusaince. Furthermore, if you knew they will send 100 before you spend, you could just as well have them wait until the sum accrues and have them send that sum in a single transaction.

This specification is already compatible with segregated witness. I'm not sure what I would change about it to make it a "segwit extension".

You could use a single Schnorr signature for N inputs that require any key. You would do some fancy math to combine all the keys, and check the signature is signed by the combination, rather than checking for each key individually. So, suddenly your proposal here would become useful in non-reuse circumstances as well.

I will assign your BIP number different based on whether you intend to move forward with this as-is (13x range), or whether you intend to make it a segwit extension (14x range). Just let me know and I will assign and merge (you don't need to update the draft first, just telling me which you intend is sufficient).

[priestc]

It also links the UTXOs together so third-parties can determine they are part of the same wallet.

Yes, and sometimes this is desired behavior. Sometimes a person may want to publish on of their address, and people who send payments to that address, may be OK with one of their addresses being linked to that address. Consider the case of The Red Cross publishing an address for donations. If I send money to their public address, my wallet is linked to the Red Cross. When I'm doing my taxes, I can easily reference the TXID that has my wallet on one end, and the Red Cross on the other end. If my wallet re-used addresses, and if the Red Cross had used a stealth address, I would have no way to prove to the IRS I had made that donation. With publishing addresses (which leads to re-using addresses), this is possible.

On the other hand, if I were buying bulk xanax from the darknet, I would not want either wallet to re-use addresses.

It depends on the usecase.

What happens when you spend after 100, and then the same person sends a 101st?

Then you'd have to re-use the private key to move the funds that come after your first coalescing transaction. So you'd have to use the private key twice to move 101 payments. Without wildcard inputs, you'd need to re-use the private key 101 times. Two published signatures is much safer than having 101 published signatures.

Furthermore, if you knew they will send 100 before you spend, you could just as well have them wait until the sum accrues and have them send that sum in a single transaction.

Only if all the payments are coming from the same source.

Take for example a donate address written at the bottom of a blog post that just went viral. 1000 people from around the world sends $0.05 worth of btc to that address. None of the senders are connected in any way. They are all independent entities. There is no way for them to coordinate together to batch their payments into the same transaction.

You could use a single Schnorr signature for N inputs that require any key. You would do some fancy math to combine all the keys, and check the signature is signed by the combination, rather than checking for each key individually. So, suddenly your proposal here would become useful in non-reuse circumstances as well.

You lost me at "fancy math". It sounds like to me you're describing a way to do wildcard inputs in a way that doesn't result in address-reuse. It could be considered a more private version of regular wildcard inputs.

I wrote the BIP the way I wrote it because I wanted the change to be as easy as possible to implement. I'm not very knowledgeable about cryptography and I know many other developers who are interested in building things on top of bitcoin are not very knowledgeable about cryptography either. I think anything that can be achieved without using cryptography is preferable to a method that uses cryptography. Making this a segwit extension means in order to implement it safely, you have to have a certain level of cryptographic knowledge not required by the non-seqwit version. The questions is, is there a usecase for private wildcard transactions? It seems to me that if you're doing private payments between two parties, its better to not have any linking between addresses.

I will assign your BIP number different based on whether you intend to move forward with this as-is (13x range), or whether you intend to make it a segwit extension (14x range). Just let me know and I will assign and merge (you don't need to update the draft first, just telling me which you intend is sufficient).

Couldn't both be done? I think its best to do the non-segwit version first, then some time after segwit gets merged, someone could add the segwit version. I think its better to do it simple first.

[luke-jr]

Yes, and sometimes this is desired behavior. Sometimes a person may want to publish on of their address, and people who send payments to that address, may be OK with one of their addresses being linked to that address. Consider the case of The Red Cross publishing an address for donations. If I send money to their public address, my wallet is linked to the Red Cross. When I'm doing my taxes, I can easily reference the TXID that has my wallet on one end, and the Red Cross on the other end. If my wallet re-used addresses, and if the Red Cross had used a stealth address, I would have no way to prove to the IRS I had made that donation. With publishing addresses (which leads to re-using addresses), this is possible.

Or they can just provide receipts like they do today... By reusing addresses, you not only harm the privacy of both parties involved, but also of everyone else using Bitcoin since the observer knows it wasn't involving their wallet.

Then you'd have to re-use the private key to move the funds that come after your first coalescing transaction. So you'd have to use the private key twice to move 101 payments. Without wildcard inputs, you'd need to re-use the private key 101 times. Two published signatures is much safer than having 101 published signatures.

My point is that it is never safe to reuse the address, because you can't know when the sender is done with it if you've given them the okay to reuse.

Only if all the payments are coming from the same source.

Even if they aren't, you could have the senders all make an anyone-can-pay transaction. Eg, Lighthouse.

Take for example a donate address written at the bottom of a blog post that just went viral. 1000 people from around the world sends $0.05 worth of btc to that address. None of the senders are connected in any way. They are all independent entities. There is no way for them to coordinate together to batch their payments into the same transaction.

But there's also no way to tell them "okay, stop using that address now".

Couldn't both be done? I think its best to do the non-segwit version first, then some time after segwit gets merged, someone could add the segwit version. I think its better to do it simple first.

Sure. Let's just make this be the non-segwit version at BIP 131 then, and a segwit version can be a separate BIP.