|
Ya zebedee, imo your quick to comment, and quick to judge, and mostly wrong. The only thing I can remember that you got right, months in advance was hitting the month that the last Ixcoin would be mined. Despite your claims of doom, all three versions of the client passed the test with flying colors.
@FrictionlessCoin - know that your well aware of the many details required to get this stuff right, so appreciate hearing that, and your continued helping out...big thankyou.
We've all been real busy working in the background, syncing our work, setting up test rigs, getting the latest source corrected of errors...
Thought I'd pop on here and check real quick, plus see what contributions, if any, had shown up.
My god, I can't tell you how much this means, thankyou so very much donors. Over 4000 Ixcoins in the last 24hrs. That really means allot.
l8r
GR
|
|
|
|
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 |
|
|
|
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; |
|
|
|
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. |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
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 |
|
|
|
For those interested, work done by me last Nov to upgrade Ixcoin, is now finally posted, mostly build system stuff, that needed allot of attention. What is now up on GitHub, also includes up-to the minute recent activity, as we get these remaining software problems figured out and resolved, changes could come from several differnet directions. so...atm 6 commits from me Allot of new work on the table, added the latest v10 core build system, customized and working well with our back ported source at the v9 level. Allot of tests are now passing too. From source, anyone can now build Ixcoin, just ./configure the tests enabled (default), and see the pass/fail results. Week before last, we could not build any without considerable pain. Combined with what mmpool has given us here, important new clues and fixes will hopefully become apparent. My goal is to start build #1 of the Ixcoin v0.9.4 test series. It will primarily be updates to repair the problems found so far, so don't hold us hostage to a date, I have no idea if this will go on for days or weeks, but we'll keep producing test builds until the problems are resolved and we can agree it's ready to be released. Once all the primary & QT tests pass, I will produce build #1, for at least several target host types. Can say with certainty, that using the new builder tools to build Ixcoin binaries for the various 32 or 64 bit linux & windows systems, or on a mac, will be pretty straightforward & easier to do. An important asset for our coin to have, plus operational in a number of places, and working well for users too. Onward to Ixcoin v0.9.4-rc1 Merge pull request #13 Ahmed, time to hit the trenches... https://github.com/IXCoin-Dev/IXCoin/pull/13GR |
|
|
|
|
Super feedback mmpool, thanks much!
....Reviewing it here now too
I've wanted to remove that BIP30 related code, also think it's ok, but needed to do more research.
Please do, your know how on that history, is better than mine.
Obviously,,, we also need to update the miner description strings...
On-> The blocks don't appear if I do a 'listtransactions' though.
That definitely needs to be fixed.
On-> Is 'listtransactions' broken for generated blocks?
Sure looks like it is, will start now to look closely into that code, try to find answers.
On->Was BIP30 ever enabled on ixcoin anyway
If I could have answered that, with a for sure no, would have deleted that source in a heartbeat.
Really hope we can crack those final errors....this is a big start!
GR
|
|
|
|
@Ahmed @Vlad Sure can understand your frustration, and perhaps my leaving the pre-release flag so that the Ixcoin Core wallet builds a pre-release was a mistake, it's easy to change in src. It sure would be nice to see cex.io step forward with additional development funds, but equally as important, test results. Other than a couple, very nice donations (much thanks), which I've still got at my donation address, the work done to-date has been personally rewarding, not based on financial gain. Seems the same for everyone here, from what I can tell, has all been done for FREE, or personal cost. However, until bounty targets have been met, there is only so much one can do, to show progress. As a group, think we've done a great deal, if you count the combined hours. With comments like mmpool's just posted, I've gotta say....didn't know that, lets see if we can get it fixed, and then get even more feedback, after a new build is made. However when referencing your message link, and the source being discussed, I find that it's https://github.com/FrictionlessCoin/iXcoin/pull/1your talking about, in other words, it references the v8 client. So I'm kinda confused as to wither or not your talking about the v9.3 ixcoin having this problem. I don't think it does. Please feel free to pm me here with your details, or post the specifics related to your v9 build tests, that would be helpful. These things do need testing, and I've been of the opinion, we need more feedback, before the new wallet upgrade is shipped out in a released state. @mmpool - If you can help test, Is the Source on github ok, or do you need a particular binary, if so which platform. General observation: Please correct me if I'm wrong, but from what I can tell, there are a growing number of v9.3 clients out there on the network now, and working very well for the users. RPC calls to the daemon or -qt server, for use in various operations also seem to also be working very well. If this is not the case, please help me catch up on the backlog of discussions and point me to it, so we can get it fixed. Hard to do, if you don't know about it. Hi, I would like to know
Default RPC port
Minimum transaction fee
Estimated block time in seconds
daemon file
Exact spelling of the conf file with path for
Windows
Mac
Linux
for Ixcoin. Can someone help me?
WIll try to do as much as I can, off the top of my head... which means it could be wrong, however best shot: The default RPC port is 8338 Min Tx fee, never really got worked on by me, pretty much standard bitcoin v0.9.3 code I think. After our discussions months ago, seemed consensuses was to leave it as bitcoin v9 had done, allot of stuff changed between v8 and v9 there. We can certainly work on hard coding something specific now, if that is what is wanted, I argued it should be enforced back then, although now we're really starting to taste the reason why we must move towards an enforceable minimum. Estimated block time, hmm got me there, would have to look that up. The block target time is something I should know. the daemon file is called ixcoind.exe on windows and simply ixcoind on linux Linux versions I now build, have a configuration directory path of /home/<username>/.ixcoin ...in which all the blockchain, wallet and ixcoin.conf (the config file) settings can be found. On Windows versions, the config files are called the same name (ixcoin.conf), but the path to them varies, depending on which flavor of windex your running. We don't have a v9 version for the Mac, that I know of. And my latest attempts to build them here just failed last night, even with the latest version of bitcoin v0.10.99 depends. Think that without an upgrade on my debian OS, the machine can't find dependencies new enough. It will have to be done by someone else for now, I've gotta load a new OS, on another hard disk, before trying again, takes time. Been working hard on getting darwin to build, but it's kinda complicated to build on a Mac for a Mac, and I'm trying to do it from a linux machine. @steelhouse - Agree with you there, was surprised to find out how complex the transaction fee code had gotten in v9.3, planning to once again attack that section of code and hopefully produce results that enforce a minimum, but not break what they are doing already, for other aspects of the calculations. As there was so much work to do getting the upgrade to this point, was burden enough, without trying to modify the Tx fee calculations as well. It will be revisited. As of yet though, I do not see any consensuses on what that should be. Ixcoin amazed me, by passing the 'last coin' mined date, with success in all our client versions, now we're entering a new phase. Mining has risen, and is about to fall hard into economic bad times. There will be pockets of opportunity though, and for Ixcoin we must learn to survive on Tx fees only, a true test for any cryptocurrency, and one that could become a shining beacon of hope. Not only for those miners in the years to come, but also the users of it, a true currency, and method of transferring wealth around the planet, far easier than gold. I'm confident we will succeed. GR |
|
|
|
|
Will follow your progress Vlad,
...just so far out of the loop, it's hard to comment on, have not followed the politics much, been buried in the details.
Wanted to thank the member joining our translation team. Italian done well, will be a big PLUS!
|
|
|
|
|
Sure deadsea33, fine by me....
Thanks Jumbley. For sure that would be a load of new people adding transactions to the chain...
Sounds good Ahmed. WIll sync up my local repo with your current main ixcoin-dev branch this week and make sure I'm ready to generate pull requests, plus get back on freenode chat so we can stay in touch and not bump into each others work. Perhaps we may yet be able to pull in some of my work done on the 'depends' builder, not sure yet. More than likely any changes I make in the near term, will be onelines, as I try to fix _tr prefixes missing in the code, where the strings are messages we want translated. Extractstrings.py works pretty good if that is done correctly and builds src/qt/ixcoinstrings.cpp for us. Then get them shipped off to transifex for translation..and the results brought back in as a new commit, after what I hope is a small amount of hand editing.
|
|
|
|
Hi IXCOIN gang! Wow.....well into the new year already, sounds like some exciting stuff happening... Will be spending the next few days trying to catch up on developments. Personal note: Thanks again Jumbley, your able to say so much, with just a few words.... @Ahmed - As you know, cause we've been hanging out on freenode ##ixcoin for months, I worked hard on Ixcoin in Nov, almost exclusively on a major new 'depends' builder, able to quickly build executables for cross-platform targets on a linux machine, there are some other minor enhancements I made to, primarily to migrate the clientversion methodology closer to the latest bitcoin we had at the time. For those that don't know, when I started helping out here, I was basically learning and building Ixcoin on a Windows 32 bit machine, using the MingW compiler and development tools required to build crypto. Anyway, since last showing up, I've completely migrated my personal computer/web experience & more importantly the development platform & tools one needs over to a Debian wheezy 64 bit OS setup. A very big change, it's hard to describe how fantastic it's been to breath new life into this old hardware.  Ahmed my point is, if you've got ongoing efforts to port Ixcoin to v0.10! Wow, that is a huge jump! I want to support it! It goes way past what I have here locally, makes that work obsolete. Story of my life haha... No hard feels though, it's my intention to never release that work, unless need be, as I learned allot from it. If you're not able to get the port of Ixcoin to v0.10 done as easily as you've hoped, it's available. My guess is that your efforts will prove successful, there will be no need to create separate branches or make that migration in baby steps. In either case, I'll see you again soon on irc, been buried in code this last month and unavailable, hope you had a good holiday. For the rest of you, what this all means is that I'm pretty much setup to provide production class builds to various targets for Ixcoin, and it's quick. Once the toolchains have been built. I see the Bitcoin gurus released a major new update right after the new year, changes to the 'depends' builder concept I'm now using. Finally there is a pretty good chance we can offer Darwin builds from a linux hosted builder, I want us to have that capability. Will be testing Bitcoin's latest over the next two weeks, if someone else has it figured out already, super. Please step forward. There are lots of other loose ends I want to work on, but my priority is going to shift now to finishing what I started which is, the process of generating language translations files we need for Ixcoin. Can handle the technical aspect of it, but it's not my specialty, so always looking for help in that regard. Humans have so many different languages. You can find the account I created for team work here: https://www.transifex.com/projects/p/ixcoin-core-qt/I'll announce when I have the 1st set of Ixcoinstrings submitted. Getting a good set of language files for Ixcoin is something which I think is real important, and hope to streamline the process enough, that it can get done periodically. As I haven't been around much for over two months, want all of you to know that I still fully support everyones efforts to advance Ixcoin's presence into what I think will be a big time growing market place for 2015! We may not all agree on what direction to take, or how to do it, but that is all part of the great experiment. Not to be taken as a personal attack, simply because we may disagree. More to follow... have a few hundred thousand posts to wade through... GR |
|
|
|
kind of rethorical question  But do you know? Is there a way to trade bullion to crypto conveniently and quickly back and forth? Where can i trade tokens that entitle me to bullion with others (aka metal backed hedges with option to ship) for crypto? Option to ship, ya right. Sorry, but I just don't believe in that as really being an <option>. Go ahead and play that game if you want to, for me: IF it's not secured in my wallet or delivered and backed up to my safe, I'm guessing its a scam. Physical Silver<-->Crypto trades have always interested me. After doing considerable amount of study a couple months ago, to update myself on the buy side of that trade, I would use AmigaMetals, out of Colorado today. Have not used them yet though, so it's just an opinion. My early posts on here, from back in 2012, are proof that I developed some partners to exchange with that were also interested in this topic. At the time 1oz of Silver was worth 4-6 bitcoins, and I would still be willing to sell there if your interested in taking immediate delivery. Break even price for me! Haha, shipped overnight or 2-day priority in the usa. Could be a good deal for you if all those Dec14 Silver futures contracts demand to take delivery. Have you seen that? Last I looked it was over 100K contracts. I know most of you are laughing, it's been a bad trade all this time, back then though it was all about developing trading partners and learning about crypto for me. If your in Europe, perhaps this fellow out of London could get you a better deal  bigtimespaghetti https://bitcointalk.org/index.php?topic=230141.4920GR P.S. I'd be interested in some Unobtanium. |
|
|
|
Submit requests for non PoS coins for Wallets!
Sure would like to get an Andriod wallet going for Ixcoin, it should be an easy one for you. Our work is nearly completed & shortly we'll have all the major builds out for win32/64, mac & linux PPA flavors equal to the 0.9.3 Bitcoin codebase level. Know your more than likely extremely busy, but would like to attack the problem of having a version that runs on an Andriod and have not really started the process of figuring out what needs to be done. Perhaps you could easily do it, for me it will be a totally new learning experience. Haven't really looked into what issues would be involved, any pointers would be greatly appreciated or feel free to address the community @ large and the Ixcoin Foundation in our ToDo thread here: https://bitcointalk.org/index.php?topic=230141.0Thanks much, GR |
|
|
|
It depends on how your coin has the 'sendalert' command coded. In order to use the 'sendalert' command the parameters typically go: The message you want to send is the 1st parameter, the 2nd is the private key for every coin I've looked at. Haven't looked at peercoin though. Typing 'help sendalert', or sendalert with no parameters into your console should return the help message with the details spelled out. However knowing what priority to use depends on what other parts of the code use for things like out of hard disk space or major coin forks detected, stuff like that which should always take priority when it comes to alerting the user to issues detected by their client and displayed as the highest priority Alert message. Picking an alert id is important from the perspective of being able to send another one later on that can delete all the previously issued alerts of a lower value. That is about all you really need to be known, in order to use the alert system. Spent a great deal of time on this in Sept for Ixcoin codebase while working on our 0.9.2.1/0.9.3 release. Wish I'd made the alert commits separate from allot of other stuff, I was working on at the time, so I could reference you to those specific changes. Originally added the 'sendalert' command code to rpcmisc.cpp, then moved it to rpcnet.cpp, where I think it belongs. We only build that command into non-release code, but everyone gets the benefit now of being able to use the 'getnetworkinfo' command, where they can see ALL the alerts propagating over the network in the JSON response string returned. Also our sendalert method offers (for those that know the private key) optional parameters for setting the number of days an alert is relayed, as well as when it expires, not just canceling previous alerts as an optional parameter like I'd seen in many other coins. My code base and commit history here could possibly help you some: https://github.com/GroundRod/IXCoin/tree/iXcoin/srcThink the commits on Sept 24th & the 30th were the most relevant to your question: https://github.com/GroundRod/IXCoin/commits/iXcoin/srchttps://github.com/GroundRod/IXCoin/commit/304ec765b20fcda0f5f65847b62c47926a18a8d3I know that Gavin has done allot of work recently & been changing this part of the code in Bitcoin source, as it heads into rc1, at some point I'll be re-visiting those changes as we once again migrate up... Hope that helps, GR ETA: Thanks gatra for that link to laanwj's commit, had not seen that particular way of doing sendalert before, it's interesting, yet I still don't like the idea of building an executable with the private key, don't ever let that version get out for your coin, or anyone could generate them. |
|
|
|
@Vlad2Vlad - It's never been easy to be an early adopter & I know its hard to <not> look @ the price, but the volume is extraordinary, and you said yourself what that is a prelude too This coin seems to have persevered for quite some time now. I'm keeping an eye on it, but what exactly does this coin have to offer that other coins don't?
@sgi02 - Yes it has persevered, and today we have 3 years and 26 weeks of blockchain to prove it. Recently (Oct 2014) Ixcoin proved a core aspect of crypto currencies in general, and bitcoin in particular was valid. As I don't expect to live long enough to see this same thing happen for Bitcoin, it was a core reason I got involved in Ixcoin, and a big part of the crypto coin experiment. It passed the test with flying colors. The question was: When all the coins have been mined, what is going to happen? Will the network survive? Will the software fail? It did survive and the software did NOT fail. IXCOIN now has zero inflation. Today we are seeing an ever growing community of supporters, in part because Ixcoin is Bitcoin without all the problems @ a fraction of the price, to Vlad's dismay. Bitcoin is having a really ruff time of it @ the moment, and learning how to cope with vast amounts of growth, I think it will succeed in that effort and I also think that Ixcoin will be right here leveraging that expertise, as well as exploring the world of zero inflation in crypto coin land. I'm pretty sure no other POW (Proof-Of-Work) coin has done this, certainly no other coin this old. If your like me, and bought most of your BTC when it was $5 in the summer of 2012, you'll join us & we look forward to having you onboard. @Kraizi - Thanks for that update & lots of good responses to the question we see most often. We get asked that allot. I've been excited to see IXCo.in show up on the scene with an Asian based IXC exchange, and look forward to their release of an Electrum wallet. To see this volume on the exchange already, in such a short time, is....how do I say it. Extraordinary! -------------------------------------- Ixcoin CORE 0.9.3 development update: -------------------------------------- It's been awhile, so felt it important to give you all an informative update on what has been happening with Core code development. Allot of work has been going on in the background for a complete release of the new Ixcoin Core 0.9.3 software. For those of you that don't regularly follow the Github commits, I've been making some final changes to our repository, primarily those changes were to correct a few minor problems with our code regarding testnet and regression testing modes of operation and is a prelude to the clients merged-mining code final test & release. This aspect of the software development is now in Ahmed capable hands & I expect he will be reporting here as Testnet progress unfolds, possibly a private mainnet fork will be operated for awhile to ensure everything is working 100% before final builds are made to everyone's favorite OS/platform. In the interest of expediting future upgrades & in order to keep us current with Bitcoin Core code more easily, he's reverted allot of my work back to a bitcoin state. At the moment, I"m not sure how extensive that re-work will have to be, just found out about it in the last 24hrs & will try to post something after looking at the issues involved. As most of you know I'm committed to keeping Ixcoin code updated & this re-factoring shouldn't be a problem. My expectation is it can be done while the final merged-mining tests are going on. Shouldn't be to much longer before all of you can enjoy having a new fully functional Ixcoin node operating on the network or an Electrum wallet, which would also be way cool. We do need more seed-nodes to place in the code, anyone able & willing to commit to maintaining 24/7 nodes @ a static IP, please PM me here, or post in the thread so we can get those entries created and into the final 0.9.3 builds. It would be greatly appreciated. GR ETA: So far a number of people have downloaded and are using my last build, v0.9.2.1, unless your a miner, it's fully functional and no problems have been reported: You can find that Win32 Setup and a Bootstrap.dat archive for Ixcoin here: https://github.com/GroundRod/IXCoin/releases |
|
|
|
|
@thunderjet - Excellent find! Spent allot of time in that RelayWalletTransaction(), convinced that was where the problem must be @. My initial reaction here is that you've nailed it. My experience is primarily with the 0.9.2+ codebase & there is significant differences between the two there, did not know that about 0.8.6. We'll have to see what Gnosis thinks, but I'm really happy you pointed this out!
GR
|
|
|
|
|
Show Posts
