Granted that removing the 21M coin cap is basically a non-starter in de
bitcoin community I'd like to respond to a couple points in your proposal.
The Y% difficulty adjustment should still be calculated through some
averaging of a certain number N of past blocks. Otherwise two lucky high
Maybe I'm getting this wrong but wouldn't this scheme imply that a miner is
incentivized to limit the amount of transactions in a block to capture the
maximum fee of the ones included?
As an example, mined blocks currently carry ~0.8 btc in fees right now. If
I were to submit a transaction paying
Also how is this not a tax on coin holders? By forcing people to move
coins around you would be chipping away at their wealth in the form of
extorted TX fees.
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
I couldn't agree more. It would require however for the Devs to throw their
weight behind this with a lot of momentum. Spoonnet has been under
development for quite some time now. Counter offering SegWit plus Spoonnet
12-24 months later would be a very progressive stance that I think would
catch
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
>
Your BIP implementation should stress the capacity to softfork the rate of
blocksize increase if necessary. You briefly mention that:
*If over time, this growth factor is beyond what the actual technology
offers, the intention should be to soft fork a tighter limit.*
However this can work both
in against their will?
Daniele
On Dec 10, 2016 6:39 PM, "Pieter Wuille" <pieter.wui...@gmail.com> wrote:
> On Sat, Dec 10, 2016 at 4:23 AM, Daniele Pinna via bitcoin-dev <
> bitcoin-dev@lists.linuxfoundation.org> wrote:
>
>> We have models for estimating the probability th
We have models for estimating the probability that a block is orphaned
given average network bandwidth and block size.
The question is, do we have objective measures of these two quantities?
Couldn't we target an orphan_rate < max_rate?
On Dec 10, 2016 1:01 PM,
This seems unnecessarily complicated ("don't use cannon to kill mosquito"
kind of thing). If the community were interested in a realtime hashrate
rebalancing proposal one could simply adjust difficulty at each new block
using the current method.
If faster relaxation in case of adversity is
If SegWit were implemented as a hardfork, could the entire blockchain be
reorganized starting from the Genesis block to free up historical space?
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
My paper did show that the advantage decreased with the block reward.
However, in that limit, it also seemed to imply that a network state would
appear where the revenue per unit hash decreased with increasing hashrate
which should be impossible as just discussed.
In a followup email, I showed
-in-Uncapped-Block-Size-Fee-Markets
Daniele Pinna, Ph.D
On Thu, Aug 27, 2015 at 12:59 AM, Tom Harding t...@thinlink.com wrote:
Thanks for posting this. I'm very interested to read your paper when it
is available.
On 8/26/2015 3:22 PM, Daniele Pinna via bitcoin-dev wrote:
I don't get how it's very
However, that is outside the scope of the result that an individual
miner's profit per block is always maximized at a finite block size Q* if
Shannon Entropy about each transaction is communicated during the block
solution announcement. This result is important because it explains how a
minimum
Since my longer post seems to be caught in moderator purgatory I will
rehash its results into this much smaller message. I apologize for the
spamming.
I present a theorem whose thesis is obvious to many.
*THESIS: All hashrates* *h' h generate a revenue per unit of hash v'
v. *
Let us
I don't get how it's very risky to have the Mike and Gavin redirect the
course of the bitcoin protocol but it's totally fine to consider complex
miner voting protocols as a hard fork option.
I believe that this community has not given due weight to the analysis
proposed by Peter__R on the
15 matches
Mail list logo