On May 11, 2016 7:33 PM, "Peter Todd" wrote:
> The optimisation has been independently discovered two or three times
(Spondoolies and maybe Bitmain).
The idea that a precedent can be set, whereby those who seek or are awarded
mining optimization patents risk retaliatory consensus changes, is ver
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11 May 2016 22:27:09 GMT-04:00, Tom Harding via bitcoin-dev
wrote:
>On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote:
>>
>> If we change the protocol then the message to the ecosystem is that
>> ASIC optimizations should be kep
On 5/10/2016 2:43 PM, Sergio Demian Lerner via bitcoin-dev wrote:
>
> If we change the protocol then the message to the ecosystem is that
> ASIC optimizations should be kept secret.
Further to that point, if THIS optimization had been kept secret, nobody
would be talking about doing anything, as w
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
On 11 May 2016 21:23:21 GMT-04:00, Russell O'Connor via bitcoin-dev
wrote:
>Is the design and manufacturing processes for the most power efficient
>ASICs otherwise patent unencumbered? If not, why do we care so much
>about
>this one patent over
Aside from patents related to the silicon manufacturing process itself and
patents not yet published, yes, the process is unencumbered, and setting the
correct precedent (that the community will fight large centralization risks) is
important in the first case.
Matt
On May 11, 2016 9:23:21 PM E
Is the design and manufacturing processes for the most power efficient
ASICs otherwise patent unencumbered? If not, why do we care so much about
this one patent over all the others that stand on the road between pen and
paper computation and thermodynamically ideal computation?
On Wed, May 11, 20
On Wed, May 11, 2016 at 11:01 PM, Peter Todd via bitcoin-dev
wrote:
> Secondly, we can probably make the consensus PoW allow blocks to be mined
> using
> both the existing PoW algorithm, and a very slightly tweaked version where
> implementing AsicBoost gives no advantage. That removes any incent
On Tue, May 10, 2016 at 08:14:33PM -0700, Timo Hanke wrote:
> There is no way to tell from a block if it was mined with AsicBoost or not.
> So you don’t know what percentage of the hashrate uses AsicBoost at any
> point in time. How can you risk forking that percentage out? Note that this
> would b
On Wed, May 11, 2016 at 10:42 PM, Timo Hanke via bitcoin-dev
wrote:
> This is what I meant. If existing hardware gets forked-out it will
> inevitably lead to the creation of an altcoin. Simply because the hardware
> exists and can't be used for anything else both chains will survive. I was
> only
On Wed, May 11, 2016 at 03:16:58PM -0700, Simon Liu via bitcoin-dev wrote:
> > giving one
> > manufacturer/licenser a huge influence in who is successful in a market
> > that we're all relying on remaining rather flat.
>
> Central planning is a slippery slope. Let the market decide the winners
>
Ups, I forgot that you take the midstate which of course depends on the
version number. So forget everything I said about the version bits. You are
right. But why take the midstate? It can be any hash of the first chunk. So
you probably want to take a hash function that's available in standard
soft
On Wed, May 11, 2016 at 3:47 AM, Jannes Faber
wrote:
> On 11 May 2016 at 12:36, Henning Kopp wrote:
>
>> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev
>> wrote:
>> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
>> > bitcoin-dev@lists.linuxfoundation.org> wrote:
On 05/11/2016 02:01 PM, Matt Corallo via bitcoin-dev wrote:
> Indeed, I think the "ASICs are bad, because 1-CPU-1-vote" arguments
> mostly died out long ago, and, indeed, the goal that many making those
> arguments had of building "unoptimizeable" ASICs failed with them.
Discussion quietened down
I was told that the patent appears to be owned exclusively by Bitmain
in China https://www.google.com/patents/CN105245327A?cl=en
On Wed, May 11, 2016 at 4:50 PM, Matt Corallo via bitcoin-dev
wrote:
> That's the reason for this post! All current major ASIC manufacturers
> have made warrants that t
Indeed, I think the "ASICs are bad, because 1-CPU-1-vote" arguments
mostly died out long ago, and, indeed, the goal that many making those
arguments had of building "unoptimizeable" ASICs failed with them.
I think everyone understands that there will always be some ability to
iterate on ASIC desig
That's the reason for this post! All current major ASIC manufacturers
have made warrants that they are not using AsicBoost (with the exception
of the 21 Inc Bitcoin computer).
The fact that the optimization was patented is what has required that we
work to hardfork it out, not that people might ha
Eelet me revise that last paragraph. That's 12 *GB* of filters at
today's block height (at fixed false-positive rate 1e-6. Compared to block
headers only which are about 33 MB today. So this proposal is not really
compatible with such a wallet being "light"...
Damn units...
Bob McElrat
I like this idea, but let's run some numbers...
bfd--- via bitcoin-dev [bitcoin-dev@lists.linuxfoundation.org] wrote:
> A Bloom Filter Digest is deterministically created of every block
Bloom filters completely obfuscate the required size of the filter for a desired
false-positive rate. But, an
Sorry, you must have meant all 12 bytes. That makes finding a collision
substantially harder. However, you may have to restrict yourself to 10
bytes because you don't know if any hardware does timestamp rolling
on-chip. Also you create an incentive to mess around with the version bits
instead, so y
Luke, do you mean to replace the first 4 bytes of the second chunk (bytes
64..67 in 0-based counting) by the XOR of those 4 bytes with the first 4
bytes of the midstate? (I assume you don't care about 12 bytes but rather
those 4 bytes.)
This does not work. All it does is adding another computation
On 11 May 2016 at 16:18, Sergio Demian Lerner via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> Jorge Timón said..
> > What do you mean by "embrace" in the context of a patented optimization
> that one miner can prevent the rest from using?
>
> Everyone seems to assume that one ASI
On Wednesday, May 11, 2016 12:20:55 PM Sergio Demian Lerner via bitcoin-dev
wrote:
> On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
> sergio.d.ler...@gmail.com> wrote:
> > You can find it here:
> > https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-blo
> > ck-header/
>
Jorge Timón said..
> What do you mean by "embrace" in the context of a patented optimization
that one miner can prevent the rest from using?
Everyone seems to assume that one ASIC manufacturer will get the advantage
of AsicBoost while others won't. If a patent license is non-exclusive, then
all ca
On May 11, 2016 05:15, "Timo Hanke via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> Again: this is unlike the hypothetical persistence of two chains after a
hardfork that is only contentious but doesn’t change the mining algorithm,
the kind of hardfork you are proposing would gu
Ehm, I though those discussions about "ASICs are bad, because X" ended
years ago by starting "ASIC unfriendly" altcoins. ASIC industry is twisted
even without AsicBoost. I don't see any particular reason why to change
rules just because of 10% edge.
This is opening Pandora box and it is potentiall
On Tue, May 10, 2016 at 6:43 PM, Sergio Demian Lerner <
sergio.d.ler...@gmail.com> wrote:
>
>
> You can find it here:
> https://bitslog.wordpress.com/2014/03/18/the-re-design-of-the-bitcoin-block-header/
>
> Basically, the idea is to put in the first 64 bytes a 4 byte hash of the
> second 64-byte
On 11 May 2016 at 12:36, Henning Kopp wrote:
> On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev
> wrote:
> > On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
> > bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > > There is no way to tell from a block if it was mined
On Wed, May 11, 2016 at 11:21:10AM +0200, Jannes Faber via bitcoin-dev wrote:
> On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> > There is no way to tell from a block if it was mined with AsicBoost or
> > not. So you don’t know what percent
On 11 May 2016 at 05:14, Timo Hanke via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:
> There is no way to tell from a block if it was mined with AsicBoost or
> not. So you don’t know what percentage of the hashrate uses AsicBoost at
> any point in time. How can you risk forking that
29 matches
Mail list logo
