Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

[Ryan Grant via bitcoin-dev]

Praxeology Guy,

On Fri, Apr 7, 2017 at 12:56 PM, praxeology_guy
 wrote:
> TLDR Unless I'm missing something, your claim that a
> misconfiguration would result in a stop chain is wrong because BIP9
> only works on soft forks.

If our rule change timing is different from changes on the chain with
most work, then (extending Johnson Lau's terminology a bit) we may
experience subjective hardfork-ness; due to miners creating blocks
which the economic majority goes on to accept, though they have a less
restrictive ruleset than ours.

> The user would have to adopt a soft fork at a time where no miner
> has also done the same, and where someone creates a contradictory
> block (which normally wouldn't happen unless someone was being
> malicious).

Correct for the segwit soft fork, which is narrowing the definition
of a nonstandard transaction.  It's safe to say that if a block with a
tx violating cleanstack were to occur on a non-segwit chain, that it
was for malicious reasons.

However, some future forks - that a full node experiences as
low subjective hardfork-ness (i.e. soft forks) - might restrict
more common things.

> Never the less, I kind of like the idea of the user being notified
> when a newly activated more stringent soft fork rule caused a block
> to be rejected.  The first time it happens, a message could come up,
> and then for some time after maybe it would be logged somewhere
> easily accessible.

Sure, a nice-to-have would be a SetfLargeWorkInvalidChainFound() that
was aware as well, though clients can make these decisions themselves.
___
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

[Jimmy Song via bitcoin-dev]

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.


> If anything, we would be making policy changes to prevent the use of
> patented PoW algorithms instead of making changes to enable them.
>

Is that patented in any jurisdiction, all jurisdictions or only certain
jurisdictions? Would a patent granted for SHA256 in Swaziland be sufficient
for Bitcoin to change the Proof of Work algorithm? This is a very
subjective judgment based on quasi-legality and I don't think that's a road
that Bitcoin should go down.

Certainly, it would be better if the patent for ASICBoost were
open-sourced, but the legality of such-and-such thing in such-and-such
jurisdiction should not affect Bitcoin policy as that in itself introduces
significant risk to the network. A sufficiently authoritarian government
can then grant a monopoly for various algorithms in their country and
negatively impact Bitcoin.

Indeed, there are already many individuals that disobey the laws of their
country to help the Bitcoin network run. I would expect the same with
patents. Should there come a time when a patent or some other legal
maneuvering gives one network actor a large advantage to the detriment of
the network, I believe that Bitcoin will handle that in the specific case.

In the meantime, I believe such changes increase the odds of Segwit
actually being accepted and activated as per BIP-141.
___
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

[praxeology_guy via bitcoin-dev]

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

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

[Gregory Maxwell via bitcoin-dev]

On Fri, Apr 7, 2017 at 9:14 PM, Tomas  wrote:
> The long term *minimal disk storage* requirement, can obviously not be less
> then all the unspent outputs.

Then I think you may want to retract the claim that "As this solution,
reversing the costs of outputs and inputs, [...] updates to the
protocol addressing the UTXO growth, might not be worth considering
*protocol improvements* "

As you note that the output costs still bound the resource
requirements. Short of radical protocol changes like TXO-proofs the
UTXO data remains a driving unavoidable long term resource cost, not
an implementation detail.  Implementation optimizations like improving
locality further or keeping spentness in memory do not change this
fact.

> The storage that is accessed during peak load (block validation with
> pre-synced transactions), is minimized as this only needs the transaction
> index (to lookup ptrs from hashes), the tip of the spend-tree and the tip of

Latency related costs in Bitcoin Core also do not depend on the number
of outputs in transactions in a block. When a transaction is handled
it goes into an in-memory buffer and only gets flushed later if isn't
spent before the buffer fills.  A block will take more time to
validate with more inputs, same as you observer, but the aggregate
resource usage for users depends significantly on outputs (so, in fact
there is even further misaligned incentives than just the fact that
small outputs have a outsized long term cost).
___
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

[Jimmy Song via bitcoin-dev]

I've gotten feedback from Adam Back that you actually don't need all 32
bits in the header for overt ASICBoost, so I'm modifying my proposal. Of
the 32-bit version field, bits 16 to 23 are reserved for miners, the
witness commitment stays as defined in BIP-141 except that it's now
required. BIP9 then is modified so that bits 16 to 23 are now no longer
usable.

On Fri, Apr 7, 2017 at 3:06 PM, Jimmy Song  wrote:

> Hey everyone, This is an idea that I had about Segwit and Gregory's
> proposal from yesterday that I wanted to run by everyone on this list. I'm
> not at all sure what this would mean for non-upgraded nodes on the network
> and would like feedback on that. This is not a formal BIP as it's a
> modification to a previously submitted one, but I'm happy to formalize it
> if it would help.
> 
> MotivationOne of the interesting aspects of Gregory Maxwell’s proposal is
> that it only precludes the covert version of ASICBoost. He specifically
> left the overt version alone.
>
> Overt ASICBoost requires grinding on the version bits of the Block header
> instead of the Merkle Root. This is likely more efficient than the Merkle
> Root grinding (aka covert ASICBoost) and requires way less resources
> (much less RAM, SHA256 calculations, no tx shuffling, etc).
>
> If we combine Gregory Maxwell’s proposal with BIP-141 (Segwit) and add a
> slight modification, this should, in theory, make ASICBoost a lot more
> useful to miners and appeal to their financial interests.
> The Modification
>
> Currently, the version bits (currently 4 bytes, or 32 bits) in the header
> are used for BIP9 signaling. We change the version bits to a nonce-space so
> the miners can use it for overt ASICBoost. The 32-bits are now moved over
> to the Coinbase transaction as part of the witness commitment. The witness
> commitment goes from 38 bytes to 42 bytes, with the last 4 bytes being used
> as the version bits in the block header previously. The witness commitment
> becomes required as per Gregory Maxwell’s proposal.
> Reasoning
>
> First, this brings ASICBoost out into the open. Covert ASICBoost becomes
> much more costly and overt ASICBoost is now encouraged.
>
> Second, we can make this change relatively quickly. Most of the Segwit
> testing stays valid and this change can be deployed relatively quickly.
>
> Note on SPV clients
>
> Currently Segwit stores the witness commitment in the Coinbase tx, so
> lightweight clients will need to get the Coinbase tx + Merkle proof to
> validate segwit transactions anyway. Putting block version information in
> the Coinbase tx will not impose an extra burden on upgraded light clients.
>
___
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/07/2017 02:44 PM, Tomas via bitcoin-dev wrote:
> Hi Eric,
> 
> On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote:
>> Optimization for lower memory platforms then becomes a process
>> of reducing the need for paging. This is the purpose of a cache.
>> The seam between disk and memory can be filled quite nicely by a
>> small amount of cache. On high RAM systems any cache is actually
>> a de-optimization but on low RAM systems it can prevent excessive
>> paging. This is directly analogous to a CPU cache.
> 
> 
> I am not entirely sure I agree with that, or understand it
> correctly.
> 
> If -for example - the data of some application is a set  of
> records which can be sorted from least frequently used to most
> frequently used then doing just that sort will beat any
> application-layer cache. Regardless of size of data and size of
> RAM, you simply allow the OS to use disk caching or memory map
> caching to work its  magic .

It's a reasonable assumption, and given that the no-explicit-cache
implementation is a subset of the optionally-cached implementation,
was of course the initial implementation.

> In fact, I would argue that an application-layer cache *only*
> makes sense if the data model shows a *hard* distinction between
> often and not often used data. If usage-frequency is a continuous
> line, caching is best left to the OS by focussing on proper spatial
> and temporal locality of reference of your data, because the OS has
> much more information to make the right decision.

In practice this is not the case. The Bitcoin data model is neither
continuous nor strictly segregated by usage.

It is true that with sufficient RAM a cache is totally
counterproductive. It is also my experience that an independent UTXO
store is not a reasonable/necessary trade of disk space, memory
scalability, and/or code complexity in exchange for speed.

But on lower memory systems a explicit cache is beneficial. The
difference is clearly measurable in production code by simply changing
the cache limit and testing on various configurations.

e
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY6CXnAAoJEDzYwH8LXOFOf0YH/2qk3hYC6iEDW/DWM2ffkdb9
QM7A29Pvbfw9Wjr5Xx+ugIQvlAr4T+nByOCT6AnrqNU5K3UUmbC0KIB1rEL94hsK
QYVlLs0cOrjg8qKJpck+wcgiWw3VbEa/Y44hK7NLUxoy2HsLYaxPhqFH3GGgowqR
syga626jf2YUyudZxj1gFuqn7grkwghnzdrEUJMcqQo8IvCqjftGXlKxBGyB/AIs
Dx+5EWO9Q9IxrNpg/fsKKB6xkMxkmSx2hbD7dmEBvi/afbVF66rDTinjInG/LCju
pV7kT/GAWqGQGku6sQyAOexsxVhWA8EA/QEjvbyyGb+3YnR0s6nPk+CxO+RkOgo=
=e+Pr
-END PGP SIGNATURE-
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP Proposal: Inhibiting a covert optimization on the Bitcoin POW function

[Jan Čapek via bitcoin-dev]

Hi,

1 comment below
On Fri, 7 Apr 2017 17:52:17 -0300
Sergio Demian Lerner via bitcoin-dev
 wrote:

> 
>   BIP: TBD
>   Layer: Consensus
>   Title: Inhibiting a covert optimization on the Bitcoin POW function
>   Author: Sergio Demian Lerner 
>   Status: Draft
>   Type: Standards Track
>   Created: 2016-04-07
>   License: PD
> 
> 
> ==Abstract==
> 
> This proposal inhibits the covert use of a known optimization in
> Bitcoin Proof of Work function.
> 
> The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
> "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
> document are to be interpreted as described in RFC 2119.
> 
> ==Motivation==
> 
> Due to a design oversight the Bitcoin proof of work function has a
> potential optimization which can allow a rational miner to save up-to
> 30% of their energy
> costs (though closer to 20% is more likely due to implementation
> overheads).
> 
> Timo Hanke and Sergio Demian Lerner applied for a patent on this
> optimization. The company "Sunrise Tech Group, Llc" has offered to
> license it to any interested party in the past. Sunrise Tech Group
> has been marketing their patent licenses under the trade-name
> ASICBOOST.  The document takes no position on the validity or
> enforceability of the patent.
> 
> There are two major ways of taking advantage of this optimization, as
> described
> by the patent:
> One way which is highly detectable and is not in use on the network
> today and a covert way which has significant interaction and potential
> interference with the Bitcoin protocol.  The covert mechanism is not
> easily detected except through its interference with the protocol.
> 
> In particular, the protocol interactions of the covert method can
> block the implementation of virtuous improvements such as segregated
> witness.
> 
> The use of this optimization could result in a big payoff, but the
> actual sum depends on the degree of research, investment and effort
> put into designing
> the improved cores.
> 
> On the above basis the potential for covert use of this optimization
> in the covert form and interference with useful improvements presents
> a danger to the Bitcoin system.
> 
> ==Background==
> 
> The general idea of this optimization is that SHA2-256 is a merkle
> damgard hash
> function which consumes 64 bytes of data at a time.
> 
> The Bitcoin mining process repeatedly hashes an 80-byte 'block
> header' while incriminating a 32-bit nonce which is at the end of
> this header data. This means that the processing of the header
> involves two runs of the compression function run-- one that consumes
> the first 64 bytes of the header and a second which processes the
> remaining 16 bytes and padding.
> 
> The initial 'message expansion' operations in each step of the
> SHA2-256 function operate exclusively on that step's 64-bytes of
> input with no influence from prior data that entered the hash.
> 
> Because of this if a miner is able to prepare a block header with
> multiple distinct first 64-byte chunks but identical 16-byte
> second chunks they can reuse the computation of the initial
> expansion for multiple trials. This reduces power consumption.
> 
> There are two broad ways of making use of this optimization. The
> obvious way is to try candidates with different version numbers.
> Beyond upsetting the soft-fork detection logic in Bitcoin nodes this
> has little negative effect but it is highly conspicuous and easily
> blocked.
> 
> The other method is based on the fact that the merkle root
> committing to the transactions is contained in the first 64-bytes
> except for the last 4 bytes of it.  If the miner finds multiple
> candidate root values which have the same final 32-bit then they
> can use the optimization.
> 
> To find multiple roots with the same trailing 32-bits the miner can
> use efficient collision finding mechanism which will find a match
> with as little as 2^16 candidate roots expected, 2^24 operations to
> find a 4-way hit, though low memory approaches require more
> computation.
> 
> An obvious way to generate different candidates is to grind the
> coinbase extra-nonce but for non-empty blocks each attempt will
> require 13 or so additional sha2 runs which is very inefficient.
> 
> This inefficiency can be avoided by computing a sqrt number of
> candidates of the left side of the hash tree (e.g. using extra
> nonce grinding) then an additional sqrt number of candidates of
> the right  side of the tree using transaction permutation or
> substitution of a small number of transactions.  All combinations
> of the left and right side are then combined with only a single
> hashing operation virtually eliminating all tree related
> overhead.
> 
> With this final optimization finding a 4-way collision with a
> moderate amount of memory requires ~2^24 hashing operations
> instead of the >2^28 operations that would be require for
> 

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

[Tomas via bitcoin-dev]

Hi Eric,

On Fri, Apr 7, 2017, at 21:55, Eric Voskuil via bitcoin-dev wrote:
> Optimization for lower memory platforms then becomes a process of
> reducing the need for paging. This is the purpose of a cache. The seam
> between disk and memory can be filled quite nicely by a small amount
> of cache. On high RAM systems any cache is actually a de-optimization
> but on low RAM systems it can prevent excessive paging. This is
> directly analogous to a CPU cache. 


I am not entirely sure I agree with that, or understand it correctly.

If -for example - the data of some application is a set  of records
which can be sorted from least frequently used to most frequently used
then doing just that sort will beat any application-layer cache.
Regardless of size of data and size of RAM, you simply allow the OS to
use disk caching or memory map caching to work its  magic .

In fact, I would argue that an application-layer cache *only* makes
sense if the data model shows a *hard* distinction between often and not
often used data. If usage-frequency is a continuous line, caching is
best left to the OS by focussing on proper spatial and temporal locality
of reference of your data, because the OS has much more information to
make the right decision. 

___
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

[Tomas via bitcoin-dev]

Answering both,



On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev 
 wrote:
>> 

>> I'm still lost on this-- AFAICT your proposals long term resource

>> requirements are directly proportional to the amount of
>> unspent output
>> data, which grows over time at some fraction of the total transaction
>> volume (plus the rate of spending which is more or less a constant).
>> 

>> Can you help out my understanding here?

>> 



On Fri, Apr 7, 2017, at 20:39, Bram Cohen wrote:

> Expanding on this question a bit, it's optimized for parallel access,
> but hard drive access isn't parallel and memory accesses are very
> fast, so shouldn't the target of optimization be about cramming as
> much as possible in memory and minimizing disk accesses?


The long term *minimal disk storage* requirement, can obviously not be
less then all the unspent outputs. Minimal disk requirements is not
something bitcrust attempts to address.


 The storage that is accessed during peak load (block validation with
 pre-synced transactions), is minimized as this only needs the
 transaction index (to lookup ptrs from hashes), the tip of the spend-
 tree and the tip of the spend-index (together to check double
 spents/spending non-existing outputs). These not only easily fit in
 RAM, but are accessed in a cache efficient way. *These* only grow with
 inputs as the spend tree contains one record per input referencing the
 output being spent.


Script validation is also not something bitcrust *directly* addresses;
it uses libbitcoinconsensus for the actual validation and lookups to
outputs are mostly similar. They are kept fast by trusting the OS on MRU
caching of transaction-outputs; I don't think that for this part the
UTXO index has much drawbacks,. Bitcrust seems to have a small advantage
due to the awesomeness of Rayon's parallelization and the lock-free data
structures, but a disadvantage in that keeping all spent outputs
decreases spatial locality of reference. Script validation is not the
innovative part.


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

[bitcoin-dev] BIP Proposal: Inhibiting a covert optimization on the Bitcoin POW function

[Sergio Demian Lerner via bitcoin-dev]

  BIP: TBD
  Layer: Consensus
  Title: Inhibiting a covert optimization on the Bitcoin POW function
  Author: Sergio Demian Lerner 
  Status: Draft
  Type: Standards Track
  Created: 2016-04-07
  License: PD


==Abstract==

This proposal inhibits the covert use of a known optimization in Bitcoin
Proof of Work function.

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.

==Motivation==

Due to a design oversight the Bitcoin proof of work function has a potential
optimization which can allow a rational miner to save up-to 30% of their
energy
costs (though closer to 20% is more likely due to implementation overheads).

Timo Hanke and Sergio Demian Lerner applied for a patent on this
optimization. The company "Sunrise Tech Group, Llc" has offered to license
it to any interested party in the past. Sunrise Tech Group has been
marketing their patent licenses under the trade-name ASICBOOST.  The
document takes no position on the validity or enforceability of the patent.

There are two major ways of taking advantage of this optimization, as
described
by the patent:
One way which is highly detectable and is not in use on the network
today and a covert way which has significant interaction and potential
interference with the Bitcoin protocol.  The covert mechanism is not
easily detected except through its interference with the protocol.

In particular, the protocol interactions of the covert method can block the
implementation of virtuous improvements such as segregated witness.

The use of this optimization could result in a big payoff, but the actual
sum depends on the degree of research, investment and effort put into
designing
the improved cores.

On the above basis the potential for covert use of this optimization
in the covert form and interference with useful improvements presents a
danger to the Bitcoin system.

==Background==

The general idea of this optimization is that SHA2-256 is a merkle damgard
hash
function which consumes 64 bytes of data at a time.

The Bitcoin mining process repeatedly hashes an 80-byte 'block header' while
incriminating a 32-bit nonce which is at the end of this header data. This
means that the processing of the header involves two runs of the compression
function run-- one that consumes the first 64 bytes of the header and a
second which processes the remaining 16 bytes and padding.

The initial 'message expansion' operations in each step of the SHA2-256
function operate exclusively on that step's 64-bytes of input with no
influence from prior data that entered the hash.

Because of this if a miner is able to prepare a block header with
multiple distinct first 64-byte chunks but identical 16-byte
second chunks they can reuse the computation of the initial
expansion for multiple trials. This reduces power consumption.

There are two broad ways of making use of this optimization. The obvious
way is to try candidates with different version numbers.  Beyond
upsetting the soft-fork detection logic in Bitcoin nodes this has
little negative effect but it is highly conspicuous and easily
blocked.

The other method is based on the fact that the merkle root
committing to the transactions is contained in the first 64-bytes
except for the last 4 bytes of it.  If the miner finds multiple
candidate root values which have the same final 32-bit then they
can use the optimization.

To find multiple roots with the same trailing 32-bits the miner can
use efficient collision finding mechanism which will find a match
with as little as 2^16 candidate roots expected, 2^24 operations to
find a 4-way hit, though low memory approaches require more
computation.

An obvious way to generate different candidates is to grind the
coinbase extra-nonce but for non-empty blocks each attempt will
require 13 or so additional sha2 runs which is very inefficient.

This inefficiency can be avoided by computing a sqrt number of
candidates of the left side of the hash tree (e.g. using extra
nonce grinding) then an additional sqrt number of candidates of
the right  side of the tree using transaction permutation or
substitution of a small number of transactions.  All combinations
of the left and right side are then combined with only a single
hashing operation virtually eliminating all tree related
overhead.

With this final optimization finding a 4-way collision with a
moderate amount of memory requires ~2^24 hashing operations
instead of the >2^28 operations that would be require for
extra-nonce  grinding which would substantially erode the
benefit of the optimization.

It is this final optimization which this proposal blocks.

==New consensus rule==

Beginning block X and until block Y the coinbase transaction of
each block MUST either contain a BIP-141 segwit commitment or a
correct WTXID commitment with ID 0xaa21a9ef.

(See BIP-141 "Commitment 

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

[Eric Voskuil via bitcoin-dev]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 04/07/2017 11:39 AM, Bram Cohen via bitcoin-dev wrote:
> Expanding on this question a bit, it's optimized for parallel
> access, but hard drive access isn't parallel and memory accesses
> are very fast, so shouldn't the target of optimization be about
> cramming as much as possible in memory and minimizing disk
> accesses?

While this may seem to be the case it is not generally optimal. The
question is overly broad as one may or may not be optimizing for any
combination of:

startup time (first usability)
warm-up time (priming)
shutdown time (flush)
fault tolerance (hard shutdown survivability)
top block validation (read speed)
full chain validation (read/write speed)
RAM consumption
Disk consumption
Query response
Servers (big RAM)
Desktops (small RAM)
Mining (fast validation)
Wallets (background performance)
SSD vs. HDD

But even limiting the question to input validation, all of these
considerations (at least) are present.

Ideally one wants the simplest implementation that is optimal under
all considerations. While this may be a unicorn, it is possible to
achieve a simple implementation (relative to alternatives) that allows
for the trade-offs necessary to be managed through configuration (by
the user and/or implementation).

Shoving the entire data set into RAM has the obvious problem of
limited RAM. Eventually the OS will be paging more of the data back to
disk (as virtual RAM). In other words this does not scale, as a change
in hardware disproportionately impacts performance. Ideally one wants
the trade between "disk" and "memory" to be made by the underlying
platform, as that is its purpose. Creating one data structure for disk
and another for memory not only increases complexity, but denies the
platform visibility into this trade-off. As such the platform
eventually ends up working directly against the optimization.

An on-disk structure that is not mapped into memory by the application
allows the operating system to maintain as much or as little state in
memory as it considers optimal, given the other tasks that the user
has given it. In the case of memory mapped files (which are optimized
by all operating systems as central to their virtual memory systems)
it is possible for everything from zero to the full store to be memory
resident.

Optimization for lower memory platforms then becomes a process of
reducing the need for paging. This is the purpose of a cache. The seam
between disk and memory can be filled quite nicely by a small amount
of cache. On high RAM systems any cache is actually a de-optimization
but on low RAM systems it can prevent excessive paging. This is
directly analogous to a CPU cache. There are clear optimal points in
terms of cache size, and the implementation and management of such a
cache can and should be internal to a store. Of course a cache cannot
provide perfect scale all the way to zero RAM, but it scales quite
well for actual systems.

While a particular drive may not support parallel operations one
should not assume that a disk-based store does not benefit from
parallelism. Simply refer to the model described above and you will
see that with enough memory the entire blockchain can be
memory-resident, and for high performance operations a fraction of
that is sufficient for a high degree of parallelism.

In practice a cache of about 10k transactions worth of outputs is
optimal for 8GB RAM. This requires just a few blocks for warm-up,
which can be primed in inconsequential time at startup. Fault
tolerance can be managed by flushing after all writes, which also
reduces shutdown time to zero. For higher performance systems,
flushing can be disabled entirely, increasing shutdown time but also
dramatically increasing write performance. Given that the blockchain
is a cache, this is a very reasonable trade-off in some scenarios. The
model works just as well with HDD as SSD, although certainly SSD
performs better overall.

e
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.22 (GNU/Linux)

iQEcBAEBCAAGBQJY5+7GAAoJEDzYwH8LXOFOsAsH/3QK55aWH6sAi6OsTwV1FLZV
Y/2SSjwn1vUh55MDkPpCxDwV99JqVwpk0vGM8mGg5s4ZS8sxOPqwGiBz/SZWbF9v
oStJS0DjUPnbYtI/mrC30GuAYVcKnc5DFDHvjX6f0xrLIzViFR7eiW0npUH6Xipt
RI9Mockaf1CqqGExtbIqWal0YDEQGH0ekXRp7uEjh8nPUoKqTVvxDCgqVooQfvfx
EeKX9ruSv/r91EM1JQuH8HBBF7+R24tmMtwbpGx0zrDg5ytpIyrRzVH/ze1Mj2a3
ZxThvofGzhKcDiTPWiJI11DBYUvhSH4Kx0uWLzFUA0gxPfWkZQKJWNDl2CEwljk=
=C7rD
-END PGP SIGNATURE-
___
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

[Gregory Maxwell via bitcoin-dev]

On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev
 wrote:
> A network in which many nodes maintain a transaction index also enables a
> class of light node applications that ask peers to prove existence and
> spentness of TXO's.

Only with the additional commitment structure such as those proposed
by Peter Todd in his stxo/txo commitment designs, e.g.
https://petertodd.org/2016/delayed-txo-commitments
___
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

[Tom Harding via bitcoin-dev]

On Apr 6, 2017 6:31 PM, "Tomas via bitcoin-dev" <
bitcoin-dev@lists.linuxfoundation.org> wrote:


Bitcrust just uses a *transaction-index*, where outputs can be looked up
regardless of being spent.



A network in which many nodes maintain a transaction index also enables a
class of light node applications that ask peers to prove existence and
spentness of TXO's.
___
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

[Bram Cohen via bitcoin-dev]

Expanding on this question a bit, it's optimized for parallel access, but
hard drive access isn't parallel and memory accesses are very fast, so
shouldn't the target of optimization be about cramming as much as possible
in memory and minimizing disk accesses?

On Fri, Apr 7, 2017 at 11:18 AM, Gregory Maxwell via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
>  wrote:
> >As this
> > solution, reversing the costs of outputs and inputs, seems to have
> > excellent performance characteristics (as shown in the test results),
> > updates to the protocol addressing the UTXO growth, might not be worth
> > considering *protocol improvements*
>
> I'm still lost on this-- AFAICT your proposals long term resource
> requirements are directly proportional to the amount of unspent output
> data, which grows over time at some fraction of the total transaction
> volume (plus the rate of spending which is more or less a constant).
>
> Can you help out my understanding here?
> ___
> 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

[Gregory Maxwell via bitcoin-dev]

On Thu, Apr 6, 2017 at 10:12 PM, Tomas via bitcoin-dev
 wrote:
>As this
> solution, reversing the costs of outputs and inputs, seems to have
> excellent performance characteristics (as shown in the test results),
> updates to the protocol addressing the UTXO growth, might not be worth
> considering *protocol improvements*

I'm still lost on this-- AFAICT your proposals long term resource
requirements are directly proportional to the amount of unspent output
data, which grows over time at some fraction of the total transaction
volume (plus the rate of spending which is more or less a constant).

Can you help out my understanding here?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed lock-in

[praxeology_guy via bitcoin-dev]

Ryan Grant,

TLDR Unless I'm missing something, your claim that a misconfiguration would 
result in a stop chain is wrong because BIP9 only works on soft forks.

Does BIP9 work with hard forks? Pretty sure it is only for soft forks. If you 
want to make a hard fork, there is not much point in waiting for any particular 
miner hash power adoption rate.

With a softfork, here is the only condition for a "stopped chain":
1. User adopts more stringent rules.
2. Someone maliciously creates an invalid block as evaluated by the more 
stringent rules in #1, but that is valid to older nodes
3. No one ever mines a different block at the height of the block in #2, 
instead all of the miners only build on top of the block built at #2.

The user would have to adopt a soft fork at a time where no miner has also done 
the same, and where someone creates a contradictory block (which normally 
wouldn't happen unless someone was being malicious).

Never the less, I kind of like the idea of the user being notified when a newly 
activated more stringent soft fork rule caused a block to be rejected. The 
first time it happens, a message could come up, and then for some time after 
maybe it would be logged somewhere easily accessible. Such an event could be an 
excellent trigger to enable replay attack prevention, although maybe not 
automatically... unless everyone was pretty sure that a long-standing competing 
fork was likely to occur.

Cheers,
Praxeology Guy

 Original Message 
Subject: Re: [bitcoin-dev] Draft BIP: Version bits extension with guaranteed 
lock-in
Local Time: April 7, 2017 8:55 AM
UTC Time: April 7, 2017 1:55 PM
From: bitcoin-dev@lists.linuxfoundation.org
To: Bitcoin Protocol Discussion 

The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.

If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.
___
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

[Tomas via bitcoin-dev]

Thank you,



The benches are running in Google Cloud Engine; currently on 8 vCPU
32gb, but I tend to switch hardware regularly.


Roughly, the results are better for Bitcrust with high end hardware and
the difference for total block validations is mostly diminished at 2
vCPU, 7,5 gb.


Note that the spend-tree optimization primarily aims to improve peak
load order validation; when a block with pre-synced transactions comes
in, but this is tricky to accurately bench with Core using this simple
method of comparison by logs.


I will upgrade to, and show the results against 0.14 in the next weeks.


Best,

Tomas





On Fri, Apr 7, 2017, at 16:14, Greg Sanders wrote:

> Interesting work.

> 

> I was wondering if you could tellank  us what specs for the machine
> being used as preliminary benchmark is here:
> https://bitcrust.org/results ?
> 

> I'd be interested to also see comparisons with 0.14 which has some
> improvements for script validation with more cores.
> 

> On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev  d...@lists.linuxfoundation.org> wrote:
>> Thank you Marcos,

>> 

>>  Though written in Rust, bitcrust-db is definitely usable as
>>  pluggable
>>  module as its interface will be roughly some queries, add_tx and

>>  add_block with blobs and flags. (Bitcrust internally uses a

>>  deserialize-only model, keeping references to the blobs with the
>>  parsed
>>  data).

>> 

>>  However, from Core's side I believe network and storage are
>>  currently
>>  rather tightly coupled, which will make this far from trivial.

>> 

>>  Regardless, I am also hoping (with funding & a team) to build a
>>  Bitcrust
>>  networking component as well to bring a strong competitor to the
>>  market.
>> 

>>  best,

>>  Tomas

>> 

>> 

>> 

>> 

>> On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:

>>  > Hi Tomas,

>>  >

>>  > I've read it and think it is an excellent work, I'd like to see it
>>  > integrated into bitcoin-core as a 'kernel module'.

>>  >

>>  > I see there are a lot of proof of concepts out there, IMO
>>  > every one
>>  > deserve a room in the bitcoin client as a selectable feature, to
>>  > make the
>>  > software more flexible and less dictatorial, an user could easily
>>  > select
>>  > which features she wants to run.

>>  >

>>  > Best regards,

>>  > Marcos

>>  >

>>  > > I have been working on a bitcoin implementation that uses a
>>  > > different
>>  > > approach to indexing for verifying the order of transactions.
>>  > > Instead of
>>  > > using an index of unspent outputs, double spends are verified by
>>  > > using a
>>  > > spend-tree where spends are scanned against spent outputs
>>  > > instead of
>>  > > unspent outputs.

>>  > >

>>  > > This allows for much better concurrency, as not only blocks, but
>>  > > also
>>  > > individual inputs can be verified fully in parallel.

>>  > >

>>  > > I explain the approach at https://bitcrust.org, source code is
>>  > > available
>>  > > at https://github.com/tomasvdw/bitcrust

>>  > >

>>  > > I am sharing this not only to ask for your feedback, but also to
>>  > > call
>>  > > for a clear separation of protocol and implementations: As this
>>  > > solution, reversing the costs of outputs and inputs, seems to
>>  > > have
>>  > > excellent performance characteristics (as shown in the test
>>  > > results),
>>  > > updates to the protocol addressing the UTXO growth, might not be
>>  > > worth
>>  > > considering *protocol improvements* and it might be best to
>>  > > address
>>  > > these concerns as implementation details.

>>  > >

>>  > > Kind regards,

>>  > > Tomas van der Wansem

>>  > > to...@bitcrust.org

>>  > > Bitcrust

>>  > > ___

>>  > > 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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Erik Aronesty via bitcoin-dev]

It is *not proof of stake.* when:

a) burn happens regardless of whether you successfully mine.
b) miner cannot know which tx are burns
c) the majority of burns cannot be used for mining and are simply lost
(poisson discovery distribution)
d) burn involves real risk: *every bit as much at stake *

