Skip to content

Commit a6816e4

Browse files
hardingbitschmidty
harding
authored and
bitschmidty
committed
Newsletters: add 59 (2019-08-14)
1 parent 9941b9f commit a6816e4

File tree

6 files changed

+190
-0
lines changed

6 files changed

+190
-0
lines changed

‎_includes/specials/bech32/22-priority.md

Lines changed: 35 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,35 @@
1+
We've frequently mentioned the fee savings available to people spending
2+
segwit inputs, but we've never before mentioned that you don't need to
3+
take advantage of the savings. If you want, you can pay the same fee
4+
you would've paid without segwit in order to possibly have your
5+
transaction confirm more quickly (all other things being equal). For some
6+
users, such as traders attempting arbitrage across exchanges, saving
7+
money may not be as important as faster confirmation
8+
for the same amount of money.
9+
10+
To examine this idea, let's first generate a chart using Bitcoin Core's
11+
fee estimates that illustrates the potential fee savings available to
12+
creators of typical single-sig, one-input, two-output transactions:
13+
14+
![Estimated fee in USD, Y=fee, X=confirmation target](/img/posts/2019-08-rate-over-time.png)
15+
16+
We see that, in general, it takes longer for a transaction to confirm
17+
the less you pay---but users of segwit can often pay less per
18+
transaction for the same amount of waiting. Now let's simply re-arrange
19+
the axes for the same data:
20+
21+
![Estimated fee in USD, Y=confirmation target, X=fee](/img/posts/2019-08-time-over-rate.png)
22+
23+
For a given fee, it's expected that users of segwit will sometimes wait
24+
less time for confirmation than legacy users, with native segwit users
25+
gaining the greatest advantage. In these estimates, the variation in
26+
confirmation speed for different transaction types all paying the same
27+
total fee can be more than 6 blocks (about an hour on average).
28+
29+
For users and organizations who have a fixed maximum price they're
30+
willing to pay in fees per transaction, using segwit could significantly
31+
reduce confirmation time for their transactions during periods of
32+
high activity. Although this advantage only benefits people spending
33+
from bech32 and other segwit addresses, it's another reason to expect
34+
people and organizations will increasingly request your software and
35+
services pay bech32 addresses in the near future.

‎_posts/en/2019-03-19-bech32-sending-support.md

Lines changed: 6 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -153,5 +153,11 @@ on bech32 sending support, from March 19th to August 28th, 2019.
153153

154154
{% include specials/bech32/21-brd.md %}
155155

