[bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Daniele Pinna]

[-- Attachment #1: Type: text/plain, Size: 810 bytes --]

The following paper proposing an asymmetric memory-hard PoW had been
recently published:

http://eprint.iacr.org/2015/946.pdf

My intent is not to promote the paper as I have not finished studying it
myself. I am however interested in the dev-list's stance on potentially
altering the bitcoin PoW protocol should an algorithm that guarantees
protection from ASIC/FPGA optimization be found.

I assume that, given the large amount of money invested by some miners into
their industrial farms this would represent a VERY contentious hard fork.

It is, however, also true that a novel optimization-resistant algorithm
could greatly ameliorate decentralization in the bitcoin network due to a
resurgence of desktop/cellphone mining.

Where do the core devs stand on this matter, hypothetical as it may be?

Dpinna

[-- Attachment #2: Type: text/html, Size: 988 bytes --]

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 664 bytes --]

On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> should an algorithm that guarantees protection from ASIC/FPGA
optimization be found.

This is demonstrably impossible: anything that can be done with software
can be done with hardware. This is computer science 101.
And specialized hardware can always be more efficient, at least
energy-wise.

On the other hand, BIP99 explicitly contemplates "anti-miner hardforks"
(obviously not for so called "ASIC-resistance" [an absurd term coined to
promote some altcoins], but just for restarting the ASIC and mining market
in case mining becomes too centralized).

[-- Attachment #2: Type: text/html, Size: 838 bytes --]

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Daniele Pinna]

[-- Attachment #1: Type: text/plain, Size: 2098 bytes --]

The recently published paper I referenced cite's the Cuckoo cycle
algorithm, discusses its limitations and explains how their proposed
algorithm greatly improves on it. Again.... you're probably in a WAYYY
better position to judge this than I am. My question was purely
hypothetical as I wanted to know where the core devs stand on flipping the
mining ecosystem upside down.

Thanks for your link though, I'll read it right now (before finishing the
research article i posted :) ).

Daniele

Daniele Pinna, Ph.D

On Fri, Oct 2, 2015 at 10:14 AM, Adam Back <adam@cypherspace.org> wrote:

> There are papers demonstrating this "protection from ASIC/FPGA
> optimization" to be basically impossible
> https://download.wpsoftware.net/bitcoin/asic-faq.pdf and yet people
> keep trying...
>
> See also John Tromps cuckoo cycle paper, seems close to the best you
> could expect from memory hard.
>
> Adam
>
> On 2 October 2015 at 10:02, Daniele Pinna via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The following paper proposing an asymmetric memory-hard PoW had been
> > recently published:
> >
> > http://eprint.iacr.org/2015/946.pdf
> >
> > My intent is not to promote the paper as I have not finished studying it
> > myself. I am however interested in the dev-list's stance on potentially
> > altering the bitcoin PoW protocol should an algorithm that guarantees
> > protection from ASIC/FPGA optimization be found.
> >
> > I assume that, given the large amount of money invested by some miners
> into
> > their industrial farms this would represent a VERY contentious hard fork.
> >
> > It is, however, also true that a novel optimization-resistant algorithm
> > could greatly ameliorate decentralization in the bitcoin network due to a
> > resurgence of desktop/cellphone mining.
> >
> > Where do the core devs stand on this matter, hypothetical as it may be?
> >
> > Dpinna
> >
> >
> > _______________________________________________
> > bitcoin-dev mailing list
> > bitcoin-dev@lists.linuxfoundation.org
> > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
> >
>

[-- Attachment #2: Type: text/html, Size: 3209 bytes --]

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Adam Back]

See also https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetric_proofofwork_based_on/cvl922x

Adam

On 2 October 2015 at 10:20, Jorge Timón
<bitcoin-dev@lists.linuxfoundation.org> wrote:
>
> On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev"
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>> should an algorithm that guarantees protection from ASIC/FPGA optimization
>> be found.
>
> This is demonstrably impossible: anything that can be done with software can
> be done with hardware. This is computer science 101.
> And specialized hardware can always be more efficient, at least energy-wise.
>
> On the other hand, BIP99 explicitly contemplates "anti-miner hardforks"
> (obviously not for so called "ASIC-resistance" [an absurd term coined to
> promote some altcoins], but just for restarting the ASIC and mining market
> in case mining becomes too centralized).
>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Daniele Pinna]

[-- Attachment #1: Type: text/plain, Size: 930 bytes --]

Interesting! I didn't notice BIP 99's anti-miner hardfork proposal....
thanks for pointing it out to me.

Dpinna

Daniele Pinna, Ph.D

On Fri, Oct 2, 2015 at 10:20 AM, Jorge Timón <jtimon@jtimon.cc> wrote:

>
> On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
> >
> > should an algorithm that guarantees protection from ASIC/FPGA
> optimization be found.
>
> This is demonstrably impossible: anything that can be done with software
> can be done with hardware. This is computer science 101.
> And specialized hardware can always be more efficient, at least
> energy-wise.
>
> On the other hand, BIP99 explicitly contemplates "anti-miner hardforks"
> (obviously not for so called "ASIC-resistance" [an absurd term coined to
> promote some altcoins], but just for restarting the ASIC and mining market
> in case mining becomes too centralized).
>

[-- Attachment #2: Type: text/html, Size: 1498 bytes --]

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[NxtChg]

>...obviously not for so called "ASIC-resistance" [an absurd term coined to promote some altcoins]

Yet another fallacy of "all-or-nothing" thinking, which is so abundant in the Core camp.

The fact that you can build ASIC for any kind of algorithm _in_theory_ doesn't mean you can't make it _arbitrary_hard_ in practice.

So I would tone down the arrogance a bit.

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Jorge Timón]

[-- Attachment #1: Type: text/plain, Size: 688 bytes --]

On Oct 2, 2015 12:46 PM, "NxtChg" <nxtchg@hush.com> wrote:
>
>
> >...obviously not for so called "ASIC-resistance" [an absurd term coined
to promote some altcoins]
>
> Yet another fallacy of "all-or-nothing" thinking, which is so abundant in
the Core camp.
>
> The fact that you can build ASIC for any kind of algorithm _in_theory_
doesn't mean you can't make it _arbitrary_hard_ in practice.
>
> So I would tone down the arrogance a bit.
>

ASIC-RESISTANCE is simply not possible, I'm sorry if that position strikes
you as arrogant. Note that I didn't say anything about memory-hard, which
is possible (but not necessarily preferrable to
simple-to-implement-in-hardware pow algorithms).

[-- Attachment #2: Type: text/html, Size: 901 bytes --]

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Peter R]

[-- Attachment #1: Type: text/plain, Size: 1430 bytes --]

> On Oct 2, 2015, at 1:20 AM, Jorge Timón via bitcoin-dev <bitcoin-dev@lists.linuxfoundation.org> wrote:
> On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <bitcoin-dev@lists.linuxfoundation.org <mailto:bitcoin-dev@lists.linuxfoundation.org>> wrote:
> > should an algorithm that guarantees protection from ASIC/FPGA optimization be found.
> This is demonstrably impossible: anything that can be done with software can be done with hardware. This is computer science 101.  And specialized hardware can always be more efficient, at least energy-wise.
> 
I encourage Alex and Dmitry to consider submitting their paper to Ledger, where it will be reviewed objectively and with an open mind.  The authors have motivated their work, framed it in its scholarly context, and made explicit the contributions their paper makes.  Their manuscript, "Asymmetric proof-of-work based on the Generalized Birthday problem," clearly represents a great deal of work by the authors and I commend them for their efforts.  

In the link Adam Back provided, Greg Maxwell mentioned that “it is far from clear that 'memory hardness' is actually a useful goal.”  I agree with this statement; however, regardless of whether memory hardness turns out to be a useful goal in regards to cryptocurrency or not, a paper analyzing memory-hard proof-of-work schemes is certainly useful in helping us to figure that out. 

Best regards,
Peter

[-- Attachment #2: Type: text/html, Size: 2146 bytes --]

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Gregory Maxwell]

On Fri, Oct 2, 2015 at 8:30 AM, Daniele Pinna via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:
> The recently published paper I referenced cite's the Cuckoo cycle algorithm,
> discusses its limitations and explains how their proposed algorithm greatly
> improves on it.

They discuss a very old version of the Cuckoo cycle paper, and I
believe none of their analysis is applicable to the most recent
revision. :(

In any case, I commented more about functions of this class here:
https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetric_proofofwork_based_on/cvl922x

I don't believe changing the POW function is impossible in principle,
but I expect it would only happen due to problems with the composition
of current hash-power and not even if it were universally agreed that
some other construction were technically better (though that is a high
bar.)

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Luke Dashjr]

On Friday, October 02, 2015 8:02:43 AM Daniele Pinna via bitcoin-dev wrote:
> I am however interested in the dev-list's stance on potentially
> altering the bitcoin PoW protocol should an algorithm that guarantees
> protection from ASIC/FPGA optimization be found.
> 
> I assume that, given the large amount of money invested by some miners into
> their industrial farms this would represent a VERY contentious hard fork.
> 
> It is, however, also true that a novel optimization-resistant algorithm
> could greatly ameliorate decentralization in the bitcoin network due to a
> resurgence of desktop/cellphone mining.
> 
> Where do the core devs stand on this matter, hypothetical as it may be?

Besides ASIC-proof being even tehoretically impossible, assuming we had a PoW 
that worked using mere RAM-as-the-ASIC, this would probably not be good in 
the long term for decentralisation, as it is only a matter of time until 
botnets would bankrupt all the legitimate miners out of operation.

Restarting the mining with a new algorithm as a reaction and defence against 
centralised hoarding of mining ASICs (as we are seeing now), would be 
acceptable. It would not necessarily be contentions *to the economy*, as such 
hoarding-miners do not participate in the economy in any meaningful way (they 
do not accept payments from other bitcoin users).

Luke

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Dave Scotese]

[-- Attachment #1: Type: text/plain, Size: 4108 bytes --]

If the PoW function is changed, it ought to change slowly so as not to drop
a brick wall in front of the miners speeding toward the ever-receding goal
of protecting the blockchain.  Who's going to get on that path if the
bitcoin community does that?

But it can be done slowly.  If most of the entries is the list of possible
PoW functions are double-SHA256, then the few that aren't will offer the
healthy goal sought by those who like the idea of changing it.  The healthy
goal is for general computing machines to help protect the blockchain in an
incentivized way.  There's a sick goal too, which is to destroy large
investments in mining.  I hope no one has that goal.

At
http://bitcoin.stackexchange.com/questions/35679/is-it-possible-to-make-pow-asic-resistant-through-dynamically-generated-hash-cha/40475#40475
I proposed that ongoing competitions for the creation of new hash
algorithms could feed an ASIC-resistant PoW, defined using the
as-yet-unknowable winners of such competitions.  It is possible to make an
ASIC resistant algorithm, but it isn't a programmable algorithm - it's one
that requires human intervention.  The hash of the next block is a good
example - there's no programmable algorithm that can find it because too
much human intervention is required, but it's an algorithm well-enough
defined for us to build a billion dollar system on top of it.

That being said, I've started looking at two different kinds of
decentralization.  The literal actually-in-different-places kind is
categorically different than the much more important, virtual
impervious-to-coercion kind.  The behavior of the "centralized" oil cartel
is a good example.  The participants cheat.  This is a fundamental
principle in the debate between free-marketeers and authoritarians
regarding the emergence of monopoly.  Without coercion, monopolies fall
apart.  There's nothing coercive about our use of the double-SHA256, so in
my mind, the centralization it has so far produced is not dangerous.  It's
scary, sure, but until coercion is used to prevent me and my friends from
buying our own ASICs, it remains impervious to coercion.

Sorry for the long email that didn't make any apparent progress.  The
thinking is what matters to me, and seeing two kinds of decentralization
and recognizing that a change in PoW can be slow enough to avoid hurting
existing miners are items I haven't seen anyone else recognize, so I had to
bring them up.

notplato

On Fri, Oct 2, 2015 at 9:45 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Fri, Oct 2, 2015 at 8:30 AM, Daniele Pinna via bitcoin-dev
> <bitcoin-dev@lists.linuxfoundation.org> wrote:
> > The recently published paper I referenced cite's the Cuckoo cycle
> algorithm,
> > discusses its limitations and explains how their proposed algorithm
> greatly
> > improves on it.
>
> They discuss a very old version of the Cuckoo cycle paper, and I
> believe none of their analysis is applicable to the most recent
> revision. :(
>
> In any case, I commented more about functions of this class here:
>
> https://www.reddit.com/r/Bitcoin/comments/3n5nws/research_paper_asymmetric_proofofwork_based_on/cvl922x
>
> I don't believe changing the POW function is impossible in principle,
> but I expect it would only happen due to problems with the composition
> of current hash-power and not even if it were universally agreed that
> some other construction were technically better (though that is a high
> bar.)
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>



-- 
I like to provide some work at no charge to prove my value. Do you need a
techie?
I own Litmocracy <http://www.litmocracy.com> and Meme Racing
<http://www.memeracing.net> (in alpha).
I'm the webmaster for The Voluntaryist <http://www.voluntaryist.com> which
now accepts Bitcoin.
I also code for The Dollar Vigilante <http://dollarvigilante.com/>.
"He ought to find it more profitable to play by the rules" - Satoshi
Nakamoto

[-- Attachment #2: Type: text/html, Size: 5489 bytes --]

Re: [bitcoin-dev] Dev-list's stance on potentially altering the PoW algorithm

[Milly Bitcoin]

> Restarting the mining with a new algorithm as a reaction and defence against
> centralised hoarding of mining ASICs (as we are seeing now), would be
> acceptable. It would not necessarily be contentions *to the economy*, as such
> hoarding-miners do not participate in the economy in any meaningful way (they
> do not accept payments from other bitcoin users).
>
> Luke

I don't see any basis for these claims.  Under this theory developers 
also do not "participate in the economy" either.  These are questions 
for economists and not developers.

Maybe "we" could change the language of Core to prevent the 
centralization of developers?  Maybe switch over to FORTRAN?   lol

Russ