Spin-offs: bootstrap an altcoin with a btc-blockchain-based initial distribution

[Crestington]

Maybe someone might be able to give me a hand here in understanding what I am doing wrong when trying to make znorts Blockparser compatible for X13 Coins?

https://github.com/Crestington/blockparser

I changed the switch in makefile for PAYCON and when running it, it says it can't find any Blocks.

[1714006036]

1714006036

[1714006036]

1714006036

[1714006036]

1714006036

[1714006036]

1714006036

[YarkoL]

Maybe someone might be able to give me a hand here in understanding what I am doing wrong when trying to make znorts Blockparser compatible for X13 Coins?

https://github.com/Crestington/blockparser

I changed the switch in makefile for PAYCON and when running it, it says it can't find any Blocks.

I had a briefest of glance at your commit, and it seemed fine
except that adding uint256_t.h is unnecessary (you already got that).

Maybe it's just something with your data directory
or typo in magic numbers.

This is a bit off-topic anyway, so consider a separate thread.

[Bill White]

To be honest, this project has been fairly tedious, but I'm almost done with this part.

I can empathise.

I'm trying to resolve the discrepancies in our snapshots. In many cases one of us treated a txout as p2sh while the other treated it as a p2pkh. Also, for pubkey addresses, I checked that the public key is actually on the curve. Some of them aren't and I omitted them.

Here is an example I have not yet understood. It seems you treated the many pubkey txouts (e.g., vout 0, 1, 2, etc.) to tx
657aecafe66d729d2e2f6f325fcc4acb8501d8f02512d1f5042a36dd1bbd21d1
as p2pkh. However, they do not appear to have the correct format. I would expect them to be
41 04 x y OP_CHECKSIG
but it seems the "04" is missing (in spite of the fact that there are 65 bytes), so it's not clear what the "x" and "y" are. Do you know what you used as the x and y in these cases?

I hope to write up something small documenting the discrepancies once I understand most or all of them.

Edit (Dec 4 2015): I found out how you derived p2pkh addresses from the tx mentioned above. I was extracting x and y and then beginning the process of deriving a p2pkh address using "04 x y". It seems you take the literal 33 bytes given (even if it doesn't begin with 04) to start the process of deriving a p2pkh address. It seems blockchain.info and btc.blokr.io obtain p2pkh addresses the same way as you.

[Bill White]

I have finished analyzing the discrepancies between my snapshot and sfultong's. Details are available here:

https://mega.nz/#!UxZwGTBZ!5EoQyezyIu8wBTefINg9EuRNMN9JWE71bBIyukYNPK8

Here is a short summary. There were 9 kinds of discrepancies:

(A) 620 of the p2pkhs and 17 of the p2shs I omitted were because they had 0 balances.
(B) 438 superficially seem to be pubkey outputs, but are unspendable because the pubkey is ill-formed; I included them as p2sh while sfultong included them as p2pkh; I will now omit them.
(C) 10 p2sh sfultong omitted are unspendable raw scripts due to clear errors; I will now omit them as well.
(D) 4 are essentially p2pkh except with a OP_NOP at the end; I made them p2pkh while sfultong made them p2sh.
(E) 3 of the p2pkhs I omitted because the pubkey while formatted in an acceptable way was nevertheless not on the curve
(F) 2 of the p2pkh disagreements is because the balances were composed of one std p2pkh txout and one pubkey txout, but the pubkey one was invalid so I omitted that part of the balance. I now omit these two unspendable addresses altogether.
(G) 2 of the p2pkh disagreements is due to the duplicate txid bug for coinbase rewards (I made both spendable)
(H) 1 of the p2pkh disagreements is due to the genesis block reward (which I accepted as spendable)
(I) 1 of the p2shs I omitted was described by sfultong above: the unspendable 5 byte script 76a90088ac

A v2 of my snapshot omitting the unspendable addresses from (B), (C) and (F) is here:

https://mega.nz/#!IkBUzT5A!P4Ea4zLiJtnzFTHyqxyiNFZ00_N3E45Ra6LmFoVqCao

[sfultong]

Thanks Bill, your thoroughness is much appreciated.

Out of curiosity, I made a snapshot where I pruned all balances < 10000 satoshis, and the size was about half of the full snapshot.

[Crestington]

Thanks Bill, your thoroughness is much appreciated.

Out of curiosity, I made a snapshot where I pruned all balances < 10000 satoshis, and the size was about half of the full snapshot.

Are you able to detail how a snapshot is made?

[sfultong]

Sure thing. Sorry I didn't answer earlier.

It's a bit of a convoluted process. Had I known what I know now, I'd have based my code around a standalone leveldb parser.

1. Build and install https://github.com/sfultong/bitcoin-spinoff-toolkit
   You'll need to install libbitcoin as a dependency

2. Clone https://github.com/sfultong/bitcoin, switch to the "prune-chain" branch, and build that.
   You'll have to edit lines in src/Makefile.am (change ones containing "sfultong")

If you wish to take a snapshot at a particular height in the blockchain, you have to reindex, and also pass a -reindexLimit=x option to bitcoind, where x is the height you want.

Finally, you can run "bitcoin-cli writesnapshot" to create the actual snapshot file. The first repository has code for loading data from that.

You'll probably have difficulties/questions. Does anyone know automake/autotools? Ideally I'd like it if one didn't have to edit the Makefile.am

[Crestington]

Sure thing. Sorry I didn't answer earlier.

It's a bit of a convoluted process. Had I known what I know now, I'd have based my code around a standalone leveldb parser.

1. Build and install https://github.com/sfultong/bitcoin-spinoff-toolkit
   You'll need to install libbitcoin as a dependency

2. Clone https://github.com/sfultong/bitcoin, switch to the "prune-chain" branch, and build that.
   You'll have to edit lines in src/Makefile.am (change ones containing "sfultong")

If you wish to take a snapshot at a particular height in the blockchain, you have to reindex, and also pass a -reindexLimit=x option to bitcoind, where x is the height you want.

Finally, you can run "bitcoin-cli writesnapshot" to create the actual snapshot file. The first repository has code for loading data from that.

You'll probably have difficulties/questions. Does anyone know automake/autotools? Ideally I'd like it if one didn't have to edit the Makefile.am

What particular things would I need to do if I want to clone from one Altcoin to another?

I think taking snapshots offers a pruning update method for future protocols of existing Altcoins, and eventually Bitcoin as a measure of keeping accounts and balances after a period.

[YarkoL]

What particular things would I need to do if I want to clone from one Altcoin to another?

I'm interested in this as well...

The first thing to do is to port libbitcoin to handle altcoin.
This isn't so trivial, as the chain parameters aren't in one
place. Quite a few of them can be found in <bitcoin/bitcoin/constants.hpp>
but not all. In particular, I've had a hard time locating the base58 prefixes
(PUBKEY_ADDRESS etc)

[Crestington]

What particular things would I need to do if I want to clone from one Altcoin to another?

I'm interested in this as well...

The first thing to do is to port libbitcoin to handle altcoin.
This isn't so trivial, as the chain parameters aren't in one
place. Quite a few of them can be found in <bitcoin/bitcoin/constants.hpp>
but not all. In particular, I've had a hard time locating the base58 prefixes
(PUBKEY_ADDRESS etc)

I've been thinking about it in a way of a POS to POS chain however I think pruning would be important for all Blockchains as if most Blockchains were compact, it would solve many space issues in holding chains on low powered devices. I would think that in order to be fluid that it would need to create states and lodge unspent blocks to addresses along with their ages, old unspents get rolled over to new states as old ones are discarded. I think what I am thinking may be similar to Cryptonite mini-Blockchain scheme http://cryptonite.info/files/mbc-scheme-rev2.pdf

[TPTB_need_war]

... think pruning would be important for all Blockchains as if most Blockchains were compact, it would solve many space issues in holding chains on low powered devices. I would think that in order to be fluid that it would need to create states and lodge unspent blocks to addresses along with their ages, old unspents get rolled over to new states as old ones are discarded. I think what I am thinking may be similar to Cryptonite mini-Blockchain scheme http://cryptonite.info/files/mbc-scheme-rev2.pdf

Don't waste your time in that direction of pruning. Pruning is irrelevant [edit: bcz in a correct block chain design the nodes that need that info gain nothing from pruning and the other nodes don't need the TX data]. Sorry I don't have time to elaborate. My future actions will explain.

[Crestington]

... think pruning would be important for all Blockchains as if most Blockchains were compact, it would solve many space issues in holding chains on low powered devices. I would think that in order to be fluid that it would need to create states and lodge unspent blocks to addresses along with their ages, old unspents get rolled over to new states as old ones are discarded. I think what I am thinking may be similar to Cryptonite mini-Blockchain scheme http://cryptonite.info/files/mbc-scheme-rev2.pdf

Don't waste your time in that direction of pruning. Pruning is irrelevant. Sorry I don't have time to elaborate. My future actions will explain.

If you are going to post, atleast post why.

[bhokor]

why link the alt-coin blockchain to the bitcoin blockchain? clam distributions have showned us it have serious problems too

[sfultong]

I am happy to announce that my spinoff proof of concept is nearing completion. I have chosen litecoin to be the base for this proof of concept, because it has the biggest market cap after bitcoin (excluding ripple, of course).

The code is at https://github.com/sfultong/bitcoin.git, in the "blightcoin" branch.

I was envisioning that a version of every cryptocurrency could be created with a snapshot of the bitcoin ledger, and named by prefixing it with "bts", for bitcoin-spinoff-toolkit. Using litecoin, that gives us "bts-litecoin", or "blightcoin" for a phonetic contraction.

And really, that's my intention here: to create a blight that gets rid of the idea of starting new cryptocurrency without bootstrapping it with an existing ledger.

This is not a release. I still have to change all the mentions of "litecoin" in the project to "blightcoin", build binaries for different platforms, maybe create a site for the project, find some people to be trusted seeds for the network, etc.

[jbreher]

blightcoin. That's lulzy.

Interested to see what happens. Is this approach applicable to spinning off all/most POW coins? POS? Others?

[sfultong]

Yes. This approach should be applicable for pretty much any blockchain.

I kinda cheated for blightcoin, because the p2pkh and p2sh hashes can be signed against in the exact same way as bitcoin. For a very different cryptocurrency, I'd need to possibly create a different transaction type and have the bitcoin-spinoff-toolkit library be in charge of determining if the claims were signed correctly. But that should be easy enough.

[sfultong]

I plan to create the snapshot at height 392222, but I'll wait until 392232 to create it, so that I'm reasonably sure it's in the longest chain.

Once the snapshot is created, I plan to launch ASAP. Because snapshot balances will be treated as coinbase transactions, they won't be claimable until height 100 of the blightcoin blockchain.

[sfultong]

Note: I'm moving further discussion of progress to the other bitcoin forum site

[YarkoL]

Can we have a link?

[sfultong]

https://bitco.in/forum/threads/bitcoin-maximalism-spinoff-technology.462/#post-6067