Re: [bitcoin-dev] Block solving slowdown question/poll
Hi, noob question here: Is there a long-term plan for if the block reward drops too low to ensure the security of the network? IIUC miners only make profit from block rewards and transaction fees, and once the block reward drop to zero we're merely hoping that transaction fees will keep mining expensive enough to stop a state actor or someone from buying enough hash power to attack the network. If that's the case, should we start making plans now to change the protocol to allow an adjustable block reward? Here's a half-baked idea I had of how that could work: Since the block reward dilutes the value of the currency bitcoin holders have an incentive to keep the reward low. However, since the block reward is also (partly) what incentivizes mining, bitcoin holders also have an incentive to keep the reward high enough to keep the network secure. So if bitcoin holders were able to vote to decide the block reward they "should", hypothetically, reliably choose a value that balances these two concerns. You could implement this voting by adding an optional extra field to every txout that signals what the holder thinks the inflation rate should be. If the field is missing you just assume the default value based on the current protocol. Then, whenever a new block is mined, you take the median inflation rate of all the pre-existing utxos, weighted by the utxo value, to calculate the block's reward. Is this idea fundamentally broken somehow? Or are there already better ideas for how to tackle this problem (I don't follow this list very closely)? Or is this actually a non-issue to start with? - Andrew 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] Block solving slowdown question/poll
Hi, thanks for the replies. > Anyway, yes, your idea is fundamentally broken because a zero block reward > happens because creating even one more satoshi will push the amount of > bitcoin over 21,000,, breaking the meaning of "bitcoin," or, if you > like, creating a fundamental contradiction in our use of the term. I wouldn't really consider that fundamentally broken. It changes the meaning of "bitcoin", but so does every upgrade to the protocol. The worst problem I can see with this is that there's probably a lot of software out there which assumes a cap of 21M. But we'd have years to find and fix those bugs. > They already do so, via an implicit "field", known as the transaction fee. > This makes the vote for how much security is needed to be costly to the > voter, which is appropriate: you pay for your security. This isn't the same thing though, economically / game-theoretically speaking. Transaction fees are only paid when bitcoins get moved. There's no on-going cost for people holding bitcoins (assuming they're doing their day-to-day transactions almost entirely off-chain, which is something that's only going to become more common). More to the point, the transaction fee is only set by the current demand for block space. If transaction fees drop too low to maintain a secure hash rate then people *could* willingly pay more than they need to to get their transactions mined, but it's unlikely they will since it'd be cheaper to just pay the minimum and hope that everyone else covers the costs of keeping the network secure for them. With the voting idea everyone decides what everyone pays (via dilution) to keep the network secure. Choosing to signal a high inflation rate doesn't mean you pay more than everyone else, just that you might shift the median, so there's no tragedy-of-the-commons problem. Also, votes are weighted by the value of the utxo, so people both vote and pay in proportion to the amount of bitcoin they're holding. Does this make sense? Or is there some game-theoretic reason I'm not seeing for why transaction fees can never drop dangerously low in the first place? - Andrew 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] Statechain implementations
Hi, Great to see some work in this direction, here's some thoughts on your keygen scheme: In the scenario where Owner1=Owner2, that is, one of the owners sends some coins to itself, that owner would get to know both x1*s1 and x2*s2=x2*s1*o2_inv*o1, and, because he already knows o1 and o2, that implies knowledge of both x1*s1 and x2*s1 where x1 and x2 are random numbers sampled from an uniform distribution. Once the owner has these two numbers, he can just sum these together to obtain s1*(x1+x2). Now, because of the central limit theorem, the distribution of x1+x2 should approximate a normal one, concretely an Irwin–Hall distribution, with that approximation getting better when more numbers are collected through iterations of the protocol. Once you've collected enough numbers to approximate a normal well enough (looking at Irwin Hall distribution graphs^[1] you can observe that with less than 10 samples the distribution is already pretty similar to a normal one), it should be possible to drastically reduce the search space and apply brute force to guess the value of \sum x and, consequently, s1. Practically, it's possible that the search space is still too large for brute-force to be fruitful, so this attack might not work, but it shows that there is information leakage in every protocol iteration. On another note, if you are not already aware of, something which might be worth looking into is the possibility of further trust-minimising the SE role by forcing it's code to be run inside an AWS oracle or a hardware isolated processor such as SGX. Albert [1] https://en.wikipedia.org/wiki/Irwin%E2%80%93Hall_distribution On Wed, Mar 25, 2020, at 9:52 PM, Tom Trevethan via bitcoin-dev wrote: > Hi all, > > We are starting to work on an implementation of the statechains concept > (https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), > with particular interest in using the protocol enable the change of > ownership (novation) of an individual position in an active discreet log > contract (DLC) without an on-chain transaction, and without needing the > cooperation of the counterparty. The protocol as outlined by Ruben requires > features not currently available in Bitcoin (like SIGHASH_NOINPUT), and it is > uncertain when (or even if) this will be added. So we are looking at variants > that would work with current Bitcoin functionality, and it would be good to > get some feedback on them. > > There are two main modifications we are looking at: > 1. Instead of an eltoo-based backup/refund transaction (enabling the current > owner to claim the UTXO in case the statechain entity disappears) we propose > using a decrementing nLocktime for backup transactions as the output changes > hands. Here, the first owner gets a backup transaction with an nLocktime at > some future height (h0), then the next owner gets a backup transaction with > nLocktime (h0-c) where c is a confirmation window. This approach has the > downside of limiting the lifetime of the UTXO, but it also doesn't require > the current owner to be always online. > > 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE key > and transitory key) with a single P2(W)PKH output where the public key shared > between the SE and the current owner. The SE and the current owner can then > sign with a 2-of-2 ECDSA MPC. This enables each owner to generate their own > private key share, and the SE changes their key share at each change of > ownership (with the shared public key remaining the same). This works as > follows (.G is EC point multiplication, * is scalar multiplication): > > KeyGen: > > a. Owner 1 generates private key share o1 then calculates the corresponding > public key of the share O1 and sends it to the SE: O1 = o1.G > b. The SE then generates a private key: s1 (the SE private key share), > calculates the corresponding public key and sends it to Owner 1: S1 = s1.G > c. Both SE and Owner 1 then multiply the public keys they receive by their > own private key shares to obtain the same shared public key P (which > corresponds to a shared private key of p = o1*s1): P = o1.(s1.G) = s1.(o1.G) > d. Owner 1 creates a funding transaction (Tx0) to pay an amount A to the > address corresponding to P (but doesn't sign it). > e. Once Owner 1 and SE cooperatively sign the first backup transaction, > Owner 1 then signs and broadcasts the deposit transaction Tx0. > > Transfer from Owner 1 to Owner 2: > > a. Owner 2 generates two private keys: o2 (the new owner UTXO private key > share) and b2 (the new owner refund private key). > b. The SE generates a temporary blinding nonce x and calculates the value > x*s1 and sends this securely to Owner 2. > c. Owner 2 then multiplies this received value by the modular inverse of o2 > (o2_inv) and then sends this value (x*s1*o2_inv), to Owner 1. > d. Owner 1 then multiplies this received
Re: [bitcoin-dev] Block solving slowdown question/poll
Good morning Andrew, > > > Anyway, yes, your idea is fundamentally broken because a zero block reward > > happens because creating even one more satoshi will push the amount of > > bitcoin over 21,000,, breaking the meaning of "bitcoin," or, if you > > like, creating a fundamental contradiction in our use of the term. > > I wouldn't really consider that fundamentally broken. It changes the meaning > of > "bitcoin", but so does every upgrade to the protocol. The worst problem I can > see with this is that there's probably a lot of software out there which > assumes a cap of 21M. But we'd have years to find and fix those bugs. There are changes of meaning, and then there are changes of meaning. Smaller changes that puny humans can understand are better than larger changes beyond the ken of mortal man. To change the supply is far too big a change. > > They already do so, via an implicit "field", known as the transaction fee. > > This makes the vote for how much security is needed to be costly to the > > voter, which is appropriate: you pay for your security. > > This isn't the same thing though, economically / game-theoretically speaking. > Transaction fees are only paid when bitcoins get moved. There's no on-going > cost for people holding bitcoins (assuming they're doing their day-to-day > transactions almost entirely off-chain, which is something that's only going > to > become more common). More to the point, the transaction fee is only set by the > current demand for block space. If transaction fees drop too low to maintain a > secure hash rate then people could willingly pay more than they need to to > get their transactions mined, but it's unlikely they will since it'd be > cheaper > to just pay the minimum and hope that everyone else covers the costs of > keeping > the network secure for them. > > With the voting idea everyone decides what everyone pays (via dilution) to > keep > the network secure. Choosing to signal a high inflation rate doesn't mean you > pay more than everyone else, just that you might shift the median, so there's > no tragedy-of-the-commons problem. Also, votes are weighted by the value of > the utxo, so people both vote and pay in proportion to the amount of bitcoin > they're holding. > > Does this make sense? Or is there some game-theoretic reason I'm not seeing > for > why transaction fees can never drop dangerously low in the first place? What happens if I own a few million Bitcoin and then accidentally lose my private keys in a tragic ear-cleaning accident? Then the vote of that UTXO containing a few million Bitcoins will remain forever fixed and unable to change according to whatever you believe would make us as a community decide to change the inflation rate. If you enforce that only "recently-created" UTXOs get to vote, then in order for me to affect the vote (in the happy case where I do **not** lose all my privkeys in a tragic ear-cleaning accident), I would have to make a synthetic self-paying transaction. How is it so different from me having to make up a synthetic transaction in order to pay fees and thus affect the current security of the blockchain? -- It is helpful to remember that as a UTXO gets buried deeper, its security is inevitably better, and once I have a sufficient level of security in my ownership of the coin, I will not particularly care about any improved security and will not be interested in paying for more, hence why should I support any fork which makes me pay for my security continuously when I can simply support a fork that retains the current supply and does *not* make me pay for continued security? -- If I want to *spend* my Bitcoins on something --- and nothing has value until I actually utilize it --- then I *will* pay transaction fees. The receiver of the coin would want to ensure that the received UTXO is deeply buried to the point that it has sufficient security for the receiver, before releasing or providing me with whatever I am exchanging the coin for. Thus, if I find that there are no miners at all, I could offer a high fee to get my transaction mined. Of course, you might say that this only pays for one block. But in most cases I will have more value remaining beyond what I spend to the receiver, i.e. I have a change output from that transaction. In such a case, I can pay for more blocks by re-spending the change output to myself, paying a transaction fee each time, until the original transaction that spends to the receiver is deeply buried and the receiver credits it and then releases the product or service I am exchanging *for*. Alternately the receiver can do the same for its *own* UTXO, and will increase the payment it demands from me in order to perform this itself; thus I still end up paying for the security of the *transaction* and not the security of the *holding*. So there is really no need for any mechanism beyond transaction fees. Regards, ZmnSCPxj
Re: [bitcoin-dev] Statechain implementations
Good morning Tom, > > We are starting to work on an implementation of the statechains concept > (https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), > with particular interest in using the protocol enable the change of > ownership (novation) of an individual position in an active discreet log > contract (DLC) without an on-chain transaction, and without needing the > cooperation of the counterparty. The protocol as outlined by Ruben requires > features not currently available in Bitcoin (like SIGHASH_NOINPUT), and it is > uncertain when (or even if) this will be added. So we are looking at variants > that would work with current Bitcoin functionality, and it would be good to > get some feedback on them. > > There are two main modifications we are looking at: > 1. Instead of an eltoo-based backup/refund transaction (enabling the current > owner to claim the UTXO in case the statechain entity disappears) we propose > using a decrementing nLocktime for backup transactions as the output changes > hands. Here, the first owner gets a backup transaction with an nLocktime at > some future height (h0), then the next owner gets a backup transaction with > nLocktime (h0-c) where c is a confirmation window. This approach has the > downside of limiting the lifetime of the UTXO, but it also doesn't require > the current owner to be always online. I believe I suggested this to Ruben Somsen as well in the past, but you can replace the state update mechanism with, for example, Decker-Wattenhofer decrementing-`nSequence`, which while it has a limit on the number of updates, does not have a limit on the time that a UTXO is locked in this mechanism. You can even use the Decker-Wattenhofer trick of having a chain of decrementing-`nSequence` mechanisms to effectively multiply the number of updates that the overall mechanism can have. The drawback is that in a unilateral close condition, the time to completely resolve the unilateral close is very large. For a quick reference for this technique: * The funding transaction is anchored onchain, but all succeeding transactions are offchain. * This funding transaction has a particular funding transaction output. * There is a kickoff transaction, which is a 1-input 1-output transaction without any `nLockTime` or `nSequence` limits. * This spends the funding tx out. * The signer set of the output is the same as the signer set of the funding transaction output. * You could tweak keys or script to give a modicum of privacy. * There is one or more decrementing-`nSequence` transactions, which are 1-input 1-output transactions. * Each one has a particular `nSequence` with a relative-locktime constraint. * This spends the kickoff transaction output. * The signer set of the output is the same as the signer set of the funding transaction output. * There is one or more decrementing-`nSequence` transactions, which are 1-input 1-output transactions. * Each one has a particular `nSequence` with a relative-locktime constraint. * This spends the previous stage decrementing-`nSequence` transaction output. * The signer set of the output is the same as the signer set of the funding transaction output. * Repeat the above stage a few times. * There is one or more decrementing-`nSequence` transactions, which are 1-input multi-output transactions. * Each one has a particular `nSequence` with a relative-locktime constraint. * This spends the previous stage decrementing-`nSequence` transaction output. * The outputs of this transaction represent the current state inside the statechain. The `nSequence` use means there is no time-based lifetime limit. The decrementing-`nSequence` stages mean that earlier states have higher `nSequence` limits, and newer states have lower `nSequence` limits. Chaining multiple such mechanisms allows you to "reset" a stage by making a single update of the higher stage, which resets all further stages. So for example, we could have a multi-stage mechanism as below: ***blockchain*** [funding tx] -+ _ _ _ _ _ _ | _ _ _ _ _ _ _ offchain| +->[kickoff tx]->[[14] stage]->[[14] stage]->[[14] stage]-> state outputs The number in the brackets is the relative-locktime `nSequence` constraint in that stage transaction. Let us suppose that we agree to decrement `nSequence` by 7 blocks at each update. Then the first update will have: ***blockchain*** [funding tx] -+ _ _ _ _ _ _ | _ _ _ _ _ _ _ offchain| +->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 7] stage]-> state outputs The the second update: ***blockchain*** [funding tx] -+ _ _ _ _ _ _ | _ _ _ _ _ _ _ offchain| +->[kickoff tx]->[[14] stage]->[[14] stage]->[[ 0] stage]-> state outputs After this update, for the next update, we would also sign the
Re: [bitcoin-dev] Mitigating Differential Power Analysis in BIP-340
Hi Pieter, Thanks for the detailed response. > /secret key/secret keyI'll try to summarize the discussion we had that led > to this choice, but most of it is on > https://github.com/sipa/bips/issues/195 if you want the details. Ahh I can't believe I missed that github issue while searching. I guess I started reading a paper on DPA and got carried away. I can see you got to where I was and then went much further including some empirical analysis. Nice. I agree with the conclusion that xor is more robust than just hashing randomness in the same block as the secret key. > Let me first try to address what I think you're overlooking: in a > BIP32/Taproot like scenario, the private key that goes into the signing > algorithm functions as *both* secret and known to the attacker. That is to > say, there is a master secret s, and signing key x that goes into the hash > is x=s+a (mod n) for some value a that the attacker knows, and can modify > (he cannot control it directly, but he may be able to grind it to have a > structure he likes). I believe that means that feeding x to a hash directly > itself is already a problem, regardless of what else goes into the hash - > interactions between bits inside the hash operation that all come from x > itself can leak bit-level information of x. XORing (or any other simple > mix operation that does not expose bit-level information) into the private > key before giving it to a hash function seems like it would address this. > This is an subtle point that I didn't cross my mind. My gut feeling is there isn't even a computational argument to made that what I was suggesting is secure against DPA in that setting. DPA seems to be a PITA. A footnote in the BIP with a citation for DPA (the ed25519 one from the issue is good) and a hint about why you should avoid hashing Bitcoin secret keys altogether would be good. This brings us to the next point. It also assumes that somehow the computation of x itself is immune from > leaks (something you pointed out in a previous e-mail, I noticed). > >From my reading of the HMAC papers it seems you might be able to vary the BIP32 child index derivation to do this attack. Just thinking about it now, these attacks seem far fetched just because in order for it to be useful you need to have physical access to the device and to be able to accurately measure power consumption in high resolution (which I guess you can't do from a typical USB bus from corrupted software). Then you also need to get the user to do lots of signing or derivation with their device. I guess a malicious cable with some way of exfiltrating power consumption could do it. > I'm happy for any input you may have here. In particular, the recent > discussions around the interactions between anti-covert channel protection, > randomness, and the ability to spot check hardware devices may mean we > should revise the advice to consider not adding randomness unless such a > anti-covert channel scheme is used. > My only comment here is that there will end up being more than one way to do it and I think what you and your collaborators have put forward is at a local optimum of design (now that I understand it). Thanks and well done! It won't be the right optimum for everyone. To me, it seems like a good place to start. If you develop a decent nonce exfiltration protected signing protocol later then I don't see why HW wallets wouldn't compete for favour amongst the community by implementing and updating their devices to conform to it. LL ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Statechain implementations
Hi all, We are starting to work on an implementation of the statechains concept ( https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39), with particular interest in using the protocol enable the change of ownership (novation) of an individual position in an active discreet log contract (DLC) without an on-chain transaction, and without needing the cooperation of the counterparty. The protocol as outlined by Ruben requires features not currently available in Bitcoin (like SIGHASH_NOINPUT), and it is uncertain when (or even if) this will be added. So we are looking at variants that would work with current Bitcoin functionality, and it would be good to get some feedback on them. There are two main modifications we are looking at: 1. Instead of an eltoo-based backup/refund transaction (enabling the current owner to claim the UTXO in case the statechain entity disappears) we propose using a decrementing nLocktime for backup transactions as the output changes hands. Here, the first owner gets a backup transaction with an nLocktime at some future height (h0), then the next owner gets a backup transaction with nLocktime (h0-c) where c is a confirmation window. This approach has the downside of limiting the lifetime of the UTXO, but it also doesn't require the current owner to be always online. 2. Replacing the 2-of-2 multisig output (paying to statechain entity SE key and transitory key) with a single P2(W)PKH output where the public key shared between the SE and the current owner. The SE and the current owner can then sign with a 2-of-2 ECDSA MPC. This enables each owner to generate their own private key share, and the SE changes their key share at each change of ownership (with the shared public key remaining the same). This works as follows (.G is EC point multiplication, * is scalar multiplication): KeyGen: a. Owner 1 generates private key share o1 then calculates the corresponding public key of the share O1 and sends it to the SE: O1 = o1.G b. The SE then generates a private key: s1 (the SE private key share), calculates the corresponding public key and sends it to Owner 1: S1 = s1.G c. Both SE and Owner 1 then multiply the public keys they receive by their own private key shares to obtain the same shared public key P (which corresponds to a shared private key of p = o1*s1): P = o1.(s1.G) = s1.(o1.G) d. Owner 1 creates a funding transaction (Tx0) to pay an amount A to the address corresponding to P (but doesn't sign it). e. Once Owner 1 and SE cooperatively sign the first backup transaction, Owner 1 then signs and broadcasts the deposit transaction Tx0. Transfer from Owner 1 to Owner 2: a. Owner 2 generates two private keys: o2 (the new owner UTXO private key share) and b2 (the new owner refund private key). b. The SE generates a temporary blinding nonce x and calculates the value x*s1 and sends this securely to Owner 2. c. Owner 2 then multiplies this received value by the modular inverse of o2 (o2_inv) and then sends this value (x*s1*o2_inv), to Owner 1. d. Owner 1 then multiplies this received value by the key share o1 and sends the resulting value (x*s1*o2_inv*o1) to the SE. e. The SE then multiplies this received value by the modular inverse of the temporary nonce (x_inv) to obtain x*s1*o2_inv*o1*x_inv. This cancels the blinding nonce x to give s1*o2_inv*o1. This value, when multiplied by the new owner key share o2 equals the original shared private key s1*o1. f. The SE then sets this value equal to s2 = s1*o2_inv*o1 and deletes s1. s2 and o2 are now the key shares of `P` and can be used to colaboritively sign (with 2P ECDSA). So long as the SE delets s1, the old owner key share (o1) is of no use in deriving or co-signing with the full shared private key, and is invalidated. g. The shared public key P remains unchanged, but the corresponding private key (which no individual party ever has knowledge of or can derive) can only be determined from the key shares of the SE and Owner 2 (i.e. P = s2*o2.G). h. Owner 2 then calculates their backup public key (B2 = b2.G) and sends it to the SE. i. The SE creates a backup transaction (Tx2) that pays the output of Tx0 to the address corresponding to B2 , with `nLockTime` set to a block height h0 - c0, where c0, is a confirmation time sufficient to guarantee that Tx2 can be confirmed in the blockchain before Tx1 (therefore making Tx1 invalid). j. Owner 2 and the SE then cooperate to sign Tx2 with shared key (P) using the 2P ECDSA protocol, which Owner 2 then saves. The principle of the logic of the key transfer is that the two separate key shares are updated, but the full shared private key (which no-one knows) remains the same. The new owner chooses a new secret value for their private key share, and this (along with the private key share of the previous owner) is utilized by the SE to update their share. The use of the nonce (x) prevents any of the participants from determining any information about each others
Re: [bitcoin-dev] RFC: Deterministic Entropy From BIP32 Keychains
I think the point is to use this proposed extension/standard for a kind of "seed management" function, set it up on an offline device (an always offline laptop, or a modified hardware wallet) where you put the master seed. And then you use this as a kind of seed manager and transcript the seeds for different sub-wallets into the respective wallets as BIP39 mnemonics. So I do not think it needs any changes from existing wallet authors, as the interaction point is a bip 39 seed, which they mostly know how to use. Indeed if you were to modify an existing wallet to accept the master seed from seed management scheme and derive the seed it needs on each wallet, then that would create a weakest link in the chain risk - if that wallet was insecure, or compromised then all other derived seeds would be also and you want independence for each wallet. I do think that this use case is a practical problem for people managing multiple seeds for various wallets in a bitcoin business setting or even power users - you lose the single backup design, because it's too cumbersome to create fresh backups for each of multiple wallets, especially distributed , fireproof cryptosteel etc backups and so in practice for multi wallet scenarios probably they are not all full backed up or not backed up as robustly (not as geo-redundant, fireproof, secret-shared etc). Adam On Tue, 24 Mar 2020 at 09:32, Tim Ruffing via bitcoin-dev wrote: > > I think your proposal is simply to use BIP32 for all derivations and > the observation that you can work with derived keys with the > corresponding suffixes of the path. I believe that this is a good idea. > > But I don't think that simply writing a standard will help. It's just > one step. If all your wallets support incompatible formats, we should > work on fixing this because that's the root of the issue. Otherwise you > end up converting keys back and forth manually (as Chris pointed out), > and this can't be the goal. > > But then you need to reach out to wallet devs explicitly and get them > involved in creating the standard. Otherwise they won't use it. That's > a hard process, and it's even harder to make sure that the resulting > proposal isn't way too complex because everyone brings their special > case to the table. > > Tim > > On Sun, 2020-03-22 at 11:58 +, Ethan Kosakovsky via bitcoin-dev > wrote: > > I have completely revised the wording of this proposal I hope to be > > clearer in explaining the motivation and methodology. > > > > https://gist.github.com/ethankosakovsky/268c52f018b94bea29a6e809381c05d6 > > > > Ethan > > > > ‐‐‐ Original Message ‐‐‐ > > On Friday, March 20, 2020 4:44 PM, Ethan Kosakovsky via bitcoin-dev < > > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > > I would like to present a proposal for discussion and peer review. > > > It aims to solve the problem of "too many seeds and too many > > > backups" due to the many reasons stipulated in the proposal text. > > > > > > https://gist.githubusercontent.com/ethankosakovsky/f7d148f588d14e0bb4f70bb6afc509d0/raw/6da51e837b0e1f1b2b21f3d4cbc2c5a87969ffd5/bip-entropy-from-bip32.mediawiki > > > > > > > > > BIP: > > > Title: Deterministic Entropy From BIP32 Keychains > > > Author: Ethan Kosakovsky ethankosakov...@protonmail.com > > > Comments-Summary: No comments yet. > > > Comments-URI: > > > Status: Proposed > > > Type: Standards Track > > > Created: 2020-03-20 > > > License: BSD-2-Clause > > > OPL > > > > > > > > > ==Abstract== > > > > > > This proposal provides a way to derive entropy from a HD keychain > > > path in order to deterministically derive the initial entropy used > > > to create keychain mnemonics and seeds. > > > > > > ==Motivation== > > > > > > BIP32 uses some initial entropy as a seed to deterministically > > > derive a BIP32 root for hierarchical deterministic keychains. BIP39 > > > introduced a method of encoding initial entropy into a mnemonic > > > phrase which is used as input to a one way hash function in order > > > to deterministically derive a BIP32 seed. The motivation behind > > > mnemonic phrases was to make it easier for humans to backup and > > > store offline. There are also other variations of this theme. > > > > > > The initial motivation of BIP32 was to make handling of large > > > numbers of private keys easier to manage and backup, since you only > > > need one BIP32 seed to cover all possible keys in the keychain. In > > > practice however, due to various wallet implementations and > > > security models, the average user may be faced with the need to > > > handle an ever growing number of seeds/mnemonics. This is due to > > > incompatible wallet standards, hardware wallets (HWW), seed formats > > > and standards, as well as, the need to used a mix of hot and cold > > > wallets depending on the application and environment. > > > > > > Examples would span wallets on mobile phones, online servers > > > running protocols like Join Market or Lightning, and the
Re: [bitcoin-dev] RFC: Kicking BIP-322 (message signing) into motion
Hello,
I propose simplifying BIP-322 down to the single-proof case, and
removing some abstractions (e.g. the "actions"/"purposes" stuff):
https://github.com/bitcoin/bips/pull/903
Feedback welcome.
New version below:
```
BIP: 322
Layer: Applications
Title: Generic Signed Message Format
Author: Karl-Johan Alm
Comments-Summary: No comments yet.
Comments-URI: https://github.com/bitcoin/bips/wiki/Comments:BIP-0322
Status: Draft
Type: Standards Track
Created: 2018-09-10
License: CC0-1.0
== Abstract ==
A standard for interoperable generic signed messages based on the
Bitcoin Script format.
== Background ==
* Assume two actors, a prover P and a verifier V.
* P wants to prove that they own the private key
k associated with a given address A (which
in turn is derived from the pubkey kG).
* Let V generate a message M and hand this
to P.
* P generates a signature S by signing the
message M using k. Given S,
V can prove that P has the private key
associated with A.
The astute reader will notice that the above is missing a critical
part, namely the pubkey kG, without which the verifier
cannot actually verify the message. The current message signing
standard solves this via a cryptographic trick, wherein the signature
S above is a special "recoverable signature" type. Given
the message M and the signature S, it is
then possible to recover the pubkey kG. The system thus
derives the address for the pubkey kG, and if it does not
match A, the proof is deemed invalid.
While this is a neat trick, it unnecessarily restricts and complicates
the message signing mechanism; for instance, it is currently not
possible to sign a message for a P2SH address, because there is no
pubkey to recover from the resulting signature.
== Motivation ==
The current message signing standard only works for P2PKH (1...)
addresses. By extending it to use a Bitcoin Script based approach, it
could be made more generic without causing a too big burden on
implementers, who most likely have access to Bitcoin Script
interpreters already.
== Specification ==
A new structure SignatureProof is added, which is a
simple serializable scriptSig & witness container.
=== SignatureProof container ===
{|class="wikitable" style="text-align: center;"
|-
!Type
!Length
!Name
!Comment
|-
|VarInt||1-8||scriptsiglen||Number of bytes in scriptSig data
|-
|Uint8*||[scriptsiglen]||scriptsig||ScriptSig data
|-
|VarInt||1-8||witlen||Number of entries in witness stack
|-
|Uint8[]*||[witlen]||wit||Witness stack, as [witlen] uint8* vectors,
each one prepended with a varint of its size
|}
In some cases, the scriptsig or wit may be empty. If both are empty,
the proof is incomplete.
=== Result Codes ===
A verification call will return a result code according to the table below.
{|class="wikitable" style="text-align: center;"
|-
!Code
!Description
|-
|INCOMPLETE||Empty proof.
|-
|INCONCLUSIVE||The given proof was consensus-valid but policy-invalid.
|-
|VALID||The proof was valid.
|-
|INVALID||The proof was invalid
|-
|ERROR||An error was encountered
|}
== Signing and Verifying ==
If the challenge consists of an address is in the P2PKH (legacy)
format, sign using the legacy format (further information below).
Otherwise continue as stated below.
For both cases, generate a sighash based on the given scriptPubKey and
message as follows:
# Define the message pre-image as the sequence "Bitcoin Signed
Message:\n" concatenated with the message, encoded in UTF-8 using
Normalization Form Compatibility Decomposition (NFKD)
# Let sighash = sha256(sha256(scriptPubKey || pre-image))
A private key may be used directly to sign a message. In this case,
its P2WPKH bech32 address shall be derived, and used as the input.
=== Signing ===
The signature is generated as follows:
# Derive the private key privkey for the scriptPubKey; FAIL if not VALID
# Generate and return a signature sig with privkey=privkey, sighash=sighash
=== Verifying ===
Verify a proof, given a standard flags value, a script sig, an
optional witness, and a derived sighash as described above.
While omitted below, ERROR is returned if an unforeseen error occurs
at any point in the process. A concrete example of this is if a legacy
proof is given as input to a non-legacy address; the deserialization
of the proof will fail in this case, and this should result in an
ERROR result.
# Verify Script with flags=consensus flags (currently P2SH, DERSIG,
NULLDUMMY, CLTV, CSV, WITNESS), scriptSig=script sig,
scriptPubKey=scriptPubKey, witness=witness, and sighash=sighash
# Return INVALID if verification fails
# Verify Script with flags=standard flags (above plus STRICTENC,
MINIMALDATA, etc.), scriptSig=script sig, scriptPubKey=scriptPubKey,
witness=witness, and sighash=sighash
# Return VALID if verification succeeds, otherwise return INCONCLUSIVE
== Legacy format ==
The legacy format is restricted to the legacy P2PKH address format.
Any other input (i.e. non-P2PKH address format) must be signed using
the new format
