From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 995EB8ED for ; Sun, 22 May 2016 13:46:19 +0000 (UTC) X-Greylist: delayed 00:15:01 by SQLgrey-1.7.6 Received: from dmz-mailsec-scanner-6.mit.edu (dmz-mailsec-scanner-6.mit.edu [18.7.68.35]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BC1E3FE for ; Sun, 22 May 2016 13:46:18 +0000 (UTC) X-AuditID: 12074423-1abff70000006b08-01-5741b4a36407 Received: from mailhub-auth-4.mit.edu ( [18.7.62.39]) (using TLS with cipher DHE-RSA-AES256-SHA (256/256 bits)) (Client did not present a certificate) by (Symantec Messaging Gateway) with SMTP id DB.1F.27400.3A4B1475; Sun, 22 May 2016 09:31:15 -0400 (EDT) Received: from outgoing.mit.edu (outgoing-auth-1.mit.edu [18.9.28.11]) by mailhub-auth-4.mit.edu (8.13.8/8.9.2) with ESMTP id u4MDVEG9017056 for ; Sun, 22 May 2016 09:31:15 -0400 Received: from mail-io0-f176.google.com (mail-io0-f176.google.com [209.85.223.176]) (authenticated bits=0) (User authenticated as jlrubin@ATHENA.MIT.EDU) by outgoing.mit.edu (8.13.8/8.12.4) with ESMTP id u4MDVDus012626 (version=TLSv1/SSLv3 cipher=RC4-SHA bits=128 verify=NOT) for ; Sun, 22 May 2016 09:31:14 -0400 Received: by mail-io0-f176.google.com with SMTP id t40so85553025ioi.0 for ; Sun, 22 May 2016 06:31:14 -0700 (PDT) X-Gm-Message-State: AOPr4FX6vtrPjU4+scnrSWLVyplYKsb5DU0emtOIQzhNIignsm9Wu7ujh36hKRijXKViU0FZQUy7yIA8QjrfvQ== X-Received: by 10.107.11.18 with SMTP id v18mr7368184ioi.184.1463923873144; Sun, 22 May 2016 06:31:13 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.42.69 with HTTP; Sun, 22 May 2016 06:30:53 -0700 (PDT) In-Reply-To: References: From: Jeremy Date: Sun, 22 May 2016 09:30:53 -0400 X-Gmail-Original-Message-ID: Message-ID: To: Eric Martindale , Bitcoin Protocol Discussion Content-Type: multipart/alternative; boundary=001a113f8d266ff9f505336e56d8 X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFlrJKsWRmVeSWpSXmKPExsUixG6nrrt4i2O4QftLDYum17YOjB6/f0xm DGCM4rJJSc3JLEst0rdL4MpoX1FfsM2j4uvHb2wNjEftuhg5OSQETCT+/LnDDGILCbQxSWyb otvFyAVk32WUOD3xHSuE85FJomv6JWYIZyGjxKFZ79gg2nMkPk95zghhF0vc3LKMFcTmFRCU ODnzCQvEWE+J/k0vmUBsToFAiU/r50IN6mGSWPd9FlCCg4NNQE7iwy9TkBoWAVWJNWtfM0HM TJR4tnIHG8TMAIn+q2/AyoUFtCQ6luuDmCIC1RIte1VATGYBV4kl64QhTC+J8y+yJjAKz0Jy ziyEDISpLrF+nhBIBbOAmsTtbVfZIWxtiWULXzMvYGRdxSibklulm5uYmVOcmqxbnJyYl5da pGuml5tZopeaUrqJERz+Lso7GF/2eR9iFOBgVOLh3XHHIVyINbGsuDL3EKMkB5OSKG9qt324 EF9SfkplRmJxRnxRaU5q8SFGCQ5mJRHeVxscw4V4UxIrq1KL8mFS0hwsSuK8jAwMDEIC6Ykl qdmpqQWpRTBZGQ4OJQne85uBGgWLUtNTK9Iyc0oQ0kwcnCDDeYCGq2wBGV5ckJhbnJkOkT/F aMyx5fe1tUwc26beW8skxJKXn5cqJc6bATJOAKQ0ozQPbhoohV0Mvb/hFaM40HPCvI0gVTzA 9Ac37xXQKiagVQ+lHUBWlSQipKQaGHVLK/azzHiY5mz7YEXxwaVcLBoq11812bkwGN78aBan m3nzmefWcw3VdmIK2T/yV+hvTO5ulX0ZPSOVt9r9K/vzZ5lv1yjkMwrsNRKzWzlntsA8rbm1 G76zTnuffI67Z//S8z9cXydtmmOrwDDl5vwHjO6+ulIxU7SsJUIzdSfL1zR8Pu+QoMRSnJFo qMVcVJwIAD6iEyo8AwAA X-Spam-Status: No, score=-5.6 required=5.0 tests=BAYES_00,HTML_MESSAGE, RCVD_IN_DNSWL_MED,RP_MATCHES_RCVD autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org Subject: Re: [bitcoin-dev] BIP: OP_PRANDOM X-BeenThere: bitcoin-dev@lists.linuxfoundation.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Bitcoin Protocol Discussion List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 22 May 2016 13:46:19 -0000 --001a113f8d266ff9f505336e56d8 Content-Type: text/plain; charset=UTF-8 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 On Fri, May 20, 2016 at 2:32 PM, Eric Martindale via bitcoin-dev < bitcoin-dev@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@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 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@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 > > --001a113f8d266ff9f505336e56d8 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
nack -- not secure.=C2=A0
OP_PRANDOM also adds extra validation overhead on a block potentially com= posed of transactions all spending an OP_PRANDOM output from all different = blocks.

I do agree that random numbers are highly desirable though.<= br>
I think it would be much better for these use cases to add OP_XOR ba= ck 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 bac= k which does Blum's without OP_XOR using OP_SIZE for off-chain probabil= istic payments if anyone is interested. No fork needed, but of course it is= more limited and broken in a number of ways.=C2=A0

(sorry to those = of you seeing this twice, my first email bounced the list)

On Fri, May 20, 2016 at 2:32 PM, Eric Martin= dale via bitcoin-dev <bitcoin-dev@lists.linuxfoundatio= n.org> wrote:
Matthew,
You should take a look at OP_DETERMINISTICRANDOM [1] from= the Elements Project.=C2=A0 It aims to achieve a similar goal.

Code= is in the `alpha` branch [2].

On Fri, May 20, 201= 6 at 8:29 AM Matthew Roberts via bitcoin-dev <bitcoin-dev@lists.linuxfou= ndation.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 bloc= k hash to produce a single number but the direction that this is going in d= oesn'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 o= f the number so you have to throw away a valid POW if it doesn't give y= ou the hash you want. I suppose its possible to make it infinitely expensiv= e to manipulate the number but I can't think of anything better than th= at for now.

I need to sleep on this for now but let me kn= ow if anyone has any better ideas.



On Fri, May 20, 2016 at= 6:34 AM, Johnson Lau <jl2012@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.
=


=3D=3D 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@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev

_______________________________________________
bitcoin-dev mailing list
= bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mail= man/listinfo/bitcoin-dev


--001a113f8d266ff9f505336e56d8--