Bitcoin Forum
December 04, 2016, 02:33:24 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1]
  Print  
Author Topic: Safe Bitcoin blocks checkpointing  (Read 1339 times)
pent
Hero Member
*****
Offline Offline

Activity: 490



View Profile
March 25, 2012, 02:09:00 AM
 #1

I am a DIANNA developer. DIANNA uses Bitcoin chain as a base timestamp server and has built-in lightweight Bitcoin client based on BitcoinJ.

The primary target is make Bitcoin chain as thin as possible and safe enough simultaneously. I need an advice how to make it.

DIANNA really don't have to know what happened in Bitcoin some number of blocks ago. So I think to use Bitcoin checkpoints merged into secondary Merkle Tree in DIANNA block with hashes of checkpointed Bitcoin blocks:

genesis_hash chk1_hash@height1 chk2_hash@height2 ... chkN_hash@heightN

So the latest hash in this sequence can be considered as secondary-genesis where to start from.

The question is: how far it would be safe to make checkpoint from BitcoinCurrentBestHeight()?

I see some checkpoints in bitcoin code. But they are hardcoded and seems that there is no way to determine them automatically on new addition to this list.

So how is safe to do checkpointing every 100/1000/10000 blocks? What was the longest fork of Bitcoin chain?

Also some practical suggestions of similar procedures are welcome.

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

Posts: 1480862004

View Profile Personal Message (Offline)

Ignore
1480862004
Reply with quote  #2

1480862004
Report to moderator
1480862004
Hero Member
*
Offline Offline

Posts: 1480862004

View Profile Personal Message (Offline)

Ignore
1480862004
Reply with quote  #2

1480862004
Report to moderator
1480862004
Hero Member
*
Offline Offline

Posts: 1480862004

View Profile Personal Message (Offline)

Ignore
1480862004
Reply with quote  #2

1480862004
Report to moderator
DeathAndTaxes
Donator
Legendary
*
Offline Offline

Activity: 1218


Gerald Davis


View Profile
March 25, 2012, 04:05:26 AM
 #2

Not sure what the longest fork is but generated coins are not spendable for 120 blocks to ensure a fork can't result in spent coins being lost.
Haplo
Full Member
***
Offline Offline

Activity: 168



View Profile
March 25, 2012, 04:25:10 AM
 #3

There have been other proposals for things like this for BTC already. I'd say if your block generation rate is every 10 minutes like BTC, then a checkpoint every 144 blocks makes sense (24h).

Checkpointing can be done via a ledger to save space, and if done well it can save roughly 93% vs the blockchain. See this thread for more details on that.

If you want to increase the security of your checkpoints, you might use Meni's Proof-of-Stake system. It adds several advantages for stability of the main blockchain, helps protect against 51% attacks, and allows the checkpoints to be well agreed upon for historical purposes, esp for vendors wanting secure confirmation that a payment is absolutely final. Once a checkpoint block has been agreed upon and signed, the chances of it being reversed are virtually nil, especially if there were no competing branches at the time of signing. Relevant link.

I'm So Meta, Even This Acronym
jim618
Legendary
*
Offline Offline

Activity: 1708



View Profile WWW
March 25, 2012, 02:34:24 PM
 #4

Hi pent,

I notice you are adding in a bitcoinj based UI to your project.

Feel free to use any of the MultiBit code - it is all MIT licence.
As I expect you will be concentrating on the bitcoinj network/data layer it might save you a bit of time.

There are actions and jpanels for all the 'usual' things you want to do.
The best code is on the version 0.3 branch here:

https://github.com/jim618/multibit/tree/v0.3

I do not mind what you take and what you do with it as long as it stays open.

MultiBit HD   Lightweight desktop client.                    Bitcoin Solutions Ltd   Bespoke software. Consultancy.
pent
Hero Member
*****
Offline Offline

Activity: 490



View Profile
March 25, 2012, 02:40:49 PM
 #5

Thanks. But I don't use UI, just background threads of bitcoinj. Anyway, thanks for info.
Mike Hearn
Legendary
*
expert
Offline Offline

Activity: 1526


View Profile
March 26, 2012, 01:29:16 PM
 #6

Are you on the bitcoinj mailing list?

I just created an announcements list, it's probably a good idea for you to join it so you can keep up to date with new releases, if the dev list is too busy: bitcoinj-announce

DIANNA sounds a lot like NameCoin.

I didn't fully understand your question I'm afraid, but it sounds like you want to implement an alternative chain? It'd be good to have general support for that in the core library, if you're interested in contributing.
pent
Hero Member
*****
Offline Offline

Activity: 490



View Profile
March 26, 2012, 01:38:51 PM
 #7

DIANNA sounds a lot like NameCoin.
Actually it is very different. Like earth and sky.

I started to draw DIANNA design when i saw the NameCoin architecture is not vital. DIANNA designed to replace IANA and ICANN and hold billions of domains. DIANNA not a fork of Bitcoin (like NameCoin), but extension, as it uses Bitcoins as payment and Bitcoin chain as timestamp server. DIANNA is not vulnerable to 51% attack as long as Bitcoin isn't vulnerable.

I didn't fully understand your question I'm afraid, but it sounds like you want to implement an alternative chain? It'd be good to have general support for that in the core library, if you're interested in contributing.

Yes, It is alternative chain. Not linear like Bitcoin, but like a tree.

Well, thanks, I'll join to your mail list.
Pages: [1]
  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!