Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)
Hi ZmnSCPxj, However, a lockbox on one chain is a WT on the other > chain. We can create a free lockbox on Ess, then use that lockbox as > a WT on Tee, inflating TeeCoin. I'm not sure if I follow what you are saying here. What do you mean by 'free lockbox'? I was assuming that I created an arbitrary blockchain, say ChrisChain, that is NOT pegged to the bitcoin blockchain? I.e. the tokens on ChrisChain are worthless. Then I create a lockbox on ChrisChain with my worthless tokens and attempt to transfer them into TeeCoin's chain? However this doesn't make sense with However, this parameter is used to determine if it is a WT. Sidechain > consensus should require that freely-created lockboxes set this > parameter to 0, so that a side block that creates free lockboxes where > this parameter is non-zero is an invalid side block. Then a sidechain > will only treat a lockbox on another chain as a WT if the wtFlag > parameter is nonzero. This way, freely-created lockboxes are not > valid WT. Valid WT must lock actual, already unlocked coins, not > create new locked coins. > because I could arbitrarily set this parameter to 0. It seems that a sidechain upon inception should pay all of it's tokens to a single UTXO and prevent minting of coins after that. I'm fairly certain this is what elements does in it's genesis block. The is unrelated to the problem above, but it will be a problem in sidchain-headers-on-mainchain if we have a limited amount of mining slots in the coinbase_tx output vector. Let us assume we have a fixed set of sidechain slots in the coinbase output vector, in this case 10. However there are 15 competing sidechains for these 10 slots. It may be possible for sidechains (say 15 sidechains) to compete indefinitely for these 10 slots -- causing indefinite forks. Let us say sidechain 10 and sidechain 11 alternate block hashes in coinbase_tx.vout[10] output. This means that a WT^ will never be considered valid because it will appear to mainchain miners that there are competing forks of the SAME sidechain, when in reality it is two unique sidechains competing to mine the the limited coinbase output vector space. -Chris On Fri, Sep 8, 2017 at 9:56 AM, ZmnSCPxj wrote: > Good morning, > > Chris mentioned the use of OP_WITHDRAWPROOFVERIFY. I've come to realize > that this is actually superior to use OP_WITHDRAWPROOFVERIFY with a > sidechain-headers-on-mainchain approach. > > Briefly, a payment to OP_WITHDRAWPROOFVERIFY is an instruction to transfer > value from the mainchain to a sidechain. Thus, a payment to > OP_WITHDRAWPROOFVERIFY includes the sidechain to pay to, and a commitment > to a sidechain address (or whatever is the equivalent to a sidechain > address). > > Various OP_WITHDRAWPROOFVERIFY explanations exist. Most of them include > OP_REORGPROOFVERIFY. With sidechain-headers-on-mainchain, however, there > is > no need for reorg proofs. This is because, the mainchain can see, in real > time, which branch of the sidechain is getting extended. Thus if someone > attempts to defraud a sidechain by forking the sidechain to an invalid > state, sidechainers can immediately detect this on the mainchain and > immediately act to prevent the invalid fork from being advanced. After > all, a reorg proof is really just an SPV proof that is longer than some > previous SPV proof, that shows that the previous SPV proof is incorrect, > by showing that the block at the specified height of the WT is not present > on a longer SPV proof. > > Since sidechain-headers-on-mainchain implies merge mining of sidechains, > with no option to have independent proof-of-work of sidechains, the > sidechain's entire history is recorded on the mainchain, visible to all > mainchain nodes. > > -- > > An advantage of sidechain-headers-on-mainchain is a side-to-side peg > without > passing through the mainchain. > That is, a 2-way peg between any two chains, whether side or main. > > Sidechains supporting side-to-side transfer would require supporting > OP_WITHDRAWPROOFVERIFY, but not any of the other parts of sidechains. > > We must consider a WT format (withdrawal transaction) that is compatible > with an OP_WITHDRAWPROOFVERIFY Bitcoin transaction. > > ***That is, a lockbox UTXO on one chain is a WT on another chain.*** > > Sidechains need not follow the mainchain format for its normal > transactions, only for WT transactions that move coins across chains. > > For this, mainchain should also have its own "sidechain ID". Perhaps a > sidechain ID of 0 would be appropriate for mainchain, as its status as > mainchain. > > Suppose we have two sidechains, Ess and Tee, both of which support > side-to-side pegs. > > An Ess fullnode is a Bitcoin fullnode, but an Ess fullnode is not > necessarily a Tee fullnode, and vice versa. > > A lockbox redemption in sidechain-headers-on-mainchain is simply a spend of > a lockbox, pointing to the sidechain header containing WT, the merkle tree > path to the WT transaction from the h* c
Re: [bitcoin-dev] [BIP Proposal] Token Protocol Specification
Hi Luca, Bravissimo! Please allow me to encourage your to follow the BIP workflow as specified here https://github.com/bitcoin/bips/blob/master/bip-0002.mediawiki#BIP_workflow BIP Editor freely allocates BIP numberss, however that does not constitute approval but allows for much easier discussion of and communication about the proposal. Good luck ! On Wed, Sep 6, 2017 at 9:08 AM Luca Venturini via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Hi everyone, > > I would like to propose a standard protocol to manage tokens on top of > the Bitcoin blockchain. > > The full text is enclosed and can be found here: > > https://github.com/token21/token-protocol-specification > > Any feedback will be appreciated. > > Luca Venturini > > --- > > Abstract > > This document describes a protocol to manage digital assets (tokens) on > top of the bitcoin blockchain. The protocol enables a semantic layer > that permits reading the bitcoin transactions as operations related to > tokens. > > The protocol allows a new level of plausible deniability, while > permitting statefull public auditability on each issued token. It allows > both the user and the issuer to deny that an existing bitcoin > transaction between the two is actually a token transaction, or a new > token issuance. While both the token sender and the token issuer cannot > deny to have sent bitcoins, nobody can prove the transaction was related > to a digital asset. On top of that, to guarantee plausible deniability, > tokens can be issued, sent, and received using any existing bitcoin > client software. > > There is no need to have a wallet exclusively dedicated to manage the > tokens. With a few simple precautions by the user, tokens can be managed > using any existing Bitcoin wallet, while it is used for normal bitcoin > transactions as well. > > Since it is possible to infinitely split a token in parts, there is no > definition of the number of decimals of token generated and transferred. > The number of tokens is always an integer. > > Every operation of the protocol is performed with Bitcoin transactions, > without the use of OP_RETURN and without any form of pollution of the > blockchain, or of the UTXO set. > > The protocol permits atomic buy and sell transactions between tokens and > Bitcoin, and between different types of tokens. The only operations that > require a coin selection enabled wallet are the split and join special > operations and the token offering issuance operations. Those are used to > modify the token unit of measure and to receive bitcoins from third > parties during a token offering issuance. > > Copyright > = > This document is licensed under the 2-clause BSD license. > > Motivation > == > The current protocols that permit to issue tokens based on the bitcoin > blockchain (i.e. Counterparty, Omni, Colored Coins, Coinprism, Colu) are > flawed. > > The existing solutions usually need dedicated wallets and/or > verification nodes. Usually, a "pivot" currency is involved and atomic > transactions are not permitted unless they use the pivot currency. Those > protocols pollute the blockchain (30% or more) and in some cases they do > not accept P2SH scripts. Since the use of a dedicated wallet is > required, the users cannot plausibly deny they have got tokens. > Plausible deniability on the issuer side is not available either. None > of these protocols permits infinite division of the tokens, so usually > the number of decimals has to be specified at issuance time. The > automatic token offering issuance is not enabled as well. > > Rationale > = > Let's take an example from the real world, a yacht. We write on the > yacht's license that the owner is any person that can show a one dollar > bill having the serial number F82119977F. Thus the one dollar bill can > be exchanged between owners with extreme simplicity and full plausible > deniability. The US government will guarantee that there is no other > person having the same dollar bill. > > The protocol permits managing a token in the same way. The underlying > Bitcoin protocol will guarantee against double spending. > > Features: > > - Easy of use. Tokens can be managed using any wallet. Even if the > wallet has no coin selection feature. > - Plausible Deniability by the issuer. The issuer can generate a new > type of token and nobody analyzing the blockchain will understand that > the transaction is issuing a token. Even if a token is known, the issuer > can issue other tokens. Since a single output contains a large number of > different token types, the issuer is actually generating different types > of tokens every time she sends a new Bitcoin transaction to the network. > - Plausible Deniability by the user (no use of tokens at all, or use > of a different token type). A transaction that sends tokens from Alice > to Bob is a normal transaction. Nobody can understand that this > transaction is moving tokens unless they explic
[bitcoin-dev] BIP114 Merklized Script update and 5 BIPs for new script functions
I have rewritten and simplified BIP114, and renamed it to “Merklized Script”, as a more accurate description after consulting the original proposers of MAST. It could be considered as a special case of MAST, but has basically the same functions and scaling properties of MAST. Compared with Friedenbach’s latest tail-call execution semantics proposal, I think the most notable difference is BIP114 focuses on maintaining the static analysability, which was a reason of OP_EVAL (BIP12) being rejected. Currently we could count the number of sigOp without executing the script, and this remains true with BIP114. Since sigOp is a block-level limit, any OP_EVAL-like operation means block validity will depend on the precise outcome of script execution (instead of just pass or fail), which is a layer violation. Link to the revised BIP114: https://github.com/jl2012/bips/blob/vault/bip-0114.mediawiki On top of BIP114, new script functions are defined with 5 BIPs: VVV: Pay-to-witness-public-key: https://github.com/jl2012/bips/blob/vault/bip-0VVV.mediawiki WWW: String and Bitwise Operations in Merklized Script Version 0: https://github.com/jl2012/bips/blob/vault/bip-0WWW.mediawiki XXX: Numeric Operations in Merklized Script Version 0: https://github.com/jl2012/bips/blob/vault/bip-0XXX.mediawiki YYY: ECDSA signature operations in Merklized Script Version 0: https://github.com/jl2012/bips/blob/vault/bip-0YYY.mediawiki ZZZ: OP_PUSHTXDATA: https://github.com/jl2012/bips/blob/vault/bip-0ZZZ.mediawiki As a summary, these BIPs have the following major features: 1. Merklized Script: a special case of MAST, allows users to hide unexecuted branches in their scripts (BIP114) 2. Delegation: key holder(s) may delegate the right of spending to other keys (scripts), with or without additional conditions such as locktime. (BIP114, VVV) 3. Enabling all OP codes disabled by Satoshi (based on Elements project with modification. BIPWWW and XXX) 4. New SIGHASH definition with very high flexibility (BIPYYY) 5. Covenant (BIPZZZ) 6. OP_CHECKSIGFROMSTACK, modified from Elements project (BIPYYY) 7. Replace ~72 byte DER sig with fixed size 64 byte compact sig. (BIPYYY) All of these features are modular and no need to be deployed at once. The very basic BIP114 (merklized script only, no delegation) could be done quite easily. BIP114 has its own versioning system which makes introducing new functions very easy. Things I’d like to have: 1. BIP114 now uses SHA256, but I’m open to other hash design 2. Using Schnorr or similar signature scheme, instead of ECDSA, in BIPYYY. Reference implementation: https://github.com/jl2012/bitcoin/commits/vault ___ 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
Some comments with the tail-call execution semantics BIP: Tail-call execution semantics require “unclean stake”, i.e. final stake with more than one item. However, “unclean stake” is invalid (not just non-standard) in BIP141, so you could only use it with legacy P2SH (which is totally pointless….). A different design like OP_EVAL might be needed, or you need a new witness script version. I think you have also missed the sigOp counting of the executed script. As you can’t count it without executing the script, the current static analysability is lost. This was one of the reasons for OP_EVAL being rejected. Since sigOp is a per-block limit, any OP_EVAL-like operation means block validity will depend on the precise outcome of script execution (instead of just pass or fail), which is a layer violation. (An alternative is to make sigOp a per-input limit instead of per-block limit, just like the 201 nOp limit. But this is a very different security model) Witness script versioning is by design fully compatible with P2SH and BIP173, so there will be no hurdle for existing wallets to pay to BIP114. Actually it should be completely transparent to them. 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. > On 7 Sep 2017, at 8:38 AM, Mark Friedenbach via bitcoin-dev > wrote: > > I would like to propose two new script features to be added to the > bitcoin protocol by means of soft-fork activation. These features are > a new opcode, MERKLE-BRANCH-VERIFY (MBV) and tail-call execution > semantics. > > In brief summary, MERKLE-BRANCH-VERIFY allows script authors to force > redemption to use values selected from a pre-determined set committed > to in the scriptPubKey, but without requiring revelation of unused > elements in the set for both enhanced privacy and smaller script > sizes. Tail-call execution semantics allows a single level of > recursion into a subscript, providing properties similar to P2SH while > at the same time more flexible. > > These two features together are enough to enable a range of > applications such as tree signatures (minus Schnorr aggregation) as > described by Pieter Wuille [1], and a generalized MAST useful for > constructing private smart contracts. It also brings privacy and > fungibility improvements to users of counter-signing wallet/vault > services as unique redemption policies need only be revealed if/when > exceptional circumstances demand it, leaving most transactions looking > the same as any other MAST-enabled multi-sig script. > > I believe that the implementation of these features is simple enough, > and the use cases compelling enough that we could BIP 8/9 rollout of > these features in relatively short order, perhaps before the end of > the year. > > I have written three BIPs to describe these features, and their > associated implementation, for which I now invite public review and > discussion: > > Fast Merkle Trees > BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a > Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree > > MERKLEBRANCHVERIFY > BIP: https://gist.github.com/maaku/bcf63a208880bbf8135e453994c0e431 > Code: https://github.com/maaku/bitcoin/tree/merkle-branch-verify > > Tail-call execution semantics > BIP: https://gist.github.com/maaku/f7b2e710c53f601279549aa74eeb5368 > Code: https://github.com/maaku/bitcoin/tree/tail-call-semantics > > Note: I have circulated this idea privately among a few people, and I > will note that there is one piece of feedback which I agree with but > is not incorporated yet: there should be a multi-element MBV opcode > that allows verifying multiple items are extracted from a single > tree. It is not obvious how MBV could be modified to support this > without sacrificing important properties, or whether should be a > separate multi-MBV opcode instead. > > Kind regards, > Mark Friedenbach > ___ > 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