News48 (2019-05-28ish)

[harding]

• Fix FIXMEs. These are mostly minor stuff that should be easy to review at the last minute and that are easy to imagine how it'll look or where a link will go just from the text surrounding it.

  • I need the final URL for the video of @bitschmidty's talk (or Mike needs it for merge time tomorrow). The relevant line has a FIXME in a comment (near the bottom of the document).

• Note that this is a very long newsletter. I'm sorry about that. Please don't hesitate to suggest the culling of paragraphs or entire subsections, and to recommend that I restrain myself in the future.

• I'm unhappy with several of the diagrams in this newsletters. Before publication, I'll tighten them up a bit (remove whitespace so the font size is larger), but if anyone sees a way to materially improve them, please let me know. Alternatively, let me know if you think the newsletter would be better without them.

• The newsletter deliberately doesn't cover Blummer's difficulty opcode proposed soft fork. He said he was just soliciting feedback and would come back with an actual BIP. Since we already have an over-stuffed newsletter (our longest ever), I think it's reasonable to punt on that.

• As usually, @moneyball's SE section is added in a separate commit and I have a fixup commit on top of that with my edits so that he can review. I'll squash those together after his review.

• Finally, I do have a fear that I've terribly misunderstood COSHV and everything I wrote about it is rubbish. If that seems to be the case, even partly, this newsletter is certainly long enough for us to just yank that whole section and update the news item to say "we'll cover it in the future." Those of you with commit access, please feel free to do that without consulting with me (or make whatever other edits).

Thanks as always for reviewing my overly long and poorly illustrated ramblings!

[jnewbery]

I've left comments on two of the SE posts because I think the answers there aren't great. @moneyball - did you have any alternative SE Q/As to use?

[jnewbery]

