not so much a hard fork as a complete change of vehicle, necessitating a snapshot of the extant BEE2 chain with UTXO balances programmatically transferred to the new chain. You'll get to keep the same addresses, same keys, same balance except that Beecoin is now running off've a Core 0.12 PoS + masternode coin.
I see you have post this new wallet screenshot,so could we swap the old BEECOIN V2 to your new BEECOIN V3 now？
That is the general idea but there is more preliminary work to do. The widely-used term “snapshot” is, unfortunately, quite misleading ...
This will require some thinking. Perhaps for m-of-n support, the "claim to" string could be signed by m of n addresses and the string + all the signatures could be wrapped and broadcast to the spin-off network. The nodes would look up the address, read the redeem rules from the snapshot.bin file, and ensure that a sufficient number of correct signatures was present.
With P2SH the redeem script is not known to the network until the output is redeemed so the user would need to supply the redeemscript in the claim message. It could then be signed by as many keys as necessary.
But are there other common redeem scripts besides the standard single-address script and m-of-n multisig (native and P2SH)? I realize we could implement the full bitcoin transaction verification procedure to handle arbitrary scripts, but I was hoping to avoid this if possible.
A P2SH address is just the hash of a script. The script can be anything that the Bitcoin scripting language allows. I would guess most redeem scripts are probably fairly straightforward multisig but the redeemer supplies the redeem script so using just the blockchain there is no way to know what the scripts for the X unspent outputs to P2SH addresses are.
It probably would be a good idea to develop an UXTO parser to categorize what portion of the outputs belong to the following defined templates
1) PayToPubKey (obsolete but was used in early coinbase txs)
2) PayToPubKeyHash
4) PayToScriptHash
5) Native Multisig (not P2SH, multiple PubKeys specified directly in the tx output)
6) Non-standard *
* Note it is possible that some P2SH scripts are also non-standard but we can't categorize them as we don't know what the script is. For this "template" we mean all outputs which don't conform to any other known template.
The first step is to sync from the published blockchain. I have a client locally loading the blockchain. After 16 hours, it's reporting:
ProcessBlock: ACCEPTED
SetBestChain: new best=9164a1489a36fb2566e2 height=889032 trust=11575611798889848 blocktrust=630696890 date=07/11/14 01:43:22
should be finished later this afternoon, sometime this evening. There are over
2 million blocks in the BeecoinV2 blockchain, it's not a trivial exercise.
And the next step after syncing is to create an address ->tx index (the client only maintains a tx->address index) which will then give us a working set of UTXOs that people can then
argue about discuss. I am reviewing two possible approaches: i) re-use of existing open source s/w advertised as suitable for this purpose or ii) temporarily hack the BeecoinV2 client to use the engine to create a UTXO set. I can't see any obvious easy solution for ii), so I'm starting with i)
edited to add this paste from blockparser docs: “At this point, blockparser uses a *lot* of memory (20+ Gig is typical).“Cheers
Graham
