Topic: Spin-offs: bootstrap an altcoin with a btc-blockchain-based initial distribution - page 2. (Read 53644 times)

Are you able to detail how a snapshot is made?

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.

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

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.

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.

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.

Oh, and those txos don't fit the schema for p2pkh according to libbitcoin, so it treats them as bare, nonstandard scripts, which is why they're in my p2sh list.

I've made a new archive, this one has both the p2pkh and the p2sh results.

https://mega.nz/#!F4oWEZSb!ZDPYldwnhGIh6KPuTglfRpYVmMMpDQQG_EXRM9f0FAw

The big amount that bill didn't include (260936304319 satoshis) are actually a bunch of txos with the script "OP_DUP OP_HASH160 0 OP_EQUALVERIFY OP_CHECKSIG", so not spendable. The relevant tx ids and vout indexes are:

3be0ac3dc1c3b7fa7fbe34f4678037ed733a14e801abe6d3da42bc643a651401 1
64c01fedd5cf6d306ca18d85e842f068e19488126c411741e089be8f4052df09 1
6a86e6a5e8d5f9e9492114dafe5056c5618222f5042408ad867d3c1888855a31 0
15ad0894ab42a46eb04108fb8bd66786566a74356d2103f077710733e0516c3a 1
9edab6e7fadf1d6006315ff9394c08a7bf42e19cf61502200a1f73994f8da94b 1
3ab5f53978850413a273920bfc86f4278d9c418272accddade736990d60bdd53 1
aebe39a99114f1b46fc5a67289545e54cbfec92d08fc8ffc92dc9df4a15ea05a 1
2d00ef4895f20904d7d4c0bada17a8e9d47d6c049cd2e5002f8914bfa7f1d27b 1
03acfae47d1e0b7674f1193237099d1553d3d8a93ecc85c18c4bec37544fe386 1
aa62bdd690de061a6fbbd88420f7a7aa574ba86da4fe82edc27e2263f8743988 0
835d4dcc52e160c23173658de0b747082f1937d1184e8e1838e9394bc62c0392 1
305fbc2ec7f7f2bc5a21d2dfb01a5fc52ab5d064a7278e2ecbab0d2a27b8c392 0
ddddf9f04b4c1d4e1185cacf5cf302f3d11dee5d74f71721d741fbb507062e9e 0
6d39eeb2ae7f9d42b0569cf1009de4c9f031450873bf2ec84ce795837482e7a6 0
7ad47a19b201ce052f98161de1b1457bacaca2e698f542e196d4c7f8f45899ab 0
5bd88ab32b50e4a691dcfd1fff9396f512e003d7275bb5c1b816ab071beca5ba 1
f0137a6b31947cf7ab367ae23942a263272c41f36252fcd3460ee8b6e94a84c1 0
6d5088c138e2fbf4ea7a8c2cb1b57a76c4b0a5fab5f4c188696aad807a5ba6d8 0
0ca7f7299dc8d87c26c82badf9a303049098af050698c694fbec35c4b08fc3df 0
633acf266c913523ab5ed9fcc4632bae18d2a7efc1744fd43dd669e5f2869ce5 0
111291fcf8ab84803d42ec59cb4eaceadd661185242a1e8f4b7e49b79ecbe5f3 1
07d33c8c74e945c50e45d3eaf4add7553534154503a478cf6d48e1c617b3f9f3 0
81f591582b436c5b129f347fe7e681afd6811417973c4a4f83b18e92a9d130fd 1

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

I have a working chain with PayCon and a clone that I created and have up and running that I want to use to test out snapshots. I want to use PayCon and do a snapshot to prune off all the old Blocks, possibly something you might be interested in since it's a live traded alt-coin with a small marketcap (about 20k).

I am currently trying to find information on the process of doing the snapshot, are you able to provide any links or guides you might have? From what I've been told from talking to SuperClam, Mullick and a few others, you need to parse all addresses as a richlist into a dumpfile and send Coins to the same addresses within the new chain, things being much easier if it also has the same address starting letter.

It certainly is exciting to see progress being made on the spin-offs front.


I see three of the addresses which are corner cases where it's reasonable to make different choices. The block reward of the genesis block is not spendable in Bitcoin, but it counts as part of the 21 million. Also, the two addresses 1A1zP1eP5QGefi2DMPTfTL5SLmv7DivfNa and 1GktTvnY8KGfAS72DhzGYJRyaQNvYrK9Fg got two block rewards each, but due to a bug the transactions have the same id and are only spendable once. It's reasonable to assign each of them 50 BTC or 100 BTC. As for the other 2 addresses, my code seems to have definitely missed transactions. I will investigate this further.


For the last one, 1P8GMhC3qYkuvRRBsS5gqGegT7GvQoxAwY, the balance in my snapshot comes from tx d087410c172f57a7857b6341c952592de7934d1fee0fc745e9b7569487656876. The script appears to be a standard p2pkh script except with a OP_NOP at the end. I'm not sure whether or not this makes the 0.038... bitcoins unspendable, but it's reasonable to decide to include it or not. I still need to investigate the other three.


