Re: [bitcoin-dev] Fast Merkle Trees

2017-09-06 Thread Peter Todd via bitcoin-dev 
On Wed, Sep 06, 2017 at 09:59:54PM -0400, Russell O'Connor via bitcoin-dev 
wrote:
> The fast hash for internal nodes needs to use an IV that is not the
> standard SHA-256 IV. Instead needs to use some other fixed value, which
> should itself be the SHA-256 hash of some fixed string (e.g. the string
> "BIP ???" or "Fash SHA-256").

Note that in general, designs should *not* create new hash functions by using
custom IVs, but rather use bog-standard SHA256, and make a fixed first block.
That allows unoptimised implementations to just hash a block with the second
initialization value, and optimized implementations to start with the fixed
midstate.

-- 
https://petertodd.org 'peter'[:-1]@petertodd.org


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

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

2017-09-06 Thread CryptAxe via bitcoin-dev 
After reading
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-January/012194.html
I see that Adam is correct. Unfortunately this SF would make Felix's
confidential transactions
more complicated. The blinding and unblinding transactions would have to
be created with
minimal output values, and this will need to be considered when checking
that the fee is equal
to the total amount of input. (it would now be SUM(inputs) -
SUM(minimalOutputs))

Blinding transaction:
  Ins:
All non-confidential inputs are valid
  Outs:
  - 0..N: (new confidential outputs)
amount: 0
scriptPubkey: OP_2 <0x{32-byte-hash-value}>
witnessOut: <0x{petersen-commitment}> <0x{range-proof}>
  - last:
amount: 0
scriptPubkey: OP_RETURN OP_2 {blinding-fee-amount}
  Fee: Sum of the all inputs value


However, looking at the format of the blinding transaction, and how the
GCTXO is added to the UTXO set
by miners, it seems that a change to the blinding scriptPubKey could
allow for the use of 0 value
outputs. Even with the SF proposed by this email thread.

OP_RETURN could be added to the scriptPubKey during blinding. The amount
and scriptPubKey destination of
unblinded funds is part of the witness and the outputs of an unblinded
transaction are unspendable, so
why not also make them unspendable in the blind transaction? As far as I
can tell those outputs don't need to
be spendable, they are really just encoding data. It doesn't seem like
anything besides the confidential base
transaction and the fee output from the blind transaction need to be in
the UTXO set.

Is it still possible to add this data to the witness if the scriptPubKey
is unspendable? :

witnessOut: <0x{petersen-commitment}> <0x{range-proof}>

I think I'm missing something obvious, someone point out why this is
stupid please :)

On 09/06/2017 06:29 PM, Adam Back wrote:
> The pattern used by Felix Weiss' BIP for Confidential Transactions
> depends on or is tidier with 0-value outputs.
>
> Adam
>
>
> On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
>  wrote:
>> As long as an unspendable outputs (OP_RETURN outputs for example) with
>> amount=0 are still allowed I don't see it being an issue for anything.
>>
>> On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev"
>>  wrote:
>>> This is not a priority, not very important either.
>>> Right now it is possible to create 0-value outputs that are spendable
>>> and thus stay in the utxo (potentially forever). Requiring at least 1
>>> satoshi per output doesn't really do much against a spam attack to the
>>> utxo, but I think it would be slightly better than the current
>>> situation.
>>>
>>> Is there any reason or use case to keep allowing spendable outputs
>>> with null amounts in them?
>>>
>>> If not, I'm happy to create a BIP with its code, this should be simple.
>>> ___
>>> 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] Fast Merkle Trees

2017-09-06 Thread Mark Friedenbach via bitcoin-dev 
This design purposefully does not distinguish leaf nodes from internal nodes. 
That way it chained invocations can be used to validate paths longer than 32 
branches. Do you see a vulnerability due to this lack of distinction?

