Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

really don't see any point of following BIP49, If
> possible
> > it would be great if you can propose an alternative to BIP49 that follows
> > similar structure to what is used in electrum.
> >
> > I have proposed following changes to BIP32 serialization format
> > https://github.com/bitcoin/bips/blob/master/bip-0032.
> mediawiki#serialization-format
> > to differentiate segwit xpub/xprv. Below the list of new version bytes,
> > resulting base58 prefix and network type:
> >
> > 0x042393df ,  sxpr ,   segwit mainnet private key
> > 0x04239377 , sxpb , segwit mainnet public key
> > 0x04222463 , stpb ,  segwit testnet public key
> > 0x042224cc ,  stpr ,  segwit testnet private key
> >
>
> I have proposed a similar idea, with letters z,y,z combined with pub/prv
> (see the electrum documentation page)
>
> The point is that we need 3 types of keys, not 2, because there are two
> types of segwit output scripts: native and nested in p2sh.
>
> We could use t,u,v for testnet.
>
>
> --
>
> Message: 4
> Date: Tue, 5 Sep 2017 13:03:39 -0400
> From: Luke Dashjr 
> To: bitcoin-dev@lists.linuxfoundation.org,  Thomas Voegtlin
> 
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
> scripts
> Message-ID: <201709051303.43410.l...@dashjr.org>
> Content-Type: Text/Plain;  charset="iso-8859-1"
>
> On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev
> wrote:
> > I have heard the argument that xpub/xprv serialization is a format for
> > keys, and that it should not be used to encode how these keys are used.
> > However, the very existence of version bytes, and the fact that they are
> > used to signal whether keys will be used on testnet or mainnet goes
> > against that argument.
> >
> > If we do not signal the script type in the version bytes, I believe
> > wallet developers are going to use dirtier tricks, such as the bip32
> > child number field in combination with bip43/bip44/bip49.
>
> 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...
>
> As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> really doesn't make sense to differentiate segwit specifically.
>
> Luke
>
>
> --
>
> Message: 5
> Date: Tue, 5 Sep 2017 12:06:32 -0500
> From: Chris Stewart 
> To: ZmnSCPxj , Bitcoin Protocol
> Discussion
> 
> Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification
> of drivechains and spv proofs)
> Message-ID:
>  mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Hi ZmnSCPxj,
>
> Basically, in case of a sidechain fork, the mainchain considers the longest
> > chain to be valid if it is longer by the SPV proof required length.  In
> the
> > above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> > longer than the other sidechain fork that ended at d.
> >
> > Mainchain nodes can validate this rule because the sidechain headers are
> > embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes
> can
> > validate this part of the sidechain rule of "longest work chain".
> >
>
> What happens in the case that the provided merkle tree hash has a invalid
> transaction in it? Wouldn't this mean that the mainchain nodes would think
> the longest work chain is the valid chain, and it would kill off any
> consensus valid chain that sidechain miners are trying to construct? It
> seems that a malicious miner could extend the chain to whatever the SPV
> proof block height is and make it impossible for the chain to reorg after
> that. I guess if that is a sufficiently long block waiting period it may
> not be a realistic concern, but something to think about any way.
>
> Just a side note -- I think it should be highly recommended that the
> coinbase maturity period on the sidechain to be longer than 288 (or
> whatever we decide on the parameter). This incentivizes the s:miners to
> work together to extend the chain by working with other s:miners (otherwise
> they won't be able to claim their bribes). If they do not work together
> they will not be able to spend their s:coinbase_tx outputs until they
> extend their own sidechain by 288 blocks meaning they need to tie up a
> large amount of capital to go rogue on their fork.
>
> Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op
> code
> <https://github.com/ElementsProject/elements/blob/
> ele

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

[Kabuto Samourai via bitcoin-dev]

We support a change to the version bits of the HD serialization that will
inform the receiving utility of the exact derivation method used for the
pubkeys. Third-parties handling xpubs must not require additional
information from the user about the derivation path or serialization format
of the addresses under that xpub. When you have to ask, "Is this a SegWit
xpub?" then you've already lost.

Avoiding a total UX nightmare is in everyone's interests.

I think Luke and Thomas may be talking past one another. When exporting a
root master HD seed, encoding the {x,y,z}{pub,prv} distinctions makes no
sense, as the root seed should derive all paths for all coins. Wallets may
need additional code to discover which paths have been used when importing
a root seed. But when exporting / importing an account-level seed for
watch-only and receive address generation, changing the serialization
version bytes is appropriate and (in our view) essential to avoid loss of
funds.

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?


On Tue, Sep 5, 2017 at 1:09 PM, Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
>
> On 05.09.2017 19:03, Luke Dashjr wrote:
>
> > It seems desirable to use the same seed for all different script
> formats...
>
> That does not seem desirable to everybody.
>
> If you want to guarantee that users will be able to recover all their
> funds from their mnemonic seed (and that is what they expect), then
> wallets must implement all script formats, even the ones that are
> deprecated. In addition, the list of script formats that must be
> supported is not defined in advance, but it keeps growing. This makes
> wallet implementation increasingly difficult. In the long run, seed
> portability is guaranteed to fail in such a system.
>
> > As you note, xpub\xprv are already being used for both P2PKH and P2SH. It
> > really doesn't make sense to differentiate segwit specifically.
>
> That's not a reason. The fact that xpub/xprv can be used for both P2PKH
> and P2SH has already resulted in users receiving coins on addresses they
> do not control.
> ___
> 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] Sidechain headers on mainchain (unification of drivechains and spv proofs)