156+
## Same fee, faster confirmation
157+
158+
*Originally published in [Newsletter #59][].*
159+
160+
{% include specials/bech32/22-priority.md %}
161+
156162
## Footnotes
157163
{:.no_toc}

‎_posts/en/newsletters/2019-08-14-newsletter.md

Lines changed: 99 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,99 @@
1+
---
2+
title: 'Bitcoin Optech Newsletter #59'
3+
permalink: /en/newsletters/2019/08/14/
4+
name: 2019-08-14-newsletter
5+
slug: 2019-08-14-newsletter
6+
type: newsletter
7+
layout: newsletter
8+
lang: en
9+
---
10+
This week's newsletter briefly describes two discussions on the
11+
Bitcoin-Dev mailing list, one about Bitcoin vaults and one about
12+
reducing the size of public keys used in taproot. Also included are our
13+
regular sections about bech32 sending support and notable changes in
14+
popular Bitcoin infrastructure projects.
15+
16+
{% comment %}<!-- include references.md below the fold but above any Jekyll/Liquid variables-->{% endcomment %}
17+
{% include references.md %}
18+
19+
## Action items
20+
21+
- **[Optech schnorr/taproot workshops][taproot-workshop]:** Optech is hosting
22+
workshops in San Francisco (September 24) and New York (September 27) on
23+
schnorr signatures and taproot. Engineers will learn about these technologies
24+
and how they apply to their own products and services, build schnorr and
25+
taproot wallet implementations, and have an opportunity to take part in the
26+
feedback process for these proposed changes to the Bitcoin protocol.
27+
28+
Member companies should [send us an email][optech email] to reserve spots for
29+
your engineers.
30+
31+
## News
32+
33+
- **Bitcoin vaults without covenants:** In a [post][vault1] to the
34+
Bitcoin-Dev mailing list, Bryan Bishop describes how pre-signed
35+
transactions paid to scripts using `OP_CHECKSEQUENCEVERIFY` (CSV)
36+
could allow users to detect and block attempts to steal their money by
37+
a thief who had gained access to the user's private keys, a capability
38+
previously referred to as providing *Bitcoin vaults.* After
39+
describing at length both the basic protocol and several possible
40+
variations, Bishop made a second [post][vault2] describing one case
41+
where it would still be possible to steal from the vaults, although he
42+
also suggests a partial mitigation that would limit losses to a
43+
percentage of the protected funds and he requests proposals for the
44+
smallest necessary change to Bitcoin's consensus rules to fully
45+
mitigate the risk.
46+
47+
- **Proposed change to schnorr pubkeys:** Pieter Wuille started a
48+
[thread][pubkey32] on the Bitcoin-Dev mailing list requesting feedback
49+
on a proposal to switch [bip-schnorr][] and [bip-taproot][] to using
50+
32-byte public keys instead of the 33-byte compressed pubkeys
51+
previously proposed. Compressed pubkeys include a bit to indicate to
52+
verifiers whether their Y coordinate is an even or odd number.
53+
This can be combined with an algorithm that allows verifiers to
54+
determine two possible Y coordinates for the full pubkey from the
55+
32-byte X coordinate contained in the compressed pubkey. One of these
56+
coordinates is odd and one is even, so the oddness bit allows
57+
verifiers to pick the correct coordinate, preventing them from having
58+
to try both combinations during verification (which would slow down
59+
verification in general and eliminate any benefits from
60+
batch signature verification). Several
61+
<span title="voodoo">mathematical</span> schemes have been proposed
62+
that would produce signatures for keys whose Y coordinates could be
63+
inferred without the additional bit (which is currently the only data
64+
contained within a prefix byte). This would save one vbyte for each
65+
payment to a taproot output (potentially thousands of vbytes per block
66+
if most users migrate to taproot) and 0.25 vbytes for each public key
67+
included in a script-path spend. For previous discussion about
68+
32-byte pubkeys, please see [Newsletter #48][oddness byte].
69+
70+
## Bech32 sending support
71+
72+
*Week 22 of 24 in a [series][bech32 series] about allowing the people
73+
you pay to access all of segwit's benefits.*
74+
75+
{% include specials/bech32/22-priority.md %}
76+
77+
## Notable code and documentation changes
78+
79+
*Notable changes this week in [Bitcoin Core][bitcoin core repo],
80+
[LND][lnd repo], [C-Lightning][c-lightning repo], [Eclair][eclair repo],
81+
[libsecp256k1][libsecp256k1 repo], [Bitcoin Improvement Proposals
82+
(BIPs)][bips repo], and [Lightning BOLTs][bolts repo].*
83+
84+
- [C-Lightning #2858][] limits the maximum number of pending HTLCs in
85+
each direction to 30 (down from the maximum 483 allowed by the LN
86+
specification) and makes the value configurable with a
87+
`--max-concurrent-htlcs` option. The fewer the number of pending
88+
HTLCs, the smaller the byte size and fee cost of a unilateral close transaction
89+
because settling each HTLC produces a separate output that can only be
90+
spent by a fairly large input.
91+
92+
{% include linkers/issues.md issues="2858" %}
93+
[bech32 series]: /en/bech32-sending-support/
94+
[oddness byte]: {{news48}}#move-the-oddness-byte
95+
[vault1]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017229.html
96+
[vault2]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html
97+
[pubkey32]: https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017247.html
98+
[pr pubkey32]: https://github.com/sipa/bips/pull/52
99+
[taproot-workshop]: /workshops#taproot-workshop

‎img/posts/2019-08-feerates.gnuplot

Lines changed: 50 additions & 0 deletions
Original file line numberDiff line numberDiff line change
@@ -0,0 +1,50 @@
1+
#!/usr/bin/gnuplot
2+
3+
set style line 1 lc rgb '#8b1a0e' pt 4 ps 0.25 lt 1 lw 2
4+
set style line 2 lc rgb '#5e9c36' pt 4 ps 0.25 lt 1 lw 2
5+
set style line 3 lc rgb '#0025ad' pt 4 ps 0.25 lt 1 lw 2
6+
set style line 4 lc rgb '#d95319' pt 4 ps 0.25 lt 1 lw 2
7+
set style fill transparent solid 0.5 noborder
8+
9+
set terminal pngcairo size 800,200 font "Sans,12" transparent
10+
11+
set grid
12+
set tics nomirror
13+
unset border
14+
15+
CONF_RANGE=40
16+
USDBTC=12000
17+
## Byte size of typical 1-in-2-out tx from https://bitcoinops.org/en/bech32-sending-support/#fee-savings-with-native-segwit
18+
p2pkh=220
19+
p2sh_p2wpkh=167
20+
p2wpkh=141
21+
22+
fee(vbytes) = vbytes/1000.*USDBTC
23+
24+
set yrange [2:CONF_RANGE]
25+
set ylabel "Estimated wait time\n(blocks)"
26+
set xlabel "Fee in USD (1 BTC = $" . USDBTC / 1000 . "k USD)"
27+
set format x '$%.2f'
28+
set xtics 0.25
29+
set output './2019-08-time-over-rate.png'
30+
# Data generated using: for i in $( seq 2 1008 ) ; do bitcoin-cli estimatesmartfee $i ; done > fees.$( date +%s )
31+
plot '<sed -n "s/.*feerate...//p" ~/fees.1565306099' u ($1*fee(p2pkh)):($0+2) with lines ls 1 title "Legacy P2PKH" \
32+
, '' u ($1*fee(p2sh_p2wpkh)):($0+2) with lines ls 2 title "Hybrid P2SH-P2WPKH" \
33+
, '' u ($1*fee(p2wpkh)):($0+2) with lines ls 3 title "Segwit P2WPKH" \
34+
35+
36+
unset yrange
37+
set xrange [2:CONF_RANGE]
38+
set ylabel "Fee in USD\n(1 BTC = $" . USDBTC / 1000 . "k USD)"
39+
set xlabel "Estimated wait time (blocks)"
40+
set xtics 5
41+
set ytics 0.5
42+
set format y '$%.2f'
43+
unset format x
44+
set output './2019-08-rate-over-time.png'
45+
plot '<sed -n "s/.*feerate...//p" ~/fees.1565306099' u ($0+2):($1*fee(p2pkh)) with lines ls 1 title "Legacy P2PKH" \
46+
, '' u ($0+2):($1*fee(p2sh_p2wpkh)) with lines ls 2 title "Hybrid P2SH-P2WPKH" \
47+
, '' u ($0+2):($1*fee(p2wpkh)) with lines ls 3 title "Segwit P2WPKH" \
48+
49+
system("optipng -o7 ./2019-08-time-over-rate.png")
50+
system("optipng -o7 ./2019-08-rate-over-time.png")

‎img/posts/2019-08-rate-over-time.png

18.6 KB
Loading

‎img/posts/2019-08-time-over-rate.png

21.4 KB
Loading

0 commit comments

Comments
 (0)