Yes, I didn't include txouts with a value of 0, and that explains some of these. However, it does appear that I unintentionally missed several dust outputs.


This sounds correct, although it's possible I recognized some scripts as provably unspendable. In addition, I may have converted 1-of-1 multisig into p2pkh instead of p2sh.


The 2609 btc p2sh does worry me, so please let me know if you do track it down. Can you post the p2sh results on Mega as well?

I hope you're enjoying the project. I know it's a surprising amount of work.

Exciting to see this actually going forward!

p2sh comparison is complete. There are no disagreements on balances for hashes present in both snapshots.

I took any bare script uxtos and converted them to p2sh, and it appears bill did the same.

There are 448 p2sh transactions that are present in bill's but not mine. They're all dust, and of the 5 random ones I tested, I couldn't find them on blockchain.info, so they must've been bare scripts, if anything.

There are 22 p2sh transactions that are present in mine but not bill's. One of them is a massive 2609 btc utxo which must've come from a bare script. I'll write some code to see if I can track that down for him.

I'm happy to announce the snapshot creation code for p2pkh balances seems to mostly agree with bill white's snapshot, taken at height 349999.

The 5 addresses where our balance amounts disagree seem to come down to bitcoin quirks (like the genesis block not being a valid input to other transactions).

There are 4 addresses present in his snapshot that aren't present in mine and aren't present on blockchain.info. They're only like 3 btc, so whatever.

There are 1061 addresses present in my snapshot that aren't present in his, but they're all dust.

Full details:
https://mega.nz/#!llxnmb7J!ND9NMtO-XQQRsLHyM7227sBkA2EWr6lLr15o5seEObs


Next steps:
 1. check p2sh balances against bill's (should be pretty quick)
 2. add code to filter dust (or really, give the ability to filter below arbitrary amounts)
 3. the fun part... a real, proof-of-concept spinoff! (I've already put some work into this while waiting on slow snapshot-taking processes)

I like the idea of doing a spin off using bitcoin and an alt or even a handful of alts that have similar and desirable features. You could peg the exchange rate at a cretin block height with all merged alts.

why I like the idea of going for "big game" is it adds to the the dynamic that rewards developers.

here is an examples:
During the early development stage the spin-off has no value or very little. I am presuming the spin-off still has an mission schema tied to PoW, a developer invests time in a project has an opportunity to mine along with everyone else and should.

The idea of a problematic pre-mine is largely mitigated because the spin-off has a pre-mine built in with block height of the spin-offs as its initial distribution it just needs to be claimed.

Now if the idea gains traction and the developer is motivated and the developer has a new opportunity to buy spin-off coins that will be dumped on the market, the developer has insider knowlage in a way, and that's a belief in the system and his willingness to continue working on it.  he also has the ability to work with his mined coins selling them or saving them depending on his criteria for success.

I think the market dynamic of "Big Game" will bring in developers and big winners and looser very early on, it's likely in a success scenario the winners could be the developers and eventually the network of users, the only losers are the people who don't believe and dump their coins. The advantage here is there is a double gold rush 1 to mine and 2 to buy dumped coins knowing the mining scheme.

The developer has another advantage and that is to accumulate coins of the other alts or bitcoin, knowing the block height of the snapshot.   

Keeping the developer financially invested in the success of the spin-off is important, and i think "big game" snapshots will make or break the idea so worth trying form the start. 

That is pretty much what I thought. Since it is a proof of concept and
turned out not entirely successful, it could still attract devs precisely for the
challenge of going after bigger game. Lessons learned and so on.

But if an attempt to target a very prominent alt right from the outset
should fail, it could dissuade anyone to proceed with the development.
The perception could be that spinoffs are a dead idea.

Why steer clear of the biggies? Why not start at the top?

I suppose it's better to work out the kinks on a smaller crypto, so that I don't risk the hype dying if/when I have to fix things and possibly restart the chain. But I'm fairly impatient, and the ideal for me would be if the hype pulls in other developers who are better than me with C++ and are willing to support the code.

Figuring out how I want people to claim multisig and other pay-to-script-hash transactions has been a bit of a stumbling block, but I think I've finally settled on something that will work for all of them and isn't too hard on the user.

Care to share your criteria for picking one? If for nothing
else, just to stir up some exciting speculation 

For my part, I'd steer clear of any biggies now, but still would
go after a coin with a decent following and a nontrivial
divergence from the Bitcoin codebase.

It's good to hear you're making fast progress. It will be especially interesting to me to have confirmation (hopefully) that the snapshot I took was correct. To be specific about my snapshot, it was of the address balances after the block at height 349,999 and before the block at height 350,000. Since the genesis block has height 0, this means it includes the first 350,000 blocks. Also, I simplified the snapshot to list accounts using either p2pkh or p2sh. As you probably know, many of the "scripts" can easily be made p2pkh (most or all of the early txouts had the right form, but were not yet p2pkh). All the others can be made p2sh. The snapshot data is available here:

https://mega.nz/#F!0xhzUbTS!h-LeyiTbF9dXgusKCc_bfQ

also sounds way cool!

exciting work! looking forward to seeing it.