Re: [bitcoin-dev] hashcash-newhash

[ZmnSCPxj via bitcoin-dev]

Good morning Karl,

> Hi,
>
> I'd like to revisit the discussion of the digest algorithm used in hashcash.
>
> I believe migrating to new hashing algorithms as a policy would significantly 
> increase decentralization and hence security.

Why do you believe so?

My understanding is that there are effectively two strategies for ensuring 
decentralization based on hash algorithm:

* Keep changing the hash algorithm to prevent development of ASICs and ensure 
commodity generic computation devices (GPUs) are the only practical target.
* Do not change the algorithm, to ensure that knowledge of how best to 
implement an ASIC for the algorithm becomes spread out (through corporate 
espionage, ASIC reverse-engineering, patent expiry, and sheer engineering 
effort) and ASICs for the algorithm are as commoditized as GPUs.

The former strategy has the following practical disadvantages:

* Developing new hash algorithms is not cheap.
  The changes to the hashcash algorithm may need to occur faster than the speed 
at which we can practically develop new, cryptographically-secure hash 
algorithms.
* It requires coordinated hardforks over the entire network at an alarmingly 
high rate.
* It arguably puts too much power to the developers of the code.

On the other hand, the latter strategy requires us only to survive an 
intermediate period where ASICs are developed, but not yet commoditized; and 
during this intermediate period, the centralization pressure of ASICs might not 
be more powerful than other centralization pressures

--

Which brings us to another point.

Non-ASIC-resistance is, by my understanding, a non-issue.

Regardless of whether the most efficient available computing substrate for the 
hashcash algorithm is CPU, GPU, or ASIC, ultimately miner earnings are 
determined by cost of power supply.

Even if you imagine that changing the hashcash algorithm would make CPUs 
practical again, you will still not run it on the CPU of a mobile, because a 
mobile runs on battery, and charging a battery takes more power than what you 
can extract from the battery afterwards, because thermodynamics.

Similarly, geographic locations with significant costs of electrical power will 
still not be practical places to start a mine, regardless if the mine is 
composed of commodity server racks, commodity video cards, or commodity ASICs.

If you want to solve the issue of miner centralization, the real solution is 
improving the efficiency of energy transfer to increase the areas where cheap 
energy is available, not stopgap change-the-algorithm-every-6-months.


Regards,
ZmnSCPxj


>
> I believe the impact on existing miners could be made pleasant by gradually 
> moving the block reward from the previous hash to the next (such that both 
> are accepted with different rewards).  An appropriate rate could possibly be 
> calculated from the difficulty.
>
> You could develop the frequency of introduction of new hashes such that once 
> present-day ASICs are effectively obsolete anyway due to competition, new 
> ones do not have time to develop.
>
> I'm interested in hearing thoughts and concerns.
>
> Karl Semich


___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

[ZmnSCPxj via bitcoin-dev]

Good morning Thomas,

> So I think the question to ask would be "why can't we just make sure it's not 
> 64?"

If we accept a 60-byte tx, then SHA-256 will pad it to 64 bytes, and it may 
still be possible to mount CVE-2017-12842 attack with 32-bits of work.
Of course some other details will be changed from the standard SHA-256 in 
mounting this attack, but from my poor understanding it seems safer to just 
avoid the area around length 64.

It *might* be safe to accept 65-byte or larger (but do not believe me, I only 
play a cryptographer on the Internet), but that does not help your specific 
application, which uses 60 byte tx.

Regards,
ZmnSCPxj

>
> On Sat, May 23, 2020 at 11:24 AM Greg Sanders  wrote:
>
> > AFAIU the number was picked to protect against CVE-2017-12842 covertly. 
> > See: https://github.com/bitcoin/bitcoin/pull/16885 which updated the text 
> > to explicitly mention this fact.
> >
> > On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev 
> >  wrote:
> >
> > > Hello list,
> > >
> > > I have been trying to CPFP a transaction using OP_RETURN, because the
> > > remaining output value would have been lower than the dust threshold.
> > >
> > > The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
> > > single p2wsh input.
> > >
> > > The result is a 60 bytes transaction (without witness), that gets
> > > rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
> > > is equal to 82 bytes.
> > >
> > > Why is that value so high? Would it make sense to lower it to 60?
> > >
> > > Thomas
> > > ___
> > > bitcoin-dev mailing list
> > > bitcoin-dev@lists.linuxfoundation.org
> > > https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

[Greg Sanders via bitcoin-dev]

So I think the question to ask would be "why can't we just make sure it's
not 64?"

On Sat, May 23, 2020 at 11:24 AM Greg Sanders  wrote:

> AFAIU the number was picked to protect against CVE-2017-12842 covertly.
> See: https://github.com/bitcoin/bitcoin/pull/16885
>  which updated the
> text to explicitly mention this fact.
>
> On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Hello list,
>>
>> I have been trying to CPFP a transaction using OP_RETURN, because the
>> remaining output value would have been lower than the dust threshold.
>>
>> The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
>> single p2wsh input.
>>
>> The result is a 60 bytes transaction (without witness), that gets
>> rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
>> is equal to 82 bytes.
>>
>> Why is that value so high? Would it make sense to lower it to 60?
>>
>>
>> Thomas
>> ___
>> bitcoin-dev mailing list
>> bitcoin-dev@lists.linuxfoundation.org
>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

[Greg Sanders via bitcoin-dev]

AFAIU the number was picked to protect against CVE-2017-12842 covertly.
See: https://github.com/bitcoin/bitcoin/pull/16885
 which updated the
text to explicitly mention this fact.

On Sat, May 23, 2020 at 11:20 AM Thomas Voegtlin via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Hello list,
>
> I have been trying to CPFP a transaction using OP_RETURN, because the
> remaining output value would have been lower than the dust threshold.
>
> The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
> single p2wsh input.
>
> The result is a 60 bytes transaction (without witness), that gets
> rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
> is equal to 82 bytes.
>
> Why is that value so high? Would it make sense to lower it to 60?
>
>
> Thomas
> ___
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] MIN_STANDARD_TX_NONWITNESS_SIZE and OP_RETURN

[Thomas Voegtlin via bitcoin-dev]

Hello list,

I have been trying to CPFP a transaction using OP_RETURN, because the
remaining output value would have been lower than the dust threshold.

The scriptPubkey of the output was OP_RETURN + OP_0, and there was a
single p2wsh input.

The result is a 60 bytes transaction (without witness), that gets
rejected because it is lower than MIN_STANDARD_TX_NONWITNESS_SIZE, which
is equal to 82 bytes.

Why is that value so high? Would it make sense to lower it to 60?


Thomas
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

[bitcoin-dev] hashcash-newhash

[Karl via bitcoin-dev]

Hi,

I'd like to revisit the discussion of the digest algorithm used in hashcash.

I believe migrating to new hashing algorithms as a policy would
significantly increase decentralization and hence security.

I believe the impact on existing miners could be made pleasant by gradually
moving the block reward from the previous hash to the next (such that both
are accepted with different rewards).  An appropriate rate could possibly
be calculated from the difficulty.

You could develop the frequency of introduction of new hashes such that
once present-day ASICs are effectively obsolete anyway due to competition,
new ones do not have time to develop.

I'm interested in hearing thoughts and concerns.

Karl Semich
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev