Re: [bitcoin-dev] Unlimited Max Blocksize (reprise)

-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

Re: [bitcoin-dev] A Transaction Fee Market Exists Without a Block Size Limit--new research paper suggests

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

[bitcoin-dev] ERRATA CORRIGE + Short Theorem

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

[bitcoin-dev] Unlimited Max Blocksize (reprise)

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

Re: [bitcoin-dev] ERRATA CORRIGE + Short Theorem

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

Re: [bitcoin-dev] Capacity increases for the Bitcoin system.

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

Re: [bitcoin-dev] bitcoin-dev Digest, Vol 10, Issue 13

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

Re: [bitcoin-dev] Three hardfork-related BIPs

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

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

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,

Re: [bitcoin-dev] Managing block size the same way we do difficulty (aka Block75)

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

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

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 >

Re: [bitcoin-dev] UTXO growth scaling solution proposal

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

Re: [bitcoin-dev] Barry Silbert segwit agreement

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

Re: [bitcoin-dev] Rebatable fees & incentive-safe fee markets

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

Re: [bitcoin-dev] Some thoughts on removing timestamps in PoW

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