I don't think this is a great SE question/answer. It's too broad and unspecific (give me an overview of Bitcoin Core architecture). I think an expanded version of this would be a great blog post/series, or even talk (eg https://bitcoinedge.org/tutorial/EN:platforms-an-overview-of-bitcoin-core-architecture).

[moneyball]

I agree an expanded version would be great and it is something we can consider. I still think including this is useful even if high level and broad. I do not feel strongly about it at all though, so I'll leave it to @jnewbery to make the final decision prior to publication.

[bitschmidty]

For clarify, I like

bit of additional data representing the sign.

[bitschmidty]

@jnewbery I have https://youtu.be/rPLY20YzeqU but that is under Jonas' account.

[bitschmidty]

This was actually open to non members as well. I suggest the wording as:

at Optech's first executive-focused briefing.

[bitschmidty]

... and creates, but does not broadcast, an unsigned...

[moneyball]

ACK da97f74

(but still need to consider @jnewbery feedback)

[moneyball]

My feedback for everything except COSHV, which I still need to review.

[moneyball]

Should the summary mention the Optech executive seminar / the Fees presentation?

[moneyball]

For consideration, you could mention 1 or more use cases/benefits (ie congestion control, vaults) or just describe it as "a restricted form of covenants" as a teaser to increase the # of readers that read the full section.

[moneyball]

I agree an expanded version would be great and it is something we can consider. I still think including this is useful even if high level and broad. I do not feel strongly about it at all though, so I'll leave it to @jnewbery to make the final decision prior to publication.

[jnewbery]

I've got as far as the 'Rolling coinjoin' section. I'll log on again later to finish review.

[jnewbery]

I've tried rewriting this. Let me know what you think:

Move the oddness byte: Bitcoin public keys are graph points, so they are most naturally specified using an X,Y coordinate pair. However, because a valid pubkey must be on the elliptic curve, it’s possible to find both valid Y coordinates (one odd, one even) for any given X coordinate given the curve formula. In compressed key format, the first byte contains a single bit to specify whether the y coordinate is odd or even, followed by 32 bytes to encode the X coordinate. The proposed bip-taproot followed this convention and used 33 bytes to encode the taproot output key.

This week, John Newbery suggested that we use some method to avoid placing this byte in the scriptPubKey. Wuille agreed that this could be useful and will attempt implementing a variation where the bit will be included as part of the taproot witness data, which has unused bits. This will reduce the cost to create a taproot output by 1.0 vbytes, making it the same as P2WSH currently.

(Note that the proposal is to place the y-oddness bit in the leading byte of the control block, which has unused bits, so this doesn't increase the size of the witness).

[ajtowns]

I'd write it as just "Bitcoin public keys are most naturally specified using an X,Y coordinate pair, for example via the uncompressed public key format used in the early days of Bitcoin" or similar? "graph points" seems a weird way of describing it at any rate. John's rephrase seems better to me, fwiw.

[harding]

@jnewbery

Note that the proposal is to place the y-oddness bit in the leading byte of the control block, which has unused bits, so this doesn't increase the size of the witness

I phrased it that way because I don't understand what you and sipa were talking about. You and he mention the control block, but IIUC, the control block isn't there for key-path spends. For script-path spends where the control block is present, I don't think you need the Y bit as there's no signature verification being done---you can compare just the X coordinate of the output pubkey to just the X coordinate of ec_add(tweak, internal_key).

[ajtowns]

For key path spends, you just always treat the key as if it were even (so imply an 0x02 prefix). If your secret key generated an odd key (0x03 prefix), just negate it to get the secret key for the even variant.

For script path spends you need the oddness in order to batch verification, because you need to verify Q = P+H(P,S)*G but if you're guessing Q's parity, then you might actually be plugging (-Q) = P+H(P,S)*G into the verifier, in which case you'll get a failure when you should be getting a success.

[jnewbery]

Erlay was announced today. I think it's fine to write it up for next week's newsletter, given we already have a bumper edition this week.

[ajtowns]

Better to give things at least a day or two before a write up in general, in my opinion; better if the newsletter tries to be detailed and informative rather than catching breaking news. YMMV etc

[jnewbery]

Here you go: https://www.youtube.com/watch?v=ihUQ4C42KUk

[jnewbery]

remove 'further'?

[jnewbery]

I think the 141 vbytes is assuming both outputs are P2WPKH. That's not the case for column three, where the txout to the multisig address is a P2WSH, which is 12 bytes more, making that column 153 vbytes.

I also make column three 418.75 vbytes (10 bytes overhead, 67.75 bytes for the txin and 11 x 31 vbytes for the txouts)

[ajtowns]

141 vbytes matches the 1-input, 2-output (p2wpkh) example on https://en.bitcoin.it/wiki/Weight_units#Weight_for_segwit_transactions.

(Would be nice to provide the working for the vbyte calculations in an ipynb link or a onhover tooltip)

[harding]

@jnewbery

I think the 141 vbytes is assuming both outputs are P2WPKH. That's not the case for column three, where the txout to the multisig address is a P2WSH

If we're magically assuming key/sig aggregation (e.g. multiparty ecdsa), then P2WPKH is usable here.

@ajtowns

Would be nice to provide the working for the vbyte calculations in an ipynb link or a onhover tooltip

But that would defeat the efficiency gains of me making stuff up randomly as I go. :-)

[jnewbery]

I make the low fee transaction to be 629.75 vbytes (10 bytes overhead, 309.75 vbytes for the txin - a 10-of-10 P2WSH multisig, and ten 31 vbyte txouts)

EDIT: you're using an aggregate signature here, so the txin can be a simple P2TR keypath spend.

[jnewbery]

nice disclaimer! consider s/any random/a/

[jnewbery]

As discussed in IRC, I think this should be expanded to explain that you're using musig key aggregation, and what the exchange of messages is.

[ajtowns]

If you're assuming taproot and musig, you could simplify the protocol to be:

• I want to pay to N taproot addresses
• Treat those as pubkeys P1..PN, calculate P=muSig(P1,P2,..,PN)
• Create an unsigned tx, TX1, spending your funds and paying to P (with a change address), and an unsigned tx TX2, spending TX1, paying to each of the N taproot addresses.

No interactivity was required to this point; the interactive steps are just the remainder:

• Contact each of the recipients, getting them to sign TX2 that spends TX1.
• Once TX2 is fully signed, pass it around so everyone has a copy, then sign and publish TX1.

It might be that one of the pubkeys, eg, P5, was based on a NUMS point so that it could only be spent via tapscript, in which case signing TX2 will fail, but as that's an interactive step it could fail anyway.

Doing that with existing script means replacing muSig by either doing a multisig-via-pubkeyhash script, or asking the people you're sending to for the pubkey rather than just using the pubkeyhash from the p2pkh/p2wpkh addresses they've already given you.

The key difference with COSHV is that it eliminates the need for the interactive step entirely (and hence the failure modes).

[jnewbery]

These images come out a bit squashed on my display. I can right-click to open the image in a new tab, but is there some way we can make that friendlier? Perhaps some lightbox effect?

[jonatack]

s/VERY/VERIFY/

[jonatack]

that's... quite a few indeed

[jonatack]

compliment?

[jonatack]

Great read; shaping up to an excellent bitcoinops issue

[moneyball]

strike the 'and' before Danielle?

[ajtowns]

btw, what happened to Carol? did she retire? :(

[harding]

Is there an semi-official list of names to use? I always use the same names out to E, but after that I make it up ad hoc (excluding special cases like Eve for eavesdroppers and Mallory for malicious actors)

[moneyball]

"the receivers" ?

[moneyball]

I'm not sure we should add even more to the newsletter, but something to consider pointing out is the tree could be imbalanced / use Huffman encoding such that the most likely spending requires the least tree depth / smallest transaction size.

[ajtowns]

I don't think the COSHV MAST example is a good one (see comment inline for alternatives); also various nits. Given how long it took to read/review, must have taken forever to write. Wow.

[ajtowns]

"it'll be" reads odd to me there, maybe "but if Taproot is adopted, it will use v1 segwit addresses that will [also use bech32]." ?

[ajtowns]

I'd write it as just "Bitcoin public keys are most naturally specified using an X,Y coordinate pair, for example via the uncompressed public key format used in the early days of Bitcoin" or similar? "graph points" seems a weird way of describing it at any rate. John's rephrase seems better to me, fwiw.

[ajtowns]

FWIW, it always seems better to me to answer "why should I care about this?" first.

[ajtowns]

If you're assuming taproot and musig, you could simplify the protocol to be:

• I want to pay to N taproot addresses
• Treat those as pubkeys P1..PN, calculate P=muSig(P1,P2,..,PN)
• Create an unsigned tx, TX1, spending your funds and paying to P (with a change address), and an unsigned tx TX2, spending TX1, paying to each of the N taproot addresses.

No interactivity was required to this point; the interactive steps are just the remainder:

• Contact each of the recipients, getting them to sign TX2 that spends TX1.
• Once TX2 is fully signed, pass it around so everyone has a copy, then sign and publish TX1.

It might be that one of the pubkeys, eg, P5, was based on a NUMS point so that it could only be spent via tapscript, in which case signing TX2 will fail, but as that's an interactive step it could fail anyway.

Doing that with existing script means replacing muSig by either doing a multisig-via-pubkeyhash script, or asking the people you're sending to for the pubkey rather than just using the pubkeyhash from the p2pkh/p2wpkh addresses they've already given you.

The key difference with COSHV is that it eliminates the need for the interactive step entirely (and hence the failure modes).

[ajtowns]

You could do a more generic analysis, that just compares the combined tx (k inputs, N outputs, high fee rate) with the sum of the setup tx (k inputs, 1 32B p2wsh output, high fee rate) and the distribution tx (1 input, N outputs, low fee rate). But I think the main difference between COSHV and this by hand setup isn't the fee cost, it's that you don't need the interactivity with all the recipients before you can put the setup tx on chain.

The maths for this being worthwhile is just (k*a + N*b)*H > (k*a+1*y)*H + (1*x+N*b)*L where H is the high fee rate, L is the low fee rate, a is your input cost, b is the average output cost, y is the output cost for the COSHV or equivalent address, and x is the cost for spending from that address. That formula simplifies to:

H/L > (N*b+x)/(N*b-y)

(assuming y>N*b). Normally y should be about the same as b, while x is about b/2 for COSHV, but will be much larger if you're using current script and CHECKMULTISIG.

[harding]

@ajtowns

You could do a more generic analysis

I think that'd be useful in documentation that recommends commited-forward-batching (or whatever you call this technique). Obviously, having a formula would also make it nice to provide a graph showing how much this saves per outputs to be created.

Here, I think using a single specific example with a story attached makes the most sense as it requires the least amount of mental effort on the part of the reader to skim. You and John actually went through the table looking for errors because you want this newsletter to be accurate (thank you!), but I expect normal readers to just skip down to the bottom line (that's why it's in bold) and the conclusion sentence after it. That's good, because all I want the reader to think at this point is "this is a useful technique for saving money; now show me how COSHV makes this better".

[ajtowns]

141 vbytes matches the 1-input, 2-output (p2wpkh) example on https://en.bitcoin.it/wiki/Weight_units#Weight_for_segwit_transactions.

(Would be nice to provide the working for the vbyte calculations in an ipynb link or a onhover tooltip)

[ajtowns]

This isn't necessary -- Alice an instead generate a NUMS point P (that can't be used for signing), generate the OP_COSHV script S, calculate the taproot point Q = P+H(P,S)*G, and pay to Q. To spend, you need to know the NUMS point P, the script structure for S and the outputs that are being paid to.

The advantage of having P as a musig point instead is the recipients can then change the arrangement later if they want.

[harding]

@ajtowns

This [Alice asking participants for their pubkeys] isn't necessary

It is, because that pubkey (as a Taproot address) is where the output will ultimately be sent. I say "pubkey" here instead of "address" so that this looks almost identical to the example in the previous section using current script. There's a parenthetical here saying the pubkey is the taproot address and a linked footnote about why you shouldn't assume taproot addresses are necessarily pubkeys.

The advantage of having P as a musig point instead is the recipients can then change the arrangement later if they want.

Since we're going to use that feature in later subsections, I think it's best that we introduce Alice here as using musig to create the taproot internal key. I think it's always better for her to do so anyway.

[ajtowns]

Alice has to give all the receivers a copy of all the outputs, otherwise they can't claim their specific output.

[ajtowns]

I think the approach Jeremy is thinking of is a tree of outputs, ie:

• I want to pay to 125 people
• I make 25 COSHV outputs of 5 payments each
• I make 5 second level COSHV outputs, each grouping 5 of the 25 COSHV outputs I just generated
• I make a transaction that pays to a COSHV commitment of those 5 COSHV outputs

If one of the 125 people wants to collect their funds, they publish three transactions: one that expands the single COSHV commitment into 5; another that expands one of those into another 5; and a final one that expands one of those into 5 actual payments, including their own.

I think the more interesting (and scalable) MAST approach is to allow increasing fees: if Alice is paying 3 people, create a MAST tree of:

 [1 Bob, 2 Carol, 1.5 Dave, 0.4 Alice] OP_COSHV
 100 OP_CSV [1 Bob, 2 Carol, 1.5 Dave, 0.3995 Alice] OP_COSHV
 2000 OP_CSV [1 Bob, 2 Carol, 1.5 Dave, 0.39 Alice] OP_COSHV

allowing the first path to be used immediately, but adding 0.0005 BTC in fees via the second path if there hasn't been a low fee period within 100 blocks, and adding 0.01 BTC in fees if there hasn't been a low enough fee period in two weeks.

[ajtowns]

"active" not "activate"?

[JeremyRubin]

Had a chance to review the OP_COSHV parts! A few notes:

1. Overall, great summary. Captured the heart of what it's doing!
2. The S in COSHV is really to emphasize that it is OutputS, as opposed to Output, which could be separately discussed as an alternative design
3. The n! blowup only happens if you want to allow anyone to exit at any level. And because each level requires a Merkle tree lookup, this ends up being N Log N data! Uh-oh! It's much simpler if you just commit to a balanced tree of transaction data and have two options on the tapscript tree -- expand all or expand by two. Then you get something that is O(log(N)) worst case per individual, overall O(2N), and and E[O(1)] overhead if the expand all path is used -- we can learn optimal tree structures from real-world use over time.
4. We have some issues with malleability in the current design I didn't think about w.r.t. sequence and locktime and version. There is a simple fix for it, OP_SECURETHEBAG (which is like OP_COSHV, but you hash everything like a txid but the COutPoints values)
5. The size overhead of these txns can be reduced a lot if we ever figure out how/enable templated tapscript, for which there's a pending proposal from me (don't hold your breath, but it should be soft-fork friendly)

3 is probably the most critical to correct if you're time constrained.

4 is just a small spec error, and there are couple ways to fix it not mentioned here (e.g., by using CLTV or adding a Version Verify

[jnewbery]

Lightly reviewed the rest of it. Amazing newsletter, @harding!

[jnewbery]

This looks a bit weird directly below the Electrum image and talking about the Bitcoin Core wallet.

[jnewbery]

Should [ivgi tweet], [updated qr paragraph], [optech twitter] and [optech contributors] be in the newsletter markdown file instead of here?

[harding]

@JeremyRubin thanks for reviewing! I'll be pushing edits soon that implement the change from a MAST tree to an output tree; I think your design there is not only better but it also makes that section of the article much easier to read.

I'm unable to see where the malleability concerns come from, unless it's some sort of future-proof thing. It seems to me that the only thing you can do with tx version now is disable BIP68 consensus-enforced sequence, but if a tapscript is using BIP112 OP_CSV, it should fail if tx.version <2, right? For BIP68 sequence and nLockTime in other contexts, if anyone creates a transaction that can't be included in a block, that doesn't seem like an issue for COSHV because one of the other people with a copy of the transaction tree can just create an alternative transaction that can be included.

I'm sure I'm missing something obvious. If you could give me a hint, that'd be appreciated. We're pretty close to our publication deadline now and I don't want to try to describe something that I don't understand, so I think I'm going to omit that for now. We'll be able to cover it in a later newsletter when you make your proposal for it.

[harding]

I've gone through all the feedback (thanks!) and fixed all the nits and addressed most of the other comments. I've also fixed all the fixmes. That's all been pushed. If I get hit by a bus in the next couple hours (while sitting in my apartment), I think this should be publishable.

I'm going to keep working on some final edits and maybe image optimizations. I'll try to have that all done by 10:00 EDT (which is late, I know, sorry).

[ajtowns]

With COSHV all exits are certain (p=1) so none are more likely than others; I think the difference is some are more urgent than others. The outcome's the same -- since they're more urgent they're more likely to hit during high fees, so a shorter path saves fees.

[jnewbery]

"transaction transaction"

[jnewbery]

'the same amount of security' seems difficult to quantify. Yes, it's the same number of confirmations that need to be unwound to double spend, but the security model does seem different somehow, in that the funds can be held up until one of the recipients is prepared to pay the fee.

I'd consider rewording "the same amount of security" since it's a bit vague.

[jnewbery]

This is a bit tricky. We don't have package relay yet, so if the distribution transaction doesn't have enough fees to get into the mempool, then there's no way to bump it. That's an extreme case - most of the time I expect the distribution transaction's fee to be somewhere between the mempool minimum and the rate required to be mined. It might be worth adding that in the case of extreme fee spikes, the distribution transaction would be stranded until mempools emptied enough to accept it.

[jnewbery]

The tooltips are great, but it's not immediately intuitive that they exist. Consider adding a ℹ️symbol or a note at the bottom hover over fees in table for calculations

[harding]

Consider adding a information_sourcesymbol or a note at the bottom hover over fees in table for calculations

I agree it's hard to see that the tooltips exist, but I don't really want to draw attention to them. This is supposed to be a rough comparison table that covers just a single example to illustrate that there's significant savings to be had. Like I said to AJ, if we formally write up this idea as a way to save money, that would be the place to focus on providing formulas and stuff. Additionally, tooltips are not visible on touchscreen devices, so adding an icon here would be confusing for anyone reading on mobile (yeah, I could hide the icon on mobile or use JS to make the tooltip visible there or something).

[jnewbery]

ok. Sounds good!

[jnewbery]

It's slightly confusing that this says "save 99% on fees" but the paragraph below says "save 90%". Perhaps rephrase this to say that "anyone patient enough to wait a week for a transaction to
confirm (like the distribution transaction above) can set the feerate to 1% of that required for a fast confirmation" or similar, to make it clear that you're talking about feerate estimates here, and total fees saved in the paragraph below.

[jnewbery]

s/is COSHV is/if COSHV is/

[jnewbery]

also consider changing this to say "if COSHV becomes part of the Bitcoin protocol and sees regular use" or similar to emphasise that this is still a proposal

[jnewbery]

s/adopted/adapted/ ?

[jnewbery]

s/to construct of/to construct/

[jnewbery]

Also thank sipa for his input on key aggregation?

[jnewbery]

I've reviewed all the recent commits and it looks good to me.

ACK 9a47fc5

[jnewbery]

ACK 84a3d96

[bitschmidty]

tACK 84a3d96

[JeremyRubin]

I'm going to be annoying and leave a few more comments; overall it looks like an excellent presentation of the concept but a could have a few things a bit better; take em or leave em.

[harding]

@JeremyRubin please do!

[JeremyRubin]

https://github.com/JeremyRubin/lazuli/blob/master/doc/protocol.pdf is my earlier citation on doing it with ECDSA and shows how messy it is

[JeremyRubin]

It's not clear to me that you want to have a 'bushy tree' which pays out along a path rather than a simplest possible 8 or 16 node binary tree where payouts only happen on the leaf nodes. But you can, so it's not inaccurate. There's a trade off around free-riding and other things.

But I'm OK with is as the example of how to do it.

[JeremyRubin]

At every subtree

[JeremyRubin]

or every so often.

[JeremyRubin]

Also each participant only needs to verify their own path's commitments, other participants subtrees are not needed, which should improve privacy.

[JeremyRubin]

This isn't a necessity, you don't need to know the subtrees!

[harding]

Ah, that's fair. With the prior MAST construction, you did need to know; with output trees, you only need to know the path to your output (which leaks some data from other people's values in aggregate, but not necessarily anything directly).

[JeremyRubin]

Also the channel factories part was good before, but maybe a bit too much content :)

[jnewbery]

ACK 8c39672

[bitschmidty]

tACK 8c39672

[bitschmidty]

Big pat on the back for @harding for authoring this beast of a newsletter and for reviews from @JeremyRubin @jonatack @ajtowns @jnewbery and @moneyball w/ input from @sipa

[JeremyRubin]

I'm unable to see where the malleability concerns come from, unless it's some sort of future-proof thing. It seems to me that the only thing you can do with tx version now is disable BIP68 consensus-enforced sequence, but if a tapscript is using BIP112 OP_CSV, it should fail if tx.version <2, right? For BIP68 sequence and nLockTime in other contexts, if anyone creates a transaction that can't be included in a block, that doesn't seem like an issue for COSHV because one of the other people with a copy of the transaction tree can just create an alternative transaction that can be included.

If only I understood it better myself I could explain it -- I find OP_CSV and OP_CLTV to be something I can never load into my head how they work (appreciate any references).

Essentially the issue is best thought of in terms of channel factories. I have a txn A which has an output A.vout[0] which is OP_COSHV to create B.vout[0], which is a payment channel.

When I create txn B, neither the version nor the locktime is committed to in A.vout[0]'s OP_COSHV, so they can be set to any value. Given that, setting them can change the TXID which can break the payments made in the channel.

Does that make sense?

[harding]

@JeremyRubin thanks! That payment channels problem does make sense. I'll try to work in a note about that when we cover the other COSHV usages in next week's newsletter.

[JeremyRubin]

Yeah I'll try to put out an amended BIP by then