> On Sep 6, 2017, at 6:59 PM, Russell O'Connor  wrote:
> 
> The fast hash for internal nodes needs to use an IV that is not the standard 
> SHA-256 IV. Instead needs to use some other fixed value, which should itself 
> be the SHA-256 hash of some fixed string (e.g. the string "BIP ???" or "Fash 
> SHA-256").
> 
> As it stands, I believe someone can claim a leaf node as an internal node by 
> creating a proof that provides a phony right-hand branch claiming to have 
> hash 0x8..100 (which is really the padding value for the second half 
> of a double SHA-256 hash).
> 
> (I was schooled by Peter Todd by a similar issue in the past.)
> 
>> On Wed, Sep 6, 2017 at 8:38 PM, Mark Friedenbach via bitcoin-dev 
>>  wrote:
>> Fast Merkle Trees
>> BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
>> Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

2017-09-06 Thread Kabuto Samourai via bitcoin-dev 
Thanks for the proposal. Aside from potential privacy implications of
revealing the derivation path for non BIP-44, 45, 49 HD nodes, this scheme
is superior to the alternate {x,y,z}pub idea. Since coin_type is part of
the path, the 'xpub' prefix may be shared across all coins if they so
choose. This format provides lock-in for BIP-49 going forward and opens the
door for a parallel native-SegWit BIP.

The birthday field is interesting. Could you provide some motivation for
its inclusion?

Could you also add some test vectors?

There are a few minor grammar / spelling errors, but we can nitpick those
after this goes to the pull request stage on bitcoin/bips.

On Wed, Sep 6, 2017 at 5:29 PM, Pavol Rusnak via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
>
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
>
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
>
> Feel free to comment.
>
> --
> Best Regards / S pozdravom,
>
> Pavol "stick" Rusnak
> CTO, SatoshiLabs
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-Kabuto

PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A  B065 320F B934 A79B 6A99
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Proposal: Extended serialization format for BIP-32 wallets

2017-09-06 Thread Thomas Voegtlin via bitcoin-dev 


On 07.09.2017 00:29, Pavol Rusnak via bitcoin-dev wrote:
> The discussion about changing bip32 version bytes for SegWit got me
> thinking and I ended up with what I think is the best proposal:
> 
> https://github.com/satoshilabs/slips/blob/master/slip-0032.md
> 
> (It is hosted in SL repo for now, but if there is will, I would love to
> have this added to BIP repo as an extension to BIP32)
> 
> Feel free to comment.
> 


Your proposal forces wallets to use the derivation path in order to
determine the type of output script. it will work only in the context of
BIP43.

Therefore, it should not be proposed as a BIP32 improvement, but as a
improvement of BIP43.

A solution is still needed to wallets who do not wish to use BIP43
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Fast Merkle Trees

2017-09-06 Thread Russell O'Connor via bitcoin-dev 
The fast hash for internal nodes needs to use an IV that is not the
standard SHA-256 IV. Instead needs to use some other fixed value, which
should itself be the SHA-256 hash of some fixed string (e.g. the string
"BIP ???" or "Fash SHA-256").

As it stands, I believe someone can claim a leaf node as an internal node
by creating a proof that provides a phony right-hand branch claiming to
have hash 0x8..100 (which is really the padding value for the
second half of a double SHA-256 hash).

(I was schooled by Peter Todd by a similar issue in the past.)

On Wed, Sep 6, 2017 at 8:38 PM, Mark Friedenbach via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Fast Merkle Trees
> BIP: https://gist.github.com/maaku/41b0054de0731321d23e9da90ba4ee0a
> Code: https://github.com/maaku/bitcoin/tree/fast-merkle-tree
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

2017-09-06 Thread Adam Back via bitcoin-dev 
The pattern used by Felix Weiss' BIP for Confidential Transactions
depends on or is tidier with 0-value outputs.

Adam


On 7 September 2017 at 00:54, CryptAxe via bitcoin-dev
 wrote:
> As long as an unspendable outputs (OP_RETURN outputs for example) with
> amount=0 are still allowed I don't see it being an issue for anything.
>
> On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev"
>  wrote:
>>
>> This is not a priority, not very important either.
>> Right now it is possible to create 0-value outputs that are spendable
>> and thus stay in the utxo (potentially forever). Requiring at least 1
>> satoshi per output doesn't really do much against a spam attack to the
>> utxo, but I think it would be slightly better than the current
>> situation.
>>
>> Is there any reason or use case to keep allowing spendable outputs
>> with null amounts in them?
>>
>> If not, I'm happy to create a BIP with its code, this should be simple.
>> ___
>> 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] SF proposal: prohibit unspendable outputs with amount=0

2017-09-06 Thread CryptAxe via bitcoin-dev 
As long as an unspendable outputs (OP_RETURN outputs for example) with
amount=0 are still allowed I don't see it being an issue for anything.

On Sep 5, 2017 2:52 PM, "Jorge Timón via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> This is not a priority, not very important either.
> Right now it is possible to create 0-value outputs that are spendable
> and thus stay in the utxo (potentially forever). Requiring at least 1
> satoshi per output doesn't really do much against a spam attack to the
> utxo, but I think it would be slightly better than the current
> situation.
>
> Is there any reason or use case to keep allowing spendable outputs
> with null amounts in them?
>
> If not, I'm happy to create a BIP with its code, this should be simple.
> ___
> 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] Merkle branch verification & tail-call semantics for generalized MAST

2017-09-06 Thread Mark Friedenbach via bitcoin-dev 
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] Proposal: Extended serialization format for BIP-32 wallets

2017-09-06 Thread Pavol Rusnak via bitcoin-dev 
The discussion about changing bip32 version bytes for SegWit got me
thinking and I ended up with what I think is the best proposal:

https://github.com/satoshilabs/slips/blob/master/slip-0032.md

(It is hosted in SL repo for now, but if there is will, I would love to
have this added to BIP repo as an extension to BIP32)

Feel free to comment.

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] SF proposal: prohibit unspendable outputs with amount=0

2017-09-06 Thread Tier Nolan via bitcoin-dev 
On Tue, Sep 5, 2017 at 10:51 PM, Jorge Timón via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Is there any reason or use case to keep allowing spendable outputs
> with null amounts in them?
>

Someone could have created a timelocked transaction that depends on a zero
value output.

This could be protected by requiring a tx version number change.  Only zero
outputs in the new version would be affected.

I am not sure how strictly people are sticking to that rule though.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2017-09-06 Thread Luca Venturini via bitcoin-dev 

Hi Luke,

thanks for your feedback.

I can try to coordinate with the OpenAssets group, but the base 
requirements are completely different. For example, they are very far 
from any form of plausible deniability.


Please tell me which problems are not solved technically, so that I can 
try to fix the differences between the claims and the technical part, if 
any.


Luca

On 09/06/2017 08:58 PM, Luke Dashjr wrote:

I think you could check out and coordinate with the OpenAssets proposal.

Your current draft also claims to solve a lot of problems that it doesn't
actually solve technically...

Luke


On Wednesday 06 September 2017 11:44:47 Luca Venturini via bitcoin-dev 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
transacti

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

2017-09-06 Thread Luke Dashjr via bitcoin-dev 
I think you could check out and coordinate with the OpenAssets proposal.

Your current draft also claims to solve a lot of problems that it doesn't 
actually solve technically...

Luke


On Wednesday 06 September 2017 11:44:47 Luca Venturini via bitcoin-dev 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 explicitly know which
> transaction is the token issuance. In fact a single address contains a
> large number of token types, and the use of tokens itself can be denied.
>   - Accountability

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

2017-09-06 Thread Luca Venturini via bitcoin-dev 

Hi Dan,

thank you for your feedback. Let me clarify that the plausible 
deniability is a property of the protocol. If this will become a BIP, 
and will be approved, there will be wallets that will manage tokens. In 
the meantime, and in the future, it is important that a person with a 
legacy bitcoin wallet can hold, issue and transfer bitcoins without 
disclose that there are tokens involved. Tokens are contained in Bitcoin 
transactions without any modification.


Vanity addresses are on option. They are not mandatory. In situations 
where plausible deniability is a concern they will, probably, not be used.


Sending to someone 0.2312 bitcoin is really easy. You don't need any 
form of math and you are sending exactly 12 tokens from your wallet. 
Sometimes it is suspect, but sending 0.03423122 in order to send 23122 
tokens does not seem suspect to me. The large majority of the 
transactions have strange numbers like this one.


