On Thu, Apr 10, 2014 at 3:24 PM, Jesus Cea wrote:
> On 11/04/14 00:15, Mark Friedenbach wrote:
>> Checkpoints will go away, eventually.
> Why?. The points in the forum thread seem pretty sensible.
Because with headers first synchronization the major problems that
they solve— e.g. block flooding D
On 11/04/14 00:15, Mark Friedenbach wrote:
> Checkpoints will go away, eventually.
Why?. The points in the forum thread seem pretty sensible.
--
Jesús Cea Avión _/_/ _/_/_/_/_/_/
j...@jcea.es - http://www.jcea.es/ _/_/_/_/ _/_/_/_/ _/_/
Twitter:
Checkpoints will go away, eventually.
On 04/10/2014 02:34 PM, Jesus Cea wrote:
> On 10/04/14 18:59, Pieter Wuille wrote:
>> It's important to
>> note that this is a strict reduction in security: we're now trusting
>> that the longest chain (with most proof of work) commits to a valid
>> UTXO set (
On 10/04/14 18:59, Pieter Wuille wrote:
> It's important to
> note that this is a strict reduction in security: we're now trusting
> that the longest chain (with most proof of work) commits to a valid
> UTXO set (at some point in the past).
AFAIK, current bitcoin code code already set blockchain c
On Thu, Apr 10, 2014 at 10:12 PM, Tier Nolan wrote:
> On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille
> wrote:
>>
>> If you trust hashrate for determining which UTXO set is valid, a 51%
>> attack becomes worse in that you can be made to believe a version of
>> history which is in fact invalid.
>
>
On Thu, Apr 10, 2014 at 7:32 PM, Pieter Wuille wrote:
> If you trust hashrate for determining which UTXO set is valid, a 51%
> attack becomes worse in that you can be made to believe a version of
> history which is in fact invalid.
>
If there are invalidation proofs, then this isn't strictly true
You took the quote out of context:
"a full node can copy the chain state from someone else, and check that
its hash matches what the block chain commits to. It's important to
note that this is a strict reduction in security: we're now trusting
that the longest chain (with most proof of work) commi
On Thu, Apr 10, 2014 at 8:19 PM, Paul Rabahy wrote:
> Please let me know if I have missed something.
A 51% attack can make you believe you were paid, while you weren't.
Full node security right now validates everything - there is no way
you can ever be made to believe something invalid. The only
You say UTXO commitments is "a strict reduction in security". If UTXO
commitments were rolled in as a soft fork, I do not see any new attacks
that could happen to a person trusting the committed UTXO + any remaining
blocks to catch up to the head.
I would imagine the soft fork to proceed similar t
Ok I think I've got a good understanding of where we're at now. I can
promise that the next person to waste your time in 30 days will not be me.
I'm pleasantly surprised to see a community that doesn't kickban newcomers
and takes the time to explain (re-explain) concepts.
Hoping to add *beneficial
On Thu, Apr 10, 2014 at 6:47 PM, Brian Hoffman wrote:
> 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 could serve a specific superblock, which could be
> pieced
Okay...will let myself out now ;P
On Thu, Apr 10, 2014 at 12:54 PM, Ricardo Filipe
wrote:
> that's what blockchain pruning is all about :)
>
> 2014-04-10 17:47 GMT+01:00 Brian Hoffman :
> > Looks like only about ~30% disk space savings so I see your point. Is
> there
> > a critical reason why bl
that's what blockchain pruning is all about :)
2014-04-10 17:47 GMT+01:00 Brian Hoffman :
> 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 could serve a specific
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 o
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 could serve a specific superblock, which could
be pieced together from different nodes to get the full blockchain? This
Suggestions always welcome!
The main problem with this is that the block chain is mostly random bytes
(hashes, keys) so it doesn't compress that well. It compresses a bit, but
not enough to change the fundamental physics.
However, that does not mean the entire chain has to be stored on expensive
This is probably just noise, but what if nodes could compress and store
earlier transaction sets (archive sets) and serve them up conditionally. So
if there were let's say 100 archive sets of (10,000 blocks) you might have
5 open at any time when you're an active archive node while the others sit
o
On Thu, Apr 10, 2014 at 2:10 PM, Gregory Maxwell wrote:
> But sure I could see a fixed range as also being a useful contribution
> though I'm struggling to figure out what set of constraints would
> leave a node without following the consensus? Obviously it has
> bandwidth if you're expecting t
On Thu, Apr 10, 2014 at 4:57 AM, Wladimir wrote:
> Just wondering: Would there be a use for a [static] node that, say, always
> serves only the first 10 blocks? Or, even, a static range like block
> 10 - 20?
The last time we discussed this sipa collected data based on how often
blocks
On Thu, Apr 10, 2014 at 1:37 PM, Mike Hearn wrote:
> Chain pruning is probably a separate thread, changing subject.
>
>
>> Reason is that the actual blocks available are likely to change
>> frequently (if
>> you keep the last week of blocks
>
>
> I doubt anyone would specify blocks to keep in ter
Chain pruning is probably a separate thread, changing subject.
> Reason is that the actual blocks available are likely to change frequently
> (if
> you keep the last week of blocks
I doubt anyone would specify blocks to keep in terms of time. More likely
it'd be in terms of megabytes, as that's
21 matches
Mail list logo
