GroundRod
|
|
January 26, 2015, 07:34:26 PM |
|
Because the 0.8.6 client was NEVER deployed, the effective dates don't apply.
For a 0.9.x client that will be deployed, use a data that is in the future.
That struck me as the solution to this issue, thanks FrictionlessCoin for the suggestion. Will be thinking over the downside, while cleaning up code today. Keep the brainstorming ideas coming, this has all been very helpful. @kraizi - Some good questions, so ditto on them, from me. Trying to understand how to best handle the older clients issue. @mmpool - Will setup 2 nodes as you suggest, reproducing the problem is my biggest hurdle to fixing it. Combined with the errors I'm seeing now, from being able to build the standard tests, it is starting to feel like we may actually be able to get this done. Also the git diff edits you've made, looks like in part, to get the test running, is most helpful. Thank you. GR
|
|
|
|
GroundRod
|
|
January 26, 2015, 08:06:46 PM |
|
An interesting topic i don't see discussed much, what if bitcoin forks with features the community doesn't want. Does ixcoin become more attractive or will ixc always be developed in lock step?
Hi Ya JohnnyBTCSeed! It's been awhile, so just wanted to say hello, been asking myself that question too, as my answer tends to go to the details, it can be rather long winded. When my connection to BCT crapped out last night, you fortunately now don't have to read it. The short of it is this, there are aspects of what the Bitcoin guys are doing that we simply don't care about, at least for now, other things related to good security practices would be good to add. Once we get the issues being discussed fixed, I think what Cinnamon mentioned a few pages back about Transaction Fees will be our focus. Also as the merged mining component is so critical and unique to Ixcoin's place in the cryptocoin sphere, I intend on documenting it & cleaning up the code we use. First though, we need to get it working. Also...Recently it came to my attention, how wonderful finding and creating a very large block, one with lots of transaction fees in it, can be to a miner. I will try to get him to do a write up on that experience, titled something like: The joys of mining transaction fees... l8r GR
|
|
|
|
mmpool
|
|
January 26, 2015, 08:57:09 PM |
|
I'm curious did you see this same issue when you upgraded your pool from v0.3.24 to v0.8.6? It should have occurred then too, right?
BIP30 is for preventing duplicate transactions so I assume it wouldn't be an issue with every single block generated. Are you seeing 'tried to overwrite transaction' errors on every block?
Also, I believe the majority of pool hasing power for iXcoin is still using v0.3.24. How do we get the rest of the pools migrated to v0.8.6 or v0.9.x without causing a fork? The start date in v0.8.6 is already in the past. Or is this even a fork issue?
I didn't see it in 0.8.6 and it's not causing the block to be rejected. Possibly it's something to do with the testing setup I've done - I'll check and ensure the transactions aren't being propagated multiple times. I'll confirm here in a day or so when I can retest. I thought the other pools were on 0.8.6? It's been a while since it's been done and mmpool has been using it since confirming it could merge mine blocks successfully. Edit: Friction clarified whether 0.8.6 was deployed. mmpool runs it but I have no issue with modifying the BIP 16/30 start dates. The biggest issue seems to be the transactions not appearing in listtransactions. I'll do more testing as well and will experiment with sending a portion of the pools hashrate to the 0.9.x client at some point.
|
mmpool.org - BTC Pool - DGM - pays tx fees/vardiff/merge mining/ tor
|
|
|
GroundRod
|
|
January 26, 2015, 11:57:45 PM |
|
Anyone interested is welcome to follow along... https://github.com/GroundRod/IXCoin/commit/e7c07a3bfc28c539916d171b8f8dccb152c4522aHad to revert the 80 byte OP_RETURN change, that broke transaction testing, and so more work needs to be done on that issue, also moved BIP30 problem off until 3/15/2016, we still need to solve both problems. Cleaned up the code and getting ready for more fixes. @mmpool - I've not yet got setup to test list transactions, but working on it... l8r GR
|
|
|
|
GroundRod
|
|
January 27, 2015, 12:06:08 AM |
|
Oh and I forgot to mention, the 2 checkpoint test failures are: test/Checkpoints_tests.cpp(28): error in "sanity": check !Checkpoints::CheckBlock(11111, p134444) failed test/Checkpoints_tests.cpp(29): error in "sanity": check !Checkpoints::CheckBlock(134444, p11111) failed So armed with that intel, plus what mmpool has provided, I think that we can have a problem there solved pretty quick. As to the exact attributes failing in lines 28 & 29, the source can be found in the src/test https://github.com/GroundRod/IXCoin/blob/iXcoin/src/test/Checkpoints_tests.cpp
|
|
|
|
mmpool
|
|
January 27, 2015, 01:30:12 AM |
|
Oh and I forgot to mention, the 2 checkpoint test failures are: test/Checkpoints_tests.cpp(28): error in "sanity": check !Checkpoints::CheckBlock(11111, p134444) failed test/Checkpoints_tests.cpp(29): error in "sanity": check !Checkpoints::CheckBlock(134444, p11111) failed
These are testing for bitcoin block hashes but these have been removed in the Checkpoint code. Replace with the hashes and block numbers in 'src/checkpoints.cpp'.
|
mmpool.org - BTC Pool - DGM - pays tx fees/vardiff/merge mining/ tor
|
|
|
GroundRod
|
|
January 27, 2015, 03:32:48 AM |
|
Looking at the 0.8.6 source, BIP 16 and 30 was enabled for 02 Jan 2014 01:07:11 GMT. So we'll have to keep them enabled: + // BIP30 for Ixcoin will go into effect on 2014-01-01 0:00 UTC + // date -j -f "%b %d %Y" "Jan 01 2014" "+%s" + int64 nBIP30SwitchTime = 1388624831;
+ // BIP16 will be enabled for Ixcoin will go into effect on 2014-01-01 0:00 UTC + // date -j -f "%b %d %Y" "Jan 01 2014" "+%s" + int64 nBIP16SwitchTime = 1388624831;
I plugged the epoch into http://www.epochconverter.com/ and got the different time to the comments. Reviewing the posts here, and realized this was the correct answer, we need the same as v8, so was changing the code to the correct value, based on the date, and got this: Epoch timestamp: 1388534400 Timestamp in milliseconds: 1388534400000 Human time (GMT): Wed, 01 Jan 2014 00:00:00 GMT Upon running the value apparently programmed, we get a date/time of the following for int64 nBIP30SwitchTime = 1388624831; GMT: Thu, 02 Jan 2014 01:07:11 GMT ...is that what everybody wants then for BIP30 testing? Or the date as listed, with the correct value, or some future date? Hate to have to keep changing this. On the BIP16 test, bitcoin uses this value : // BIP16 didn't become active until Apr 1 2012 int64_t nBIP16SwitchTime = 1333238400; Guess what, the comment and value match. From our v8 listed above, I would say the comment states one date, while the value specifies another, same as BIP30, whatever you guys want, is fine by me... I just want the comment to match the value, and have both BIP16 and BIP30 work for us too. @mmpool - Thanks for the epochconverter link, great tool.
|
|
|
|
GroundRod
|
|
January 27, 2015, 03:38:22 AM Last edit: January 27, 2015, 05:09:38 AM by GroundRod |
|
Oh and I forgot to mention, the 2 checkpoint test failures are: test/Checkpoints_tests.cpp(28): error in "sanity": check !Checkpoints::CheckBlock(11111, p134444) failed test/Checkpoints_tests.cpp(29): error in "sanity": check !Checkpoints::CheckBlock(134444, p11111) failed
These are testing for bitcoin block hashes but these have been removed in the Checkpoint code. Replace with the hashes and block numbers in 'src/checkpoints.cpp'. Ya got it thanks, unfortunately it only fixes the test, so that it passes, which is one more down, at least. After fixing that, Turned off the checkpoint enable flag at the top of the checkpoint.cpp code for building here at least, should have the same effect as your pastebin showed was required on that file. line 35: bool fEnabled = false;
|
|
|
|
GroundRod
|
|
January 27, 2015, 09:38:12 AM |
|
Another update commit b338c797fd8817445d4db1997f9ffcb730f072be : Fix Checkpoint test, fix rpcmining bug v9.3 uses CScriptNum, cleanup BIP30/16 comments & set epoch to match v8 nodes https://github.com/GroundRod/IXCoin/commit/b338c797fd8817445d4db1997f9ffcb730f072beAfter more consideration, have set the BIP30 value back to what Ahmed had originally, this time with a correct date/time comment for the event, this should match what v8 nodes are doing, if anyone has a better idea, please chime in.... The code at just after line 2000 in main.cpp now looks like this: // Do not allow blocks that contain transactions which 'overwrite' older transactions, // unless those are already completely spent. // If such overwrites are allowed, coinbases and transactions depending upon those // can be duplicated to remove the ability to spend the first instance -- even after // being sent to another address. // See BIP30 and http://r6.ca/blog/20120206T005236Z.html for more information. // This logic is not necessary for memory pool transactions, as AcceptToMemoryPool // already refuses previously-known transaction ids entirely. // For Bitcoin, this rule was originally applied all blocks whose timestamp was after March 15, 2012, 0:00 UTC. // Now that the whole chain is irreversibly beyond that time it is applied to all blocks except the // two in the chain that violate it. // // GR Note: Ixcoin has no such two blocks, that I am aware of. The epoch 1388624831 has been // arbitrarily picked while developing v8, so in order to remain compatible with those v8 nodes // now running on the network, our v9 core will continue to have the same & remain compatible. // // This prevents exploiting the issue against nodes in their initial block download. // // This rule applies to all IXCoin blocks whose timestamp is after 1388624831. // // BIP30 for IXCOIN has gone into effect on 02 Jan 2014 01:07:11 GMT // Code Updated on: 1/27/2015 by GroundRod // Generated from: http://www.epochconverter.com/ // Epoch timestamp: 1388624831 // Human time: Thu, 02 Jan 2014 01:07:11 GMT int64_t nBIP30SwitchTime = 1388624831; bool fEnforceBIP30 = (!pindex->phashBlock) || (pindex->nTime > nBIP30SwitchTime); if (fEnforceBIP30) { for (unsigned int i = 0; i < block.vtx.size(); i++) { uint256 hash = block.GetTxHash(i); if (view.HaveCoins(hash) && !view.GetCoins(hash).IsPruned()) return state.DoS(100, error("ConnectBlock() : tried to overwrite transaction"), REJECT_INVALID, "bad-txns-BIP30"); } } // As well, BIP16 didn't become active for Ixcoin, until 02 Jan 2014 01:07:11 GMT int64_t nBIP16SwitchTime = 1388624831; bool fStrictPayToScriptHash = (pindex->nTime >= nBIP16SwitchTime); @mmpool - Now that I'm starting to understand the changes you've been making to allow the mining test to proceed, will not be putting those into our main development branch, but only on a local build to conduct the test. The above BIP30, checkpoints, starting merge mining block and other references needing to be disabled for the test, will have to be done, after cloning or pulling the latest source. What might help you on the test though, was a repair I just found & made in rpcmining.cpp, an important line had been commented out and so we were not building the block vtx[0].vin[0].ScriptSig in getauxblock(), this was due to upgrading from v9.2.1, and the removal of CBigNum references in creating CScript objects. Hopefully this change, will now work fine there... - // FIXME: Debugging 9.3 upgrade build problem, commenting out this line fixed it (GR) - // the problem is related to use of CBigNum, they are no longer referenced in script objects - //pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nBits << CBigNum(1) << OP_2; + pblock->vtx[0].vin[0].scriptSig = CScript() << pblock->nBits << CScriptNum(1) << OP_2; As there was no reference for me to work from on auxpow while upgrading, we need to be watching carefully CBigNum usage in various parts of that merged-mining code. As I recall, that was the only spot which had caused me a compile error though, and gone unfixed, until now. GR
|
|
|
|
mmpool
|
|
January 27, 2015, 09:56:47 AM |
|
@mmpool - Now that I'm starting to understand the changes you've been making to allow the mining test to proceed, will not be putting those into our main development branch, but only on a local build to conduct the test. This is the right thing to do, thanks. The changes are solely to allow testing on a new chain. I'll run another test in a day or two and post back with the results.
|
mmpool.org - BTC Pool - DGM - pays tx fees/vardiff/merge mining/ tor
|
|
|
Vlad2Vlad
Legendary
Offline
Activity: 3052
Merit: 1534
www.ixcoin.net
|
|
January 27, 2015, 06:08:43 PM |
|
I can't believe all this AWESOME work GroundRod is doing. And the man has never asked for a dime.
GroundRod, can you post your IXC Address?
I encourage anyone with the ability [and desire] to donate some IXC to GroundRod.
His level of work right now is world-class, what you see only from Bitcoin core devs. I had no idea he would be back to help out let alone to put in this kind of code-work.
WOW!
|
iXcoin - Welcome to the F U T U R E!
|
|
|
Vlad2Vlad
Legendary
Offline
Activity: 3052
Merit: 1534
www.ixcoin.net
|
|
January 27, 2015, 06:12:17 PM Last edit: January 28, 2015, 09:14:16 AM by Vlad2Vlad |
|
And [due to this level of coding] I will be adding GroundRod to iXcoin.org site as an iXcoin dev.
Wish I could pay you a salary, GroundRod...maybe one day [soon] I will.
Cheers!
|
iXcoin - Welcome to the F U T U R E!
|
|
|
|
cinnamon_carter
Legendary
Offline
Activity: 1148
Merit: 1018
It's about time -- All merrit accepted !!!
|
|
January 28, 2015, 04:40:50 AM |
|
I agree , i have been a bit busy but did look over the commits and some good progress is being made, I am always impressed 1000x by code that works vs. people who say 'why can't it do this or that' ..... until you have actually tried to build something yourself, make changes or even get the client to compile you don't get a true appreciation for how specialized some of the talent level is that has gone into these projects over the years and is going on right now.
GR and Ahmed have done some very solid work.
thanks to mmpool for the test info also , that probably took him hours and hours of work that is like a thankless job......so please consider these things
the iX community is stronger now in many ways than ever and I hope to see that trend to continue in 2015 and beyond, happy to be a part of things here.
i am making a new build system to help test and contribute but ran into a little snag, hopefully after i get some sleep and back to my apartment (staying with a friend last few days) i can complete my new virtual linux 'machine' designed just for iX building and testing and catch up to the changes Ground Rod put on his fork of github. Also what is not posted in the forums here is all the communication in private and (in public) on github so everyone understands there are hundreds of hours of many peoples work involved. If you have anything to contribute join us on github. If not relax and in time I see some good progress ahead.
|
Check out my coin Photon Merge Mine 5 other Blake 256 coins - 6x your hash power https://www.blakecoin.org/The obvious choice is not always the best choice. LOOK DEEPER - Look into the Blake 256 Family -- CC
|
|
|
zebedee
Donator
Hero Member
Offline
Activity: 668
Merit: 500
|
|
January 28, 2015, 05:29:54 AM |
|
The address: xnxZzr7KU1U6BRBqvtpdrMKv9PCMd7z2NC
Have yet to get around to generating a vanity address.
Sadly it seems no-one has gotten around to tipping you either... Pretty sad really.
|
|
|
|
Vlad2Vlad
Legendary
Offline
Activity: 3052
Merit: 1534
www.ixcoin.net
|
|
January 28, 2015, 08:47:03 AM Last edit: January 28, 2015, 09:10:30 AM by Vlad2Vlad |
|
I love you zebedee, you are one of the reasons who caused this new flame of vitality in this forum.
Thanks for all your heads up you gave us in the past, and for you sure you will give us in the future. You are always here for us.
DeadSea, are you ok? lol Zebedee caused the "new flame" and vitality in this thread?
Wat?
Did I miss something? Zebedee hasn't done even ONE positive thing for this community let alone "flame on".He gave us all the heads up? He was always here for us and will be in the future? Wat? hahahaaaaa. I really can't tell if you're just mocking him. He was dead wrong about everything [except the actual end of mining date, which was a guesstimate and which proved meaningless]. I gave all the heads up to everyone! Months and years ahead.I brought the fire [down from ZION] - to this community and I flamed on [like a Superstar] many times when it was necessary! Pat pat pat....myself on my back cause you're loving the wrong dude, man. There are so many people on this thread that have done something for iXcoin - some little and some a lot, but let me tell you, one of those people was and is NOT zebedee. Yet you took the time to really give this guy love and props for things he has NEVER done?
Wat? I find it incredibly bizarre that you are kissing up and bowing down to this guy like that.
As if he is....
|
iXcoin - Welcome to the F U T U R E!
|
|
|
Vlad2Vlad
Legendary
Offline
Activity: 3052
Merit: 1534
www.ixcoin.net
|
|
January 28, 2015, 09:05:08 AM |
|
Oh wait, I was wrong.
Zebedee did one thing for this community ALL year long [last year].
He constantly and consistently used FUD to try and scare everyone out of their iXCoins. He kept saying ixCoin was gonna die once mining ended and this was a certainty and that CEX would stop mining it and we would all lose our money so we should dump our coins.
Now who would work so hard for so long to scare everyone out of their iXCoins?
And why would a former board member [and the principal contact with CEX] now falsely praise him?
Zebedee, are you finally ready for your grand entrance?
And did you bring 10+ HERO sock puppets to fight me with?
Looks like my vacation is up - Let's rock!
Flame-on!
|
iXcoin - Welcome to the F U T U R E!
|
|
|
zebedee
Donator
Hero Member
Offline
Activity: 668
Merit: 500
|
|
January 28, 2015, 11:04:16 AM |
|
Did I miss something?
Zebedee hasn't done even ONE positive thing for this community let alone "flame on".
He gave us all the heads up? He was always here for us and will be in the future?
Wat? hahahaaaaa. I really can't tell if you're just mocking him.
He was dead wrong about everything [except the actual end of mining date, which was a guesstimate and which proved meaningless].
Yes, I remember, that time I showed I knew more about this coin than anyone on this thread, and showed you up to be the gaseous windbag you clearly are. You wouldn't even bet a bitcoin or two from what I remember, so sure are you of your convictions. And you can't even donate a few of your shitcoins to that dude. If I held any I would, but I only hold BTC, and they're only for worthwhile causes. And so far I've been dead right about the slow death of this coin. I admit, it's a more agonizing, drawn-out death than I anticipated. But IXC will go the way of ATC ( http://atc.blockr.io/).
|
|
|
|
FrictionlessCoin
Legendary
Offline
Activity: 868
Merit: 1000
Cryptotalk.org - Get paid for every post!
|
|
January 28, 2015, 12:34:58 PM |
|
Did I miss something?
Zebedee hasn't done even ONE positive thing for this community let alone "flame on".
He gave us all the heads up? He was always here for us and will be in the future?
Wat? hahahaaaaa. I really can't tell if you're just mocking him.
He was dead wrong about everything [except the actual end of mining date, which was a guesstimate and which proved meaningless].
Yes, I remember, that time I showed I knew more about this coin than anyone on this thread, and showed you up to be the gaseous windbag you clearly are. You wouldn't even bet a bitcoin or two from what I remember, so sure are you of your convictions. And you can't even donate a few of your shitcoins to that dude. If I held any I would, but I only hold BTC, and they're only for worthwhile causes. And so far I've been dead right about the slow death of this coin. I admit, it's a more agonizing, drawn-out death than I anticipated. But IXC will go the way of ATC ( http://atc.blockr.io/). There must be something psychologically wrong with you when you keep bashing a coin that is virtually dead. The crazy thing about iXcoin is that unlike most other dead alt-coins, it runs as a parasite to the Bitcoin mining network. It never really is dead so long as the pools support the coin. BTW, great thankless work by GR, Cinnamon and Ahmed to keep the development going. I know, it does take a lot of work and really the only true compensation here is the knowledge you gain working on the internal workings of a coin. The only unfortunate fact with iXcoin is that the major holders don't see it in their best interest to donate coins for development. There are parties out there with 100,000's of iXcoin but don't even take the time to donate just a fraction of their holding to improve the coin. It is just absolutely ridiculous behavior, but that's just how it really is.
|
|
|
|
Vlad2Vlad
Legendary
Offline
Activity: 3052
Merit: 1534
www.ixcoin.net
|
|
January 28, 2015, 03:35:29 PM |
|
Well Zeb, I guess many are more scared of Ripple right now, and the last $30 million funding round, ex Obama advisor onboard, strong connection with banks, and the backing of a company called google. iXcoin? Really? Right now, the only way to stop iXcoin once and for all is probably by stopping Bitcoin mining. That's maybe what they'll use that 30 million for. That's some beautiful FUD right there.
|
iXcoin - Welcome to the F U T U R E!
|
|
|
|