Hi Thomas, Can you explain why P2WPKH nested in BIP16 P2SH require a different version than P2WPKH? It seems to me both would would generate same bitcoin address in txout and hence would be in the same wallet account. I am fine with your proposal too. Would be great if you can list all new versions including testnet ones. I would prefer all testnet ones start with t (easier to identify) instead of having t,u,v Thanks On Wed, Sep 6, 2017 at 3:21 AM, < bitcoin-dev-request@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-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 > To: shiva sitamraju , Bitcoin Protocol > Discussion > 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 > To: Thomas Voegtlin , Bitcoin Protocol > Discussion > 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 > 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 > To: bitcoin-dev@lists.linuxfoundation.org, Thomas Voegtlin > > 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 > 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 > 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 > 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: attachments/20170905/37b0bcbe/attachment-0001.html> > > ------------------------------ > > Message: 6 > Date: Tue, 5 Sep 2017 20:09:19 +0200 > From: Thomas Voegtlin > To: Luke Dashjr , > "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 > To: Bitcoin Dev > Subject: [bitcoin-dev] SF proposal: prohibit unspendable outputs with > amount=0 > Message-ID: > 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 > ****************************************** >