On 11/05/2015 04:25 p.m., Leo Wandersleb wrote:
> I assume that 1 minute block target will not get any substantial support but
> just in case only few people speaking up might be taken as careful
support of
> the idea, here's my two cents:
>
> In mining, stale shares depend on delay between pool/
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
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
gt; From: Sergio Lerner <mailto:sergioler...@certimix.com>
> Sent: 11/05/2015 5:05 PM
> To: bitcoin-development@lists.sourceforge.net
> <mailto:bitcoin-development@lists.sourceforge.net>
> Subject: [Bitcoin-development] Reducing the block rate instead of increasing
> the m
PM
To:
bitcoin-development@lists.sourceforge.net<mailto:bitcoin-development@lists.sourceforge.net>
Subject: [Bitcoin-development] Reducing the block rate instead of increasing
the maximum block size
In this e-mail I'll do my best to argue than if you accept that
increasing the transactions
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
10 matches
Mail list logo
