I've been following the discussion of the block size limit and IMO it
is clear that any constant block size limit is, as many have said
before, just kicking the can down the road.
My problem with the dynamic lower limit solution based on past blocks
is that it doesn't account for usage spikes. I
He also said that the equation for miners has many variables, as it
should. There is no disadvantage if the network speed is the same
between the miners. If there is a difference in network speed, the
miner is incentivized to invest in their network infrastructure.
2015-05-31 23:55 GMT+01:00 Alex
2015-06-01 0:40 GMT+01:00 Pindar Wong pindar.w...@gmail.com:
On Mon, Jun 1, 2015 at 7:23 AM, Ricardo Filipe ricardojdfil...@gmail.com
wrote:
He also said that the equation for miners has many variables, as it
should. There is no disadvantage if the network speed is the same
between
i guess you look at the glass half full :)
even though what you say is true, we should aim for wallets not to
require those instructions, by standardizing these things in BIPs.
let's hope bitcoin doesn't fail in standards as our industries have in
the past...
2015-03-11 19:04 GMT+00:00 Jim
-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Ricardo Filipe
GSD/INESC-ID Lisboa
--
Dive into the World of Parallel Programming The Go
anyway, any kind of compression that comes to the blockchain is
orthogonal to pruning.
I agree that you will probably want some kind of replication on more
recent nodes than on older ones. However, nodes with older blocks
don't need to be static, get the block distribution algorithm to
sort it
that's what blockchain pruning is all about :)
2014-04-10 17:47 GMT+01:00 Brian Hoffman brianchoff...@gmail.com:
Looks like only about ~30% disk space savings so I see your point. Is there
a critical reason why blocks couldn't be formed into superblocks that are
chained together and nodes
Or have blocks distributed through pruned nodes as a DHT.
2014-04-07 20:13 GMT+01:00 Mark Friedenbach m...@monetize.io:
On 04/07/2014 12:20 PM, Tamas Blummer wrote:
Validation has to be sequantial, but that step can be deferred until the
blocks before a point are loaded and continous.
And
2014-04-07 21:08 GMT+01:00 Troy Benjegerdes ho...@hozed.org:
I have to play dissenter here again..
Using a bitcoin address as a persistent identity key is the first real-world
use of Bitcoin that I can imagine will make it a 'killer app' that everyone
and their grandma will want to use.
I
Kevin,
the thing is you gave us a bad link... what is the correct URL of your project?
2014-04-02 16:30 GMT+01:00 Kevin kevinsisco61...@gmail.com:
On 4/2/2014 11:13 AM, Laszlo Hanyecz wrote:
Maybe this site serves up exploits selectively? I'm guessing most people
are getting the 'domain for
2014-03-25 13:49 GMT+00:00 Peter Todd p...@petertodd.org:
On Tue, Mar 25, 2014 at 08:45:00AM -0400, Gavin Andresen wrote:
On Tue, Mar 25, 2014 at 8:28 AM, Peter Todd p...@petertodd.org wrote:
Bitcoin doesn't scale. There's a lot of issues at hand here, but the
most fundemental of them is
so much discussion for a visual update...
make this a user experiment:
-give the user the possibility to use BTC/mBTC/uMTC
-retrieve the results after some time
-make the default the most used option
2014-03-14 16:15 GMT+00:00 Alex Morcos mor...@gmail.com:
I think Mark makes some good
We would only end up with few copies of the historic data if users
could choose what parts of the blockchain to store. Simply store
chunks randomly, according to users available space, and give priority
to the N most recent chunks to have more replicas in the network.
You don't need bittorrent
13 matches
Mail list logo
