Re: [bitcoin-dev] Making OP_TRUE standard?

[ZmnSCPxj via bitcoin-dev]

Good morning Luke and list,


> 
> (Aside, in case it wasn't clear on my previous email, the template-script idea
> 
> would not make it mandatory to spend in the same block, but that the UTXO
> 
> would merely cease to be valid after that block. So the 0-value output does
> 
> not take up a UTXO db entry when left unused.)

Thank you for clearing this up.  It seems, I misunderstood.  So my earlier 
rumination, about having two options for Lightning, is incorrect.

For Lightning, we just need to add this 0-value OP_TRUE output always to 
transactions that require both side signatures (commitment, HTLC-timeout, 
HTLC-success), and it will always serve as a "hook" for  adding more fees if 
needed.

Regards,
ZmnSCPxj
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

[Bram Cohen via bitcoin-dev]

I'm not sure about the best way to approach soft-forking (I've opined on it
before, and still find the details mind-numbing) but the end goal seems
fairly clearly to be an all of the above: Have aggregatable public keys
which support simple signatures, taproot with BIP 114 style taproot, and
Graftroot. And while you're at it, nuke OP_IF from orbit and make all the
unused opcodes be return success.

This all in principle could be done in one fell swoop with a single new
script type. That would be a whole lot of stuff to roll out at once, but at
least it wouldn't have so many painstaking intermediate soft forks to
administer.

On Thu, May 10, 2018 at 7:23 AM, Russell O'Connor via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thanks for writing this up Anthony.
>
> Do you think that a CHECKSIGFROMSTACK proposal should be included within
> this discussion of signature soft-forks, or do you see it as an unrelated
> issue?
>
> CHECKSIGFROMSTACK enables some forms of (more) efficent MPC (See
> http://people.csail.mit.edu/ranjit/papers/scd.pdf), enables poor-man's
> covenants, and I believe the lightning folks are interested in it as well
> for some constant space storage scheme.
>
> On Thu, May 10, 2018 at 8:10 AM, Anthony Towns via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello world,
>>
>> After the core dev meetup in March I wrote up some notes of where I
>> think things stand for signing stuff post-Schnorr. It was mostly for my
>> own benefit but maybe it's helpful for others too, so...
>>
>> They're just notes, so may assume a fair bit of background to be able to
>> understand the meaning of the bullet points. In particular, note that I'm
>> using "schnorr" just to describe the signature algorithm, and the terms
>> "key aggregation" to describe turning an n-of-n key multisig setup into
>> a single key setup, and "signature aggregation" to describe combining
>> signatures from many inputs/transactions together: those are often all
>> just called "schnorr signatures" in various places.
>>
>>
>> Anyway! I think it's fair to split the ideas around up as follows:
>>
>> 1) Schnorr CHECKSIG
>>
>>   Benefits:
>> - opportunity to change signature encoding from DER to save a few
>>   bytes per signature, and have fixed size signatures making tx size
>>   calculations easier
>>
>> - enables n-of-n multisig key aggregation (a single pubkey and
>>   signature gives n-of-n security; setup non-interactively via muSig,
>>   or semi-interactively via proof of possession of private key;
>>   interactive signature protocol)
>>
>> - enables m-of-n multisig key aggregation with interactive setup and
>>   interactive signature protocol, and possibly substantial storage
>>   requirements for participating signers
>>
>> - enables scriptless scripts and discreet log contracts via
>>   key aggregation and interactive
>>
>> - enables payment decorrelation for lightning
>>
>> - enables batch validation of signatures, which substantially reduces
>>   computational cost of signature verification, provided a single
>>   "all sigs valid" or "some sig(s) invalid" output (rather than
>>   "sig number 5 is invalid") is sufficient
>>
>> - better than ecdsa due to reducing signature malleability
>>   (and possibly due to having a security proof that has had more
>>   review?)
>>
>>Approaches:
>>  - bump segwit version to replace P2WPKH
>>  - replace an existing OP_NOP with OP_CHECKSCHNORRVERIFY
>>  - hardfork to allowing existing addresses to be solved via Schnorr
>> sig
>>as alternative to ECDSA
>>
>> 2) Merkelized Abstract Syntax Trees
>>
>>Two main benefits for enabling MAST:
>> - logarithmic scaling for scripts with many alternative paths
>> - only reveals (approximate) number of alternative execution branches,
>>   not what they may have been
>>
>>Approaches:
>> - replace an existing OP_NOP with OP_MERKLE_TREE_VERIFY, and treat an
>>   item remaining on the alt stack at the end of script exeution as a
>>   script and do tail-recursion into it (BIP 116, 117)
>> - bump the segwit version and introduce a "pay-to-merkelized-script"
>>   address form (BIP 114)
>>
>> 3) Taproot
>>
>>Requirements:
>> - only feasible if Schnorr is available (required in order to make the
>>   pubkey spend actually be a multisig spend)
>> - andytoshi has written up a security proof at
>>   https://github.com/apoelstra/taproot
>>
>>Benefits:
>> - combines pay-to-pubkey and pay-to-script in a single address,
>>   improving privacy
>> - allows choice of whether to use pubkey or script at spend time,
>>   allowing for more efficient spends (via pubkey) without reducing
>>   flexibility (via script)
>>
>>Approaches:
>> - bump segwit version and introduce a "pay-to-taproot" address form
>>
>> 4) Graftroot
>>
>>Requirements:
>> 

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

[Chris Belcher via bitcoin-dev]

Thanks for the summary,

It may be worth emphasizing the fungibility aspects of all this.

That summary contains ideas to possibly have separate address types,
opcodes and scriptSigs/witnesses for different feature, at least to
start with. To me this would seem bad because it may miss out on the
fungibility gain from having everything look exactly the same.

With schnorr we may have a unique opportunity to greatly improve
fungibility. It's not too hard to imagine a world where users of
Lightning Network, coinswap, MAST, scriptless scripts, multisig,
taproot, graftroot, etc and regular single-signature on-chain payments
all appear completely indistinguishable. Tracking and data mining could
become pointless when coins can teleport undetectably to a different
place on the blockchain via any number of off-chain protocols.

Of course the downside of doing it like this is that every feature would
probably have to be developed, reviewed, tested and deployed together,
rather than one at a time.

On 10/05/18 13:10, Anthony Towns via bitcoin-dev wrote:
> Hello world,
> 
> After the core dev meetup in March I wrote up some notes of where I
> think things stand for signing stuff post-Schnorr. It was mostly for my
> own benefit but maybe it's helpful for others too, so...
> 
> They're just notes, so may assume a fair bit of background to be able to
> understand the meaning of the bullet points. In particular, note that I'm
> using "schnorr" just to describe the signature algorithm, and the terms
> "key aggregation" to describe turning an n-of-n key multisig setup into
> a single key setup, and "signature aggregation" to describe combining
> signatures from many inputs/transactions together: those are often all
> just called "schnorr signatures" in various places.
> 
> 
> Anyway! I think it's fair to split the ideas around up as follows:
> 
> 1) Schnorr CHECKSIG
> 
>   Benefits:
> - opportunity to change signature encoding from DER to save a few
>   bytes per signature, and have fixed size signatures making tx size
>   calculations easier
> 
> - enables n-of-n multisig key aggregation (a single pubkey and
>   signature gives n-of-n security; setup non-interactively via muSig,
>   or semi-interactively via proof of possession of private key;
>   interactive signature protocol)
> 
> - enables m-of-n multisig key aggregation with interactive setup and
>   interactive signature protocol, and possibly substantial storage
>   requirements for participating signers
> 
> - enables scriptless scripts and discreet log contracts via
>   key aggregation and interactive
> 
> - enables payment decorrelation for lightning
> 
> - enables batch validation of signatures, which substantially reduces
>   computational cost of signature verification, provided a single
>   "all sigs valid" or "some sig(s) invalid" output (rather than
>   "sig number 5 is invalid") is sufficient
> 
> - better than ecdsa due to reducing signature malleability
>   (and possibly due to having a security proof that has had more
>   review?)
> 
>Approaches:
>  - bump segwit version to replace P2WPKH
>  - replace an existing OP_NOP with OP_CHECKSCHNORRVERIFY
>  - hardfork to allowing existing addresses to be solved via Schnorr sig
>as alternative to ECDSA
> 
> 2) Merkelized Abstract Syntax Trees
> 
>Two main benefits for enabling MAST:
> - logarithmic scaling for scripts with many alternative paths
> - only reveals (approximate) number of alternative execution branches,
>   not what they may have been
> 
>Approaches:
> - replace an existing OP_NOP with OP_MERKLE_TREE_VERIFY, and treat an
>   item remaining on the alt stack at the end of script exeution as a
>   script and do tail-recursion into it (BIP 116, 117)
> - bump the segwit version and introduce a "pay-to-merkelized-script"
>   address form (BIP 114)
> 
> 3) Taproot
> 
>Requirements:
> - only feasible if Schnorr is available (required in order to make the
>   pubkey spend actually be a multisig spend)
> - andytoshi has written up a security proof at
>   https://github.com/apoelstra/taproot
> 
>Benefits:
> - combines pay-to-pubkey and pay-to-script in a single address,
>   improving privacy
> - allows choice of whether to use pubkey or script at spend time,
>   allowing for more efficient spends (via pubkey) without reducing
>   flexibility (via script)
> 
>Approaches:
> - bump segwit version and introduce a "pay-to-taproot" address form
> 
> 4) Graftroot
> 
>Requirements:
> - only really feasible if Schnorr is implemented first, so that
>   multiple signers can be required via a single pubkey/signature
> - people seem to want a security proof for this; not sure if that's
>   hard or straightforward
> 
>Benefits:
> - allows delegation of authorisation to spend an output already
>   

Re: [bitcoin-dev] MAST/Schnorr related soft-forks

