Despite what some of you may think about the opinions expressed in my last post, I'm not interested in changing Ixcoin to nullify past blocks, especially those from which development funds are coming from. Was just pointing out, programming can take many directions, most of them are the wrong way to go....community consensus is really important here, and I appreciate the engaged response and discussion it generated, everyone that cared to speak up, I hope got a chance to do so. If circumstances change, its not a topic to late to discuss, but I think all of us agree it would be a bad idea. My preference though would be to change the logo, perhaps down the road...
@cinnamon_carter - Indeed, really well said!!!
post.
The Satoshi Nakamoto white paper can be seen here:
https://en.bitcoin.it/wiki/Bitcoin_white_paper...and yes, skimmed all 9 pages, once along time ago, think it was late '11 or 2012. Then last Dec '13. read and re-read it a over the coarse of several days. That was more than 8 months ago now, and I agree with you, it is something everyone involved in the financial revolution that is these crypto-coin-thingies should take it to heart, and try to understand it, to the best of his/her ability. It defines a new way, compared to how most of us where raised, to think about: Money.
Yes I'll try to spend sometime 'talking with' the ixcoind executable you built, been getting prepared to compile my own executables from source, been learning how to fork and fetch copies of Almed's masters to work on locally, have everything downloaded which should be needed to build Bitcoin 0.9.2.1, so hopefully I'm close, been trying to get Ubuntu & VirtualBox setup the way I want, learning to use GitHub, no small task in itself! The history and the way it got organized is also an interesting story, for those that care...what an invention!
Come to think of it, testing your ixcoind.exe might just get exercised in the project I've taken on for myself, building a Ixcoin Bootstrap.dat file, starting with the source code here:
IXCoin\contrib\linearize
Trying to help get it ready for release, before the end of mining party hits, it doesn't matter in the process of building the executables. Something we all want to have, with the executables though IMO: That code Almed is using ,came from Bitcoin (indirectly through a DVC fork), and I'm pretty sure linearize.py is still for Bitcoin, we need it to work for Ixcoin, so I'm writing the config file and changing the code, so that it works for our coin, runs in python to build the linearized version of a blockchain, finally apply that output (bootstrap.dat) to the executable when there is no blockchain files, confirm it initialized properly. All those hungry new Ixcoin holders will be needing a clean/new blockchain & (I hope) find bootstrap.dat very useful in bringing over 3 years of transaction history up-to-date.
I'm building some bootstrap.dat files for testing on my machine this week, not sure if space anywhere to upload, once I'm done with the code changes, plan is to release it officially via a torrent, it's going to be somewhere in the 300MB range compressed. How about ixcoin.org, do we have any server space there? Somewhere I can ftp'it. Can send it out as a torrent, but I can't keep a machine on to seed it all the time here. Other suggestions?
So just chugging along...plan is to generate what is for me, the 'first' Git Pull request to Almed, so as to notify him to bring those changes into his source base, at least if I'm understanding how to say that right, learning how to do all this is the 'big deal' to me, still trying to figure allot of stuff out. Anyway hope to play at least a very tiny roll here as part of a developer team, having you on board w/time Cinnamon_Carter is a really big deal, and although Almed has been doing the heavy lifting, I'm looking forward to being able to help out more in the future too.
@Vlad2Vlad - Ya it might get down to a few large centralized power(s), but I don't see Bitcoin going to one. As you know, where I've seen a possible weakness is in the transaction Tx and Relay fees coded into our Ixcoin executable, asked Almed about it, doesn't seem to bother him, at least for right now. So I'm not going to be doing anything there, unless we can agree on 'what needs' to be done.
One could work on that part of the code, perhaps change it to be more friendly to users that might be trying to send Ixcoin with zero or too low of a transaction fee, when known miners no longer accept 0.0 fees, it becomes a BIG problem. It means that a coin send for you could be lost for a very long time. As we're soon no longer mining coins, a code change to Ixcoin could become a plus-plus....to those of us using the network, and 'perhaps' a bargaining chip you can use when telling others what we intend on offering, enforcement of transaction fees is important to a coin that no longer mines them and we're going to be doing that, because we have to. We'll see than your funds get delivered quickly and easily to the recipient. This is not to say it's a
reversible charge in the traditional sense, but it could be thought of as a 'Save an innocent' user from accidentally (or intentional-think cheap) sending coins that can never get delivered. If you ever have to 'reverse a charge' from within your wallet software, so as to 'try it again' with a higher fee, I'm pretty sure most people
won't have a clue. Instead, they'll consider the coins lost, because of the dam coin's network. That is what I'm trying to avoid & a Reminder: No coding work is being offered here to be included in the up-and-coming release, nothing regarding Tx/Relay fees will be different, I'm pretty sure it will be identical to the Bitcoin 0.9.2.1 code base in this regard. But the code 'could' get changed, if we want it to be and we keep it simple enough.
@Deadsea33 - Its interesting info, and along the lines of what I also think are some good ideas, I'm not expert enough to comment, other than to suspect that faster block times would mean accepting a reduction in the hash (security) that is allowed for a merged block to be included in the ixcoin blockchain. 'IF' that thinking is correct, one could argue that the hash rate has gotten so high 'now', that we could live with allot less (as proof of work), if it meant that in so doing, our ability to speed up transaction transversal time gets reduced. Say by a factor of 4x or in the 2-3 minute range. Kinda thinking it sounds like a really good idea, yet my guess is there is some details I don't understand well enough, so kinda talking to myself out loud here...
L8r All,
GR
