Return-Path: Received: from smtp1.linuxfoundation.org (smtp1.linux-foundation.org [172.17.192.35]) by mail.linuxfoundation.org (Postfix) with ESMTPS id F3D0997 for ; Sun, 8 Oct 2017 09:28:35 +0000 (UTC) X-Greylist: whitelisted by SQLgrey-1.7.6 Received: from mail-wm0-f42.google.com (mail-wm0-f42.google.com [74.125.82.42]) by smtp1.linuxfoundation.org (Postfix) with ESMTPS id CCD5F130 for ; Sun, 8 Oct 2017 09:28:34 +0000 (UTC) Received: by mail-wm0-f42.google.com with SMTP id q124so15727283wmb.0 for ; Sun, 08 Oct 2017 02:28:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:in-reply-to:references:from:date:message-id:subject:to; bh=7MEx67JddXOsgfWFiT9Kp/Pb4h5hxYf6QKq21Xncibc=; b=NXV7DMlTLzmtIE8FZf0afkX1vLXhGEi+6EaYnCcCB2ewfOw1CLQoiGPBHRfUrUZ5s6 h2VDMCsRYq1etkOmb0hjMS84qnjEGog0fqZx7NeREbcNMdSXFwOghwZV3bAmOwGmSh91 XEHiQF65oUiqhALHNkDENu5Zi+NXbnoPqJ/xr9fm8nl9BRsQKXICLoBeKbjOKbjXpny6 1PjtxML7viZgFUKo/NklkaC9uIR0338/q80sMVSL2BDSCnY/+KJH6R2irtpJ8hHPldtE LI3ZYi8CUy/GFCoH2qPWsShtgO6Gy0oN7+QebSWCZ1LstQLz/DRv9IaTpHxJPqd6U+H2 um7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:in-reply-to:references:from:date :message-id:subject:to; bh=7MEx67JddXOsgfWFiT9Kp/Pb4h5hxYf6QKq21Xncibc=; b=TBsYwE4ClX6dEn6nzEJaA1/QPG1pqR04N/ef0dunwepKdMDLNwN1JTQ0fAEAA5an+s JqLJq2hdylsBy8pZOACrWPWJHR8RUsqPtt5snBCwDbQP0N9nMFftKc+snUhJE1jg6h5a 2dfnjhaMxPyDtRqj7Jgv4yslQcltLjmgrIO/iOzTJoVaeuCt9m9Xp69nlMfKgkF9R7Id a83rVYKgBCqGAYuZBP4mZ5iRbndQTpBtH2iVgPehSauaG1K+SgPPpkhwZyhWKN7syy+G zYHDpCr3msV9SKf7uiOJ8XaIQxYl+e12NTqk6JkEDcuz4RivJYkMcYGjKx9C8BpVHARV 4Kug== X-Gm-Message-State: AMCzsaXmfZo1zRW48Iw6kp5nUhurUDGD19BK7UO5+Eur4UcPvs9a9+9d 3hvTtAlrzdAb3LvnPh0aVW9SDD+9utJjaHY0ZzABaHbE X-Google-Smtp-Source: AOwi7QAIQA2ZjMNc58A80Y8Mo6O50UnbJV0pp3alIOYPUcsCf4TEXErhwNF5j6boAkopiyvWwrCsM+nPmnNOmB68WY4= X-Received: by 10.80.151.47 with SMTP id c44mr5598207edb.139.1507454913311; Sun, 08 Oct 2017 02:28:33 -0700 (PDT) MIME-Version: 1.0 Received: by 10.80.216.6 with HTTP; Sun, 8 Oct 2017 02:28:32 -0700 (PDT) In-Reply-To: References: From: Kevin Pan Date: Sun, 8 Oct 2017 17:28:32 +0800 Message-ID: To: bitcoin-dev@lists.linuxfoundation.org Content-Type: multipart/alternative; boundary="f403045c2c249f783c055b05b2f3" X-Spam-Status: No, score=0.4 required=5.0 tests=DKIM_SIGNED,DKIM_VALID, DKIM_VALID_AU,FREEMAIL_FROM,HTML_MESSAGE,RCVD_IN_DNSWL_NONE, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.1 X-Spam-Checker-Version: SpamAssassin 3.3.1 (2010-03-16) on smtp1.linux-foundation.org X-Mailman-Approved-At: Sun, 08 Oct 2017 10:18:13 +0000 Subject: Re: [bitcoin-dev] A solution may solve Block Withholding Attack 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, 08 Oct 2017 09:28:36 -0000 --f403045c2c249f783c055b05b2f3 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable But I think this one is simpler and better than Luke's. And now is different like 2012, pools need be more independ today. Pools want to express their opinion or standpoint. Some of can't do that like remove the NYA tag and one the reason is the Block Withholding Attack. Kevin Pan On Fri, Oct 6, 2017 at 10:36 PM, James Hilliard wrote: > There have been some other proposals to deal with this such as > https://lists.linuxfoundation.org/pipermail/bitcoin-dev/ > 2012-June/001506.html > that may be possible to implement in existing miners. > > On Tue, Oct 3, 2017 at 9:52 AM, =E6=BD=98=E5=BF=97=E5=BD=AA via bitcoin-d= ev > wrote: > > Here is a solution may solve Block Withholding Attack. The general idea > is > > came from Aviv Zohar(avivz@cs.huji.ac.il), I made it work for Bitcoin. > > Anyway, thanks Aviv. > > > > =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D > > > > DIFF_1 =3D 0x00000000FFFF0000000000000000000000000000000000000000000000 > 000000; > > > > Diff =3D DIFF_1 / target > > > > this is equal to > > > > Diff =3D DIFF_1 / (target - 0) or Diff =3D DIFF_1 / abs(target - 0) > > > > now, we change diff algo to below: > > > > New_Diff =3D DIFF_1 / abs(target - offset) > > > > Offset is 32 bytes, like uint256 in Bitcoin, range is [0, 2^256), > > define: offset_hash =3D DSHA256(offset). > > > > we need to do a little change to the merkle root hash algo, put the > > offset_hash as a tx hash in the front of tx hashes. > > > > [offset_hash, coinbase_tx_hash, tx01_hash, tx02_hash, =E2=80=A6 , tx_n_= hash] > > > > Actually could put offset_hash in any place in the array of hashes. > > > > network_hash_range =3D network_hash_end - network_hash_begin > > > > miner_hash_range =3D miner_hash_end - miner_hash_begin > > > > The offset value MUST between network_hash_begin/end or > > miner_hash_begin/end. > > > > https://user-images.githubusercontent.com/514951/ > 31133378-e00d9ca2-a891-11e7-8c61-73325f59f6ed.JPG > > > > When mining pool send a job to miners, put the PoW hash range > > (miner_hash_begin/end) in the job. So if the miners find a hash which > value > > is between [miner_hash_begin, miner_hash_end], means it's SHOULD be a > > valid share, could submit the share to the pool. If the hash value is > > between [network_hash_begin, network_hash_end] means find a valid block= . > > > > The network_diff is much much high than the miner's diff, means the > > network_hash_range is much much smaller than miner_hash_range. By now, > > a typical miner's pool diff is around 16K, network diff is 112386328513= 2, > > so miner_hash_range is at least million times bigger than > > network_hash_range. > > The miners only know miner_hash_range, it's impossible for cheat miners > > to find out which share could make a valid block or not. > > > > Problems: > > 1. it's a hard fork. > > 2. will make existed asic dsha256 chips useless, but I think it's only = a > > small change to make new asic chips based on existed tech. > > > > _______________________________________________ > > bitcoin-dev mailing list > > bitcoin-dev@lists.linuxfoundation.org > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev > > > --f403045c2c249f783c055b05b2f3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
But I think this one is s= impler and better than Luke's.
And now is different like 2012, poo= ls need be more independ today. Pools want=C2=A0
to express their opinion or standpoint. Some of can't do tha= t like remove the=C2=A0
NYA tag and on= e the reason is the Block Withholding Attack.

Kevin Pan

On Fri, Oct 6, 2017 a= t 10:36 PM, James Hilliard <james.hilliard1@gmail.com> wrote:
There have been some other prop= osals to deal with this such as
https://lists.linuxfoun= dation.org/pipermail/bitcoin-dev/2012-June/001506.html
that may be possible to implement in existing miners.

On Tue, Oct 3, 2017 at 9:52 AM, =E6=BD=98=E5=BF=97=E5=BD=AA via bitcoin-dev=
<bitcoin-dev@li= sts.linuxfoundation.org> wrote:
> Here is a solution may solve Block Withholding Attack. The general ide= a is
> came from Aviv Zohar(avivz@cs.h= uji.ac.il), I made it work for Bitcoin.
> Anyway, thanks Aviv.
>
> =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D
>
> DIFF_1 =3D 0x00000000FFFF0000000000000000000000000000000000000000= 000000000000;
>
> Diff =3D DIFF_1 / target
>
> this is equal to
>
> Diff =3D DIFF_1 / (target - 0) or Diff =3D DIFF_1 / abs(target - 0) >
> now, we change diff algo to below:
>
> New_Diff =3D DIFF_1 / abs(target - offset)
>
> Offset is 32 bytes, like uint256 in Bitcoin, range is [0, 2^256),
> define: offset_hash =3D DSHA256(offset).
>
> we need to do a little change to the merkle root hash algo, put the > offset_hash as a tx hash in the front of tx hashes.
>
> [offset_hash, coinbase_tx_hash, tx01_hash, tx02_hash, =E2=80=A6 , tx_n= _hash]
>
> Actually could put offset_hash in any place in the array of hashes. >
> network_hash_range =3D network_hash_end - network_hash_begin
>
> miner_hash_range =3D miner_hash_end - miner_hash_begin
>
> The offset value MUST between network_hash_begin/end or
> miner_hash_begin/end.
>
> https://user-images.githubusercontent.com/514951/31133378-e00d= 9ca2-a891-11e7-8c61-73325f59f6ed.JPG
>
> When mining pool send a job to miners, put the PoW hash range
> (miner_hash_begin/end) in the job. So if the miners find a hash which = value
> is between [miner_hash_begin, miner_hash_end], means it's SHOULD b= e a
> valid share, could submit the share to the pool. If the hash value is<= br> > between [network_hash_begin, network_hash_end] means find a valid bloc= k.
>
> The network_diff is much much high than the miner's diff, means th= e
> network_hash_range is much much smaller than miner_hash_range. By now,=
> a typical miner's pool diff is around 16K, network diff is 1123863= 285132,
> so miner_hash_range is at least million times bigger than
> network_hash_range.
> The miners only know miner_hash_range, it's impossible for cheat m= iners
> to find out which share could make a valid block or not.
>
> Problems:
> 1. it's a hard fork.
> 2. will make existed asic dsha256 chips useless, but I think it's = only a
> small change to make new asic chips based on existed tech.
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@l= ists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

--f403045c2c249f783c055b05b2f3--