[Russell O'Connor via bitcoin-dev]

Thanks for writing this up Anthony.

Do you think that a CHECKSIGFROMSTACK proposal should be included within
this discussion of signature soft-forks, or do you see it as an unrelated
issue?

CHECKSIGFROMSTACK enables some forms of (more) efficent MPC (See
http://people.csail.mit.edu/ranjit/papers/scd.pdf), enables poor-man's
covenants, and I believe the lightning folks are interested in it as well
for some constant space storage scheme.

On Thu, May 10, 2018 at 8:10 AM, Anthony Towns via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello world,
>
> After the core dev meetup in March I wrote up some notes of where I
> think things stand for signing stuff post-Schnorr. It was mostly for my
> own benefit but maybe it's helpful for others too, so...
>
> They're just notes, so may assume a fair bit of background to be able to
> understand the meaning of the bullet points. In particular, note that I'm
> using "schnorr" just to describe the signature algorithm, and the terms
> "key aggregation" to describe turning an n-of-n key multisig setup into
> a single key setup, and "signature aggregation" to describe combining
> signatures from many inputs/transactions together: those are often all
> just called "schnorr signatures" in various places.
>
>
> Anyway! I think it's fair to split the ideas around up as follows:
>
> 1) Schnorr CHECKSIG
>
>   Benefits:
> - opportunity to change signature encoding from DER to save a few
>   bytes per signature, and have fixed size signatures making tx size
>   calculations easier
>
> - enables n-of-n multisig key aggregation (a single pubkey and
>   signature gives n-of-n security; setup non-interactively via muSig,
>   or semi-interactively via proof of possession of private key;
>   interactive signature protocol)
>
> - enables m-of-n multisig key aggregation with interactive setup and
>   interactive signature protocol, and possibly substantial storage
>   requirements for participating signers
>
> - enables scriptless scripts and discreet log contracts via
>   key aggregation and interactive
>
> - enables payment decorrelation for lightning
>
> - enables batch validation of signatures, which substantially reduces
>   computational cost of signature verification, provided a single
>   "all sigs valid" or "some sig(s) invalid" output (rather than
>   "sig number 5 is invalid") is sufficient
>
> - better than ecdsa due to reducing signature malleability
>   (and possibly due to having a security proof that has had more
>   review?)
>
>Approaches:
>  - bump segwit version to replace P2WPKH
>  - replace an existing OP_NOP with OP_CHECKSCHNORRVERIFY
>  - hardfork to allowing existing addresses to be solved via Schnorr sig
>as alternative to ECDSA
>
> 2) Merkelized Abstract Syntax Trees
>
>Two main benefits for enabling MAST:
> - logarithmic scaling for scripts with many alternative paths
> - only reveals (approximate) number of alternative execution branches,
>   not what they may have been
>
>Approaches:
> - replace an existing OP_NOP with OP_MERKLE_TREE_VERIFY, and treat an
>   item remaining on the alt stack at the end of script exeution as a
>   script and do tail-recursion into it (BIP 116, 117)
> - bump the segwit version and introduce a "pay-to-merkelized-script"
>   address form (BIP 114)
>
> 3) Taproot
>
>Requirements:
> - only feasible if Schnorr is available (required in order to make the
>   pubkey spend actually be a multisig spend)
> - andytoshi has written up a security proof at
>   https://github.com/apoelstra/taproot
>
>Benefits:
> - combines pay-to-pubkey and pay-to-script in a single address,
>   improving privacy
> - allows choice of whether to use pubkey or script at spend time,
>   allowing for more efficient spends (via pubkey) without reducing
>   flexibility (via script)
>
>Approaches:
> - bump segwit version and introduce a "pay-to-taproot" address form
>
> 4) Graftroot
>
>Requirements:
> - only really feasible if Schnorr is implemented first, so that
>   multiple signers can be required via a single pubkey/signature
> - people seem to want a security proof for this; not sure if that's
>   hard or straightforward
>
>Benefits:
> - allows delegation of authorisation to spend an output already
>   on the blockchain
> - constant scaling for scripts with many alternative paths
>   (better than MAST's logarithmic scaling)
> - only reveals the possibility of alternative execution branches,
>   not what they may have been or if any actually existed
>
>Drawbacks:
> - requires signing keys to be online when constructing scripts (cannot
>   do complicated pay to cold wallet without warming it up)
> - requires storing signatures for scripts (if you were able to
>   reconstruct the sigs, 

Re: [bitcoin-dev] BIP sighash_noinput

[Christian Decker via bitcoin-dev]

Olaoluwa Osuntokun  writes:
> Super stoked to see that no_input has been resurrected!!! I actually
> implemented a variant back in 2015 when Tadge first described the
> approach to me for both btcd [1], and bitcoind [2]. The version being
> proposed is _slightly_ differ though, as the initial version I
> implemented still committed to the script being sent, while this new
> version just relies on witness validity instead. This approach is even
> more flexible as the script attached to the output being spent can
> change, without rendering the spending transaction invalid as long as
> the witness still ratifies a branch in the output's predicate.

Yeah, we removed the script commitment out of necessity for eltoo, but
it seems to add a lot of flexibility that might be useful. One
additional use-case that came to mind is having a recovery transaction
for vault-like scenarios, i.e., a transaction that can short-circuit a
thawing process of frozen funds. You'd keep that transaction in a vault,
pre-signed and bind it to whatever action you'd like to interrupt.

> Given that this would introduce a _new_ sighash flag, perhaps we
> should also attempt to bundle additional more flexible sighash flags
> concurrently as well?  This would require a larger overhaul w.r.t to
> how sighash flags are interpreted, so in this case, we may need to
> introduce a new CHECKSIG operator (lets call it CHECKSIG_X for now),
> which would consume an available noop opcode. As a template for more
> fine grained sighashing control, I'll refer to jl2012's BIP-0YYY [3]
> (particularly the "New nHashType definitions" section).  This was
> originally proposed in the context of his merklized script work as it
> more or less opened up a new opportunity to further modify script
> within the context of merklized script executions.  The approach reads
> in the sighash flags as a bit vector, and allows developers to express
> things like: "don't sign the input value, nor the sequence, but sign
> the output of this input, and ONLY the script of this output". This
> approach is _extremely_ powerful, and one would be able to express the
> equivalent of no_input by setting the appropriate bits in the sighash.

I purposefully made the proposal as small and as well defined as
possible, with a number of possible applications to back it, since I
think this might be the best way to introduce a new feature and make it
as uncontroversial as possible. I'm not opposed to additional flags
being deployed in parallel, but they'll need their own justification and
analysis, and shouldn't be rushed just "because we're doing noinput".

Going for a separate op-code is definitely an option we considered, but
just for noinput it'd be duplicating quite a lot of existing
functionality. With additional sighash flags it might become necessary,
but I don't think it is necessary just for noinput.

> Looking forward in hearing y'alls thoughts on this approach, thanks.
>
> [1]: https://github.com/Roasbeef/btcd/commits/SIGHASH_NOINPUT
> [2]: https://github.com/Roasbeef/bitcoin/commits/SIGHASH_NOINPUT
> [3]: 
> https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki#new-nhashtype-definitions
>
> -- Laolu
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] eltoo: A Simplified update Mechanism for Lightning and Off-Chain Contracts

[Christian Decker via bitcoin-dev]

Olaoluwa Osuntokun via bitcoin-dev
 writes:

> Hi Jimpo,
>
> You're correct that the introduction of symmetric state now
> re-introduces the dependency between the CSV value of the commitment,
> and the HTLC timeouts.  It's worth nothing that this issue existed in
> an earlier version of the BOLT spec, this was pointed out by Mats in
> the past: [1][2]. The dependency meant that if we wanted to allow very
> long CSV time outs (like 1 month +), then this would have the adverse
> effect of increasing the total CLTV timeout along the entire route. As
> a result, we moved to the 2-stage HTLC scheme which is now implemented
> and deployed as a part of BOLT 1.0. It may be the case that in the mid
> to near future, most implementations aren't concerned about long time
>  locks due to the existence of robust and reliable private
> outsourcers.

It's worth mentioning that the requirement for extremely large CLTV deltas
would already create incredibly long CLTV deltas between the endpoints,
since the endpoint delta accumulates along the path. This is true for
LN-Penalty as well as eltoo. eltoo's requirement to settle before the
HTLCs touch the blockchain adds a stage in which need to start on-chain
settlement to ensure the HTLC hits the chain before its CLTV
expires. We can imagine this as a separate timewindow, that does not
accumulate across multiple hops (settlement ordering is not an issue,
CLTV resolution is).

My hope is that indeed with the simpler watch-towers we can reduce both
the CLTV deltas as well as the settlement timeouts for eltoo, so that
they become negligible.

> As a side effect of the way the symmetric state changes the strategy
> around breach attempts, we may see more breach attempts (and therefore
> update transactions) on the chain since attempting to cheat w/ vanilla
> symmetric state is now "costless" (worst case we just use the latest
> state, best case I can commit the state better for me. This is in
> stark contrast to punishment/slashing based approaches where a failed
> breach attempt results in the cheating party losing all their funds.

Not exactly costless, since the breaching party will have to pay the
on-chain fees, and we may be able to reintroduce the reserve in order to
add an additional punishment on top of the simple update mechanism
(selectively introducing asymmetry).

> However, with a commitment protocol that uses symmetric state. The
> 2-stage HTLC scheme doesn't actually apply. Observe that with
> Lighting's current asymmetric state commitment protocol, the "clock"
> starts ticking as soon as the commitment hits the chain, and we follow
> the "if an output pays to me, it must be delayed as I may be
> attempting a breach". With symmetric state this no longer applies, the
> clock instead starts "officially" ticking after the latest update
> transaction has hit the chain, and there are no further challenges. As
> a result of this, the commitment transaction itself doesn't need to
> have any CSV delays within the Script branches of the outputs it
> creates. Instead, each of those outputs can be immediately be spent as
> the challenge period has already elapsed, and from the PoV of the
> chain, this is now the "correct" commitment. Due to this, the HTLC
> outputs would now be symmetric themselves, and look very much like an
> HTLC output that one would use in a vanilla on-chain cross-chain
> atomic swap.

In addition to this it is worth pointing out that the old/replaced HTLCs
have no way of ever touching the blockchain, so we can throw away a
whole heap of data about these HTLCs, that we would have to carry around
indefinitely if this were not the case. The same reason the HTLCs start
ticking when a settlement touches the chain in LN-penalty is also the
reason we need to carry all that data around. eltoo can be said to
contain the two stage HTLC commit we added on top of LN-penalty.

Cheers,
Christian
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Idea: More decimal places for lower minimum fee

[Alex Morcos via bitcoin-dev]

Fee rates in Bitcoin Core are measured in satoshis/kB.   There are a couple
places where a minimum of 1000 satoshis/kB is assumed.

Setting "incrementalrelayfee" to a smaller than default value and either
leaving "minrelaytxfee" unset or also setting it smaller will be sufficient
to allow your node to accept and relay transactions with smaller fee
rates.  Of course without the rest of the network making these changes
and/or the miners being willing to mine those transactions, it won't be of
much benefit.

Fee estimation doesn't distinguish fee rates less than 1000 sats/kB.  This
would be more substantial to change.



On Thu, May 10, 2018 at 4:10 AM, st-bind--- via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Currently, the minimum fee of 1 satoshi per byte corresponds to about 0.09
> USD per kB, which is no longer insignificant. Maybe the time has come now
> to introduce more decimal places and make the minimum fee 1 of the new
> smallest unit. This way, everyday payments would again be possible with
> virtually no fee without flooding the mempool with free spam transactions.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] BIP proposal - Dandelion: Privacy Preserving Transaction Propagation

[Bradley Denby via bitcoin-dev]

Hi all,

We're writing with an update on the Dandelion project. As a reminder,
Dandelion
is a practical, lightweight privacy solution that provides Bitcoin users
formal
anonymity guarantees. While other privacy solutions aim to protect
individual
users, Dandelion protects privacy by limiting the capability of adversaries
to
deanonymize the entire network.

Bitcoin's transaction spreading protocol is vulnerable to deanonymization
attacks. When a node generates a transaction without Dandelion, it transmits
that transaction to its peers with independent, exponential delays. This
approach, known as diffusion in academia, allows network adversaries to link
transactions to IP addresses.

Dandelion prevents this class of attacks by sending transactions over a
randomly
selected path before diffusion. Transactions travel along this path during
the
"stem phase" and are then diffused during the "fluff phase" (hence the name
Dandelion). We have shown that this routing protocol provides near-optimal
anonymity guarantees among schemes that do not introduce additional
encryption
mechanisms.

Since the last time we contacted the list, we have:
 - Completed additional theoretical analysis and simulations
 - Built a working prototype
   (https://github.com/mablem8/bitcoin/tree/dandelion)
 - Built a test suite for the prototype
   (https://github.com/mablem8/bitcoin/blob/dandelion/test/
functional/p2p_dandelion.py)
 - Written detailed documentation for the new implementation
   (https://github.com/mablem8/bips/blob/master/bip-
dandelion/dandelion-reference-documentation.pdf)

Among other things, one question we've addressed in our additional analysis
is
how to route messages during the stem phase. For example, if two Dandelion
transactions arrive at a node from different inbound peers, to which
Dandelion
destination(s) should these transactions be sent? We have found that some
choices are much better than others.

Consider the case in which each Dandelion transaction is forwarded to a
Dandelion destination selected uniformly at random. We have shown that this
approach results in a fingerprint attack allowing network-level botnet
adversaries to achieve total deanonymization of the P2P network after
observing
less than ten transactions per node.

To avoid this issue, we suggest "per-inbound-edge" routing. Each inbound
peer is
assigned a particular Dandelion destination. Each Dandelion transaction that
arrives via this peer is forwarded to the same Dandelion destination.
Per-inbound-edge routing breaks the described attack by blocking an
adversary's
ability to construct useful fingerprints.

This iteration of Dandelion has been tested on our own small network, and we
would like to get the implementation in front of a wider audience. An
updated
BIP document with further details on motivation, specification,
compatibility,
and implementation is located here:
https://github.com/mablem8/bips/blob/master/bip-dandelion.mediawiki

We would like to thank the Bitcoin Core developers and Gregory Maxwell in
particular for their insightful comments, which helped to inform this
implementation and some of the follow-up work we conducted. We would also
like
to thank the Mimblewimble development community for coining the term
"stempool,"
which we happily adopted for this implementation.

All the best,
Brad Denby 
Andrew Miller 
Giulia Fanti 
Surya Bakshi 
Shaileshh Bojja Venkatakrishnan 
Pramod Viswanath 
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] Idea: More decimal places for lower minimum fee

[st-bind--- via bitcoin-dev]

Currently, the minimum fee of 1 satoshi per byte corresponds to about 
0.09 USD per kB, which is no longer insignificant. Maybe the time has 
come now to introduce more decimal places and make the minimum fee 1 of 
the new smallest unit. This way, everyday payments would again be 
possible with virtually no fee without flooding the mempool with free 
spam transactions.

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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

[Patrick Shirkey via bitcoin-dev]

> On 3/17/18, someone posted on the Lightning-dev list, "Can I try
> Lightning without running a fully-fledged bitcoin block chain? (Yubin
> Ruan)."  The inquirer was asking because he didn't have much space to
> store the entire blockchain on his laptop.
>
> I replied:
>
> "Developers,
>
> On THIS note and slightly off-topic but relevant, why can't chunks of
> blockchain peel off the backend periodically and be archived, say on
> minimum of 150 computers across 7 continents?
>
> It seems crazy to continue adding on to an increasingly long chain to
> infinity if the old chapters (i.e. more than, say, 2 years old) could be
> stored in an evenly distributed manner across the planet. The same 150
> computers would not need to store every chapter either, just the index
> would need to be widely distributed in order to reconnect with a chapter
> if needed. Then maybe it is no longer a limitation in the future for
> people like Yubin. "
>
> It was suggested by a couple of lightning developers that I post this
> idea on the bitcoin-dev list.  So, here I post :).
>

