Re: [bitcoin-dev] Taproot proposal
Good morning list, > > Can this "unknown discrete logarithm" be made provably unknown, so all > > signers are assured of this property? Bonus points if the outside world > > can't tell. The exact mechanism could be outside the scope of the BIP, but > > knowing that it's possible is useful. > > Yes, that's a TODO that's left in the draft, but this is absolutely > possible (using a hash-to-curve operation). As ZmnSCPxj already > suggested, there can even be a fixed known constant you can use for > this. However, you get better privacy by taking this fixed known > constant (call it C) and using as internal key a blinded version of it > (C+rG, for some random value r, and G the normal secp256k1 generator); > as long as the DL between G and C is unknown, this is safe (and does > not reveal to the world that in fact no key-path was permitted when > spending). Gregory Maxwell commented some days ago: > 2019-05-11T23:35:02 sipa: also someone might want to point out to > ZmnSCPxj that his scheme for getting a NUMS point is insecure (it must also > commit to G because we don't know how G was generated) I am assuming that gmax is referring to my description of the "hash-to-point" or "hash-to-curve" operation. A little more research shows this: https://crypto.stackexchange.com/a/25603 >From the above, it seems the method that real cryptographers use is: 1. Generate some random data d. 2. Get x = h(G | d) where G is the existing generator for secp256k1. 3. Find a point on secp256k1 with X coordinate x. 4. If not found, go to 1. In any case, I am almost sure that for every case where the "everyone agrees" path is unwanted in a taproot address, the simple "put your own pubkey lock on the door and throw away the privkey" technique would work without requiring a NUMS point: the same taproot assumption should also work here. But generation of a NUMS point might be of independent interest in any case (e.g. setting up Pedersen commitments). Regards, ZmnSCPxj ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
[bitcoin-dev] Code not following proof of security
If MAX_FUTURE_BLOCK_TIME in chain.h is set smaller than DEFAULT_MAX_TIME_ADJUSTMENT in timedata.h, the POW security can be undermined by a 33% Sybil attack on the nodes. Blocks with accurate timestamps would be rejected which allows various attacks. Code should reflect a proof of security, so it should be coded as DEFAULT_MAX_TIME_ADJUSTMENT = MAX_FUTURE_BLOCK_TIME / 2 (or sufficiently commented) otherwise future developers could make a change that hurts security. "Unintended consequences due to how disparate code interacts" is the result of code not following a proof of security. I came across this while trying to "derive" POW security from within Lamport's 1982 framework. The problem is that POW security requires clock synchronization. But using median of network time for it is a consensus mechanism that is subject to Byzantine attacks. So POW requires an absolute bound on time (enforced by an oracle) that is at least as stringent as the allowed timestamp variation. The rule to revert to node time if network time is >70 minutes off is the real bound that honest nodes can impose unilaterally, limiting the potential damage of consensus (if MAX_FUTURE_BLOCK_TIME is not too small). This fail-safe uses node operators as the oracle, who can all approximately agree as to what time it is without asking each other. A >50% Sybil attack on nodes fails because an honest new node joining can unilaterally reject the chain if the current timestamp is not realistic. Cryptonote appears to have done away with network time without ill effect. The only other option to "the node operator is the oracle" is to assume all internal clocks have a max drift, but this would disconnect timestamps from real time to the extent of that drift (if I'm reading Halpern, etc 1984 IBM correctly). I'm assuming Mike Hearn was wrong in saying the centralization of NTP (or GPS) is acceptable: https://bitcointalk.org/index.php?topic=10241.msg148084#msg148084 This affects coins who reduced MAX_FUTURE_BLOCK_TIME without either removing the time consensus mechanism or reducing the DEFAULT_MAX_TIME_ADJUSTMENT. Many have done this in order to have faster responding difficulty algorithms, otherwise a large MAX_FUTURE_BLOCK_TIME allows a sizable manipulation of difficulty. Therefore, MAX_FUTURE_BLOCK_TIME should itself should be a function of the size of the difficulty window for proof of security (instead of a constant). I suspect more constants = less proof of security. For example MFBT = WindowTimespan / 10 would limit timestamp manipulation to 10% per window. ___ bitcoin-dev mailing list bitcoin-dev@lists.linuxfoundation.org https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
