š
Original date posted:2016-05-22
š Original message:nack -- not secure.
OP_PRANDOM also adds extra validation overhead on a block potentially
composed of transactions all spending an OP_PRANDOM output from all
different blocks.
I do agree that random numbers are highly desirable though.
I think it would be much better for these use cases to add OP_XOR back and
then use something like Blum's fair coin-flipping over the phone. OP_XOR
may have other uses too.
I have a write-up from a while back which does Blum's without OP_XOR using
OP_SIZE for off-chain probabilistic payments if anyone is interested. No
fork needed, but of course it is more limited and broken in a number of
ways.
(sorry to those of you seeing this twice, my first email bounced the list)
--
@JeremyRubin <https://twitter.com/JeremyRubin>;
<https://twitter.com/JeremyRubin>;
On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Matthew,
>
> You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements
> Project. It aims to achieve a similar goal.
>
> Code is in the `alpha` branch [2].
>
> [1]: https://www.elementsproject.org/elements/opcodes/
> [2]:
> https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305
>
> On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> Good point, to be honest. Maybe there's a better way to combine the block
>> hashes like taking the first N bits from each block hash to produce a
>> single number but the direction that this is going in doesn't seem ideal.
>>
>> I just asked a friend about this problem and he mentioned using the hash
>> of the proof of work hash as part of the number so you have to throw away a
>> valid POW if it doesn't give you the hash you want. I suppose its possible
>> to make it infinitely expensive to manipulate the number but I can't think
>> of anything better than that for now.
>>
>> I need to sleep on this for now but let me know if anyone has any better
>> ideas.
>>
>>
>>
>> On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
>>
>>> Using the hash of multiple blocks does not make it any safer. The miner
>>> of the last block always determines the results, by knowing the hashes of
>>> all previous blocks.
>>>
>>>
>>> == Security
>>>
>>> Pay-to-script-hash can be used to protect the details of contracts that
>>> use OP_PRANDOM from the prying eyes of miners. However, since there is also
>>> a non-zero risk that a participant in a contract may attempt to bribe a
>>> miner the inclusion of multiple block hashes as a source of randomness is a
>>> must. Every miner would effectively need to be bribed to ensure control
>>> over the results of the random numbers, which is already very unlikely. The
>>> risk approaches zero as N goes up.
>>>
>>>
>>>
>> _______________________________________________
>> bitcoin-dev mailing list
>> bitcoin-dev at lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160522/22a4184e/attachment.html>;
Jeremy [ARCHIVE] /
npub1q8ā¦8qwta
2023-06-07 17:50:55
in reply to nevent1qā¦f8np
Author Public Key
npub1q86n5vtxkwerzwfqza3hwls8pl8764244464talfqy2vpj0qaz6q38qwtaPublished at
2023-06-07 17:50:55Event JSON
{
"id": "d771cb53fbb141adcb5b778357c60b113cbdf1e345c1bc6cd0ca979a70aac6fc",
"pubkey": "01f53a3166b3b23139201763777e070fcfed5555ad7555f7e90114c0c9e0e8b4",
"created_at": 1686160255,
"kind": 1,
"tags": [
[
"e",
"bfc4a6cf67c142fa452617fc9aee29b5337b5198d13bd22094049bf77aa4fad0",
"",
"root"
],
[
"e",
"7f966e84672ae03585b228f93d1f4903f1032a5cce985777d04e70a85db923df",
"",
"reply"
],
[
"p",
"092601597d30aa94c18773e5c3ebb3d83699778aa298e6d633db9e06da261ed7"
]
],
"content": "š
Original date posted:2016-05-22\nš Original message:nack -- not secure.\n\nOP_PRANDOM also adds extra validation overhead on a block potentially\ncomposed of transactions all spending an OP_PRANDOM output from all\ndifferent blocks.\n\nI do agree that random numbers are highly desirable though.\n\nI think it would be much better for these use cases to add OP_XOR back and\nthen use something like Blum's fair coin-flipping over the phone. OP_XOR\nmay have other uses too.\n\nI have a write-up from a while back which does Blum's without OP_XOR using\nOP_SIZE for off-chain probabilistic payments if anyone is interested. No\nfork needed, but of course it is more limited and broken in a number of\nways.\n\n(sorry to those of you seeing this twice, my first email bounced the list)\n\n--\n@JeremyRubin \u003chttps://twitter.com/JeremyRubin\u003e\n\u003chttps://twitter.com/JeremyRubin\u003e\n\nOn Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev \u003c\nbitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\n\u003e Matthew,\n\u003e\n\u003e You should take a look at OP_DETERMINISTICRANDOM [1] from the Elements\n\u003e Project. It aims to achieve a similar goal.\n\u003e\n\u003e Code is in the `alpha` branch [2].\n\u003e\n\u003e [1]: https://www.elementsproject.org/elements/opcodes/\n\u003e [2]:\n\u003e https://github.com/ElementsProject/elements/blob/alpha/src/script/interpreter.cpp#L1252-L1305\n\u003e\n\u003e On Fri, May 20, 2016 at 8:29 AM Matthew Roberts via bitcoin-dev \u003c\n\u003e bitcoin-dev at lists.linuxfoundation.org\u003e wrote:\n\u003e\n\u003e\u003e Good point, to be honest. Maybe there's a better way to combine the block\n\u003e\u003e hashes like taking the first N bits from each block hash to produce a\n\u003e\u003e single number but the direction that this is going in doesn't seem ideal.\n\u003e\u003e\n\u003e\u003e I just asked a friend about this problem and he mentioned using the hash\n\u003e\u003e of the proof of work hash as part of the number so you have to throw away a\n\u003e\u003e valid POW if it doesn't give you the hash you want. I suppose its possible\n\u003e\u003e to make it infinitely expensive to manipulate the number but I can't think\n\u003e\u003e of anything better than that for now.\n\u003e\u003e\n\u003e\u003e I need to sleep on this for now but let me know if anyone has any better\n\u003e\u003e ideas.\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e\n\u003e\u003e On Fri, May 20, 2016 at 6:34 AM, Johnson Lau \u003cjl2012 at xbt.hk\u003e wrote:\n\u003e\u003e\n\u003e\u003e\u003e Using the hash of multiple blocks does not make it any safer. The miner\n\u003e\u003e\u003e of the last block always determines the results, by knowing the hashes of\n\u003e\u003e\u003e all previous blocks.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e == Security\n\u003e\u003e\u003e\n\u003e\u003e\u003e Pay-to-script-hash can be used to protect the details of contracts that\n\u003e\u003e\u003e use OP_PRANDOM from the prying eyes of miners. However, since there is also\n\u003e\u003e\u003e a non-zero risk that a participant in a contract may attempt to bribe a\n\u003e\u003e\u003e miner the inclusion of multiple block hashes as a source of randomness is a\n\u003e\u003e\u003e must. Every miner would effectively need to be bribed to ensure control\n\u003e\u003e\u003e over the results of the random numbers, which is already very unlikely. The\n\u003e\u003e\u003e risk approaches zero as N goes up.\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e\u003e\n\u003e\u003e _______________________________________________\n\u003e\u003e bitcoin-dev mailing list\n\u003e\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\u003e\n\u003e\n\u003e _______________________________________________\n\u003e bitcoin-dev mailing list\n\u003e bitcoin-dev at lists.linuxfoundation.org\n\u003e https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev\n\u003e\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160522/22a4184e/attachment.html\u003e",
"sig": "c3719ac33c578c44de53bbb6496b37788a30117a011eb2ca730b1bc629469756c674d9bc8a35dd33c5aadcb8da954ca9bc2112fbb15dfcfcbfcc4d23c25cd1f9"
}