You can already use the "prune" flag to get a snapshot of the blockchain
but it is incompatible with "txindex" and "rescan" so maybe that is and
issue for lightning nodes?




-- 
Patrick Shirkey
Boost Hardware

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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

[ZmnSCPxj via bitcoin-dev]

Good morning karl and Segue,

Specifically for c-lightning, we are not yet rated for pruned bitcoind use, 
although if you installed and started running bitcoind before installing the 
lightningd, caught up to the chain, and then installed lightningd and set 
things up so that bitcoind will get killed if lightningd stops running (so that 
bitcoind will "never" leave lightningd too far behind).

Officially though pruned bitcoind is not supported for c-lightning, so loss of 
funds due to doing the above idea is entirely your fault.

On the topic of such a "chapter-based" archiving, it needs to get implemented 
and reviewed.  As-is I see no reason why it cannot be done, but I think the 
details are far more important.

1.  How do we select the archive servers?
2.  How can we ensure that no chapter has only a small number of actual owners 
who could easily coordinate to deny access to historical blockchain data to 
those they deem undesirable?

Regards,
ZmnSCPxj

‐‐‐ Original Message ‐‐‐

On May 10, 2018 2:48 PM, アルム　カールヨハン via bitcoin-dev 
 wrote:

> He can use pruning to only store the last X MB of the blockchain. It
> 
> will store the UTXO set though, which is a couple of GBs. In total, a
> 
> pruned node with pruning set to 1000 MB ends up using 4.5 GB
> 
> currently, but it varies slightly due to the # of UTXOs in existence.
> 
> On Thu, May 10, 2018 at 9:56 AM, Segue via bitcoin-dev
> 
> bitcoin-dev@lists.linuxfoundation.org wrote:
> 
> > On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning
> > 
> > without running a fully-fledged bitcoin block chain? (Yubin Ruan)." The
> > 
> > inquirer was asking because he didn't have much space to store the entire
> > 
> > blockchain on his laptop.
> > 
> > I replied:
> > 
> > "Developers,
> > 
> > On THIS note and slightly off-topic but relevant, why can't chunks of
> > 
> > blockchain peel off the backend periodically and be archived, say on minimum
> > 
> > of 150 computers across 7 continents?
> > 
> > It seems crazy to continue adding on to an increasingly long chain to
> > 
> > infinity if the old chapters (i.e. more than, say, 2 years old) could be
> > 
> > stored in an evenly distributed manner across the planet. The same 150
> > 
> > computers would not need to store every chapter either, just the index would
> > 
> > need to be widely distributed in order to reconnect with a chapter if
> > 
> > needed. Then maybe it is no longer a limitation in the future for people
> > 
> > like Yubin. "
> > 
> > It was suggested by a couple of lightning developers that I post this idea
> > 
> > on the bitcoin-dev list. So, here I post :).
> > 
> > Segue
> > 
> > bitcoin-dev mailing list
> > 
> > bitcoin-dev@lists.linuxfoundation.org
> > 
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> 
> bitcoin-dev mailing list
> 
> bitcoin-dev@lists.linuxfoundation.org
> 
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev


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

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

