Timo Hanke [ARCHIVE] on Nostr: 📅 Original date posted:2016-10-02 📝 Original message:> When you proposed the ...
📅 Original date posted:2016-10-02
📝 Original message:> When you proposed the extra nonce space BIP [1], you had already
> applied for your ASICBOOST patent [2] without disclosure in the BIP
> [1] nor in your Bitcoin Core pull request #5102 [2].
There may be quite a few things to clarify here, and a possible
misunderstanding:
The BIP proposal [1] and accompanying pull request [3] does not increase or
decrease the entanglement of Bitcoin consensus code with any patents. This
is indicated by the title of the pull request: "No forking Extra nonce
added to Bitcoin header." It is not a fork at all (soft or hard). The
consensus is not changed.
AsicBoost is possible with or without adoption of that BIP proposal. Of
several ways to implement AsicBoost (all described in the patent
application), making use of the version field is only one. And even that
particular one has always been possible since the beginning of Bitcoin and
is still possible today. It is not the case that the BIP proposal enables
AsicBoost in a way that wasn't possible before.
The rationale behind the BIP proposal was to eliminate incentives to mess
with the merkle root and, in the extreme case, to mine empty blocks. This
incentive is real, and it is real with or without AsicBoost. It costs
hardware manufacturers real $ in additional hardware components right now
to cope with the pre-hashing load.
Timo
On Sun, Oct 2, 2016 at 12:36 PM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Sergio,
>
> It is critically important to the future of Bitcoin that consensus
> code avoid any unnecessary entanglements with patents because "the
> free market" allows you and anyone else to make consensus change
> proposals that rely on (unknown) patents - but this is something we
> should all be working to avoid, as it unnecessarily hinders Bitcoin
> development and everyone's ability to deploy. Consensus code must not
> be hindered by patents and Bitcoin should retain its permissionless
> qualities.
>
> When you proposed the extra nonce space BIP [1], you had already
> applied for your ASICBOOST patent [2] without disclosure in the BIP
> [1] nor in your Bitcoin Core pull request #5102 [2].
>
> The ASICBOOST patent [2] describes the same process as in the BIP [1]
> and proposed code [3] "As we explained in our Provisional Application,
> it has been proposed to partition the 4-byte Version field in the
> block header (see, Fig. 6) and use, e.g., the high 2-byte portion as
> additional nonce range."
>
> Today when you proposed a new sidechain BIP [4], Peter Todd was
> (rightly) concerned about the prior lack of disclosure of your patents
> related to your prior consensus modification proposal. Hence the
> concern is that this might be happening this time as well.
>
> There is no evidence that any of the other filers for the
> ASICBOOST-like patents by mining companies other than your own were
> going to be using it offensively as those other companies appeared to
> understand the decentralization risk of having an advantage enforced
> by legal and not technical means.
>
> It's great that you have now committed to looking into the Defensive
> Patent License. This seems likely to mitigate some of the patent
> concerns. Although it would be a show of good faith if you also agreed
> to license ASICBOOST under the DPL.
>
> [1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
> [2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
> [3]: Extra nonce pull request: https://github.com/bitcoin/
> bitcoin/pull/5102
> [4]: COUNT_ACKS
> [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/
> 013174.html
>
> On Sun, Oct 2, 2016 at 6:13 PM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Please Peter Todd explain here all what you want to say about a patent
> of a
> > hardware design for an ASIC.
> >
> > Remember that ASICBoost is not the only patent out there, there are at
> least
> > three similar patents, filed by major Bitcoin ASIC manufacturers in three
> > different countries, on similar technologies.
> >
> > That suggest that the problem is not ASICBoot's: you cannot blame any
> > company from doing lawful commerce in a FREE MARKET.
> >
> > It is a flaw in Bitcoin design that could be corrected if the guidelines
> I
> > posted in [1] had been followed.
> >
> > [1]
> > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-
> the-bitcoin-block-header/
> >
> >
> >
> >
> > _______________________________________________
> > 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/20161002/ed3b4e7a/attachment.html>;
📝 Original message:> When you proposed the extra nonce space BIP [1], you had already
> applied for your ASICBOOST patent [2] without disclosure in the BIP
> [1] nor in your Bitcoin Core pull request #5102 [2].
There may be quite a few things to clarify here, and a possible
misunderstanding:
The BIP proposal [1] and accompanying pull request [3] does not increase or
decrease the entanglement of Bitcoin consensus code with any patents. This
is indicated by the title of the pull request: "No forking Extra nonce
added to Bitcoin header." It is not a fork at all (soft or hard). The
consensus is not changed.
AsicBoost is possible with or without adoption of that BIP proposal. Of
several ways to implement AsicBoost (all described in the patent
application), making use of the version field is only one. And even that
particular one has always been possible since the beginning of Bitcoin and
is still possible today. It is not the case that the BIP proposal enables
AsicBoost in a way that wasn't possible before.
The rationale behind the BIP proposal was to eliminate incentives to mess
with the merkle root and, in the extreme case, to mine empty blocks. This
incentive is real, and it is real with or without AsicBoost. It costs
hardware manufacturers real $ in additional hardware components right now
to cope with the pre-hashing load.
Timo
On Sun, Oct 2, 2016 at 12:36 PM, Btc Drak via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Sergio,
>
> It is critically important to the future of Bitcoin that consensus
> code avoid any unnecessary entanglements with patents because "the
> free market" allows you and anyone else to make consensus change
> proposals that rely on (unknown) patents - but this is something we
> should all be working to avoid, as it unnecessarily hinders Bitcoin
> development and everyone's ability to deploy. Consensus code must not
> be hindered by patents and Bitcoin should retain its permissionless
> qualities.
>
> When you proposed the extra nonce space BIP [1], you had already
> applied for your ASICBOOST patent [2] without disclosure in the BIP
> [1] nor in your Bitcoin Core pull request #5102 [2].
>
> The ASICBOOST patent [2] describes the same process as in the BIP [1]
> and proposed code [3] "As we explained in our Provisional Application,
> it has been proposed to partition the 4-byte Version field in the
> block header (see, Fig. 6) and use, e.g., the high 2-byte portion as
> additional nonce range."
>
> Today when you proposed a new sidechain BIP [4], Peter Todd was
> (rightly) concerned about the prior lack of disclosure of your patents
> related to your prior consensus modification proposal. Hence the
> concern is that this might be happening this time as well.
>
> There is no evidence that any of the other filers for the
> ASICBOOST-like patents by mining companies other than your own were
> going to be using it offensively as those other companies appeared to
> understand the decentralization risk of having an advantage enforced
> by legal and not technical means.
>
> It's great that you have now committed to looking into the Defensive
> Patent License. This seems likely to mitigate some of the patent
> concerns. Although it would be a show of good faith if you also agreed
> to license ASICBOOST under the DPL.
>
> [1]: BIP: https://github.com/BlockheaderNonce2/bitcoin/wiki
> [2]: ASICBOOST PATENT https://www.google.com/patents/WO2015077378A1?cl=en
> [3]: Extra nonce pull request: https://github.com/bitcoin/
> bitcoin/pull/5102
> [4]: COUNT_ACKS
> [https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2016-October/
> 013174.html
>
> On Sun, Oct 2, 2016 at 6:13 PM, Sergio Demian Lerner via bitcoin-dev
> <bitcoin-dev at lists.linuxfoundation.org> wrote:
> > Please Peter Todd explain here all what you want to say about a patent
> of a
> > hardware design for an ASIC.
> >
> > Remember that ASICBoost is not the only patent out there, there are at
> least
> > three similar patents, filed by major Bitcoin ASIC manufacturers in three
> > different countries, on similar technologies.
> >
> > That suggest that the problem is not ASICBoot's: you cannot blame any
> > company from doing lawful commerce in a FREE MARKET.
> >
> > It is a flaw in Bitcoin design that could be corrected if the guidelines
> I
> > posted in [1] had been followed.
> >
> > [1]
> > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-
> the-bitcoin-block-header/
> >
> >
> >
> >
> > _______________________________________________
> > 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/20161002/ed3b4e7a/attachment.html>;