In the document, when I say "wallet" I mean every single bitcoin wallet 
that you can use today to hold bitcoins. The base of the plausible 
deniability is that there is no "special" wallet involved. Maybe there 
will be special wallets to manage tokens, but they are not mandatory. 
The consolidation is needed only when using wallets that do not allow 
coin selection.


The state of the tokens is fully contained in the bitcoin blockchain. 
There is no need for verification nodes, nor for any other software. 
Maybe you already issued some tokens using this protocol and I cannot 
know it. Unless you disclose it.


There is no "special" need to create small outputs. In order to send a 
transaction containing tokens, you need to send a bitcoin transaction. 
The bitcoin value will be transfered along with the token value. If you 
issue tokens with a token offering transactions (aka ICO), the value of 
the bitcoin transferred to you is exactly the price of the tokens, so 
there is no "extra" bitcoin value involved.


I'm sorry if the example of the corporation is not clear. The idea was 
only that Alice receives from the shareholders the bitcoin value, in 
order to use that same value to give back the tokens. There is no 
interest. As I wrote, people got equity for "time, money, furniture, 
knowledge". I could simply write that Alice sends small outputs without 
receiving the underlying bitcoin value beforehand.


I agree that memorable names are great to social scalability. This is 
why you can use a vanity address or only the first part of the vanity 
address to identify a token type.


Cheers,

Luca

On 09/06/2017 07:24 PM, Dan Anderson wrote:

Hi Luca,

Here are some comments...

1. This is clever, but it has a lot of "gotchas" that I think will work against 
its ability to scale socially. Especially, when you suggest that following the rules by 
memory/manually gains users the most advantage in terms of deniability.

2. The plausible deniability of this protocol is suspect as it would seem fairy apparent 
to a third party that it was being used. Vanity addresses, satoshis adding to tidy 
amounts, frequent "consolidation". Especially, when you make a mistake and 
perform actions to try again.

3. In your docs, when you say "wallet" do you mean a single Bitcoin address or 
do you mean an HD wallet? I become confused while reading. Address vs same wallet vs 
other wallet.

4. It's not clear to me how this protocol does not need verification nodes or 
some kind of node software to compute state.

5. I don't think it's a given that this design will cause less UTXOs. I could 
see people creating many small outputs as a result of trying to get the right 
amount of signal satoshis.

6. In your example of a corporation, it seems like people got equity for free. 
Why do they need to send 1 BTC at all, if they just get it back, plus interest?

7. I wouldn't underestimate the value of memorable names for social scalability.

I will keep thinking about it, as the ICO portion is something I have been 
looking for ideas on and I have similar reservations about existing token 
protocols, so I hope these comments help you.

-
Dan Anderson



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

Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts

2017-09-06 Thread Pavol Rusnak via bitcoin-dev 
On 05/09/17 19:03, Luke Dashjr via bitcoin-dev wrote:
> I think it makes more sense to use a child number field for this purpose.
> It seems desirable to use the same seed for all different script formats...

If I were designing the serialization format today, I would drop the
fingerprint and expand child number to full BIP32 path. Good thing is
that we already have depth, so we know how long the BIP32 path would be.

So I suggest the following:

4 byte: version bytes
1 byte: depth
depth * 4 bytes: bip32 path
32 bytes
33 bytes

-- 
Best Regards / S pozdravom,

Pavol "stick" Rusnak
CTO, SatoshiLabs
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

2017-09-06 Thread Luca Venturini via bitcoin-dev 

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 explicitly know which 
transaction is the token issuance. In fact a single address contains a 
large number of token types, and the use of tokens itself can be denied.
 - Accountability. Everybody can see the state of the distribution of a 
type of token.
 - Tunnel mode (confidentiality by issuer and user versus a third 
party). Alice can send tokens to Bob and ask him to give the tokens to 
Charlie, without telling to Bob what is the type of the token given. 
Alice can disclose this information in the future, if she wants.
 - It is possible to perform open or closed issuances. While an

Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts

