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 enou
-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 implementation
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 otherwise
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 ASI
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
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_ and intentionally
Thomas,
> the change is not opt-in and will require coordination; and the continuation
> of the chain thereafter depends on people actually running the hard-fork
> code, not just being aware there is something happening.
This situation applies to soft forks as well.
- if you wish your software
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
> 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 w
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 uni
> 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 limited by the numb
> 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 bitcr
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 maintain a transaction index also
>> > enables a
>> > cl
> 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 protocol / implementation
> separation as
-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
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 to prove existence and
> spentness of TXO's.
Only with
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 reward + fees
Capital Rent is a barrier to entry, and hence in desiring a more distributed
system, we would like to mini
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,
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 i
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 mo
>
>
> 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 em
>
> 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:
Be
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
meth
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 cos
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 eff
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 incentive
> 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 version
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 o
28 matches
Mail list logo