(It's the difference between a computer secured by not being connected to
the internet, and a computer secured by re-imaging from a computer that
was, in the past, not connected to the internet.)

It is possible to craft a burn-network such that the only way for a miner
to prevent a burn is to prevent all transactions other than his own.

This is still a weakness, and I can't see a way around it though.


On Fri, Apr 7, 2017 at 8:59 AM, Jannes Faber via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev  linuxfoundation.org> wrote:
>
>>
>> Ethically, this situation has some similarities to the DAO fork.
>>
>>
>> Much better analogy:
>>
>> 1. An ISV make software which makes use of an undocumented OS feature.
>> 2. That feature is no longer present in the next OS release.
>> 3. ISV suffers losses because its software cannot work under new OS, and
>> thus people stop buying it.
>>
>> I think 99% of programmers would agree that this loss was inflicted by a
>> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
>> undocumented features is something you do on your own risk.
>>
>
> Right. And in this case, code still is law: if the code specifies a
> version number field and some miner finds an optimization that only works
> when the version number == 1 then it's his own problem once the network
> upgrades to version 2. In no way is there anything ethical about blocking
> the upgrade.
>
> History is not an indicator of the possible values any field can hold in
> the future. Limiting your operation to some arbitrary subset is at your own
> risk.
>
> Regarding the comparison: I haven't heard anyone even suggest rolling back
> the last year of the blockchain to undo the damage already done, any
> comparison can end there. If Jonathan wants to persist with this comparison
> it would be more like people deciding to stop further funding of the hacked
> contract. Yeah, that evil.
>
> --
> Jannes Faber
>
>
> ___
> 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

[Greg Sanders via bitcoin-dev]

Interesting work.

I was wondering if you could tell us what specs for the machine being used
as preliminary benchmark is here: https://bitcrust.org/results ?

I'd be interested to also see comparisons with 0.14 which has some
improvements for script validation with more cores.

On Fri, Apr 7, 2017 at 4:47 AM, Tomas via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> Thank you Marcos,
>
> Though written in Rust, bitcrust-db is definitely usable as pluggable
> module as its interface will be roughly some queries, add_tx and
> add_block with blobs and flags. (Bitcrust internally uses a
> deserialize-only model, keeping references to the blobs with the parsed
> data).
>
> However, from Core's side I believe network and storage are currently
> rather tightly coupled, which will make this far from trivial.
>
> Regardless, I am also hoping (with funding & a team) to build a Bitcrust
> networking component as well to bring a strong competitor to the market.
>
> best,
> Tomas
>
>
>
> On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:
> > Hi Tomas,
> >
> > I've read it and think it is an excellent work, I'd like to see it
> > integrated into bitcoin-core as a 'kernel module'.
> >
> > I see there are a lot of proof of concepts out there, IMO every one
> > deserve a room in the bitcoin client as a selectable feature, to make the
> > software more flexible and less dictatorial, an user could easily select
> > which features she wants to run.
> >
> > Best regards,
> > Marcos
> >
> > > I have been working on a bitcoin implementation that uses a different
> > > approach to indexing for verifying the order of transactions. Instead
> of
> > > using an index of unspent outputs, double spends are verified by using
> a
> > > spend-tree where spends are scanned against spent outputs instead of
> > > unspent outputs.
> > >
> > > This allows for much better concurrency, as not only blocks, but also
> > > individual inputs can be verified fully in parallel.
> > >
> > > I explain the approach at https://bitcrust.org, source code is
> available
> > > at https://github.com/tomasvdw/bitcrust
> > >
> > > I am sharing this not only to ask for your feedback, but also to call
> > > for a clear separation of protocol and implementations: As this
> > > solution, reversing the costs of outputs and inputs, seems to have
> > > excellent performance characteristics (as shown in the test results),
> > > updates to the protocol addressing the UTXO growth, might not be worth
> > > considering *protocol improvements* and it might be best to address
> > > these concerns as implementation details.
> > >
> > > Kind regards,
> > > Tomas van der Wansem
> > > to...@bitcrust.org
> > > Bitcrust
> > > ___
> > > 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] Draft BIP: Version bits extension with guaranteed lock-in

[Ryan Grant via bitcoin-dev]

The primary failure mode of a user's misconfiguration of nTimeout will
be a stopped chain.

If less-sophisticated users are offered these configuration settings
then chaintip progress failures that result from them should be
prominently displayed.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Jannes Faber via bitcoin-dev]

On 6 April 2017 at 19:13, Alex Mizrahi via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

>
> Ethically, this situation has some similarities to the DAO fork.
>
>
> Much better analogy:
>
> 1. An ISV make software which makes use of an undocumented OS feature.
> 2. That feature is no longer present in the next OS release.
> 3. ISV suffers losses because its software cannot work under new OS, and
> thus people stop buying it.
>
> I think 99% of programmers would agree that this loss was inflicted by a
> bad decision of ISV, and not by OS vendor changing OS internals. Relying on
> undocumented features is something you do on your own risk.
>

Right. And in this case, code still is law: if the code specifies a version
number field and some miner finds an optimization that only works when the
version number == 1 then it's his own problem once the network upgrades to
version 2. In no way is there anything ethical about blocking the upgrade.

History is not an indicator of the possible values any field can hold in
the future. Limiting your operation to some arbitrary subset is at your own
risk.

Regarding the comparison: I haven't heard anyone even suggest rolling back
the last year of the blockchain to undo the damage already done, any
comparison can end there. If Jonathan wants to persist with this comparison
it would be more like people deciding to stop further funding of the hacked
contract. Yeah, that evil.

--
Jannes Faber
___
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

[Tomas via bitcoin-dev]

Thank you Marcos,

Though written in Rust, bitcrust-db is definitely usable as pluggable
module as its interface will be roughly some queries, add_tx and
add_block with blobs and flags. (Bitcrust internally uses a
deserialize-only model, keeping references to the blobs with the parsed
data).  

However, from Core's side I believe network and storage are currently
rather tightly coupled, which will make this far from trivial.

Regardless, I am also hoping (with funding & a team) to build a Bitcrust
networking component as well to bring a strong competitor to the market.

best,
Tomas



On Fri, Apr 7, 2017, at 09:55, Marcos mayorga wrote:
> Hi Tomas,
> 
> I've read it and think it is an excellent work, I'd like to see it
> integrated into bitcoin-core as a 'kernel module'.
> 
> I see there are a lot of proof of concepts out there, IMO every one
> deserve a room in the bitcoin client as a selectable feature, to make the
> software more flexible and less dictatorial, an user could easily select
> which features she wants to run.
> 
> Best regards,
> Marcos
> 
> > I have been working on a bitcoin implementation that uses a different
> > approach to indexing for verifying the order of transactions. Instead of
> > using an index of unspent outputs, double spends are verified by using a
> > spend-tree where spends are scanned against spent outputs instead of
> > unspent outputs.
> >
> > This allows for much better concurrency, as not only blocks, but also
> > individual inputs can be verified fully in parallel.
> >
> > I explain the approach at https://bitcrust.org, source code is available
> > at https://github.com/tomasvdw/bitcrust
> >
> > I am sharing this not only to ask for your feedback, but also to call
> > for a clear separation of protocol and implementations: As this
> > solution, reversing the costs of outputs and inputs, seems to have
> > excellent performance characteristics (as shown in the test results),
> > updates to the protocol addressing the UTXO growth, might not be worth
> > considering *protocol improvements* and it might be best to address
> > these concerns as implementation details.
> >
> > Kind regards,
> > Tomas van der Wansem
> > to...@bitcrust.org
> > Bitcrust
> > ___
> > 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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[praxeology_guy via bitcoin-dev]

Daniele Pinna,

Can you please not forget to supply us more details on the claims made 
regarding the reverse engineering of the Asic chip?

gmaxwell told me that back even in S7 chips its possible to set the SHA256 
midstate/IV instead of just resetting it to the standard SHA256 IV. This 
essentially allows you to re-use midstates, which is one of the key necessary 
features for the ASICBOOST optimization to work. From the chip's perspective 
there is not much difference between the covert and overt optimization methods, 
particularly given that the whole IV/midstate vector can be set.

The covert method just requires more work than the overt method:. overt you 
just permutate the version bits, vs the covert one requires you find partial 
hash collisions of the tx merkle root. The extra work to find the partial tx 
merkle root hash collisions could be done at different stages in the mining 
system... some speculate that it could be done in the miner's FPGA.

Not sure how exactly gmaxwell (or his friend) did it. I don't currently own any 
mining hardware nor the time to do it myself.

Cheers,
Praxeology Guy___
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

[Marcos mayorga via bitcoin-dev]

Hi Tomas,

I've read it and think it is an excellent work, I'd like to see it
integrated into bitcoin-core as a 'kernel module'.

I see there are a lot of proof of concepts out there, IMO every one
deserve a room in the bitcoin client as a selectable feature, to make the
software more flexible and less dictatorial, an user could easily select
which features she wants to run.

Best regards,
Marcos

> I have been working on a bitcoin implementation that uses a different
> approach to indexing for verifying the order of transactions. Instead of
> using an index of unspent outputs, double spends are verified by using a
> spend-tree where spends are scanned against spent outputs instead of
> unspent outputs.
>
> This allows for much better concurrency, as not only blocks, but also
> individual inputs can be verified fully in parallel.
>
> I explain the approach at https://bitcrust.org, source code is available
> at https://github.com/tomasvdw/bitcrust
>
> I am sharing this not only to ask for your feedback, but also to call
> for a clear separation of protocol and implementations: As this
> solution, reversing the costs of outputs and inputs, seems to have
> excellent performance characteristics (as shown in the test results),
> updates to the protocol addressing the UTXO growth, might not be worth
> considering *protocol improvements* and it might be best to address
> these concerns as implementation details.
>
> Kind regards,
> Tomas van der Wansem
> to...@bitcrust.org
> Bitcrust
> ___
> 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] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Alex Mizrahi via bitcoin-dev]

> Can you please not forget to supply us more details on the claims made
> regarding the reverse engineering of the Asic chip?
>
> It is absolutely crucial that we get these independently verified ASAP.
>

Bitmain confirmed that their chips support ASICBOOST and it can be used for
mining:

https://blog.bitmain.com/en/regarding-recent-allegations-smear-campaigns/

They claim that they don't use it on mainnet, but that claim cannot be
verified. it is possible to do covert ASICBOOST in a 100% covert manner.
(It can be done without "transaction reordering" so it's not worth
analyzing blocks etc.)
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on the Bitcoin POW function

[Emilian Ursu via bitcoin-dev]

The fact that this is possible should be enough for us to implement 
meassures against it.


On Fri, 7 Apr 2017, Daniele Pinna via bitcoin-dev wrote:



Can you please not forget to supply us more details on the claims made 
regarding the reverse engineering of the Asic chip?

It is absolutely crucial that we get these independently verified ASAP.

Daniele

  Message: 2
  Date: Thu, 6 Apr 2017 21:38:31 +
  From: Gregory Maxwell 
  To: Bitcoin Dev 
  Subject: Re: [bitcoin-dev] BIP proposal: Inhibiting a covert attack on
          the     Bitcoin POW function
  Message-ID: