[Dev] Develop new core 0.9.3 for feathercoin, together
-
For SX Txs to be processed you need some miner nodes to be running SX. Really it is dangerous to send SX before the network is updated so SX should not be enabled until a set date in the future.
To test this run two nodes only connected to each other with a couple of empty data dirs so you can mine from the genesis block using the internal miner, or use the testnet. Then you will see if it is confirmed.
-
Go team!
Between the two of you, Liz and Bush, this should be completely doable it seems right?
-
I plan to build a p2pool on 0.9.3 with Stealth address, hope to confirmed
-
For SX the entire network needs to be updated for it to be safe.
I will pull and test SX in 0.9.3. It might be sensible to now add your work to the main repo, make sure it is 100% and then release SX and 0.9.3 at the same time.
-
Cool, but but does this mean no SX before Christmas?
-
I try my best to finish it, But I’m not sure
-
I support Bush’s approach:
- merge Bush’s branch on github with Lizhis so we get the hard work from Lizhi ( THANKS LIZHI !!!) into the main trunk
- release the 0.9.x version
- enable SX several weeks later, when the majority of wallets are updated. The 0.8.7.0/.1 update showed, that it takes a lot of time to get the majority of wallets to the latest version and as Bush says SX is safe only if the whole network is supporting it or at least the majority of wallets/miners
We need a good time table to do it.
Also, what will be the influence on the Android wallet? We already have a backlog and are still short on Android developers who could help here.
-
I had build a p2pool for 0.9.3 core , I hope to test SX, Now commit SX transaction right, but can not comfire them on MAIN_NET.
-
a p2pool on 0.9.3 core http://block.ftc-c.com:19327/static/
-
I can see SX Txs in block explore that base on 0.9.3 core . It send SX Transaction success, You can fiind those TXID in block.ftc-c.com , but no miner can confirm them ??? ???
twice, send 0.01 ftc to dooFJnznafPjRs2xtwZM8pabY35qn9MqqDxmpfUzbaNzBLCwWwKwcCWXaxDZKZwsq8jyrLmuXn8gUtAcd7xRAPG6AjqF3WgKEwbAAv
http://block.ftc-c.com/tx/dcc0260532025d6d7ecd69cd3cdd8ed9ea58ea4d96669a9e2b83c46e33e058fd
http://block.ftc-c.com/tx/5450cbc71b182a92e626be374c54fe4a5def179c363923fcd982248da7d0058e
is it must solo mine ?
-
You’ve already done the p2pool for the core?
Liz mate! I, im speachless…
Danke, Arigato, 谢谢 !
-
Yes, http://block.ftc-c.com , It base new core. P2Pool on http://block.ftc-c.com:19327/static/
-
Looks awesome!
I would post a screen cap of it but bayimg is down so I have no where i feel ok with uploading images to.
note to self… decentralise bayimg…
-
Today , I find SX Transaction confirmed on MAIN_NET . pleasantly surprised. five days ago, they are broadcast.
txid=5450cbc71b182a92e626be374c54fe4a5def179c363923fcd982248da7d0058e
txid=dcc0260532025d6d7ecd69cd3cdd8ed9ea58ea4d96669a9e2b83c46e33e058fd
http://block.ftc-c.com/tx/dcc0260532025d6d7ecd69cd3cdd8ed9ea58ea4d96669a9e2b83c46e33e058fd
-
So sx:tx is working?
-
I think so, I started them, but I did not notice. I will broadcast some new SX Transaction, If pool that base 0.9.3 core can find a new block, SX Transaction will recorded in the blockchain. Wait 24 hours
-
one good news : SX transaction can be comfirmed on blockchain.
one bad news : receiver can not get it.
I was checking the possible problems.
SX Transaction Id= c5316042cf0977d24ac56461e9048ad57688a0c80aaa7460fe10f7b9d06cad14
{“txid”:“c5316042cf0977d24ac56461e9048ad57688a0c80aaa7460fe10f7b9d06cad14”,“version”:1,“locktime”:0,
“vin”:[{“txid”:“09c4f594e153ff79dd502b2487df1866b2b045dc51d4d6646cdd511a30771e96”,“vout”:0,“scriptSig”:{“asm”:“3044022021ea37946dc7f52bc77544d8a89d3106a92f6bb08442516dfdd51a2dfe98119c0220692911be19e396d802c302691d5b4418f1f9e370d73f142abea3c3a0124ddf7201 034585c4019c0f25fd2abb1a48b4687748a8c491e05eaa763f908d5cc1cf354aca”,
“hex”:“473044022021ea37946dc7f52bc77544d8a89d3106a92f6bb08442516dfdd51a2dfe98119c0220692911be19e396d802c302691d5b4418f1f9e370d73f142abea3c3a0124ddf720121034585c4019c0f25fd2abb1a48b4687748a8c491e05eaa763f908d5cc1cf354aca”},
“sequence”:4294967295,“n”:0,“addr”:“6emyuq63JUfAGyQG23Rb8wEoCAAVuoYtEc”,“valueSat”:4000000,“value”:0.04,“doubleSpentTxID”:null}],
“vout”:[{“value”:“0.02000000”,“n”:0,
“scriptPubKey”:{“asm”:“OP_DUP OP_HASH160 8b228b91299e3d336a6ed1959bedf4895ed57268 OP_EQUALVERIFY OP_CHECKSIG”,“hex”:“76a9148b228b91299e3d336a6ed1959bedf4895ed5726888ac”,“reqSigs”:1,“type”:“pubkeyhash”,“addresses”:[“6rR86RiPxpinTZikPW9BhLgyoWM6dMs2UC”]}},
{“value”:“0.01000000”,“n”:1,“scriptPubKey”:{“asm”:“OP_DUP OP_HASH160 f1ff54fe8c6e7d6548655798b0fce84e76a5995d OP_EQUALVERIFY OP_CHECKSIG”,“hex”:“76a914f1ff54fe8c6e7d6548655798b0fce84e76a5995d88ac”,“reqSigs”:1,“type”:“pubkeyhash”,“addresses”:[“71o1WXm9Sg7pne7ExbnqtUyR55rNm1NZRS”]}},{“value”:“0.00000000”,“n”:2,
“scriptPubKey”:{“asm”:"OP_RETURN 023b3d88aa81c8f7ff9c3b60c52bb5a8cd41dbe5968a381160da0a8f0d8c234bcb",“hex”:“6a21023b3d88aa81c8f7ff9c3b60c52bb5a8cd41dbe5968a381160da0a8f0d8c234bcb”,“type”:“nulldata”}}],
“blockhash”:“4632333ff88ae4a8bdec948692a33d489be8b789aa3e2e4f01b139808736dae8”,“confirmations”:5782,“time”:1418977466,“blocktime”:1418977466,“valueOut”:0.03,“size”:269,“valueIn”:0.04,“fees”:0.01} -
Because some code conflict , I’m fixing the ACP issue. I rewrite SetBestChain function, Now checkpointsync has been added to the project.
Over the past 2 days , It work all right. I think core wallet have supported ACP. I will submit code in tonight.
-
Oh you little beauty!
Really?!
I can’t wait to see this confirmed!
That was a lot quicker then expected!
-
I’m waiting , if my miner can find a block include SX , successful.
https://github.com/FeatherCoin/Feathercoin/commit/9a77224a31b47e5d40f365447a6f036c10e75bb6
//for 0.8.7 ACP bool SetBestChain(CValidationState &state, CBlockIndex* pindexNew) { // All modifications to the coin state will be done in this cache. // Only when all have succeeded, we push it to pcoinsTip. CCoinsViewCache view(*pcoinsTip, true); // Find the fork (typically, there is none) uint256 hashfork = view.GetBestBlock(); CBlockIndex* pfork = mapBlockIndex.find(hashfork)->second; CBlockIndex* plonger = pindexNew; while (pfork && pfork != plonger) { while (plonger->nHeight > pfork->nHeight) { plonger = plonger->pprev; assert(plonger != NULL); } if (pfork == plonger) break; pfork = pfork->pprev; assert(pfork != NULL); } // List of what to disconnect (typically nothing) vector