Re: [bitcoin-dev] Interrogating a BIP157 server, BIP158 change proposal
Jim Posen, A few years ago you mentioned roastbeef’s proposal of a P2P message to retrieve all prev-outputs for a given block: 1) Introduce a new P2P message to retrieve all prev-outputs for a given > block (essentially the undo data in Core), and verify the scripts against > the block by executing them. While this permits some forms of input script > malleability (and thus cannot discriminate between all valid and invalid > filters), it restricts what an attacker can do. This was proposed by Laolu > AFAIK, and I believe this is how btcd is proceeding. > I’m trying to find the follow up on this. Was there discussion about it under another name (thread, PR, bip etc)? Apologies if I’m being obtuse and it’s easily found but for the life of me I can’t find any references. Bip157 seems to not make any mention of it. Thanks! Dustin > If anyone has other ideas, I'd love to hear them. > > -jimpo > > [1] > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2018-June/016057.html > > > > On Mon, Feb 4, 2019 at 10:53 AM Tamas Blummer via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > >> TLDR: a change to BIP158 would allow decision on which filter chain is >> correct at lower bandwith use >> >> Assume there is a BIP157 client that learned a filter header chain >> earlier and is now offered an alternate reality by a newly connected BIP157 >> server. >> >> The client notices the alternate reality by routinely asking for filter >> chain checkpoints after connecting to a new BIP157 server. A divergence at >> a checkpoint means that the server disagrees the client's history at or >> before the first diverging checkpoint. The client would then request the >> filter headers between the last matching and first divergent checkpoint, >> and quickly figure which block’s filter is the first that does not match >> previous assumption, and request that filter from the server. >> >> The client downloads the corresponding block, checks that its header fits >> the PoW secured best header chain, re-calculates merkle root of its >> transaction list to know that it is complete and queries the filter to see >> if every output script of every transaction is contained in there, if not >> the server is lying, the case is closed, the server disconnected. >> >> Having all output scripts in the filter does not however guarantee that >> the filter is correct since it might omit input scripts. Inputs scripts are >> not part of the downloaded block, but are in some blocks before that. >> Checking those are out of reach for lightweight client with tools given by >> the current BIP. >> >> A remedy here would be an other filter chain on created and spent >> outpoints as is implemented currently by Murmel. The outpoint filter chain >> must offer a match for every spent output of the block with the divergent >> filter, otherwise the interrogated server is lying since a PoW secured >> block can not spend coins out of nowhere. Doing this check would already >> force the client to download the outpoint filter history up-to the point of >> divergence. Then the client would have to download and PoW check every >> block that shows a match in outpoints until it figures that one of the >> spent outputs has a script that was not in the server’s filter, in which >> case the server is lying. If everything checks out then the previous >> assumption on filter history was incorrect and should be replaced by the >> history offered by the interrogated server. >> >> As you see the interrogation works with this added filter but is highly >> ineffective. A really light client should not be forced to download lots of >> blocks just to uncover a lying filter server. This would actually be an >> easy DoS on light BIP157 clients. >> >> A better solution is a change to BIP158 such that the only filter >> contains created scripts and spent outpoints. It appears to me that this >> would serve well both wallets and interrogation of filter servers well: >> >> Wallets would recognize payments to their addresses by the filter as >> output scripts are included, spends from the wallet would be recognized as >> a wallet already knows outpoints of its previously received coins, so it >> can query the filters for them. >> >> Interrogation of a filter server also simplifies, since the filter of the >> block can be checked entirely against the contents of the same block. The >> decision on filter correctness does not require more bandwith then download >> of a block at the mismatching checkpoint. The client could only be forced >> at max. to download 1/1000 th of the blockchain in addition to the filter >> header history. >> >> Therefore I suggest to change BIP158 to have a base filter, defined as: >> >> A basic filter MUST contain exactly the following items for each >> transaction in a block: >> • Spent outpoints >> • The scriptPubKey of each output, aside from all OP_RETURN >> output scripts. >> >> Tamas Blummer >>
Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
Hi Tim, Hm, so what vectors is this supposed to mitigate? Leaking through the > generated public keys? Anything else? The main thing it’s protecting against is the stealing of your funds by malicious hardware & software. There are some side benefits as well though. - What are you trying to achieve? You seem to describe how you get > from the setup to the goal in four steps but I don't understand what > the setup is or what the goal is. (What's a storage solution?) “Storage solution” is however you’re storing bitcoins today. Could be 12 words on some paper plus a computer running electrum. Could be a Ledger + computer. Point is this technique works regardless of how you’re storing your bitcoin. - "all SW being compromised" do you mean "SW and HW compromised"? Note > that SW and HW are parties in Pieter's writeup, not just abbreviations > for software and hardware. Yeah — if you split the SW party into two, “generator” and “validator” some interesting and useful security properties emerge. - Where are the two stages? You mention four steps. “Generator” and “validator”. The generator creates and passes on receiving addresses and withdrawal transactions (while remaining offline). The validator double checks everything the generator did.. It works best if the validator is written entirely independently of the generator. - Where do you run the external software? On a second SW? Is this the > second stage? Yes - Do you use unhardened derivation? It’s an open ended solution — it would work with a (presumably non-trivial/random) unhardened derivation just fine. - What's a k commitment? It is one of the proposed solutions presented (collected?) by Peter in this thread. As I understand it k is used to generate R in the signature. By committing to some k value the hardware wallet can’t “sneak out” your private key(s) in the R value. Best, Dustin > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Overview of anti-covert-channel signing techniques
Excellent write up, thanks for putting it together. On Tue, Mar 3, 2020 at 1:47 PM Pieter Wuille wrote: > When both the HW and the SW are compromised, clearly no security is > possible, > as all entities are controlled by the same party in that case. > While all SW being compromised can’t be stopped, splitting the SW over two stages can dramatically increase your security if both HW & SW are compromised. You can do that by: 1) When you setup your storage solution (whatever it may be), export the xpub(s) and verify the receiving addresses match xpubs with external software before receiving. 2) Generate and export withdrawal transactions offline 3) Verify transactions against the same xpub(s) using external software 4) Upload transactions This mitigates, I believe, all leak vectors besides k/R hacking and prechosen entropy. I made an external tool to just that here: https://github.com/koinkeep/gatekeeper Would love to add k commitments when (if?) we settle on best practices for it. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers
Stepan have you spent any time considering a scheme that could involve HD
keys, preregistering n (ie. 1000) preimages, or something similar to reduce
the number of rounds at time of signing?
Would a zero knowledge solution allow for a reduction in rounds?
On Wed, Feb 26, 2020 at 7:13 PM Stepan Snigirev via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> This topic appeared in the list a few times so I would like to discuss it
> in more detail and maybe push forward to standardization.
>
> We have to accept that any hardware wallet or an air-gapped computer we
> use to sign transactions can be compromised. It may happen via a supply
> chain attack or malicious firmware update.
>
> If the signer is isolated (faraday cage, airgap and so on), it still can
> leak private keys to the outside world by choosing nonces for signatures in
> a funny way such that the attacker can calculate our private keys. Back in
> the days, I wrote a small post [1] and a proof-of-concept demo [2] of this
> attack.
>
> Deterministic nonce generation can be verified only if we have private
> keys somewhere else. It doubles the attack surface - now we need to
> maintain two independent signers from different vendors that use the same
> private key and the same deterministic algorithm for a nonce generation. In
> addition to that, as Pieter mentioned in the Schnorr-BIP, deterministic
> nonces are vulnerable to glitch attacks [3].
>
> A simple way to fix it is by forcing the signer to use additional entropy
> from the host. This protocol takes away the privilege of picking nonce from
> the signer and doesn't require any secret material outside the signer.
>
> I suggest the following implementation of the protocol for signing a
> message `m`:
>
> 1. Host picks a random number `n` and sends its hash together with the
> message `m` to the signer.
> 2. Signer computes a nonce `k` it wants to use for signing. It can be
> either a deterministic scheme or using RNG. Signer commits to the chosen
> nonce by sending the corresponding point `R=kG` to the host.
> 3. Host sends the preimage `n` to the signer
> 4. Signer tweaks the nonce by this number `k'=k+n`, signs the message and
> sends back the signature (R',s)
> 5. Host verifies that the public point in the signature is tweaked by n:
> `R'==R+nG`
>
> ASCII-art:
>
>HostUntrusted signer
> 1. Pick random n --- sha256(n),m --> calculate nonce k
> 2. <-- R=kG -- commit to k
> 3. Send preimage n ---> sign with nonce k'=k+n
> 4. Verify R'==R+nG <--- sig --
>
> I believe this protocol solves the problem. A drawback of this scheme is
> that the number of communication rounds doubles, so it might be pretty
> inconvenient for air-gapped remotely located signers.
>
> I also suggest the following extensions that might be helpful for certain
> use-cases
>
> # Extensions
>
> ## Multiple hosts
>
> There are some use-cases where multiple hosts are involved in the setup
> and all hosts don't trust each other and the signer. So all of them want to
> give extra entropy to the signer and verify that it was included. At the
> moment I have exactly this scenario - our main MCU doesn't trust the
> proprietary closed-source secure element, and the computer doesn't trust
> the whole hardware wallet. We need a way to convince both of them that
> their entropy was used in the nonce.
>
> It can be solved by concatenating hashes and preimages:
>
> Host1 --- h(n1) --> Host 2 -- h(n1) h(n2) --> Signer
> <--- R+n2 G -<--- R ---
> --- n1 ->-- n1 n2 > sign with k''=k+n1+n2
> Ver: R''==R'+n1 G Ver: R''==R+n2 G + n1 G
>
> In this case, the first host doesn't even notice that the second host was
> also using this protocol and mixing in the entropy. And the signer only
> needs to add one extra number to the nonce.
>
> ## Stateless random signer
>
> If the signer wants to generate a nonce non-deterministically but doesn't
> have an ability to store a generated nonce it may send back to the host
> some meta-information that would help it to re-generate the same nonce
> later. It can be for example additional random data used in a deterministic
> scheme, either encrypted and authenticated or just as a plain text (I am
> more a fan of encrypted though).
>
> Generally, the host shouldn't care what this data is about - he just
> stores the data between rounds and sends it back to the signer with the
> next round.
>
> # Implementation for PSBT
>
> We can either use proprietary fields [4] or define key-value pairs and add
> them to the BIP-174. Depends if anyone else is interested in using this
> protocol or not.
>
> I would suggest the following key-value per-input pairs assuming multiple
> hosts want to mix in external entropy:
>
> 1. Key: {PSBT_IN_EXT_NONCE_HASH}|{pubkey}, Value:
> {sha256(n1)}|{sha256(n2)}|...
> 2. Key: {PSBT_IN_NONCE_COMMITMENT}|{pubkey}, Value:
Re: [bitcoin-dev] Nonce blinding protocol for hardware wallets and airgapped signers
+1 love that progress is being made on this. Excited to implement it once it’s ready. Would love if things like the incrementing number were included in the standard as well. Cheers! On Fri, Feb 28, 2020 at 9:51 AM Marko via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Thanks for starting this initiative; it has been a long standing goal of > mine to implement and release this protocol. Your blog post on the topic > actually inspired me to pick up this work again a few months ago. > > Jonas Nick has implemented the protocol in the secp256k1 library for > Schnorr sigs here: https://github.com/bitcoin-core/secp256k1/pull/590 > > I have backported the same scheme to ECDSA in the secp256k1 library > here, so it can be used also for current transactions: > > https://github.com/bitcoin-core/secp256k1/pull/669 > > I also made proof of concepts for the BitBox02 hw wallet firmware and > BitBoxApp wallet to verify that the protocol also works well in practice. > > The actual scheme used in those implementations is a generalized > sign-to-contract scheme, where the final nonce is computed as `k' = k + > H(k*G, n)` instead of `k'=k+n`, but otherwise it works mostly the same > for the anti nonce covert channel protocol. I suggest to use this scheme > in PSBT as well. > > > We can either use proprietary fields [4] or define key-value pairs and > add > > them to the BIP-174. Depends if anyone else is interested in using this > > protocol or not. > > I'd definitely be interested in seeing widespread support for this, and > standardizing it would help with that. > > With PSBT used with an air-gapped signer, there is increased danger in > implementing the protocol wrongly by relying on the contents of the PSBT > alone in the final verification step of a signature. The PSBT must be > verified carefully against state stored by the host for the PSBT. > Otherwise the signer can for example change or pre-fill the relevant > NONCE fields and leak the private keys anyway. Is there a current best > practice for how a PSBT can be identified by the host to store/retrieve > the state? > > Are there other examples in PSBT where the host can't trust the contents > of the PSBT the signer returns (except of course for the parts the user > can verify themselves, like recipients, amounts, etc.)? In any case, > guidelines or conventions on how to avoid the pitfalls would be good. > > Best, Marko > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Bitcoin Core to disable Bloom-based Filtering by default
Has someone built an analysis of how much extra bandwidth CFB uses over bloom filters? Obviously an active merchant in an impoverished country paying data rates per MB will never be able to afford CFB — so those people are being cut out of Bitcoin entirely. I suppose the plan is they will rely on custodial services now? But if someone receives say, 5 tx a day, how much more bandwidth precisely will CFB require over bloom? On Mon, Jul 22, 2019 at 8:10 AM Tom Harding via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > On 7/20/19 10:46 AM, Matt Corallo via bitcoin-dev wrote: > > (less trustful and privacy-violating) alternative > > over the coming years. > > The same paper that established the 'privacy-violating' conventional > wisdom presented mitigations which have seen little exploration. > https://eprint.iacr.org/2014/763.pdf > > Meanwhile we have custodial LN, the L-BTC altcoin and, today, a massive > push into infrastructure for fully custodial accounts. > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
I’ve solved the same problem in a different way. 1) Submit a transaction 2) Collect all reject messages (that have matching txid in the reject data) 3) Wait 16 seconds after first error message received (chosen semirandomly from trial and error) before processing errors 4) Wait for our txid to be submitted back to us through the mempool, if we get it notify success and delete all pending error events 5) Signal failure with the given reject code if present (after the 16 seconds have elapsed) 6) If no error or success after 20 seconds, signal timeout failure This works fairly well in testing. Newer transaction types seem to generate reject codes 100% of the time (from at least one node when sending to 4 nodes) so this culling / time delay approach is essentially required. On a related note: One issue is that RBF attempts with too small a fee and accidental double spends (with enough fee for 1 tx but not a RBF) both generate the same reject code: not enough fee. A new reject code for RBF based too small of fee would definitely make for a better user experience as I’ve seen this exact problem create confusion for users. Removing reject codes would make for a much worse user experience. “Your tx failed and we have no idea why” would be the only message and it would require waiting for a full timeout. On Wed, Mar 13, 2019 at 3:16 PM Oscar Guindzberg via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > > I'd like to better understand this, but it would be easier to just > > read the code than ask a bunch of questions. I tried looking for the > > handling of reject messages in Android Bitcoin Wallet and BitcoinJ > > and didn't really find and handling other than logging exceptions. > > Would you mind giving me a couple pointers to where in the code > > they're handled? > > > https://github.com/bitcoinj/bitcoinj/blob/master/core/src/main/java/org/bitcoinj/core/TransactionBroadcast.java#L93-L108 > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great Consensus Cleanup
What about putting it in a deprecated state for some time. Adjust the transaction weight so using the op code is more expensive (10x, 20x?) and get the word out that it will be removed in the future. You could even have nodes send a reject code with the message “OP_CODESEPARATOR is depcrecated.” On Sun, Mar 10, 2019 at 7:55 AM LORD HIS EXCELLENCY JAMES HRMH via bitcoin-dev wrote: > > Opinion: Lock in a blockheight to get rid of it 10 years in the future. > Use it as press that Bitcoin is going to lose $1,000,000 if some mystery > person does not put their transaction through by then, try for global > presses. Use the opportunity to get rid of it while you are able. Once > gazetted anything is public knowledge. > > Regards, > LORD HIS EXCELLENCY JAMES HRMH > > -- > *From:* bitcoin-dev-boun...@lists.linuxfoundation.org < > bitcoin-dev-boun...@lists.linuxfoundation.org> on behalf of Matt Corallo > via bitcoin-dev > *Sent:* Saturday, 9 March 2019 7:14 AM > *To:* Sjors Provoost > *Cc:* Bitcoin Protocol Discussion > *Subject:* Re: [bitcoin-dev] OP_CODESEPARATOR Re: BIP Proposal: The Great > Consensus Cleanup > > Aside from the complexity issues here, note that for a user to be > adversely affect, they probably have to have pre-signed lock-timed > transactions. Otherwise, in the crazy case that such a user exists, they > should have no problem claiming the funds before activation of a soft-fork > (and just switching to the swgwit equivalent, or some other equivalent > scheme). Thus, adding additional restrictions like tx size limits will > equally break txn. > > > On Mar 8, 2019, at 14:12, Sjors Provoost wrote: > > > > > >> (1) It has been well documented again and again that there is desire to > remove OP_CODESEPARATOR, (2) it is well-documented OP_CODESEPARATOR in > non-segwit scripts represents a rather significant vulnerability in Bitcoin > today, and (3) lots of effort has gone into attempting to find practical > use-cases for OP_CODESEPARATOR's specific construction, with no successes > as of yet. I strongly, strongly disagree that the highly-unlikely remote > possibility that someone created something before which could be rendered > unspendable is sufficient reason to not fix a vulnerability in Bitcoin > today. > >> > >>> I suggest an alternative whereby the execution of OP_CODESEPARATOR > increases the transactions weight suitably as to temper the vulnerability > caused by it. Alternatively there could be some sort of limit (maybe 1) on > the maximum number of OP_CODESEPARATORs allowed to be executed per script, > but that would require an argument as to why exceeding that limit isn't > reasonable. > >> > >> You could equally argue, however, that any such limit could render some > moderately-large transaction unspendable, so I'm somewhat skeptical of this > argument. Note that OP_CODESEPARATOR is non-standard, so getting them mined > is rather difficult in any case. > > > > Although I'm not a fan of extra complicity, just to explore these two > ideas a bit further. > > > > What if such a transaction: > > > > 1. must have one input; and > > 2. must be smaller than 400 vbytes; and > > 3. must spend from a UTXO older than fork activation > > > > Adding such a contextual check seems rather painful, perhaps comparable > to nLockTime. Anything more specific than the above, e.g. counting the > number of OP_CODESEPARATOR calls, seems like guess work. > > > > Transaction weight currently doesn't consider OP codes, it only > considers if bytes are part of the witness. Changing that to something more > akin to Ethereums gas pricing sounds too complicated to even consider. > > > > > > I would also like to believe that whoever went through the trouble of > using OP_CODESEPARATOR reads this list. > > > > Sjors > > > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Removal of reject network messages from Bitcoin Core (BIP61)
The reject message is helpful for figuring out why a tx was rejected.
It’s not useful for determining success, yes. Particularly when doing
segwit / newer types of tx’s as there’s always one or more pesky nodes who
still don’t support it and send a reject message for perfectly good tx’s.
But after a delay where you haven’t seen your tx propagated on the network,
it’s useful to know *why* it failed.
What would be nice is actually expanding this error message. Currently with
RBF tx’s “fee too small” is sent for both original transactions as well as
replacement transactions. So a bug accidentally sending spent txos
(currently in mempool) says “fee too small” instead of something more
appropriate like “fee too small to supersede existing unconfirmed
transaction.”
On Tue, Mar 5, 2019 at 7:26 PM Marco Falke via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Bitcoin Core may send "reject" messages as response to "tx", "block" or
> "version" messages from a network peer when the message could not be
> accepted.
>
> This feature is toggled by the `-enablebip61` command line option and has
> been
> disabled by default since Bitcoin Core version 0.18.0 (not yet released as
> of
> time of writing). Nodes on the network can not generally be trusted to send
> valid ("reject") messages, so this should only ever be used when connected
> to a
> trusted node. At this time, I am not aware of any software that requires
> this
> feature, and I would like to remove if from Bitcoin Core to make the
> codebase
> slimmer, easier to understand and maintain. Let us know if your application
> relies on this feature and you can not use any of the recommended
> alternatives:
>
> * Testing or debugging of implementations of the Bitcoin P2P network
> protocol
> should be done by inspecting the log messages that are produced by a
> recent
> version of Bitcoin Core. Bitcoin Core logs debug messages
> (`-debug=`) to a stream (`-printtoconsole`) or to a file
> (`-debuglogfile=`).
>
> * Testing the validity of a block can be achieved by specific RPCs:
> - `submitblock`
> - `getblocktemplate` with `'mode'` set to `'proposal'` for blocks with
> potentially invalid POW
>
> * Testing the validity of a transaction can be achieved by specific RPCs:
> - `sendrawtransaction`
> - `testmempoolaccept`
>
> * Wallets should not use the absence of "reject" messages to indicate a
> transaction has propagated the network, nor should wallets use "reject"
> messages to set transaction fees. Wallets should rather use fee
> estimation
> to determine transaction fees and set replace-by-fee if desired. Thus,
> they
> could wait until the transaction has confirmed (taking into account the
> fee
> target they set (compare the RPC `estimatesmartfee`)) or listen for the
> transaction announcement by other network peers to check for propagation.
>
> I propose to remove "reject" messages from Bitcoin Core 0.19.0 unless
> there are
> valid concerns about its removal.
>
> Marco
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
How could you prove the private key is in the burning transaction? On Tue, Jan 22, 2019 at 11:56 AM Satoshin via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > This could could be a viable option. I think this is the right approach. > > Any downside to this and how much does this add to the blockweight if > anything at all. > > Anonymouse > > > On Jan 22, 2019, at 4:19 AM, ZmnSCPxj via bitcoin-dev < > bitcoin-dev@lists.linuxfoundation.org> wrote: > > > > Good Morning Matt, > > > >> ### ZmnSCPxj, > >> > >> I'm intrigued by this mechanism of using fixed R values to prevent > multiple signatures, but how do we derive the R values in a way where they > are > > unique for each blockheight but still can be used to create signatures > or verify? > > > > One possibility is to derive `R` using standard hierarchical derivation. > > Then require that the staking pubkey be revealed to the sidechain > network as actually being `staking_pubkey = P + hash(P || parent_R) * G` > (possibly with some trivial protection against Taproot). > > To sign for a blockheight `h`, you must use your public key `P` and the > specific `R` we get from hierarchical derivation from `parent_R` and the > blockheight as index. > > > > > > > > Regards, > > ZmnSCPxj > > ___ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
Re: [bitcoin-dev] Proof-of-Stake Bitcoin Sidechains
Wouldn’t a revealed private key for time locked funds create a race to spend? I imagine miners who are paying attention would have the advantage but it would still just be a race. Would be nice to have the funds destroyed or sent somewhere specific. Like if somehow the revealed key was actually itself a presigned transaction. Or perhaps a 32 byte piece of a tx needed to complete it. On Tue, Jan 22, 2019 at 6:14 AM ZmnSCPxj via bitcoin-dev < bitcoin-dev@lists.linuxfoundation.org> wrote: > Good Morning Matt, > > > ### ZmnSCPxj, > > > > I'm intrigued by this mechanism of using fixed R values to prevent > multiple signatures, but how do we derive the R values in a way where they > are > unique for each blockheight but still can be used to create signatures or > verify? > > One possibility is to derive `R` using standard hierarchical derivation. > Then require that the staking pubkey be revealed to the sidechain network > as actually being `staking_pubkey = P + hash(P || parent_R) * G` (possibly > with some trivial protection against Taproot). > To sign for a blockheight `h`, you must use your public key `P` and the > specific `R` we get from hierarchical derivation from `parent_R` and the > blockheight as index. > > > > Regards, > ZmnSCPxj > ___ > bitcoin-dev mailing list > bitcoin-dev@lists.linuxfoundation.org > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
