Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id 993588EC for ; Fri, 20 May 2016 15:05:38 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-io0-f177.google.com (mail-io0-f177.google.com [209.85.223.177]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id BD8241E5 for ; Fri, 20 May 2016 15:05:37 +0000 (UTC) Received: by mail-io0-f177.google.com with SMTP id p64so57622670ioi.2 for ; Fri, 20 May 2016 08:05:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=roberts-pm.20150623.gappssmtp.com; s=20150623; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc; bh=/1f2iJeyA/7CxveSQrI8ylshrUoqUIs9U8g0YmHorMs=; b=womVYTxkSVKXsmzDObJKGV/QC1CAB7/X2WPbxDusB749t5hdZ+Nn02pIqzKqZb0UnD p7kk6u3kf5pMWE+fRv/4IG+ocwWzQC3Vi3qqpSXVsW93c/HRckEm65FTn8Be5xKX5Rm1 fsz3KWvLsj0FRwm9IoZLfeNImIi5RJiNE74mfYUxGPzAdnculCjF0gEmxwQbzQREOgfR VNLJC20uNOZuDrpvIJX2XQQ4NKmIL81BeEFv85otsrtwBG9Kbyao+aw8DIJtjjTTnu02 BKGJE43e668rPGitVwrwINy+dFGUqwli7rgWYRJB6r37Kpczw4K+F3zJJG2oxWdPTK7n RCDw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc; bh=/1f2iJeyA/7CxveSQrI8ylshrUoqUIs9U8g0YmHorMs=; b=QWLBDrHgp2pgt16ftqRyeBfmVYzPJLGQ/GgoWo1bnorhNIMlw5Xo8iwdceAbVc3f+D lh5x+LfWa4IWVA7bEGdemvpySaM7c933B7aybWKMC5PIE8rKXmtL74d62xtic+RSmOzU I+KTSsWTE/19SMtH5xnzFm3juFnUmReTVmY9SA+wGetpyJumPwszw18IsWZGiv4xDkSV Dpu+Nlre853U2e0q6mbZp18O6Ifq6inXaIlXqXjyEeWSdw9UPv+j2MJTgwn3JuObtCIJ 4AZiFXUnul3rwjFtRRxIlJkq9/t0XGi7+cP+URJPztEwVJoBBE60QeZAvdz347JeSUir s1SQ== X-Gm-Message-State: AOPr4FU7uCfiEjKpTq/gK/Zt5gBpCSR57gEAL7fNVPcygywWRYXRpUYNLEydGDynP4gJ/UxbS3I6feszVPGcMQ== MIME-Version: 1.0 X-Received: by 10.36.230.129 with SMTP id e123mr3512217ith.92.1463756736917; Fri, 20 May 2016 08:05:36 -0700 (PDT) Received: by 10.107.198.10 with HTTP; Fri, 20 May 2016 08:05:36 -0700 (PDT) X-Originating-IP: [115.70.56.56] In-Reply-To: References: Date: Fri, 20 May 2016 10:05:36 -0500 Message-ID: From: Matthew Roberts To: Johnson Lau Content-Type: multipart/alternative; boundary=94eb2c006f6457afa90533476cff X-Spam-Status: No, score=-2.6 required=5.0 tests=BAYES_00,DKIM_SIGNED, DKIM_VALID,HTML_MESSAGE,RCVD_IN_DNSWL_LOW autolearn=ham version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Fri, 20 May 2016 15:29:06 +0000 Cc: bitcoin-dev 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: Fri, 20 May 2016 15:05:38 -0000 --94eb2c006f6457afa90533476cff Content-Type: text/plain; charset=UTF-8 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. > > > --94eb2c006f6457afa90533476cff Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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 m= ultiple blocks does not make it any safer. The miner of the last block alwa= ys 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.



--94eb2c006f6457afa90533476cff--