2017-09-06 Thread Kabuto Samourai via bitcoin-dev 
> In addition, consensus might be more difficult to reach on that

Let's move forward with the simplest solution that solves the problem and
achieves consensus! Version bytes {x,y,z} fits the bill.

On Wed, Sep 6, 2017 at 4:26 AM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On 05.09.2017 21:00, Kabuto Samourai wrote:
> >
> > The Electrum approach is nice but may not go far enough, as xpub and zpub
> > both list "P2PKH or P2SH." Why not expand the number of version prefixes
> to
> > eliminate the ambiguity?
> >
>
> I agree that this would make sense if we had done it from the start.
> However, fixing that now might be difficult.
>
> My "xyz" proposal extends the current format in a way that is very easy
> to deploy, because existing software will require minimal changes.
> However, if we eliminate the p2sh ambiguity now, wallets will need to
> add extra safeguards, in order to prevent scenarios that are currently
> allowed, and they will need to handle legacy xpub/xprv differently than
> ypub and zpub. This would take much more time to deploy.
>
> In addition, consensus might be more difficult to reach on that; I guess
> not all developers will not agree that removing that ambiguity is
> useful. Since there is an infinity of possible P2SH scripts, it will
> never be possible to remove ambiguity from a master key associated to a
> P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
> strong.
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
-Kabuto

PGP Fingerprint: 1A83 4A96 EDE7 E286 2C5A  B065 320F B934 A79B 6A99
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP49 Derivation scheme changes

2017-09-06 Thread Dan Libby via bitcoin-dev 
On 08/30/2017 12:24 AM, shiva sitamraju via bitcoin-dev wrote:

> What would happen if you recover a wallet  using seed words ?
>   1. Since there is no difference in seed words between segwit/non
> segwit, the wallet would discover both m/44' and m/49' accounts
>   2. Note that we cannot ask the user to choose an account he wants to
> operate on (Segwit/Non segwit). This is like asking him the HD
> derivation path and a really bad UI
>   3. The wallet now has to constantly monitor both m/44' and m/49'
> accounts for transactions

small nit with 3.

It seems to me that the wallet would perform initial discovery on m/44
and m/49, and then would find transactions at one or the other, so it
can then record the type somewhere and from then on need only monitor
one branch.

Still, I agree it is ugly, makes initial discovery up to 2x slower, etc.

> *- XPUB Derivation*
> This is something not addressed in the BIP yet.
> 
> 1. Right now you can get an xpub balance/transaction history. With m/49'
> there is no way to know whether an xpub is from m/44' or m/49'
> 
> 2. This breaks lots of things. Wallets like electrum/armory/mycelium
> support
> importing  xpub as a watch only wallet. Also services like
> blockonomics/blockchain.info  use xpub for
> displaying balance/generating merchant addresses
> 
> Looking forward to hearing your thoughts

speaking as author of tools hd-wallet-addrs and hd-wallet-derive, I
agree this is problematic.

would be great if xpub/xprv could somehow encode their absolute path in
wallet for tools to read.  Users cannot be expected to know.


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

Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit scripts

2017-09-06 Thread Thomas Voegtlin via bitcoin-dev 


On 05.09.2017 21:00, Kabuto Samourai wrote:
> 
> The Electrum approach is nice but may not go far enough, as xpub and zpub
> both list "P2PKH or P2SH." Why not expand the number of version prefixes to
> eliminate the ambiguity?
> 

I agree that this would make sense if we had done it from the start.
However, fixing that now might be difficult.

My "xyz" proposal extends the current format in a way that is very easy
to deploy, because existing software will require minimal changes.
However, if we eliminate the p2sh ambiguity now, wallets will need to
add extra safeguards, in order to prevent scenarios that are currently
allowed, and they will need to handle legacy xpub/xprv differently than
ypub and zpub. This would take much more time to deploy.

In addition, consensus might be more difficult to reach on that; I guess
not all developers will not agree that removing that ambiguity is
useful. Since there is an infinity of possible P2SH scripts, it will
never be possible to remove ambiguity from a master key associated to a
P2SH script. Thus, the benefit of separating P2SH from P2PKH is not as
strong.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev