@gmaxwell, thanks for the explanation of the holdup issue and how to work around it with secret sharing. I also appreciate the idea of hashing private keys, thus exploiting participants’ self-interested need to keep them absolutely secret early in the protocol.
In the interim between my above posts (2018-02-08), I was pondering another idea. I frankly don’t know whether it’s a sound idea, or half-baked; so I kept it up my sleeve whilst mulling whether it’s even worth a mention. Due to a sudden interest I have in provably fair gambling, I will now give it a shot. Who knows—perhaps I may want to found my own gambling site, and make of myself Bitcoin thousandaire.
The hash the last block's ID approach can be biased by miners.
I’m usually a critic of Satoshi’s use of double-hashes. But here, I think it can really come in handy:
Use the inner hash as the source of a public pseudorandom number which is infeasible to influence or predict in advance.Zeroth iteration of the idea: Breakage requires a partial preimage attack on the input to another partial preimage attack. My gut tells me that this is one of those ideas which is either ingenious, or trivially stupid.
(Aside, is
double-SHA256 fully baked into silicon in available current-generation mining hardware? Or can it be programmed to return both the inner and outer hashes? If the former, then add the cost of making your own ASICs in calculating the real-world cost of attack.)
If that does not suffice, next iteration: Hash (or HMAC) the inner hash together with a different predefined nonce such as a counter.
E.g., for the hash at block height
h, use: HMAC_SHA256("I always win!" || (uint32_t)
h, block_inner_hash).
Or hash the inner hash together with pseudorandom material from a different source, such as a popular altcoin blockchain with a different PoW.
E.g., hash this intermediate state from a Bitcoin double-hash together with some intermediate state from an Equihash.
Aside: Of course, the inner hash can be kept secret by the generating miner whilst its commitment (the outer hash) is baked ever-deeper into the blockchain. This can probably be useful for some other purpose.
I always approach such ideas by placing myself in the role of an attacker. For simple use of the block hash as suggested by others, I understand that if the attacker wanted to influence
m bits of the hash in addition to the
n bits of needed zeroes, the cost of the attack is 2
m+n hashes. I posit that to influence the inner and outer hashes simultaneously (“zeroth iteration”), the cost would again be 2
m * 2
n = 2
m+n hashes. That is why I am trying to tie the inner hash to something else, and/or use the inner hash as an input for another hash which also depends on other independent inputs. I seek some way to substantially raise the cost above 2
m+n hashes.
There may be some means to exploit the irreversibility of the outer hash, which I have not yet thought of.The goal seems obvious, but I must state it clearly for the sake of clear argument: How could it be made infeasible for the miner to influence the result whilst also managing to create any Bitcoin blocks at all? (Much less without impractically high risk of orphans?) I know I did plenty of handwaving above. Ultimately, I’d seek to pin it down to something with a rigorously characterized 128-bit security level (or higher).
N.b., I’d be as fascinated to see this idea attacked and shot down as I would be to find out that it’s a brilliant insight.
Thanks.
(Notice: I independently conceived this idea on 2018-02-08; and I am first publicly disclosing it today, as of the timestamp on this post. I will promptly archive-snapshot this post, so as to provide at least a modicum of prior art evidence in case it’s a good idea and some idiot runs to file for a patent on it.)
