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
difficult
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
https://lists.linuxfounda
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 th
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
What about periodically committing the entire UTXO set to a special
checkpoint block which becomes the new de facto Genesis block?
Daniele
--
Message: 5
Date: Wed, 29 Mar 2017 16:41:29 +
From: Andrew Johnson
To: David Vorick
Cc: Bitcoin Dev
Subject: Re: [bitcoi
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 wa
ged in against their will?
Daniele
On Dec 10, 2016 6:39 PM, "Pieter Wuille" 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 that a block is or
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,
wrote:
Send bitcoin-dev mailing
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 require
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
https://lists.linuxfoundation.org/mailman/
Interesting! I didn't notice BIP 99's anti-miner hardfork proposal
thanks for pointing it out to me.
Dpinna
Daniele Pinna, Ph.D
On Fri, Oct 2, 2015 at 10:20 AM, Jorge Timón wrote:
>
> On Oct 2, 2015 10:03 AM, "Daniele Pinna via bitcoin-dev" <
> bitcoin-dev@
om memory hard.
>
> Adam
>
> On 2 October 2015 at 10:02, Daniele Pinna via bitcoin-dev
> wrote:
> > The following paper proposing an asymmetric memory-hard PoW had been
> > recently published:
> >
> > http://eprint.iacr.org/2015/946.pdf
> >
> >
The following paper proposing an asymmetric memory-hard PoW had been
recently published:
http://eprint.iacr.org/2015/946.pdf
My intent is not to promote the paper as I have not finished studying it
myself. I am however interested in the dev-list's stance on potentially
altering the bitcoin PoW pr
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 how
"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 f
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 absurdl
s-in-Uncapped-Block-Size-Fee-Markets
Daniele Pinna, Ph.D
On Thu, Aug 27, 2015 at 12:59 AM, Tom Harding 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'd like to submit this paper to the dev-list which analyzes how miner
advantages scale with network and mempool properties in a scenario of
uncapped block sizes. The work proceeds, in a sense, from where Peter R's
work left off correcting a mistake and addressing the critiques made by the
communit
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 existenc
"I ran some simulations, and if blocks take 20 seconds to propagate, a
network with a miner that has 30% of the hashing power will get 30.3% of
the blocks."
Peter_R's analysis of fee markets in the absence of blocksize limits [1]
shows that the hashrate advantage of a large miner is a side-effect
21 matches
Mail list logo
