Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

News48 (2019-05-28ish) #149

Merged
merged 2 commits into from May 29, 2019

Conversation

@harding
Copy link
Contributor

harding commented May 28, 2019

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

Copy link
Contributor

jnewbery left a comment

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?

endcomment %}
{% assign bse = "https://bitcoin.stackexchange.com/a/" %}

- [Where in Bitcoin Core does it do X?]({{bse}}87450) Andrew Chow

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

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

This comment has been minimized.

Copy link
@moneyball

moneyball May 28, 2019

Contributor

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.

_posts/en/newsletters/2019-05-28-newsletter.md Outdated Show resolved Hide resolved
they are most naturally specified using an X,Y coordinate pair.
However, because a valid pubkey must be on an [elliptic curve][],
it's possible to find the Y coordinate for any given X coordinate
given the curve formula and a single bit of additional data.

This comment has been minimized.

Copy link
@bitschmidty

bitschmidty May 28, 2019

Contributor

For clarify, I like

bit of additional data representing the sign.

[emptystack reply]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016947.html
[elliptic curve]: https://en.wikipedia.org/wiki/Elliptic_curve
[smaller v1 spk]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html
[vid return to fees]: / {% comment %}<!-- FIXME: get YouTube link -->{% endcomment %}

This comment has been minimized.

Copy link
@bitschmidty

bitschmidty May 28, 2019

Contributor

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

- **Presentation: A Return to Fees:** During Blockchain Week NYC earlier
this month, Bitcoin Optech contributor Mike Schmidt gave a presentation
about Bitcoin transaction fees at the executive briefings organized
for Optech member companies. The [video for his presentation][vid

This comment has been minimized.

Copy link
@bitschmidty

bitschmidty May 28, 2019

Contributor

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

at Optech's first executive-focused briefing.

that includes an output for each of the receivers. Instead, she wants
to trustlessly commit to paying them in the future without having to pay
onchain fees for ten outputs now. So Alice asks each of the receivers
for one of their public keys and creates an unsigned *setup* transaction

This comment has been minimized.

Copy link
@bitschmidty

bitschmidty May 28, 2019

Contributor

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

@moneyball

This comment has been minimized.

Copy link
Contributor

moneyball commented May 28, 2019

ACK da97f74

(but still need to consider @jnewbery feedback)

Copy link
Contributor

moneyball left a comment

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

`OP_CHECKOUTPUTSHASHVERIFY` opcode and covers continued discussion of
Taproot. Also included are our regular sections on bech32 sending
support, top-voted Bitcoin StackExchange question and answers, and
notable changes in popular Bitcoin infrastructure projects.

This comment has been minimized.

Copy link
@moneyball

moneyball May 28, 2019

Contributor

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

to require the transaction spending it include a certain set of
outputs. For details, please see the special section about the
proposal later in this newsletter.

This comment has been minimized.

Copy link
@moneyball

moneyball May 28, 2019

Contributor

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.

endcomment %}
{% assign bse = "https://bitcoin.stackexchange.com/a/" %}

- [Where in Bitcoin Core does it do X?]({{bse}}87450) Andrew Chow

This comment has been minimized.

Copy link
@moneyball

moneyball May 28, 2019

Contributor

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.

_posts/en/newsletters/2019-05-28-newsletter.md Outdated Show resolved Hide resolved
Copy link
Contributor

jnewbery left a comment

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

"so overall this feels like something with marginal costs, but
also at most marginal benefits."

- *Move the oddness byte:* Bitcoin public keys are graph points, so

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

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

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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.

This comment has been minimized.

Copy link
@harding

harding May 29, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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.

vbytes (making it the same as P2WSH currently) with either zero
or 0.25 vbytes additional cost to spend a taproot output.

- FIXME maybe minisketch thing

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

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.

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 28, 2019

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

[emptystack reply]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016947.html
[elliptic curve]: https://en.wikipedia.org/wiki/Elliptic_curve
[smaller v1 spk]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-May/016943.html
[vid return to fees]: / {% comment %}<!-- FIXME: get YouTube link -->{% endcomment %}

This comment has been minimized.

Copy link
@jnewbery
even though the distribution transaction that actually pays the
receivers hasn't been broadcast or confirmed, the payments have the same
amount of security as the confirmed setup transaction. At any time, any
of the receivers who wants to spend their money further can broadcast

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

remove 'further'?


| | Individual Payments | Batched Payment | Commit now, distribute later |
|-|-|-|-|
| Immediate (high fee) transactions | 10x141 vbytes | 1x411 vbytes | 1x141 vbytes |

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

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)

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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)

This comment has been minimized.

Copy link
@harding

harding May 29, 2019

Author Contributor

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

|-|-|-|-|
| Immediate (high fee) transactions | 10x141 vbytes | 1x411 vbytes | 1x141 vbytes |
| Cost at 0.00142112 BTC/KvB | 0.00204641 | 0.00058409 | 0.0002003 |
| Delayed (low fee) transactions | --- | --- | 1x381 vbytes |

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

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.

place within Bitcoin. We omit the extra steps of collecting pubkeys
in this newsletter's examples in order to simplify the descriptions
of COSHV. Please consider consulting with a Bitcoin expert before
you implement any random protocol you read about in the pages of

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

nice disclaimer! consider s/any random/a/

transactions or even use [payment batching][] to send one transaction
that includes an output for each of the receivers. Instead, she wants
to trustlessly commit to paying them in the future without having to pay
onchain fees for ten outputs now. So Alice asks each of the receivers

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

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.

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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

receives everyone else's signatures, then she signs and broadcasts the
setup transaction.

![FIXME](/img/posts/2019-05-tx-tree-1.png)

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 28, 2019

Contributor

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?


## Proposed transaction output commitments

The [proposed][bip-coshv] opcode `OP_CHECKOUTPUTSHASHVERY` allows a

This comment has been minimized.

Copy link
@jonatack

jonatack May 28, 2019

s/VERY/VERIFY/

subsection's example is basically the same as using the pre-signed
transaction format with current Bitcoin transactions. However, the
ability to use Taproot to allow the receivers to choose from any one of
up to several billion spending conditions adds a significant amount of

This comment has been minimized.

Copy link
@jonatack

jonatack May 28, 2019

that's... quite a few indeed

discussion forward. There's no place for a bunch of people to say,
"hey, that's a really cool idea!" We suspect 30 replies in just a few
days from some well known Bitcoin protocol developers is its own subtle
complement: it means the proposal is interesting enough to warrant

This comment has been minimized.

Copy link
@jonatack

jonatack May 28, 2019

compliment?

@jonatack

This comment has been minimized.

Copy link

jonatack commented May 28, 2019

Great read; shaping up to an excellent bitcoinops issue

explain this using an example of just four receivers instead of ten.

Bob, Charlie, and Danielle, and Edmond receive a payment to a Taproot
address that contains multiple tapleafs using the COSHV opcode. Each

This comment has been minimized.

Copy link
@moneyball

moneyball May 29, 2019

Contributor

strike the 'and' before Danielle?

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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

This comment has been minimized.

Copy link
@harding

harding May 29, 2019

Author Contributor

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)


![FIXME](/img/posts/2019-05-tx-tree-3.png)

When one of receivers wants to withdraw their money from the covenant,

This comment has been minimized.

Copy link
@moneyball

moneyball May 29, 2019

Contributor

"the receivers" ?

interactively signed by all participants before the setup transaction
could be broadcast. This could easily require the signing of millions
of combinations by each participant.

This comment has been minimized.

Copy link
@moneyball

moneyball May 29, 2019

Contributor

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.

Copy link

ajtowns left a comment

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.

As time goes on, we expect more new wallets to only implement receiving
to the current best address format. Today that's v0 segwit addresses for
P2WPKH and P2WSH using bech32, but if Taproot is adopted, it'll be v1
segwit addresses that will [also use bech32][news45 bech32]. The longer your service

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

"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]." ?

"so overall this feels like something with marginal costs, but
also at most marginal benefits."

- *Move the oddness byte:* Bitcoin public keys are graph points, so

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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.

The [proposed][bip-coshv] opcode `OP_CHECKOUTPUTSHASHVERY` allows a
Taproot address to commit to one or more tapscripts that require the
transaction spending them to include a certain set of outputs. Before
we explain why that's a useful feature, let's take a moment to look at

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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

transactions or even use [payment batching][] to send one transaction
that includes an output for each of the receivers. Instead, she wants
to trustlessly commit to paying them in the future without having to pay
onchain fees for ten outputs now. So Alice asks each of the receivers

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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

Let's look at the example above in that context. To make later
comparisons to Taproot more fair, we'll assume some form of key and
signature aggregation is being used, such as [MuSig][] or (in theory)
multiparty ECDSA (see [Newsletter #18][]).

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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.

This comment has been minimized.

Copy link
@harding

harding May 29, 2019

Author Contributor

@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".


| | Individual Payments | Batched Payment | Commit now, distribute later |
|-|-|-|-|
| Immediate (high fee) transactions | 10x141 vbytes | 1x411 vbytes | 1x141 vbytes |

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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)

outputs matched the hash digest read from the script by COSHV.

Comparing this to our example above, Alice would again ask each of the
participants for a public key (such as a Taproot

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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.

This comment has been minimized.

Copy link
@harding

harding May 29, 2019

Author Contributor

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


![FIXME](/img/posts/2019-05-tx-tree-2.png)

Alice could then give each of the receivers a copy of all ten outputs to

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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

In our previous examples, getting the distribution transaction confirmed
was an all-or-nothing endeavor. Either all ten receivers finally
received their money at the same time, or all of them were still waiting
for that confirmation to occur. However, with a MAST tree and COSHV,

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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.

channels onchain (or all of them at the same time, if the MAST tree
includes branches for those outcomes). Also, like the joinpool, it's
possible for any participant to kick out any other participant (keeping
all channels intact), allowing activate participants to remove inactive

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

"active" not "activate"?

@JeremyRubin

This comment has been minimized.

Copy link

JeremyRubin commented May 29, 2019

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

Copy link
Contributor

jnewbery left a comment

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

and warning them that some services may not support bech32
addresses](/img/posts/2019-05-electrum-choose-wallet-type.png)

Please note that it's neither required nor recommended for wallet

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

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

[trust wallet]: https://trustwallet.com/
[electrum]: https://electrum.org/
[news45 bech32]: {{news45}}#bech32-sending-support
[ivgi tweet]: https://twitter.com/shesek/status/1131733590235131905

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

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

@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented May 29, 2019

@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 added a commit to harding/bitcoinops.github.io that referenced this pull request May 29, 2019
@harding

This comment has been minimized.

Copy link
Contributor Author

harding commented May 29, 2019

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

This balanced tree construction provides a good generic starting part for
allowing individuals to exit from the covenant without having to pay all
the exit costs themselves. When applying COSHV to specific cases where
it's known some exits are more likely than others, it's possible to

This comment has been minimized.

Copy link
@ajtowns

ajtowns May 29, 2019

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.

onchain fees for ten outputs now. So Alice asks each of the receivers
for one of their public keys and creates an unsigned and unbroadcast *setup* transaction
that pays those keys using a 10-of-10 multisig script. Then she creates
a child transaction transaction that spends from the multisig output to the

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

"transaction transaction"

way for any receivers to cheat any other receiver out of a payment. So
even though the distribution transaction that actually pays the
receivers hasn't been broadcast or confirmed, the payments have the same
amount of security as the confirmed setup transaction. At any time, any

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

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

amount of security as the confirmed setup transaction. At any time, any
of the receivers who wants to spend their money can broadcast
the distribution transaction and wait for it to confirm (perhaps helping
to pay its fee using child-pays-for-parent fee bumping).

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

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.


| | Individual Payments | Batched Payment | Commit now, distribute later |
|-|-|-|-|
| Immediate (high fee) transactions | 10x<abbr title="{{p2wpkh}}">141 vbytes</abbr> | 1x<abbr title="{{batched11}}">420 vbytes</abbr> | 1x<abbr title="{{p2wpkh}}">141 vbytes</abbr> |

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

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

This comment has been minimized.

Copy link
@harding

harding May 29, 2019

Author Contributor

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

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

ok. Sounds good!

payments during high fees and then only distribute the actual payments when
fees are lower. According to Bitcoin Core fee estimates at the time of
writing, anyone patient enough to wait a week for a transaction to
confirm (like the distribution transaction above) can save 99% on fees.

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

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.

the exit costs themselves. When applying COSHV to specific cases where
it's known some exits are more likely than others, it's possible to
use unbalanced trees to make the more likely outcomes less expensive.
We expect that is COSHV is adopted and sees regular use, tools such

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

s/is COSHV is/if COSHV is/

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

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

it's known some exits are more likely than others, it's possible to
use unbalanced trees to make the more likely outcomes less expensive.
We expect that is COSHV is adopted and sees regular use, tools such
as [miniscript][] will be adopted so that they take a set of desired

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

s/adopted/adapted/ ?

covenants.

However, even with the simple example above we again see the key benefit
of COSHV is its ability to allow Alice to construct of this complex

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

s/to construct of/to construct/

We thank Jeremy Rubin and Anthony Towns for their reviews of a draft of
this newsletter, including describing to us the tree of outputs idea.
Any errors in the published version of this newsletter are the fault of
the author.

This comment has been minimized.

Copy link
@jnewbery

jnewbery May 29, 2019

Contributor

Also thank sipa for his input on key aggregation?

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented May 29, 2019

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

ACK 9a47fc5

@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented May 29, 2019

ACK 84a3d96

@bitschmidty

This comment has been minimized.

Copy link
Contributor

bitschmidty commented May 29, 2019

tACK 84a3d96

@harding harding force-pushed the harding:2019-05-28-newsletter branch from f9a1956 to 936166e May 29, 2019
@JeremyRubin

This comment has been minimized.

Copy link

JeremyRubin commented May 29, 2019

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

This comment has been minimized.

Copy link
Contributor Author

harding commented May 29, 2019

@JeremyRubin please do!

Let's look at the example above in that context. To make later
comparisons to Taproot more fair, we'll assume some form of key and
signature aggregation is being used, such as [MuSig][] or (in theory)
multiparty ECDSA (see [Newsletter #18][]).

This comment has been minimized.

Copy link
@JeremyRubin

JeremyRubin May 29, 2019

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

an individual's money was withdrawn from the covenant. A complete tree
might for ten participants might look like this:

![Example output tree for ten participants](/img/posts/2019-05-tx-tree-5.png)

This comment has been minimized.

Copy link
@JeremyRubin

JeremyRubin May 29, 2019

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.

example) would get their exit outputs as a byproduct of another person's
exit. Overall, the total number of outputs that need to be created
would be greater than the number of participants. However, if nobody
tried to exit early, a Taproot leaf at the top level could optionally

This comment has been minimized.

Copy link
@JeremyRubin

JeremyRubin May 29, 2019

At every subtree

This comment has been minimized.

Copy link
@JeremyRubin

JeremyRubin May 29, 2019

or every so often.

be interactively signed by all participants before the setup transaction
could be broadcast. For larger numbers of participants, this could
easily require the signing of many thousands of transactions by each
participant.

This comment has been minimized.

Copy link
@JeremyRubin

JeremyRubin May 29, 2019

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

very difficult for a third party to use the transaction history graph to
determine which member of the pool was exiting.

Within the pool, it would unfortunately be the case that all members would know each others' pool

This comment has been minimized.

Copy link
@JeremyRubin

JeremyRubin May 29, 2019

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

This comment has been minimized.

Copy link
@harding

harding May 29, 2019

Author Contributor

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

This comment has been minimized.

Copy link

JeremyRubin commented May 29, 2019

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

@harding harding force-pushed the harding:2019-05-28-newsletter branch from 936166e to 1bb7eba May 29, 2019
harding and others added 2 commits May 28, 2019
@harding harding force-pushed the harding:2019-05-28-newsletter branch from 1bb7eba to 8c39672 May 29, 2019
@jnewbery

This comment has been minimized.

Copy link
Contributor

jnewbery commented May 29, 2019

ACK 8c39672

@bitschmidty

This comment has been minimized.

Copy link
Contributor

bitschmidty commented May 29, 2019

tACK 8c39672

@bitschmidty bitschmidty merged commit fbde477 into bitcoinops:master May 29, 2019
2 checks passed
2 checks passed
continuous-integration/travis-ci/pr The Travis CI build passed
Details
netlify/bitcoinops/deploy-preview Deploy preview ready!
Details
@bitschmidty

This comment has been minimized.

Copy link
Contributor

bitschmidty commented May 29, 2019

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

This comment has been minimized.

Copy link

JeremyRubin commented May 30, 2019

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

This comment has been minimized.

Copy link
Contributor Author

harding commented May 30, 2019

@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

This comment has been minimized.

Copy link

JeremyRubin commented May 30, 2019

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
7 participants
You can’t perform that action at this time.