MIME-Version: 1.0
In-Reply-To: <CA+fZXJKuE_C7231-OHM2gvFUYBKjfoDoOfh+04YqHZuQF41eag@mail.gmail.com>
References: <CA+fZXJKuE_C7231-OHM2gvFUYBKjfoDoOfh+04YqHZuQF41eag@mail.gmail.com>
From: James Hilliard <james.hilliard1@gmail.com>
Date: Fri, 6 Oct 2017 08:36:15 -0600
Message-ID: <CADvTj4p09Kq6SKKD_ttbjGsE7eyiq3hvDRQo3vUk6wCGVJU8UA@mail.gmail.com>
To: =?UTF-8?B?5r2Y5b+X5b2q?= <bit.kevin@gmail.com>, 
	Bitcoin Protocol Discussion <bitcoin-dev@lists.linuxfoundation.org>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
Subject: Re: [bitcoin-dev] A solution may solve Block Withholding Attack
Precedence: list

There have been some other proposals to deal with this such as
https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2012-June/001506.ht=
ml
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@lists.linuxfoundation.org> wrote:
> Here is a solution may solve Block Withholding Attack. The general idea i=
s
> 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 0x00000000FFFF000000000000000000000000000000000000000000000000=
0000;
>
> 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_ha=
sh]
>
> 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-1=
1e7-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 val=
ue
> 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 1123863285132,
> 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
>