El 10/05/2015 06:07 p.m., Gregory Maxwell escribió:
On Sun, May 10, 2015 at 8:45 PM, Sergio Lerner
sergioler...@certimix.com wrote:
Can the system by gamed?
Users can pay fees or a portion of fees out of band to miner(s); this
is undetectable to the network.
Then this is exactly what is
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
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
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 shares
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
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
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 Antonopoulos
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
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
laa...@gmail.com wrote:
Hello all,
The release window for 0.11 is nearing,
On Tue, Apr 28, 2015 at 11:01 AM, Pieter Wuille pieter.wui...@gmail.com 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
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
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
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
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
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 needs
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
17 matches
Mail list logo