[ZmnSCPxj via bitcoin-dev]

Good morning Chris,

>>Basically, in case of a sidechain fork, the mainchain considers the longest 
>>chain to be valid if it is longer by the SPV proof required length.  In the 
>>above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E) 
>>longer than the other sidechain fork that ended at d.
>>
>>Mainchain nodes can validate this rule because the sidechain headers are 
>>embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes can 
>>validate this part of the sidechain rule of "longest work chain".
>>
>What happens in the case that the provided merkle tree hash has a invalid 
>transaction in it? Wouldn't this mean that the mainchain nodes would think the 
>longest work chain is the valid chain, and it would kill off any consensus 
>valid chain that sidechain miners are trying to construct? It seems that a 
>malicious miner could extend the chain to whatever the SPV proof block height 
>is and make it impossible for the chain to reorg after that. I guess if that 
>is a sufficiently long block waiting period it may not be a realistic concern, 
>but something to think about any way.

This is exactly the problem, and one which exists in a different form in any 
sidechain proposal.  In drivechain, malicious mainchain miners may arbitrarily 
downvote any side-to-main peg even if the side-to-main peg is valid on the 
sidechain, with mainchain fullnodes unable to gainsay them.  In original 
sidechain's SPV proofs, malicious mainchain miners may provide an invalid SPV 
proof and then censor any reorg proof against that SPV proof.  In both of those 
cases, trust in the sidechain and the value of sidecoin necessarily takes a hit.

Of course, in both of those two cases, the hit is "temporary" and the sidechain 
could theoretically recover.  In sidechain-headers-on-mainchain, the hit would 
permanently kill the sidechain.

The fact that sidechains are merge mined and cannot be mined off-mainchain 
makes sidechains entirely dependent on mainchain miner's support.  I agree with 
Sztorc that sidechains must be merge mined entirely, otherwise the sidechain 
will effectively reduce mainchain security by pulling away potential miners 
from mainchain.

OP_BRIBEVERIFY, which is intended to allow sidechain miners/protectors to be a 
separate datacenter from miners, allows anyone with either enough hashpower or 
enough maincoin to disrupt a sidechain by spamming its slot with random hash 
values.  With enough disruption, the sidechain may become unusable in 
drivechains, but may indeed be killed that way in 
sidechain-headers-on-mainchain.

>
>Just a side note -- I think it should be highly recommended that the coinbase 
>maturity period on the sidechain to be longer than 288 (or whatever we decide 
>on the parameter). This incentivizes the s:miners to work together to extend 
>the chain by working with other s:miners (otherwise they won't be able to 
>claim their bribes). If they do not work together they will not be able to 
>spend their s:coinbase_tx outputs until they extend their own sidechain by 288 
>blocks meaning they need to tie up a large amount of capital to go rogue on 
>their fork.

Yes, this seems sensible.

>
>Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op code 
>used in the elements project. Since the cannonical merkle root hashes are 
>included in the mainchain, we can provide a merkle proof to the bitcoin 
>blockchain to initiate a withdrawl from the sidechain. I wrote up a blog post 
>on how OP_WPV works here. This allows us to prove that a transaction occurred 
>on the sidechain to lock up those funds.

Yes.

Even without sidechain headers on mainchain, one might consider plain blind 
merged mining to have put even the "previous block hash" in the sidechain block 
coinbase transaction.  Thus, one might consider that in blind merged mining, h' 
commitments are really merkle tree roots, and the previous block hash is 
encoded in a special sidechain transaction on one side of the merkle tree, 
while sidechain block transactions are encoded in the other side of the merkle 
tree root.  This allows OP_WITHDRAWPROOFVERIFY to be used on blind merged 
mining, but without sidechain headers on mainchain, a compact SPV proof somehow 
must still be provided, or we are forced to use drivechain miner voting.

Regards,
ZmnSCPxj___
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

[Andreas Schildbach via bitcoin-dev]

Generally I like the idea, but maybe we should come up with a
(Bech32-based?) new standard that also includes the key birthdate (aka
"wallet birthdate").

Also I heard Core will mix addresses of all types on the same HD chain.
What prefix would it pick? "*pub"?


On 09/05/2017 12:25 PM, Thomas Voegtlin via bitcoin-dev wrote:
> BIP32 extended public/private keys have version bytes that result in the
> user visible xpub/xprv prefix. The BIP's recommendation is to use
> different version bytes for other networks (such as tpub/tprv for testnet)
> 
> I would like to use additional version bytes to indicate the type of
> output script used with the public keys.
> 
> I believe the change should be user visible, because users are exposed
> to master public keys. I propose the following prefixes:
> 
> == === ===
> VersionPrefix  Description
> == === ===
> 0x0488ade4 xprvP2PKH or P2SH
> 0x0488b21e xpubP2PKH or P2SH
> 0x049d7878 yprv(P2WPKH or P2WSH) nested in P2SH
> 0x049d7cb2 ypub(P2WPKH or P2WSH) nested in P2SH
> 0x04b2430c zprvP2WPKH or P2WSH
> 0x04b24746 zpubP2WPKH or P2WSH
> == === ===
> (source: http://docs.electrum.org/en/latest/seedphrase.html)
> 
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.
> However, the very existence of version bytes, and the fact that they are
> used to signal whether keys will be used on testnet or mainnet goes
> against that argument.
> 
> If we do not signal the script type in the version bytes, I believe
> wallet developers are going to use dirtier tricks, such as the bip32
> child number field in combination with bip43/bip44/bip49.

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

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

[Jorge Timón via bitcoin-dev]

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

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

[Thomas Voegtlin via bitcoin-dev]

On 05.09.2017 19:03, Luke Dashjr wrote:

> It seems desirable to use the same seed for all different script formats...

That does not seem desirable to everybody.

If you want to guarantee that users will be able to recover all their
funds from their mnemonic seed (and that is what they expect), then
wallets must implement all script formats, even the ones that are
deprecated. In addition, the list of script formats that must be
supported is not defined in advance, but it keeps growing. This makes
wallet implementation increasingly difficult. In the long run, seed
portability is guaranteed to fail in such a system.

> As you note, xpub\xprv are already being used for both P2PKH and P2SH. It 
> really doesn't make sense to differentiate segwit specifically.

That's not a reason. The fact that xpub/xprv can be used for both P2PKH
and P2SH has already resulted in users receiving coins on addresses they
do not control.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

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

[Chris Stewart via bitcoin-dev]

Hi ZmnSCPxj,

Basically, in case of a sidechain fork, the mainchain considers the longest
> chain to be valid if it is longer by the SPV proof required length.  In the
> above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E)
> longer than the other sidechain fork that ended at d.
>
> Mainchain nodes can validate this rule because the sidechain headers are
> embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes can
> validate this part of the sidechain rule of "longest work chain".
>

What happens in the case that the provided merkle tree hash has a invalid
transaction in it? Wouldn't this mean that the mainchain nodes would think
the longest work chain is the valid chain, and it would kill off any
consensus valid chain that sidechain miners are trying to construct? It
seems that a malicious miner could extend the chain to whatever the SPV
proof block height is and make it impossible for the chain to reorg after
that. I guess if that is a sufficiently long block waiting period it may
not be a realistic concern, but something to think about any way.

Just a side note -- I think it should be highly recommended that the
coinbase maturity period on the sidechain to be longer than 288 (or
whatever we decide on the parameter). This incentivizes the s:miners to
work together to extend the chain by working with other s:miners (otherwise
they won't be able to claim their bribes). If they do not work together
they will not be able to spend their s:coinbase_tx outputs until they
extend their own sidechain by 288 blocks meaning they need to tie up a
large amount of capital to go rogue on their fork.

Another interesting thing might be to use the OP_WITHDRAWPROOFVERIFY op code

used in the elements project. Since the cannonical merkle root hashes are
included in the mainchain, we can provide a merkle proof to the bitcoin
blockchain to initiate a withdrawl from the sidechain. I wrote up a blog
post on how OP_WPV works here
.
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.

-Chris
​
___
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

[Luke Dashjr via bitcoin-dev]

On Tuesday 05 September 2017 06:25:16 Thomas Voegtlin via bitcoin-dev wrote:
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.
> However, the very existence of version bytes, and the fact that they are
> used to signal whether keys will be used on testnet or mainnet goes
> against that argument.
> 
> If we do not signal the script type in the version bytes, I believe
> wallet developers are going to use dirtier tricks, such as the bip32
> child number field in combination with bip43/bip44/bip49.

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...

As you note, xpub\xprv are already being used for both P2PKH and P2SH. It 
really doesn't make sense to differentiate segwit specifically.

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

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[Thomas Voegtlin via bitcoin-dev]

On 05.09.2017 09:10, shiva sitamraju via bitcoin-dev wrote:
> Hi,
> 
> Thanks Thomas. The procedure described in
> http://docs.electrum.org/en/latest/seedphrase.html is really what I was
> looking for ! I really don't see any point of following BIP49, If possible
> it would be great if you can propose an alternative to BIP49 that follows
> similar structure to what is used in electrum.
> 
> I have proposed following changes to BIP32 serialization format
> https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format
> to differentiate segwit xpub/xprv. Below the list of new version bytes,
> resulting base58 prefix and network type:
> 
> 0x042393df ,  sxpr ,   segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb ,  segwit testnet public key
> 0x042224cc ,  stpr ,  segwit testnet private key
> 

I have proposed a similar idea, with letters z,y,z combined with pub/prv
(see the electrum documentation page)

The point is that we need 3 types of keys, not 2, because there are two
types of segwit output scripts: native and nested in p2sh.

We could use t,u,v for testnet.
___
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

[Pavol Rusnak via bitcoin-dev]

On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> == === ===
> VersionPrefix  Description
> == === ===
> 0x0488ade4 xprvP2PKH or P2SH
> 0x0488b21e xpubP2PKH or P2SH
> 0x049d7878 yprv(P2WPKH or P2WSH) nested in P2SH
> 0x049d7cb2 ypub(P2WPKH or P2WSH) nested in P2SH
> 0x04b2430c zprvP2WPKH or P2WSH
> 0x04b24746 zpubP2WPKH or P2WSH
> == === ===
> (source: http://docs.electrum.org/en/latest/seedphrase.html)
> 
> I have heard the argument that xpub/xprv serialization is a format for
> keys, and that it should not be used to encode how these keys are used.

I used this argument for mnemonic/seed, not xpub/xprv. I am fine with
this proposal of yours, so don't worry.

-- 
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] BIP49 Derivation scheme changes

[Pavol Rusnak via bitcoin-dev]

On 05/09/17 09:10, shiva sitamraju via bitcoin-dev wrote:
> 0x042393df ,  sxpr ,   segwit mainnet private key
> 0x04239377 , sxpb , segwit mainnet public key
> 0x04222463 , stpb ,  segwit testnet public key
> 0x042224cc ,  stpr ,  segwit testnet private key 

I am fine with both your proposal and proposal from Thomas
({x,y,z}{pub,prv}).

Let's just decide ASAP which one we'll use.


-- 
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] Sidechain headers on mainchain (unification of drivechains and spv proofs)

[ZmnSCPxj via bitcoin-dev]

Good morning all,

I have started to consider a unification of drivechains, blind merged mining, 
and sidechain SPV proofs to form yet another solution for sidechains.

Briefly, below are the starting assumptions:

1.  SPV proofs are a short chain of sidechain block headers.  This is used to 
prove to the mainchain that some fund has been locked in the sidechain and the 
mainchain should unlock an equivalent fund to the redeemer.

2.  SPV proofs are large and even in compact form, are still large.  We can 
instead use miner voting to control whether some mainchain fund should be 
unlocked.  Presumably, the mainchain miners are monitoring that the sidechain 
is operating correctly and can know directly if a side-to-main peg is valid.

3.  To maintain mainchain's security, we should use merged mining for sidechain 
mining rather than have a separate set of miners for mainchain and each 
sidechain.

4.  A blockchain is just a singly-linked list.  Genesis block is the NULL of 
the list.  Additional blocks are added at the "front" of the singly-linked 
list.  In Bitcoin, the Merkle tree root is the "pointer to head" and the 
previous block header ID is the "pointer to tail"; additional data like 
proof-of-work nonce, timestamp, and version bits exist but are not inherent 
parts of the blockchain linked list.

5.  In addition to SPV proofs, we should also support reorg proofs.  Basically, 
a reorg proof is a longer SPV proof that shows that a previous SPV proof is 
invalid.

--

With those, I present the idea, "sidechain headers in mainchain".

Let us modify Sztorc's OP_BRIBEVERIFY to require the below SCRIPT to use:

  
 OP_BRIBEVERIFY OP_DROP OP_DROP OP_DROP

We also require that  be filled only once per mainchain block, as 
per the "blind" merge mining of Sztorc.

The key insight is that the  and  are, in fact, the sidechain header.  Concatenating 
those data and hashing them is the block header hash.  Just as additional 
information (like extranonce and witness commitment) are put in the mainchain 
coinbase transaction, any additional information that the sidechain would have 
wanted to put in its header can be committed to in the sidechain's equivalent 
of a coinbase transaction (i.e. a sidechain header transaction).

(All three pieces of data can be "merged" into a single very long data push to 
reduce the number of OP_DROP operations, this is a detail)

Thus, the sidechain header chain (but not the block data) is embedded in the 
mainchain itself.

Thus, SPV proofs do not need to present new data to the mainchain.  Instead, 
the mainchain already embeds the SPV proof, since the headers are already in 
the mainchain's blocks.  All that is needed to unlock a lockbox is to provide 
some past sidechain header hash (or possibly just a previous mainchain block 
that contains the sidechain header hash, to make it easier for mainchain nodes 
to look up) and the Merkle path to a sidechain-side side-to-main peg  
transaction.  If the sidechain header chain is "long enough" (for example, 288 
sidechain block headers) then it is presumably SPV-safe to release the funds on 
the mainchain side.

--

Suppose a sidechain is reorganized, while a side-to-main peg transaction is in 
the sidechain that is to be reorganized away.

Let us make our example simpler by requiring an SPV proof to be only 4 
sidechain block headers.

In the example below, small letters are sidechain block headers to be 
reorganized, large letters are sidechain block headers that will be judged 
valid.  The sidechain block header "Aa" is the fork point.  b' is the sidechain 
block containing the side-to-main peg that is lost.

Remember, for each mainchain block, only a single sidechain block header for a 
particular sidechain ID can be added.

The numbers in this example below are mainchain block height numbers.

0: Aa
1: b'
2: c
4: C
5: d
6: D
7: E
8: F
9: G
10: H <- b' side-to-main is judged as "not valid"

Basically, in case of a sidechain fork, the mainchain considers the longest 
chain to be valid if it is longer by the SPV proof required length.  In the 
above, at mainchain block 10, the sidechain H is now 4 blocks (H,G,F,E) longer 
than the other sidechain fork that ended at d.

Mainchain nodes can validate this rule because the sidechain headers are 
embedded in the mainchain block's coinbase.  Thus, mainchain fullnodes can 
validate this part of the sidechain rule of "longest work chain".

--

Suppose I wish to steal funds from sidechain, by stealing the sidechain 
lockboxes on the mainchain.  I can use the OP_BRIBEVERIFY opcode which Sztorc 
has graciously provided to cause miners that are otherwise uninterested in the 
sidechain to put random block headers on a sidechain fork.  Since the mainchain 
nodes are not going to verify the sidechain blocks (and are unaware of 
sidechain block formats in detail, just the sidechain block headers), I can get 
away with this on the mainchain.

However, to do so, I need to pay OP_BRIBEVERIFY multiple t

Re: [bitcoin-dev] BIP49 Derivation scheme changes

[shiva sitamraju via bitcoin-dev]

Hi,

Thanks Thomas. The procedure described in
http://docs.electrum.org/en/latest/seedphrase.html is really what I was
looking for ! I really don't see any point of following BIP49, If possible
it would be great if you can propose an alternative to BIP49 that follows
similar structure to what is used in electrum.

I have proposed following changes to BIP32 serialization format
https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki#serialization-format
to differentiate segwit xpub/xprv. Below the list of new version bytes,
resulting base58 prefix and network type:

0x042393df ,  sxpr ,   segwit mainnet private key
0x04239377 , sxpb , segwit mainnet public key
0x04222463 , stpb ,  segwit testnet public key
0x042224cc ,  stpr ,  segwit testnet private key

Let me know your thoughts

