Re: [bitcoin-dev] Sidechain headers on mainchain (unification of drivechains and spv proofs)

[Chris Stewart via bitcoin-dev]

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 

Re: [bitcoin-dev] [BIP Proposal] Token Protocol Specification

[Alex Kravets via bitcoin-dev]

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 

[bitcoin-dev] BIP114 Merklized Script update and 5 BIPs for new script functions

[Johnson Lau via bitcoin-dev]

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

[Johnson Lau via bitcoin-dev]

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