shiva sitamraju [ARCHIVE] on Nostr: 📅 Original date posted:2017-09-06 📝 Original message:Hi Thomas, Can you explain ...

📅 Original date posted:2017-09-06
📝 Original message: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 at lists.linuxfoundation.org> wrote:

> Send bitcoin-dev mailing list submissions to
> bitcoin-dev at 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 at lists.linuxfoundation.org
>
> You can reach the person managing the list at
> bitcoin-dev-owner at 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 at satoshilabs.com>
> To: shiva sitamraju <shiva at blockonomics.co>, Bitcoin Protocol
> Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <9da64df3-c6a9-c232-c801-f379a6d65e44 at 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 at satoshilabs.com>
> To: Thomas Voegtlin <thomasv at electrum.org>, Bitcoin Protocol
> Discussion <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
> scripts
> Message-ID: <198be73d-4676-45e9-6e3d-b89f73e31702 at 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 at electrum.org>
> To: bitcoin-dev at lists.linuxfoundation.org
> Subject: Re: [bitcoin-dev] BIP49 Derivation scheme changes
> Message-ID: <28d57503-c2b3-7736-bfea-46506636d999 at 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 at dashjr.org>
> To: bitcoin-dev at lists.linuxfoundation.org, Thomas Voegtlin
> <thomasv at electrum.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
> scripts
> Message-ID: <201709051303.43410.luke at 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 at suredbits.com>
> To: ZmnSCPxj <ZmnSCPxj at protonmail.com>, Bitcoin Protocol
> Discussion
> <bitcoin-dev at 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 at electrum.org>
> To: Luke Dashjr <luke at dashjr.org>,
> "bitcoin-dev at lists.linuxfoundation.org"
> <bitcoin-dev at lists.linuxfoundation.org>
> Subject: Re: [bitcoin-dev] Proposal: bip32 version bytes for segwit
> scripts
> Message-ID: <41fb5a09-a964-a81b-497e-70a930b6923c at 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 at jtimon.cc>
> To: Bitcoin Dev <bitcoin-dev at lists.linuxfoundation.org>
> Subject: [bitcoin-dev] SF proposal: prohibit unspendable outputs with
> amount=0
> Message-ID:
> <CABm2gDojDQWMhw8wW1UkRGKtdbby2+6AFFZLPuRcUb7WF_u5qQ at 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 at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
> End of bitcoin-dev Digest, Vol 28, Issue 6
> ******************************************
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20170906/4a418ba1/attachment-0001.html>;