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-request@lists.linuxfoundation.org
You can reach the person managing the list at
bitcoin-dev-owner@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: BIP49 Derivation scheme changes (Pavol Rusnak)
2. Re: Proposal: bip32 version bytes for segwit scripts
(Pavol Rusnak)
3. Re: BIP49 Derivation scheme changes (Thomas Voegtlin)
4. Re: Proposal: bip32 version bytes for segwit scripts (Luke Dashjr)
5. Re: Sidechain headers on mainchain (unification of
drivechains and spv proofs) (Chris Stewart)
6. Re: Proposal: bip32 version bytes for segwit scripts
(Thomas Voegtlin)
7. SF proposal: prohibit unspendable outputs with amount=0
(Jorge Tim?n)
------------------------------------------------------------ ----------
Message: 1
Date: Tue, 5 Sep 2017 17:41:37 +0200
From: Pavol Rusnak <stick@satoshilabs.com>
To: shiva sitamraju <shiva@blockonomics.co>, Bitcoin Protocol
Discussion <bitcoin-dev@lists.linuxfoundation.org >
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
Message-ID: <9da64df3-c6a9-c232-c801-f379a6d65e44@satoshilabs.com >
Content-Type: text/plain; charset=windows-1252
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
------------------------------
Message: 2
Date: Tue, 5 Sep 2017 17:44:01 +0200
From: Pavol Rusnak <stick@satoshilabs.com>
To: Thomas Voegtlin <thomasv@electrum.org>, Bitcoin Protocol
Discussion <bitcoin-dev@lists.linuxfoundation.org >
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
scripts
Message-ID: <198be73d-4676-45e9-6e3d-b89f73e31702@satoshilabs.com >
Content-Type: text/plain; charset=windows-1252
On 05/09/17 12:25, Thomas Voegtlin via bitcoin-dev wrote:
> ========== =========== ===================================
> Version Prefix Description
> ========== =========== ===================================
> 0x0488ade4 xprv P2PKH or P2SH
> 0x0488b21e xpub P2PKH or P2SH
> 0x049d7878 yprv (P2WPKH or P2WSH) nested in P2SH
> 0x049d7cb2 ypub (P2WPKH or P2WSH) nested in P2SH
> 0x04b2430c zprv P2WPKH or P2WSH
> 0x04b24746 zpub P2WPKH 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
------------------------------
Message: 3
Date: Tue, 5 Sep 2017 18:33:00 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
To: bitcoin-dev@lists.linuxfoundation.org
Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
Message-ID: <28d57503-c2b3-7736-bfea-46506636d999@electrum.org >
Content-Type: text/plain; charset=utf-8
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.
------------------------------
Message: 4
Date: Tue, 5 Sep 2017 13:03:39 -0400
From: Luke Dashjr <luke@dashjr.org>
To: bitcoin-dev@lists.linuxfoundation.org , Thomas Voegtlin
<thomasv@electrum.org>
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
scripts
Message-ID: <201709051303.43410.luke@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 <chris@suredbits.com>
To: ZmnSCPxj <ZmnSCPxj@protonmail.com>, Bitcoin Protocol Discussion
<bitcoin-dev@lists.linuxfoundation.org >
Subject: Re: [bitcoin-dev] Sidechain headers on mainchain (unification
of drivechains and spv proofs)
Message-ID:
<CAGL6+mFHe_SfMea1oMZ3n-G3ey9yToAvTMTcfdxJ5qDD1dTXyQ@ >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/ >elements-0.14.1/src/script/ interpreter.cpp#L1420
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
<https://medium.com/@Chris_Stewart_5/what-can-go-wrong- >.when-transferring-coins-into- a-sidechain-with-op- withdrawproofverify- b2f49b02ab60
This allows us to prove that a transaction occurred on the sidechain to
lock up those funds.
-Chris
?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/ >attachments/20170905/37b0bcbe/ attachment-0001.html
------------------------------
Message: 6
Date: Tue, 5 Sep 2017 20:09:19 +0200
From: Thomas Voegtlin <thomasv@electrum.org>
To: Luke Dashjr <luke@dashjr.org>,
"bitcoin-dev@lists.linuxfoundation.org "
<bitcoin-dev@lists.linuxfoundation.org >
Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
scripts
Message-ID: <41fb5a09-a964-a81b-497e-70a930b6923c@electrum.org >
Content-Type: text/plain; charset=utf-8
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.
------------------------------
Message: 7
Date: Tue, 5 Sep 2017 23:51:45 +0200
From: Jorge Tim?n <jtimon@jtimon.cc>
To: Bitcoin Dev <bitcoin-dev@lists.linuxfoundation.org >
Subject: [bitcoin-dev] SF proposal: prohibit unspendable outputs with
amount=0
Message-ID:
<CABm2gDojDQWMhw8wW1UkRGKtdbby2+6AFFZLPuRcUb7WF_u5qQ@mail. >gmail.com
Content-Type: text/plain; charset="UTF-8"
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
End of bitcoin-dev Digest, Vol 28, Issue 6
******************************************