[Jim Posen via bitcoin-dev]

That is a good observation that most of the historical data does not need
to be kept around. I believe what you are suggested is already implemented,
however. Bitcoin Core can operate in a pruned mode, where the bulk of the
historical block data is discarded and only the current UTXO set (and a few
recent blocks) are kept. As you note, some nodes on the network need to run
in archive mode to help new nodes get in sync. BIP 159 helps identify these
archive nodes at the gossip layer.

In the case of lightning, some implementations made use of the additional
txindex, which is not compatible with pruned mode.

On Wed, May 9, 2018 at 5:56 PM, Segue via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning
> without running a fully-fledged bitcoin block chain? (Yubin Ruan)."  The
> inquirer was asking because he didn't have much space to store the entire
> blockchain on his laptop.
>
> I replied:
>
> "Developers,
>
> On THIS note and slightly off-topic but relevant, why can't chunks of
> blockchain peel off the backend periodically and be archived, say on
> minimum of 150 computers across 7 continents?
>
> It seems crazy to continue adding on to an increasingly long chain to
> infinity if the old chapters (i.e. more than, say, 2 years old) could be
> stored in an evenly distributed manner across the planet. The same 150
> computers would not need to store every chapter either, just the index
> would need to be widely distributed in order to reconnect with a chapter if
> needed. Then maybe it is no longer a limitation in the future for people
> like Yubin. "
>
> It was suggested by a couple of lightning developers that I post this idea
> on the bitcoin-dev list.  So, here I post :).
>
> Segue
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] MAST/Schnorr related soft-forks

[Anthony Towns via bitcoin-dev]

Hello world,

After the core dev meetup in March I wrote up some notes of where I
think things stand for signing stuff post-Schnorr. It was mostly for my
own benefit but maybe it's helpful for others too, so...

They're just notes, so may assume a fair bit of background to be able to
understand the meaning of the bullet points. In particular, note that I'm
using "schnorr" just to describe the signature algorithm, and the terms
"key aggregation" to describe turning an n-of-n key multisig setup into
a single key setup, and "signature aggregation" to describe combining
signatures from many inputs/transactions together: those are often all
just called "schnorr signatures" in various places.


Anyway! I think it's fair to split the ideas around up as follows:

1) Schnorr CHECKSIG

  Benefits:
- opportunity to change signature encoding from DER to save a few
  bytes per signature, and have fixed size signatures making tx size
  calculations easier

- enables n-of-n multisig key aggregation (a single pubkey and
  signature gives n-of-n security; setup non-interactively via muSig,
  or semi-interactively via proof of possession of private key;
  interactive signature protocol)

- enables m-of-n multisig key aggregation with interactive setup and
  interactive signature protocol, and possibly substantial storage
  requirements for participating signers

- enables scriptless scripts and discreet log contracts via
  key aggregation and interactive

- enables payment decorrelation for lightning

- enables batch validation of signatures, which substantially reduces
  computational cost of signature verification, provided a single
  "all sigs valid" or "some sig(s) invalid" output (rather than
  "sig number 5 is invalid") is sufficient

- better than ecdsa due to reducing signature malleability
  (and possibly due to having a security proof that has had more
  review?)

   Approaches:
 - bump segwit version to replace P2WPKH
 - replace an existing OP_NOP with OP_CHECKSCHNORRVERIFY
 - hardfork to allowing existing addresses to be solved via Schnorr sig
   as alternative to ECDSA

2) Merkelized Abstract Syntax Trees

   Two main benefits for enabling MAST:
- logarithmic scaling for scripts with many alternative paths
- only reveals (approximate) number of alternative execution branches,
  not what they may have been

   Approaches:
- replace an existing OP_NOP with OP_MERKLE_TREE_VERIFY, and treat an
  item remaining on the alt stack at the end of script exeution as a
  script and do tail-recursion into it (BIP 116, 117)
- bump the segwit version and introduce a "pay-to-merkelized-script"
  address form (BIP 114)

3) Taproot

   Requirements:
- only feasible if Schnorr is available (required in order to make the
  pubkey spend actually be a multisig spend)
- andytoshi has written up a security proof at
  https://github.com/apoelstra/taproot

   Benefits:
- combines pay-to-pubkey and pay-to-script in a single address,
  improving privacy
- allows choice of whether to use pubkey or script at spend time,
  allowing for more efficient spends (via pubkey) without reducing
  flexibility (via script)

   Approaches:
- bump segwit version and introduce a "pay-to-taproot" address form

4) Graftroot

   Requirements:
- only really feasible if Schnorr is implemented first, so that
  multiple signers can be required via a single pubkey/signature
- people seem to want a security proof for this; not sure if that's
  hard or straightforward

   Benefits:
- allows delegation of authorisation to spend an output already
  on the blockchain
- constant scaling for scripts with many alternative paths
  (better than MAST's logarithmic scaling)
- only reveals the possibility of alternative execution branches, 
  not what they may have been or if any actually existed

   Drawbacks:
- requires signing keys to be online when constructing scripts (cannot
  do complicated pay to cold wallet without warming it up)
- requires storing signatures for scripts (if you were able to
  reconstruct the sigs, you could just sign the tx directly and wouldn't
  use a script)
- cannot prove that alternative methods of spending are not
  possible to anyone who doesn't exclusively hold (part of) the
  output address private key
- adds an extra signature check on script spends

   Approaches:
- bump segwit version and introduce a "pay-to-graftroot" address form

5) Interactive Signature Aggregation

   Requirements:
- needs Schnorr

   Description:
- allows signers to interactively collaborate when constructing a
  transaction to produce a single signature that covers multiple
  inputs and/or OP_CHECKSIG invocations that are resolved by Schnorr
  signatures

   Benefits:
- reduces computational 

Re: [bitcoin-dev] Making OP_TRUE standard?

[Luke Dashjr via bitcoin-dev]

You'd send 0 satoshis to OP_TRUE, creating a UTXO. Then you spend that 0-value 
UTXO in another transaction with a normal fee. The idea is that to get the 
latter fee, the miner needs to confirm the original tranaction with the 
0-value OP_TRUE.

(Aside, in case it wasn't clear on my previous email, the template-script idea 
would not make it *mandatory* to spend in the same block, but that the UTXO 
would merely cease to be valid *after* that block. So the 0-value output does 
not take up a UTXO db entry when left unused.)

On Thursday 10 May 2018 09:33:29 Jorge Timón via bitcoin-dev wrote:
> I fail to see what's the practical difference between sending to op_true
> and giving the coins are fees directly. Perhaps it is ao obvious to you
> that you forget to mention it?
> If you did I honestlt missed it.
>
> On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
>
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> > Hi all,
> >
> > The largest problem we are having today with the lightning
> > protocol is trying to predict future fees.  Eltoo solves this elegantly,
> > but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> > commitment transactions so that we use minimal fees and then use CPFP
> > (which can't be done at the moment due to CSV delays on outputs).
> >
> > Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> > non-standard.  Are there any reasons not to suggest such a policy
> > change?
> >
> > Thanks!
> > Rusty.
> > ___
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

Re: [bitcoin-dev] Making OP_TRUE standard?

[Jorge Timón via bitcoin-dev]

But in prnciple I don't oppose to making it stardard, just want to
understand what's the point.

On Thu, 10 May 2018, 02:16 Jorge Timón,  wrote:

> I fail to see what's the practical difference between sending to op_true
> and giving the coins are fees directly. Perhaps it is ao obvious to you
> that you forget to mention it?
> If you did I honestlt missed it.
>
> On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hi all,
>>
>> The largest problem we are having today with the lightning
>> protocol is trying to predict future fees.  Eltoo solves this elegantly,
>> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
>> commitment transactions so that we use minimal fees and then use CPFP
>> (which can't be done at the moment due to CSV delays on outputs).
>>
>> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
>> non-standard.  Are there any reasons not to suggest such a policy
>> change?
>>
>> Thanks!
>> Rusty.
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Making OP_TRUE standard?

[Jorge Timón via bitcoin-dev]

I fail to see what's the practical difference between sending to op_true
and giving the coins are fees directly. Perhaps it is ao obvious to you
that you forget to mention it?
If you did I honestlt missed it.

On Wed, 9 May 2018, 01:58 Rusty Russell via bitcoin-dev, <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hi all,
>
> The largest problem we are having today with the lightning
> protocol is trying to predict future fees.  Eltoo solves this elegantly,
> but meanwhile we would like to include a 546 satoshi OP_TRUE output in
> commitment transactions so that we use minimal fees and then use CPFP
> (which can't be done at the moment due to CSV delays on outputs).
>
> Unfortunately, we'd have to P2SH it at the moment as a raw 'OP_TRUE' is
> non-standard.  Are there any reasons not to suggest such a policy
> change?
>
> Thanks!
> Rusty.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Why not archive the backend of Bitcoin blockchain?

[アルム カールヨハン via bitcoin-dev]

He can use pruning to only store the last X MB of the blockchain. It
will store the UTXO set though, which is a couple of GBs. In total, a
pruned node with pruning set to 1000 MB ends up using 4.5 GB
currently, but it varies slightly due to the # of UTXOs in existence.

On Thu, May 10, 2018 at 9:56 AM, Segue via bitcoin-dev
 wrote:
> On 3/17/18, someone posted on the Lightning-dev list, "Can I try Lightning
> without running a fully-fledged bitcoin block chain? (Yubin Ruan)."  The
> inquirer was asking because he didn't have much space to store the entire
> blockchain on his laptop.
>
> I replied:
>
> "Developers,
>
> On THIS note and slightly off-topic but relevant, why can't chunks of
> blockchain peel off the backend periodically and be archived, say on minimum
> of 150 computers across 7 continents?
>
> It seems crazy to continue adding on to an increasingly long chain to
> infinity if the old chapters (i.e. more than, say, 2 years old) could be
> stored in an evenly distributed manner across the planet. The same 150
> computers would not need to store every chapter either, just the index would
> need to be widely distributed in order to reconnect with a chapter if
> needed. Then maybe it is no longer a limitation in the future for people
> like Yubin. "
>
> It was suggested by a couple of lightning developers that I post this idea
> on the bitcoin-dev list.  So, here I post :).
>
> Segue
>
>
>
>
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev