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

Thank you for your elaborate response Eric, On Sun, Apr 9, 2017, at 00:37, Eric Voskuil wrote: > My point was that "Using a storage engine without UTXO-index" has been > done, and may be a useful reference, not that implementation details > are the same. I haven't dived into libbitcoin V2/V3

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/06/2017 05:17 PM, Tomas wrote: > Thanks, but I get the impression that the similarity is rather > superficial. My point was that "Using a storage engine without UTXO-index" has been done, and may be a useful reference, not that

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

On Sun, Apr 9, 2017, at 00:12, Gregory Maxwell wrote: > In Bitcoin Core the software _explicitly_ and intentionally does not > exploit mempool pre-validation because doing that very easily leads to > hard to detect consensus faults and makes all mempool code consensus > critical when it

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

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

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

Pavel, > I agree. I only wanted to make clear, that the impact would be > significant. Lot of parties would be involved with nonequivalent > starting positions. > > I agree with you. I believe nonequivalent starting positions are the norm in mining, not the exception and hence don't believe this

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

On Sat, Apr 8, 2017 at 8:21 PM, Johnson Lau wrote: > pre-synced means already in mempool and verified? Then it sounds like we just > need some mempool optimisation? The tx order in a block is not important, > unless they are dependent In Bitcoin Core the software _explicitly_

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

I would advise anyone worried about 'hard drive access' to order a 512GB NVME (pci-express interface) flash drive (or a laptop), and I expect the performance will make you wonder why you ever bothered with cloud. My (very brief) analysis of the performance of a full chain download on a new laptop

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

> Please no conspiracy theory like stepping on someone’s toes. I believe > it’s always nice to challenge the established model. However, as I’m > trying to make some hardfork design, I intend to have a stricter UTXO > growth limit. As you said "protocol addressing the UTXO growth, might not > be

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

Eric Voskuil, TL;DR: Electrical power is a general purpose consumer good vs PoW mining equipment is a single purpose consumer good. Hence the mining equipment rent is the barrier to entry, given if you invest in power generation capital you could use the power for a different purpose. Each

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

> On 9 Apr 2017, at 03:56, Tomas wrote: > > >> I don’t fully understand your storage engine. So the following deduction >> is just based on common sense. >> >> a) It is possible to make unlimited number of 1-in-100-out txs >> >> b) The maximum number of 100-in-1-out txs is

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

> I don’t fully understand your storage engine. So the following deduction > is just based on common sense. > > a) It is possible to make unlimited number of 1-in-100-out txs > > b) The maximum number of 100-in-1-out txs is limited by the number of > previous 1-in-100-out txs > > c) Since

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

On Sat, Apr 8, 2017, at 20:27, Tom Harding via bitcoin-dev wrote: > > > On Apr 7, 2017 12:42, "Gregory Maxwell" wrote: >> On Fri, Apr 7, 2017 at 6:52 PM, Tom Harding via bitcoin-dev >> wrote: >> > A network in which many nodes

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

> On 8 Apr 2017, at 15:28, Tomas via bitcoin-dev > wrote: >> > > I think you are being a bit harsh here . I am also clearly explaining > the difference only applies to peak load, and just making a suggestion. > I simply want to stress the importance of

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

-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On 04/08/2017 11:15 AM, praxeology_guy via bitcoin-dev wrote: > ASICBOOST causes Bitcoin's PoW to become more memory/latency > throttled instead of raw computation throttled. > > There is the equation: Power Cost + Captial Rent + Labor ~= block >

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

On Apr 7, 2017 12:42, "Gregory Maxwell" wrote: 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

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

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,

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

Jimmy, >> Until all miners update (firmware or hardware), the change encourages >> large difference in mining efficiency. And IMO it gives another >> advantage to large mining operations in general. > > Certainly, there would have to be changes for stratum, pool software, etc. > But the monetary

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

On 8 Apr 2017 5:06 am, "Jimmy Song via bitcoin-dev" < bitcoin-dev@lists.linuxfoundation.org> 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

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

> > > No, it isn't allowed right now. Doing it wouldn't invalidate blocks, but it > would clearly be an attack on the network and cause harm. The same as if > miners were to maliciously mine only empty blocks. > > What's your definition of "allowed" then? Because a miner definitely can mine only

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

> > I think it might be important that the mandatory commitment expire as in > Greg's proposal - when we do eventually hardfork, it will be simpler to do > in > a safe manner if such a commitment in the fake "old block" is not required. > OK, that makes sense. I'll modify my proposal this way:

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

Yes, you only need a few bits in the version number, probably less than 8. If you encourage the overt method of using AsicBoost I would argue that you no longer need to dis-encourage the couvert method anymore as in Greg's proposal. Nobody would use the couvert method anyway because the overt

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

On Saturday, April 08, 2017 3:17:47 PM Jimmy Song wrote: > Overt ASICBoost is allowed on the network already. Until a proposal > explicitly blocking overt ASICBoost as a soft fork is activated, this seems > to be better than the current state which is that overt ASICBoost is > allowed, but at a

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

I think it might be important that the mandatory commitment expire as in Greg's proposal - when we do eventually hardfork, it will be simpler to do in a safe manner if such a commitment in the fake "old block" is not required. I don't like your proposal because it allows ASICBoost. ASICBoost

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

Pavel, Until all miners update (firmware or hardware), the change encourages > large difference in mining efficiency. And IMO it gives another > advantage to large mining operations in general. > Certainly, there would have to be changes for stratum, pool software, etc. But the monetary

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

> Second, we can make this change relatively quickly. Most of the Segwit > testing stays valid and this change can be deployed relatively quickly. It is true only for nodes software. Most of the world's mining infrastructure (at least for pool mining) is not ready for such change. Current

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

On Sat, Apr 8, 2017, at 02:44, Gregory Maxwell wrote: > As you note that the output costs still bound the resource > requirements. Resource cost is not just a measure of storage requirement; data that needs to be accessed during peak load induce more cost then data only used during base load or