Re: [bitcoin-dev] Making OP_TRUE standard?
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
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
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 > o
Re: [bitcoin-dev] MAST/Schnorr related soft-forks
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, you
Re: [bitcoin-dev] BIP sighash_noinput
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
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
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
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
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?
> 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?
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?
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
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 cost
Re: [bitcoin-dev] Making OP_TRUE standard?
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?
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?
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