On Tue, Sep 5, 2017 at 12:12 AM, <
bitcoin-dev-requ...@lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev@lists.linuxfoundation.org
>
> To subscribe or unsubscribe via the World Wide Web, visit
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> or, via email, send a message with subject or body 'help' to
> bitcoin-dev-requ...@lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-ow...@lists.linuxfoundation.org
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of bitcoin-dev digest..."
>
>
> Today's Topics:
>
>1. Re: Horizontal scaling of blockchain (Cserveny Tamas)
>2. Re: Horizontal scaling of blockchain (Thomas Guyot-Sionnest)
>3. Re: Horizontal scaling of blockchain (Tom Zander)
>4. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)
>5. Re: Fwd:  "Compressed" headers stream (Peter Todd)
>6. Re: "Compressed" headers stream (Peter Todd)
>
>
> --
>
> Message: 1
> Date: Fri, 01 Sep 2017 18:15:53 +
> From: Cserveny Tamas 
> To: Lucas Clemente Vella , Tom Zander
> ,  Bitcoin Protocol Discussion
> 
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID:
>  n3gkfc...@mail.gmail.com>
> Content-Type: text/plain; charset="utf-8"
>
> Yes. I meant the single thread as an analogy, if a block is found, other
> blocks are worthless. (more or less) Longest chain wins.
>
> My line of though was, that currently the only way to scale with the
> traffic (and lowering the fees) is increasing the block size (which is hard
> as I learned from recent events), or reducing the complexity which is less
> secure (most likely more controversial)
>
> Splitting the chain is effectively increasing the block size, but without
> the increased hashing and validation overhead.
>
> The usage growth seems to be more of exponential rather than linear. Sooner
> or later the block size will need to be 4 mb then 40 mb, then what is the
> real limit? Otherwise waiting times and thus the fees will just grow
> rapidly. I don't think that it is desirable.
>
> With splitting the ledger, the block size can remain 1-2 mb for long time,
> only new partitions needs to be added on a schedule. This would also make
> better use of the hashing capacity.
>
> Cheers,
>
> Tamas
>
>
>
>
>
>
> On Fri, Sep 1, 2017 at 7:15 PM Lucas Clemente Vella 
> wrote:
>
> > > The current chain is effectively single threaded.
> >>
> >> This is not true, since xthin/compactblocks have been introduced we
> >> completely removed this bottle-neck.
> >> The transactions will be validated continuously, in parallel and not
> just
> >> when a block is found.
> >>
> >
> > If I understood correctly, OP was not talking about the process inside a
> > node being single threaded, but instead that the whole bitcoin
> distributed
> > system behaves as single threaded computation. OP seems to be describing
> a
> > system closer to what IOTA uses, by distributing among the miners the
> task
> > of validating the transactions. Although, without more specific details,
> it
> > is hard to judge the benefits.
> >
> > --
> > Lucas Clemente Vella
> > lve...@gmail.com
> >
> -- next part --
> An HTML attachment was scrubbed...
> URL:  attachments/20170901/d908e965/attachment-0001.html>
>
> --
>
> Message: 2
> Date: Fri, 1 Sep 2017 15:40:44 -0400
> From: Thomas Guyot-Sionnest 
> To: Cserveny Tamas ,   Bitcoin Protocol
> Discussion , Lucas
> Clemente
> Vella , Tom Zander 
> Subject: Re: [bitcoin-dev] Horizontal scaling of blockchain
> Message-ID: 
> Content-Type: text/plain; charset=windows-1252
>
> On 01/09/17 02:15 PM, Cserveny Tamas via bitcoin-dev wrote:
> > Yes. I meant the single thread as an analogy, if a block is found,
> > other blocks are worthless. (more or less) Longest chain wins.
> >
> > My line of though was, that currently the only way to scale with the
> > traffic 

[bitcoin-dev] Partial UTXO tree as commitment

[Tomas via bitcoin-dev]

I would like to propose an efficient UTXO commitment scheme.

A UTXO commitment can be useful for:

1. Fast syncing a full node, by downloading the UTXO-set
2. Proofing (non) existence of a UTXO..

Various schemes have been proposed:

* Merkle/radix trees and variants; all of which have the problem that
they significantly increase the burden of maintaining the UTXO set.
Furthermore, such schemes tend to practically prescribe the UTXO storage
format severely limiting continuous per-implementation optimizations.
* A "flat" rolling hash, eg the ECMH proposed by Pieter Wiulle which is
cheap to calculate but only solves (1) and not (2).

I propose a hybrid approach, with very limited extra burden to maintain
and reasonably small proofs: 

We divide the UTXO set in buckets by prefix of their TXID, then maintain
a rolling hash for each bucket. The commitment is then the root of the
tree constructed from the resulting bucket hashes. To construct the
tree: For each depth, we group the hashes of the next depth per 64
hashes and calculate the rolling hash of each. (Effectively, this is a
prefix tree with a fixed branch-size of 64).

Bucketcount
---
txcount = number of TXIDs in the UTXO set
bucketcount = (smallest power of 2 larger than sqrt(txcount))  << 6

Rationale for bucketcount:

* This currently gives a bucketcount of 2^19, which is very cheap to
maintain with a 16mb array of rolling hashes.
* This currently gives an average bucket size of 4kb. With a rolling
hash, full nodes don't need to maintain the buckets themselves, but they
are used for proofs.
* The burden of future UTXO growth is divided among maintaining the
rolling hashes and size of the proof: 10,000x as large UTXO set (20TB),
gives ~400kb buckets and ~1.6gb in maintaining rolling hashes.
* This gives a tree depth of 5, which means the cost of every UTXO
update is increased  by ~3 rolling hashes (and a double SHA), as the
lowest depths don't benefit from caching.
* A proof for (non) existence of a UTXO is ~ 4*64*32 =8kb (branch-nodes)
+ 4kb (bucket) = ~12kb

Specification [WIP]
---
We define the "UTXO commitment" as the serialized byte array: "U" "T"
"X" "O" VARINT(version) VARINT(txcount) UINT256(UTXO-root)[todo
clarify]

A block that contains an output in the coinbase whose scriptPubKey
consists solely of OP_RETURN [UTXO commitment] must be rejected if in
the UTXO commitment the version equals 1 and either 
* After updating the UTXO state, the number of distinct TXIDs in the
UTXO set is not equal to the txcount value of the UTXO commitment
* After updating the UTXO state, the UTXO-root in the UTXO commitment is
not equal to the UTXO-root defined below.

The UTXO-root can be calculated as follows:

* Define _bucketcount_ as (smallest power of 2 larger than
sqrt(txcount))  << 6
* Given a TXID in the UTXO set, define UTXO(TXID) as the double SHA256
of (TXID + coins). (coins is the serialization of unspent outputs to be
spec'ed). 
* Let bucket N be the set of values UTXO(TXID) for each TXID in the
UTXO-set where (TXID mod _bucketcount_) equals N.
* Let rhash N be the rolling hash (TBD) of all values in bucket N
* Let the hash sequence be the ordered sequence  rhash
[0,_bucketcount_).

1. If the hash sequence contains at most 64 entries, then the UTXO-root
is the rolling hash of all entries in the hash sequence, otherwise:
2. Group the hash sequence in ordered subsequences of 64 entries each.
3. Find the rolling hash of each subsequence
4. Continue with 1., with the hash sequence being the ordered sequence
of these rolling hashes.

Note: an implementation may want to maintain and update the set of
rolling hashes at higher depths on each UTXO set operation.

Note: the secure ECMH is a good candidate for the bucket hash. This
could also be used for the branch rolling hashes, but it might be worth
considering XOR for those as there seem to be simply not enough
candidates to find a colliding set?

Note: two magic numbers are used: "<< 6" for the bucket count, and "64"
for the branch size. They work nicely but are pulled out of a dark place
and merit some experimentation.

Use cases for light clients
-
These UTXO proofs could be used as compact fraud proofs, although the
benefit of this is not generally agreed upon.

They can also be used to increase low-conf security to light clients, by
validating the signatures and order-validity of incoming transactions
against the right bucket of the current UTXO set.

An interesting use case may be another type of light client. It could be
interesting for a light client to abandon the bloom filters, and instead
use the UTXO proofs to verify whether an incoming or outgoing
transaction is confirmed. This could be beneficial for "rarely active"
light clients such as smartphone apps, as it prevents the need to
synchronize previous blocks with bloom filters, and allows syncing to
the latest block with 12kb/output.

Summary 
--
* All

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

[Thomas Voegtlin via bitcoin-dev]

BIP32 extended public/private keys have version bytes that result in the
user visible xpub/xprv prefix. The BIP's recommendation is to use
different version bytes for other networks (such as tpub/tprv for testnet)

I would like to use additional version bytes to indicate the type of
output script used with the public keys.

I believe the change should be user visible, because users are exposed
to master public keys. I propose the following prefixes:

== === ===
VersionPrefix  Description
== === ===
0x0488ade4 xprvP2PKH or P2SH
0x0488b21e xpubP2PKH or P2SH
0x049d7878 yprv(P2WPKH or P2WSH) nested in P2SH
0x049d7cb2 ypub(P2WPKH or P2WSH) nested in P2SH
0x04b2430c zprvP2WPKH or P2WSH
0x04b24746 zpubP2WPKH or P2WSH
== === ===
(source: http://docs.electrum.org/en/latest/seedphrase.html)

I have heard the argument that xpub/xprv serialization is a format for
keys, and that it should not be used to encode how these keys are used.
However, the very existence of version bytes, and the fact that they are
used to signal whether keys will be used on testnet or mainnet goes
against that argument.

If we do not signal the script type in the version bytes, I believe
wallet developers are going to use dirtier tricks, such as the bip32
child number field in combination with bip43/bip44/bip49.


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