Bitcoin Forum
December 08, 2016, 06:28:21 PM *
News: Latest stable version of Bitcoin Core: 0.13.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 »  All
  Print  
Author Topic: Ultimate blockchain compression w/ trust-free lite nodes  (Read 68610 times)
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
June 18, 2013, 01:57:04 PM
 #381

Why can the miner not use the block-headers only to verify, that he's on the right chain? Is there a reason all the already spent transactions of the past have to be stored somewhere?

Only reading the headers you can only tell, which one is the longest chain if you receive several of them. But you want the longest VALID chain.
Here longest is the chain with more proof of work.
You have to validate all transactions to be able to know that the chain is following the protocol rules.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
1481221701
Hero Member
*
Offline Offline

Posts: 1481221701

View Profile Personal Message (Offline)

Ignore
1481221701
Reply with quote  #2

1481221701
Report to moderator
1481221701
Hero Member
*
Offline Offline

Posts: 1481221701

View Profile Personal Message (Offline)

Ignore
1481221701
Reply with quote  #2

1481221701
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1481221701
Hero Member
*
Offline Offline

Posts: 1481221701

View Profile Personal Message (Offline)

Ignore
1481221701
Reply with quote  #2

1481221701
Report to moderator
1481221701
Hero Member
*
Offline Offline

Posts: 1481221701

View Profile Personal Message (Offline)

Ignore
1481221701
Reply with quote  #2

1481221701
Report to moderator
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
July 09, 2013, 07:00:18 PM
 #382

So this was "merged" with another topic... I'm not really sure what that means or why it happened.  But I'm not finding the most recent posts.   The last one I see is June 18.  Any idea what happened?  Any way to get all the posts since then?

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
erk
Sr. Member
****
Offline Offline

Activity: 406



View Profile
October 10, 2013, 08:40:04 PM
 #383

I just installed a fresh copy of Bitcoin-Qt v0.85-beta, and it's taken 2 full days so far to download the block chain with 10-20 peers most of the time, and it's still only up to August. This strikes me as something wrong, if I were running a pool or exchange it would be a disaster and I would have lots of unhappy users. Not only does the block chain size need to be looked into, but the replication method. If I were trying to download the same size data using .torrent it would have finished in hours, not days.
altsay
Sr. Member
****
Offline Offline

Activity: 333


View Profile
December 06, 2013, 08:47:36 AM
 #384

I wonder isnt it possible to copy the up-to-date blockchain in the configuration folder and paste it to another computer.

Thank me || accuse me...with evidence.
ShadowOfHarbringer
Legendary
*
Offline Offline

Activity: 1470


Bringing Legendary Har® to you since 1952


View Profile
December 06, 2013, 10:52:55 AM
 #385

I wonder isnt it possible to copy the up-to-date blockchain in the configuration folder and paste it to another computer.
Yep, already done. Several times.

But (obviously) stop Bitcoin client first.

maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
December 20, 2013, 02:07:17 AM
 #386

I have posted to the development mailing list the first draft of a BIP for a binary authenticated prefex tree derivative of the one described in this thread. This starts the process of getting it turned into an official BIP standard. The draft is available for viewing here:

https://github.com/maaku/bips/blob/master/drafts/auth-trie.mediawiki

All comments and criticisms are welcome.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
sugarpuff
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
March 05, 2014, 06:58:15 PM
 #387

Could etotheipi negativeone (I *just* realized what that says!) or someone knowledgeable comment on how the "rolling-root"/"ledger-solution" impacts this proposal (whether it enhances it, makes it unnecessary, or is wrong for reasons XYZ)?

Summary: keep the blockchain down to some finite size by moving unspent transactions out of old blocks and into new ones at the head via a "rolling-root" mechanism.

Relevant link: https://bitcointalk.org/index.php?topic=501039

Raize
Donator
Legendary
*
Offline Offline

Activity: 1375


View Profile
March 05, 2014, 08:14:06 PM
 #388

I have posted to the development mailing list the first draft of a BIP for a binary authenticated prefex tree derivative of the one described in this thread. This starts the process of getting it turned into an official BIP standard. The draft is available for viewing here:

https://github.com/maaku/bips/blob/master/drafts/auth-trie.mediawiki

All comments and criticisms are welcome.

I guess my only comment right now is why doesn't this have a BIP number assigned to it? Due to the hard fork requirements?

OrganofCorti's Neighbourhood Pool Watch - The most informative website on blockchain health
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
March 05, 2014, 08:55:57 PM
 #389

Because I don't assign BIP numbers. There's a process to getting a BIP number assigned, which I am still working towards.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
jtimon
Legendary
*
Offline Offline

Activity: 1246


View Profile WWW
March 05, 2014, 08:58:28 PM
 #390

Due to the hard fork requirements?

This would be a softfork, not a hardfork. Meaning that a majority of miners must update, but not all users.

2 different forms of free-money: Freicoin (free of basic interest because it's perishable), Mutual credit (no interest because it's abundant)
sugarpuff
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
June 18, 2014, 10:34:49 PM
 #391

