Re: [bitcoin-dev] A Small Modification to Segwit

[g via bitcoin-dev]

Erik,

I completely agree that it will be in the long term interest of bitcoin to 
migrate, gradually, toward a commoditized POW away from the current mass 
centralization. There is a big problem here though: Hundreds of millions of 
dollars have been spent on the current algorithm, and will be a huge loss if 
this is not done slowly enough, and the miners who control the chain currently 
would likely never allow this change to happen.

Do you have any ideas regarding how to mitigate the damage of such a change for 
the invested parties? Or even how we can make the change agreeable for them?

Warm regards,
Garrett

--
Garrett MacDonald
+1 720 515 2248
g...@cognitive.ch
GPG Key

On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev 
, wrote:
> Curious: I'm not sure why a serious discussion of POW change is not on the 
> table as a part of a longer-term roadmap.
>
> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of the 
> proven, np-complete graph-theoretic or polygon manipulation POW would keep 
> Bitcoin in commodity hardware and out of the hands of centralized 
> manufacturing for many years.
>
> Clearly a level-playing field is critical to keeping centralization from 
> being a "defining feature" of Bitcoin over the long term.   I've heard the 
> term "level playing field" bandied about quite a bit.   And it seems to me 
> that the risk of state actor control and botnet attacks is less than 
> state-actor manipulation of specialized manufacturing of "SHA-256 forever" 
> hardware.   Indeed, the reliance on a fairly simple hash seems less and less 
> likely a "feature" and more of a baggage.
>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a 
> part of good maintenance of cryptocurrency in general.   Killing the existing 
> POW, and using an as-yet undefined, but deployment-bit ready POW field to 
> flip-flop between the current and the "next one" every 8 years or or so, with 
> a ramp down beginning in the 7th year  A stub function that is guaranteed 
> to fail unless a new consensus POW is selected within 7 years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would respond 
> well to a well known cutover date.   This would enable rapid-response to 
> quantum tech, or some other needed POW switch as well... because the 
> mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's 
> only irresponsible if done irresponsibly.
>
>
> > On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev 
> >  wrote:
> > > Jimmy Song,
> > >
> > > Why would the actual end users of Bitcoin (the long term and short term 
> > > owners of bitcoins) who run fully verifying nodes want to change Bitcoin 
> > > policy in order to make their money more vulnerable to 51% attack?
> > >
> > > If anything, we would be making policy changes to prevent the use of 
> > > patented PoW algorithms instead of making changes to enable them.
> > >
> > > Thanks,
> > > Praxeology Guy
> > >
> > > ___
> > > 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Using a storage engine without UTXO-index

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/08/2017 04:58 PM, Tomas wrote:
> You seem to ignore here the difference between base load and peak 
> load. If Compact blocks/XThin with further optimizations can 
> presync nearly 100% of the transactions, and nodes can do as much 
> as possible when a transaction comes in, the time spent when a 
> block comes in can be minimized and a lot more transactions can be 
> handled with the same resources.

Maybe it's an issue of terminology. I have never used the terms
base/peak load. However I've been trying to get across, poorly I
suppose, that this is actually implemented in libbitcoin. I generally
refer to it as tx pre-validation. I've also tried to relate that you
are unnecessarily relating pre-validation to compactness. These are
unrelated ideas and better considered independently. One can get
nearly all of the benefit of pre-validation while still receiving
blocks (vs. compact blocks). The advantage of compactness is reduced
latency of the block announcement. The reason for pre-validation is
amortization of the validation and/or storage cost of a block.

> The reason for "splitting" is that for an incoming transaction the
>  spent-state of the outputs being spent isn't particularly
> relevant as you seem to acknowledge. When the block comes in, the
> actual output data isn't relevant.

As I understand it you would split tx inputs and outputs and send them
independently, and that you intend this to be a P2P network
optimization - not a consensus rule change. So my comments are based
on those inferences. If we are talking about consensus changes this
conversation will end up in an entirely different place.

I don't agree with the input/output relevance statements above. When a
tx is announced the entire tx is relevant. It cannot be validated as
outputs only. If it cannot be validated it cannot be stored by the
node. Validating the outputs only would require the node store invalid
transactions.

I do accept that a double-spend detection is not an optimal criteria
by which to discard a tx. One also needs fee information. But without
double-spend knowledge the node has no rational way to defend itself
against an infinity of transactions that spend the minimal fee but
also have conflicting inputs (i.e. risking the fee only once). So tx
(pool) validation requires double-spend knowledge and at least a
summary from outputs.

> The *only* thing that needs to be checked when a block comes in is 
> the order, and the spend-tree approach absolves the need to access 
> outputs here.

Inputs that are already valid against prevouts remain valid assuming
consensus rules have not changed. But any input that spends a coinbase
must be validated for prevout height once there is a block context for
validation. Additionally the set of txs must be validated for total
size, sigops, and fee claim. So it's not true that conflict detection
alone is sufficient. Yet one can cache a tx's size, sigops, fee and
minimum height in a graph so that when a block appears that contains
that tx the input validation can be skipped.

Ignoring the (actual) requirement for the full tx on the pool
validation, the required "order" validation at (compact or other)
block arrival basically consists of traversing each tx, ensuring none
are confirmed in a block below the fork point; traversing each each of
its confirmed inputs, ensuring that none are spent in a block below
the fork point; and ensuring the block's set of transactions do not
contain missing inputs and do not double spend internal to the block.

This and the above-mentioned other required per-transaction block
validation data can be cached to an in-memory structure as a potential
optimization over navigating the store, and as you say, does not
therefore require the actual outputs (script/value). But the original
issue of needing full transactions for independent transaction
validation remains.

> As it also absolves the need for reorgs this greatly simplifies the
> design.

A reorg is conceptual and cannot be engineered out. What you are
referring to is a restructuring of stored information as a consequence
of a reorg. I don't see this as related to the above. The ability to
perform reorganization via a branch pointer swap is based not on the
order or factoring of validation but instead on the amount of
information stored. It requires more information to maintain multiple
branches.

Transactions have confirmation states, validation contexts and spender
heights for potentially each branch of an unbounded number of
branches. It is this requirement to maintain that state for each
branch that makes this design goal a very costly trade-off of space
and complexity for reorg speed. As I mentioned earlier, it's the
optimization for this scenario that I find questionable.

> I am not sure why you say that a one-step approach is more 
> "test-friendly" as this seems to be unrelated.

Full separation of concerns allows all validation to be 

Re: [bitcoin-dev] A Small Modification to Segwit

[Erik Aronesty via bitcoin-dev]

I own some miners, but realistically their end of life is what, 6 months
from now if I'm lucky?If we used difficulty ramps on two selected
POW's, then the migration could be made smooth.   I don't think changing
the POW would be very challenging.  Personally, I would absolutely love to
be back in the business of buying GPU's instead of ASICs which are
uniformly sketchy.   Does anyone *not* mine their own equipment before
"shipping late" these days?

Maybe sample a video game's GPU operations and try to develop a secure hash
whose optimal implementation uses them in a similar ratio?   Ultimately, I
think it would very challenging to find a POW that doesn't make a bad
problem worse.  I understand that's why you suggested SHA3.

Hopefully, the "nanometer race" we have will work more smoothly once the
asicboost issue is resolved and competition can return to normal.   But
"waiting things out" rarely seems to work in Bitcoin land.






On Mon, Apr 10, 2017 at 11:25 AM, g  wrote:

> Erik,
>
> I completely agree that it will be in the long term interest of bitcoin to
> migrate, gradually, toward a commoditized POW away from the current mass
> centralization. There is a big problem here though: Hundreds of millions of
> dollars have been spent on the current algorithm, and will be a huge loss
> if this is not done slowly enough, and the miners who control the chain
> currently would likely never allow this change to happen.
>
> Do you have any ideas regarding how to mitigate the damage of such a
> change for the invested parties? Or even how we can make the change
> agreeable for them?
>
> Warm regards,
> Garrett
>
> --
> Garrett MacDonald
> +1 720 515 2248 <(720)%20515-2248>
> g...@cognitive.ch
> GPG Key 
>
> On Apr 9, 2017, 2:16 PM -0600, Erik Aronesty via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org>, wrote:
>
> Curious: I'm not sure why a serious discussion of POW change is not on the
> table as a part of a longer-term roadmap.
>
> Done right, a ramp down of reliance on SHA-256 and a ramp-up on some of
> the proven, np-complete graph-theoretic or polygon manipulation POW would
> keep Bitcoin in commodity hardware and out of the hands of centralized
> manufacturing for many years.
>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term.   I've heard the
> term "level playing field" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a
> part of good maintenance of cryptocurrency in general.   Killing the
> existing POW, and using an as-yet undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>
> Something like that?
>
> Haven't thought about it *that* much, but I think the network would
> respond well to a well known cutover date.   This would enable
> rapid-response to quantum tech, or some other needed POW switch as well...
> because the mechanisms would be in-place and ready to switch as needed.
>
> Lots of people seem to panic over POW changes as "irresponsible", but it's
> only irresponsible if done irresponsibly.
>
>
> On Fri, Apr 7, 2017 at 9:48 PM, praxeology_guy via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> Jimmy Song,
>>
>> Why would the actual end users of Bitcoin (the long term and short term
>> owners of bitcoins) who run fully verifying nodes want to change Bitcoin
>> policy in order to make their money more vulnerable to 51% attack?
>>
>> If anything, we would be making policy changes to prevent the use of
>> patented PoW algorithms instead of making changes to enable them.
>>
>> Thanks,
>> Praxeology Guy
>>
>> ___
>> 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 mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Bram Cohen via bitcoin-dev]

On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Perhaps regular, high-consensus POW changes might even be *necessary* as a
> part of good maintenance of cryptocurrency in general.   Killing the
> existing POW, and using an as-yet undefined, but deployment-bit ready POW
> field to flip-flop between the current and the "next one" every 8 years or
> or so, with a ramp down beginning in the 7th year  A stub function that
> is guaranteed to fail unless a new consensus POW is selected within 7
> years.
>

That would force hard forks, cause huge governance problems on selecting
the new PoW algorithm, and probably cause even worse mining chip
manufacturer centralization because it would force miners to buy new chips
instead of sticking with the ones they've already got. They'll likely have
to keep buying new ones anyway as technology improves but it doesn't help
to force that process to go even faster.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Bram Cohen via bitcoin-dev]

On Sun, Apr 9, 2017 at 11:44 AM, Erik Aronesty via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Clearly a level-playing field is critical to keeping centralization from
> being a "defining feature" of Bitcoin over the long term.   I've heard the
> term "level playing field" bandied about quite a bit.   And it seems to me
> that the risk of state actor control and botnet attacks is less than
> state-actor manipulation of specialized manufacturing of "SHA-256 forever"
> hardware.   Indeed, the reliance on a fairly simple hash seems less and
> less likely a "feature" and more of a baggage.
>
>
Whatever your hashing function the bottleneck for mining will be power.
Equihash and Cuckoo are serious attempts at making custom hardware have no
benefit over commodity hardware, but that's more about getting rid of
custom hardware manufacturers than it is about mining decentralization,
although arguably if successful it might let botnets back in, which would
improve decentralization. While those have been surprisingly successful at
resisting hardware so far, they might eventually fall as well, and if they
do they'll have even worse properties of centralizing around a mining
hardware manufacturer than sha256 does.

It would be much safer to go the other way, to a PoW function whose best
hardware implementation is particularly straightforward and well
understood. In that case it would be best to go with sha3. Sha3 also has
the benefit of using the sponge construction, which makes it particularly
resistant to asciboost-type attacks. It was picked out specifically because
its design from a security standpoint was particularly
confidence-inspiring, and in this case it actually makes a difference.
Arguably you could also go with blake2b, whose 1024 bit block size
completely obviates the asicboost concern entirely by cramming everything
into a single block. That also might have an even simpler design in
hardware than sha3, but a real expert would need to opine on that one.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] A Small Modification to Segwit

[Jorge Timón via bitcoin-dev]

On 9 Apr 2017 4:01 pm, "Jimmy Song"  wrote:

Jorge,

Why won't the attacker use asicboost too? (Please don't say because of
> patents)
>
>
We're assuming the ASIC optimization in my example is incompatible with
ASICBoost. But if the new optimization were compatible with ASICBoost,
you're right, the network would be in an equivalent situation whether
ASICBoost was banned or not.


Only if all honest miners use asicboost, otherwise the situation for an
attack is not equivalent but worse with asicboost.

I want to point out again that overt ASICBoost can be used on the network
today. My proposal is to bring ASICBoost usage out into the open vs hiding
it. Banning ASICBoost via protocol changes is another issue completely.


Doesn't greg's proposal of disabling covert asicboost "bring asicboost
usage into the open vs hiding it" too? It also does it without making any
assumptions on whether we want to completely disable it later (I want)
while your proposal assumes we do not.

Jimmy


> On 9 Apr 2017 12:26 am, "Jimmy Song"  wrote:
>
>> Jorge,
>>
>> Suppose someone figures out an ASIC optimization that's completely
>> unrelated that gives X% speed boost over your non-ASICBoosted
>> implementation. If you ban ASICBoost, someone with this optimization can
>> get 51% of the network by adding N machines with their new optimization. If
>> you allow ASICBoost and assuming this gets a 20% speed boost over
>> non-ASICBoosted hardware, someone with this optimization would need 1.2N
>> machines to get 51%. The network in that sense is 20% stronger against this
>> attack in terms of cost.
>>
>> Jimmy
>>
>> On Sat, Apr 8, 2017 at 12:22 PM, Jorge Timón  wrote:
>>
>>> To be more specific, why "being higher will secure the Bitcoin network
>>> better against newer optimizations"?
>>> Or, to be more clear, let's forget about future "optimizations", let's
>>> just think of an attacker. Does asicboost being used by all miners
>>> make the system more secure against an attacker? No, for the attacker
>>> can use asicboost too.
>>> What about the case when not all the miners are using asicboost? Then
>>> the attacker can actually get an advantage by suing asicboost.
>>>
>>> Sometimes people compare asicboost with the use of asics in general as
>>> both providing more security for the network and users. But I don't
>>> think this is accurate. The existence of sha256d asics makes an attack
>>> with general purpose computing hardware (or even more specialized
>>> architectures like gpgpu) much more expensive and unlikely. As an
>>> alternative the attacker can spend additional resources investing in
>>> asics himself (again, making many attacks more expensive and
>>> unlikely).
>>>
>>> But as far as I know, asicboost can be implemented with software
>>> running on general purpose hardware that integrates with regular
>>> sha256d asics. There is probably an advantage on having the asicboost
>>> implementation "in the same box" as the sha256d, yet again the
>>> attacker can invest in hardware with the competitive advantage from
>>> having asicboost more intergrated with the sha256d asics too.
>>>
>>> To reiterate, whether all miners use asicboost or only a subset of
>>> them, I remain unconvinced that provides any additional security to
>>> the network (to be more precise whether that makes "tx history harder
>>> to rewrite"), even if it results on the hashrate charts looking "more
>>> secure".
>>>
>>>
>>> On Sat, Apr 8, 2017 at 6:27 PM, Jorge Timón  wrote:
>>> >
>>> >
>>> > On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev"
>>> >  wrote:
>>> >
>>> > Praxeology Guy,
>>> >
>>> >> Why would the actual end users of Bitcoin (the long term and short
>>> term
>>> >> owners of bitcoins) who run fully verifying nodes want to change
>>> Bitcoin
>>> >> policy in order to make their money more vulnerable to 51% attack?
>>> >
>>> >
>>> > Certainly, if only one company made use of the extra nonce space, they
>>> would
>>> > have an advantage. But think of it this way, if some newer ASIC
>>> optimization
>>> > comes up, would you rather have a non-ASICBoosted hash rate to defend
>>> with
>>> > or an ASICBoosted hash rate? Certainly, the latter, being higher will
>>> secure
>>> > the Bitcoin network better against newer optimizations.
>>> >
>>> >
>>> > Why?
>>>
>>
>>
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev