Btw How awful that I didn't cite my sources, please exucse me, this is
definitely not my intention sometimes I get too caught up in my own
excitemtnt
1) Martin, J., Alvisi, L., Fast Byzantine Consensus. *IEEE Transactions on
Dependable and Secure Computing. 2006. *3(3) doi: Please see
John-Phill
Hllo
I want to build from a conversation that I had w/ Peter (T?) regarding the
increase in block size in the bitcoin from its's current structure would be
the proposasl of an prepend to the hash chain itself that would be the
first DER decoded script in order to verify integrity(trust) within a s
I think long-term the chain will not be secured purely by proof-of-work. I
think when the Bitcoin network was tiny running solely on people's home
computers proof-of-work was the right way to secure the chain, and the only
fair way to both secure the chain and distribute the coins.
See https://gis
On Monday, May 11, 2015 7:03:29 AM Sergio Lerner wrote:
> 1. It will encourage centralization, because participants of mining
> pools will loose more money because of excessive initial block template
> latency, which leads to higher stale shares
>
> When a new block is solved, that information nee
On 2015-05-11 16:28, Thomas Voegtlin wrote:
> My problem is that this seems to lacks a vision. If the maximal block
> size is increased only to buy time, or because some people think that 7
> tps is not enough to compete with VISA, then I guess it would be
> healthier to try and develop off-chain i
The discussion on block size increase has brought some attention to the
other elephant in the room: Long-term mining incentives.
Bitcoin derives its current market value from the assumption that a
stable, steady-state regime will be reached in the future, where miners
have an incentive to keep min
A reminder - feature freeze and string freeze is coming up this Friday the 15th.
Let me know if your pull request is ready to be merged before then,
Wladimir
On Tue, Apr 28, 2015 at 7:44 AM, Wladimir J. van der Laan
wrote:
> Hello all,
>
> The release window for 0.11 is nearing, I'd propose the
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille wrote:
> As softforks almost certainly require backports to older releases and other
> software anyway, I don't think they should necessarily be bound to Bitcoin
> Core major releases. If they don't require large code changes, we can easily
> do them
The propagation speed gain from having smaller blocks is linear in the size
reduction, down to a small size, after which the delay of the first byte
prevails [1], however the blockchain fork rate increases superlinearly,
giving an overall worse tradeoff. A high blockchain fork rate is a symptom
of
> On 11 May 2015, at 12:10, insecurity@national.shitposting.agency wrote:
>
> On 2015-05-11 10:34, Peter Todd wrote:
>> How do you see that blacklisting actually being done?
>
> Same way ghash.io was banned from the network when used Finney attacks
> against BetCoin Dice.
>
> As Andreas Antonop
On 2015-05-11 10:34, Peter Todd wrote:
> How do you see that blacklisting actually being done?
Same way ghash.io was banned from the network when used Finney attacks
against BetCoin Dice.
As Andreas Antonopoulos says, if any of the miners do anything bad, we
just ban them from mining. Any sort of
On Mon, May 11, 2015 at 04:03:29AM -0300, Sergio Lerner wrote:
> Arguments against reducing the block interval
>
> 1. It will encourage centralization, because participants of mining
> pools will loose more money because of excessive initial block template
> latency, which leads to higher stale sh
> So if the server pushes new block
> header candidates to clients, then the problem boils down to increasing
> bandwidth of the servers to achieve a tenfold increase in work
> distribution.
Most Stratum pools already do multiple updates of the header every block
period,
bandwidth is really incon
I proposed the same thing last year (there's a video of the presentation I was
giving somewhere around). My intuition was that this would require slowly
reducing the inter-block time, probably by step reductions at particular block
heights.
Having had almost a year to think about it some more t
Yes This!
So many people seem hung up on growing the block size! If gaining a higher tps
throughput is the main aim, I think that this proposition to speed up block
creation has merit!
Yes it will lead to an increase in the block chain still due to 1mb ~1 minute
instead of ~10 minute, but the
In this e-mail I'll do my best to argue than if you accept that
increasing the transactions/second is a good direction to go, then
increasing the maximum block size is not the best way to do it. I argue
that the right direction to go is to decrease the block rate to 1
minute, while keeping the bloc
16 matches
Mail list logo