Could somebody here knowledgeable about the details of UTXO please confirm whether my understanding of how it would work in practice is correct?

maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
June 18, 2014, 10:55:25 PM
 #392

You never ever under any circumstances want to be mining on top of a chain you have not validated the entire history of.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
doldgigger
Full Member
***
Offline Offline

Activity: 170


View Profile
June 18, 2014, 11:38:10 PM
 #393

Before I read this I just want to quickly post that I personally, no matter whether justifiably or unjustifiably, I personally feel like this is the most pressing issue when it comes to Bitcoin's successful future and I really hope the core team has planed an order of priorities accordingly.

Why pressing? The blockchain is easy to understand and verify. And the practically required size might be reduced by imposing a fee on old inputs, which would lead to implementors of wallet software implementing per-wallet compression strategies in order to avoid the fee. Having some archival nodes with a full history still wouldn't hurt.

19orEcoqXQ5bzKbzbAnbQrCkQC5ahSh4P9
Feel free to PM me for consulting and development services.
sugarpuff
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
June 19, 2014, 12:51:02 AM
 #394

You never ever under any circumstances want to be mining on top of a chain you have not validated the entire history of.

Interesting point. Hope you don't mind if I mention your reply in that other thread as well.

So, what is the takeaway from that then? That new lite-nodes can use UTXO to validate arbitrary queries, but they cannot participate in securing the network until they have all the transactions for the leaf nodes of the entire UTXO tree?

maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
June 19, 2014, 03:09:13 AM
 #395

no it's worse than that -- you have to download and process every single block since Genesis. otherwise you may be on an invalid chain and not even know it.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
sugarpuff
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
June 19, 2014, 03:19:10 AM
 #396

no it's worse than that -- you have to download and process every single block since Genesis. otherwise you may be on an invalid chain and not even know it.

Can you explain why that is?

If what you're saying is true, then the rolling root is still needed for Bitcoin's future feasibility and safety: http://hackingdistributed.com/2014/06/18/how-to-disincentivize-large-bitcoin-mining-pools/#comment-1442133143

maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
June 19, 2014, 04:27:18 AM
 #397

Sure I can, now that I'm at my computer instead of my phone Wink

The miner needs to verify the entire block chain history because otherwise he has no way of knowing if he is actually on a valid chain or not. This has nothing to do with UTXO commitments, rolling root, or any other proposal. It's a basic, fundamental requirement of any consensus system: if the miners themselves operate in SPV mode (which you advocate), then anyone -- no matter their hashrate! -- can trick the network into mining an invalid chain. The attacker does so by mining a fork with invalid history and temporarily (by luck or 51%) overcoming the honest network. New miners coming online, or miners tricked into reseting their state then switch to the invalid chain This completely invalidates the SPV assumption and makes it unsafe for anybody to use the network.

"Rolling root" doesn't even make sense in the context of bitcoin, as has been explained multiple times by multiple people in your own thread. Let's not bring that discussion here. If your goal is to minimize the amount of data required to bring new non-mining nodes online, then that is what UTXO commitments does.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
sugarpuff
Jr. Member
*
Offline Offline

Activity: 56


View Profile WWW
June 19, 2014, 04:48:56 AM
 #398

The miner needs to verify the entire block chain history because otherwise he has no way of knowing if he is actually on a valid chain or not. This has nothing to do with UTXO commitments, rolling root, or any other proposal. It's a basic, fundamental requirement of any consensus system: if the miners themselves operate in SPV mode (which you advocate)

Full stop. I have never advocated that. If you believe that, then you never understood the rolling root proposal.

I agree it's best to keep the threads separate. If you have questions about how rolling root works feel free to ask in the other thread.

Sticking to UTXO though, I don't believe you answered my question. UTXO is not SPV either, so it is still not clear to me why you say they don't know whether they're on a valid chain or not. They downloaded the headers from genesis (SPV), but in addition to that they downloaded the entire UTXO meta chain which they can then use to verify any txn and build the merkle/btree or w/e the latest data structure is.

doldgigger
Full Member
***
Offline Offline

Activity: 170


View Profile
June 19, 2014, 06:36:26 PM
 #399

no it's worse than that -- you have to download and process every single block since Genesis. otherwise you may be on an invalid chain and not even know it.

People might speed up that process by relying on checkpoint hashes built into the client. Since most cryptocurrency client software is developed using git (which also comes with a cryptographically secured history), detecting manipulations there is also practical in most cases.

19orEcoqXQ5bzKbzbAnbQrCkQC5ahSh4P9
Feel free to PM me for consulting and development services.
maaku
Legendary
*
expert
Offline Offline

Activity: 905


View Profile
June 19, 2014, 08:02:18 PM
 #400

Checkpoints are a temporary hack that will go away soon, we hope.

I'm an independent developer working on bitcoin-core, making my living off community donations.
If you like my work, please consider donating yourself: 13snZ4ZyCzaL7358SmgvHGC9AxskqumNxP
Pages: « 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 [20] 21 22 »  All
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!