|
Title: Amateur hour Post by: Blinken on March 12, 2013, 03:56:38 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production.
I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Title: Re: Amateur hour Post by: gusti on March 12, 2013, 03:58:25 PM Please, not again ... ::)
Title: Re: Amateur hour Post by: misterbigg on March 12, 2013, 03:58:53 PM ...the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses ...there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. Fortunately, Bitcoin is open source. Go ahead and fork the repository, apply your fixes (since you're a developer) and let me know once you've got that debugged and tested. Then, write a paper describing your revolutionary improvements allowing Bitcoin to scale while retaining its decentralized properties. Until then, STFU. Title: Re: Amateur hour Post by: Piper67 on March 12, 2013, 03:59:59 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Really? A lot of ill-conceived design points and implementation weaknesses? Bitcoin has been around since 2009. There was one bug that caused a fork in 2010, and another one last night. Both got solved in a matter of hours. The blockchain size is an issue of agreement between the devs, not a technical one. And all of this for a piece of software that is still in beta. Do you, a professional, have any idea how this compares with, oh, I don't know... Windows 95???? Title: Re: Amateur hour Post by: Scrat Acorns on March 12, 2013, 04:00:32 PM I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose Someone doesn't know how fees and transaction priorities work. Title: Re: Amateur hour Post by: DeathAndTaxes on March 12, 2013, 04:01:27 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Then do it. Take the codebase fork it and produce BlinkCoin. Let the market decide which one is superior. STFU or do it. Here is my challenge to you. "You can't. You absolutely and completely lack that skills to accomplish what you claim". Prove me wrong. Title: Re: Amateur hour Post by: mccorvic on March 12, 2013, 04:02:48 PM Phew, what we really needed was another entire thread on this. I mean, honestly, who thought 20 threads already was really enough?
Title: Re: Amateur hour Post by: acoindr on March 12, 2013, 04:04:47 PM Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. That's not due to software design, but Bitcoin design. Broadcasting massive amounts of transaction data to home nodes, for authentication and relay, without T1 level bandwidth is not feasible. I've written a solution which addresses that issue. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 04:06:12 PM I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose Someone doesn't know how fees and transaction priorities work. If they worked, then we wouldn't have a problem with Satoishi Dice would we? Title: Re: Amateur hour Post by: drawingthesun on March 12, 2013, 04:14:53 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. If you care about Bitcoin, you should get on board and start making changes, if they do not allow your changes then create a fork. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). This is the first major problem Bitcoin has had, a few others have been smaller. But the developers have worked wonders. We have an entire decentralized monetary system that has been working with increased use for almost 3 years without a stop. Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. Whilst I agree the views against S.Dice are short sighted, the problem isn't the volume of transactions but the returns of 1 satoshi that is being considered spam. I personaly think that the developers need a solution that makes what S.Dice is doing a non-issue, but its causing issueis because of lots of 1 satoshi tx which is spamming the chain. Its a problem that needs a lot of work. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. This is rude and I can't answer if its true or not, but based on the vibe I get from you I bet you have no idea what your talking about. Many of us here are actually professional programmers/engineers and the Bitcoin project is hard! Its way out there and new, not your average web app or business application. This is new territory and of course there will be problems. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 04:17:09 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Then do it. Take the codebase fork it and produce BlinkCoin. Let the market decide which one is superior. STFU or do it. Here is my challenge to you. "You can't. You absolutely and completely lack that skills to accomplish what you claim". Prove me wrong. Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. I am just saying that it is inevitable that the design and development move to a new level, so we, as a community, need to adopt the mindset that evolution must occur and figure out how to do that. Title: Re: Amateur hour Post by: justusranvier on March 12, 2013, 04:21:34 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. Title: Whining hour Post by: Severian on March 12, 2013, 04:24:22 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. No, Bitcoin is a spontaneous production by a pro: Quote I actually did this kind of backwards. I had to write all the code before I could convince myself that I could solve every problem, then I wrote the paper. I think I will be able to release the code sooner than I could write a detailed spec. Satoshi Nakamoto, Nov 2008 (http://www.mail-archive.com/cryptography@metzdowd.com/msg09980.html) He was solving a problem with an experiment. This is the experiment. Either create your own experiment that results in a half a billion dollar market (that could disappear tomorrow) or quit whining about the experiment in progress. Thanks. Title: Re: Amateur hour Post by: drawingthesun on March 12, 2013, 04:24:59 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. I am just saying that it is inevitable that the design and development move to a new level, so we, as a community, need to adopt the mindset that evolution must occur and figure out how to do that. If you buy Bitcoin and want the value of the Bitcoin to increase, giving up your time to fix issues you can clearly see will pay off will it not? If you can help Bitcoin accommodate the issues you have identified and because of that Bitcoin will have more chance of becoming a global currency. Your actions will cause those Bitcoins you buy will be worth thousands and the time you invested to help that happen will pay off far more than taking a salary. Perhaps? Title: Re: Amateur hour Post by: Piper67 on March 12, 2013, 04:25:46 PM Those who can, do.
Those who can't, bitch. ;D Title: Re: Amateur hour Post by: Littleshop on March 12, 2013, 04:27:57 PM I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. It is hard to understand what you are even saying here. Are you saying you are so good at software development that you could write a better client for handling high volume transactions or are you saying you could easily flood the network with transactions? Hint: Both is not an answer because you would be wrong on both points. Title: Re: Amateur hour Post by: Gareth Nelson on March 12, 2013, 04:33:05 PM If you don't have time to write the fix yourself, what about outlining how to fix it so that someone else can do the heavy lifting of coding it?
Not an attack or anything - just seems like if you truly have a way to fix the issues and the only issue is lack of time then describing your method would appear to be the least you can do. Title: Re: Amateur hour Post by: wtfvanity on March 12, 2013, 04:35:34 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Nu uh. My penis is bigger than yours. Title: Re: Amateur hour Post by: drawingthesun on March 12, 2013, 04:36:46 PM I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes Also this will cost you a lot in Bitcoins, feel free to feed the miners. This might cost you a hundred Bitcoins an hour though. :) Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 04:38:39 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 04:39:10 PM I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. Yeah, so could dozens of other people here (the current devs included). But try creating such a system and also make it completely decentralized, impossible to counterfeit, impossible to create fraudulent transactions, a fair system of distribution, and nearly free to send/receive said transactions.Good luck. ;) I have no doubt that Bitcoin can (and will) be improved upon. But this is an absolutely appropriate case of "put up or shut up", because any improvements that could be made are either in progress or unknown. Unless you have specific ideas for how to improve upon the current system, or you program those ideas yourself, then your words are utterly meaningless and useless. Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 04:40:01 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. Title: Re: Amateur hour Post by: deepceleron on March 12, 2013, 04:49:36 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. As an amateur forum user, this may be an opportune time to point out to others the ignore button.Title: Re: Amateur hour Post by: Jaw3bmasters on March 12, 2013, 04:50:50 PM LOL, "BlinkCoin"........
@ OP, Isn't that why we have Ripple? BTC will eventually be too.......what's the word,........! precious, to trade lightly. "BlinkCoin" <<<------ LMAO Title: Re: Amateur hour Post by: Piper67 on March 12, 2013, 04:53:15 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. Of course he does. He's a "professional"... with a nice troll for an avatar, which should've been the first clue. Title: Re: Amateur hour Post by: bbit on March 12, 2013, 04:57:10 PM I'm laughing at this thread! :D
Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 04:57:18 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks. Title: Re: Amateur hour Post by: Piper67 on March 12, 2013, 05:01:36 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks. But the real money only starts flowing in when you uncouple the Heisenberg Compensators! Title: Re: Amateur hour Post by: jl2012 on March 12, 2013, 05:03:03 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Yes you could. Please pay the bill first: 1,000,000,000 * 0.0005 * $43 = $21,500,000 Title: Re: Amateur hour Post by: DataPlumber on March 12, 2013, 05:04:35 PM But the real money only starts flowing in when you uncouple the Heisenberg Compensators! That, or the transporters start vaporizing people. I keep forgetting which.Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 05:06:06 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 05:09:38 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Yes you could. Please pay the bill first: 1,000,000,000 * 0.0005 * $43 = $21,500,000 Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. Title: Re: Amateur hour Post by: tvbcof on March 12, 2013, 05:10:57 PM ... The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. At this point I bet there are a handful of very well capitalized entities of various types who would be delighted to take over if that is what you are getting at. Bitcoin could be huge, and controlling it could be an immensely lucrative adventure. That is probably the direction we'll need to go if we want it to evolve to service end-user transactions directly (as opposed to being a 'backing' for second tier solutions for example.) Title: Re: Amateur hour Post by: sd on March 12, 2013, 05:23:57 PM Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. Do you propose changing that? Instead of cursing the darkness how about lighting a candle by telling us what you believe needs fixing and how you believe it should be fixed. The best way to do that would be to put your ideas on a webpage somewhere and post the link here. 95% of this board will just troll but the people who matter will judge your ideas on their merits. Title: Re: Amateur hour Post by: jl2012 on March 12, 2013, 05:29:51 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Yes you could. Please pay the bill first: 1,000,000,000 * 0.0005 * $43 = $21,500,000 Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. What an amateur attack! Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 05:43:12 PM Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. Do you propose changing that? Instead of cursing the darkness how about lighting a candle by telling us what you believe needs fixing and how you believe it should be fixed. The best way to do that would be to put your ideas on a webpage somewhere and post the link here. 95% of this board will just troll but the people who matter will judge your ideas on their merits. Well, in my opinion there are several steps that would be key improvements: - Create a chained trust system, this would allow a transaction to be verified by a logarithmically smaller number of clients; the key observation here is that to prevent double spending you do not need a majority of machines to vote, you only need a quorum of trusted machines; to understand this note that there are the so-called "5 degrees of separation" meaning that you "know" everybody in the world friend of a friend of a friend, etc. If each client has a "reputation" with its neighboring clients, you can create a web of trust such that a transaction can be verified with only a hundred or so votes, instead of the thousands (or millions?) now necessary. Also, these votes will tend to happen on the fastest machines, thus further speeding the process. - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. - Base transaction priority on reputation, not age/size the way it is now. This will speed transactions being done by the largest, most trusted players and push out DOS transactions in a way far more effective and secure than the current system which can be gamed in all sorts of ways. I would note that a web of trust is also critical to protecting the network against a motivated minority from taking over the system. In the current system, its one machine, one vote. This ill-conceived design has the result that a small group of professionals using large botnets could outvote the network or a big enough sub-network such that they could seize or create coins. As the value of bitcoins grows the feasibility of this kind of attack is increasing. In a reputation system, not all machines have the same vote, but more trusted machines have greater weight, this prevents the possibility of a zombie attack. Title: Re: Amateur hour Post by: wtfvanity on March 12, 2013, 05:45:26 PM Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. Do you propose changing that? Instead of cursing the darkness how about lighting a candle by telling us what you believe needs fixing and how you believe it should be fixed. The best way to do that would be to put your ideas on a webpage somewhere and post the link here. 95% of this board will just troll but the people who matter will judge your ideas on their merits. Well, in my opinion there are several steps that would be key improvements: - Create a chained trust system, this would allow a transaction to be verified by a logarithmically smaller number of clients; the key observation here is that to prevent double spending you do not need a majority of machines to vote, you only need a quorum of trusted machines; to understand this note that there are the so-called "5 degrees of separation" meaning that you "know" everybody in the world friend of a friend of a friend, etc. If each client has a "reputation" with its neighboring clients, you can create a web of trust such that a transaction can be verified with only a hundred or so votes, instead of the thousands (or millions?) now necessary. Also, these votes will tend to happen on the fastest machines, thus further speeding the process. - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. - Base transaction priority on reputation, not age/size the way it is now. This will speed transactions being done by the largest, most trusted players and push out DOS transactions in a way far more effective and secure than the current system which can be gamed in all sorts of ways. I would note that a web of trust is also critical to protecting the network against a motivated minority from taking over the system. In the current system, its one machine, one vote. This ill-conceived design has the result that a small group of professionals using large botnets could outvote the network or a big enough sub-network such that they could seize or create coins. As the value of bitcoins grows the feasibility of this kind of attack is increasing. In a reputation system, not all machines have the same vote, but more trusted machines have greater weight, this prevents the possibility of a zombie attack. Oh good, you don't want to fix bitcoin you want to create ripple 2.0. Go ahead. Title: Re: Amateur hour Post by: Herodes on March 12, 2013, 05:57:06 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. You may want to look up the term 'arrogance'. If you don't intend to contribute, then bragging on an internet forum about your high skill levels that you will not put to use for the betterment of bitcoin is somewhat of an odd thing to do. I am sure there's plenty of 'professional software engineers' that's even better than you. No matter how good you are, there's always someone better. You may want to tone down your voice a little, as I can't see how you're contributing to the community. Title: Re: Amateur hour Post by: prezbo on March 12, 2013, 05:59:38 PM if you could control about 10 Thash/s currently you would have voting power and could you not obtain that by gaining control of Deepbit, 50BTC, Ozcoin and BTCGuild? Let's say you could. Then what would you do with this voting power? Well, what I would do is muster a DDOS attack on www.sesamestreet.org, but that's just me. The more important question is what would a group of professional Russian hackers do? The answer to that is forge a million BTC and use the proceeds to underwrite an expansion of their criminal enterprises. An even more scary possibility is that the Schumerites would take over the network and deploy armageddon: delete half the coins and quadruple spend the other half, or just transfer everyone's coins randomly between different addresses. Now, THAT would be FUD. This is your post from august 2012. And you're telling us bitcoin has serious flaws? Yeah. Title: Re: Amateur hour Post by: Timo Y on March 12, 2013, 06:00:04 PM Bitcoin has fewer bugs than most professional software I've used.
Title: Re: Amateur hour Post by: DeathAndTaxes on March 12, 2013, 06:04:44 PM Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. That is false (or at best incomplete). Spammy tx are spammy regardless of age and thus always low priority and thus always require a fee to be included by miners or relayed by nodes using the reference client rules. How are you going to "fix" something you don't understand? Title: Re: Amateur hour Post by: wtfvanity on March 12, 2013, 06:08:09 PM if you could control about 10 Thash/s currently you would have voting power and could you not obtain that by gaining control of Deepbit, 50BTC, Ozcoin and BTCGuild? Let's say you could. Then what would you do with this voting power? Well, what I would do is muster a DDOS attack on www.sesamestreet.org, but that's just me. The more important question is what would a group of professional Russian hackers do? The answer to that is forge a million BTC and use the proceeds to underwrite an expansion of their criminal enterprises. An even more scary possibility is that the Schumerites would take over the network and deploy armageddon: delete half the coins and quadruple spend the other half, or just transfer everyone's coins randomly between different addresses. Now, THAT would be FUD. This is your post from august 2012. And you're telling us bitcoin has serious flaws? Yeah. Hey, ease up there prezbo. Between August 2012 and today, he has gone from a newb troll to a Professional Programmer. Duh. Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 06:09:30 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Title: Re: Amateur hour Post by: oOoOo on March 12, 2013, 06:13:14 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. I am just saying that it is inevitable that the design and development move to a new level, so we, as a community, need to adopt the mindset that evolution must occur and figure out how to do that. Please show one piece of code you've actually written -> Title: Re: Amateur hour Post by: prezbo on March 12, 2013, 06:13:43 PM Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. That is false (or at best incomplete). Spammy tx are spammy regardless of age and thus always low priority and thus always require a fee to be included by miners or relayed by nodes using the reference client rules. How are you going to "fix" something you don't understand? Title: Re: Amateur hour Post by: wtfvanity on March 12, 2013, 06:20:01 PM Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. That is false (or at best incomplete). Spammy tx are spammy regardless of age and thus always low priority and thus always require a fee to be included by miners or relayed by nodes using the reference client rules. How are you going to "fix" something you don't understand? Ask the professional programmer. Title: Re: Amateur hour Post by: DeathAndTaxes on March 12, 2013, 06:21:36 PM That assumes
Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. That is false (or at best incomplete). Spammy tx are spammy regardless of age and thus always low priority and thus always require a fee to be included by miners or relayed by nodes using the reference client rules. How are you going to "fix" something you don't understand? That assumes no other transactions on the network. As tx volume increases legit users will raise their fees to ensure they are included in blocks in a timely manner. That means you would need to start paying fees (and then increasing amount of fees) or find your tx excluded. However yes with a "principal" of 144,0000 BTC you could add 1,000 tx to each block assuming you also could afford sufficient tx fees to "buy" enough space for them. Title: Re: Amateur hour Post by: DeathAndTaxes on March 12, 2013, 06:24:28 PM P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) http://ecx.images-amazon.com/images/I/51MwjkL9cDL.jpg Title: Re: Amateur hour Post by: sd on March 12, 2013, 06:25:16 PM Well, in my opinion there are several steps that would be key improvements: - Create a chained trust system, this would allow a transaction to be verified by a logarithmically smaller number of clients; the key observation here is that to prevent double spending you do not need a majority of machines to vote, you only need a quorum of trusted machines; to understand this note that there are the so-called "5 degrees of separation" meaning that you "know" everybody in the world friend of a friend of a friend, etc. If each client has a "reputation" with its neighboring clients, you can create a web of trust such that a transaction can be verified with only a hundred or so votes, instead of the thousands (or millions?) now necessary. Also, these votes will tend to happen on the fastest machines, thus further speeding the process. - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. - Base transaction priority on reputation, not age/size the way it is now. This will speed transactions being done by the largest, most trusted players and push out DOS transactions in a way far more effective and secure than the current system which can be gamed in all sorts of ways. I would note that a web of trust is also critical to protecting the network against a motivated minority from taking over the system. In the current system, its one machine, one vote. This ill-conceived design has the result that a small group of professionals using large botnets could outvote the network or a big enough sub-network such that they could seize or create coins. As the value of bitcoins grows the feasibility of this kind of attack is increasing. In a reputation system, not all machines have the same vote, but more trusted machines have greater weight, this prevents the possibility of a zombie attack. You propose a system that would create trusted machines and reputation. BitCoin is built on the belief that no node has a reputation greater or lesser than any other. Distributed systems that have a concept of trust can be gamed by Sybil attacks. How would you allocate 'reputation' to nodes in a way that prevents this? I really don't see how it's possible but I may be missing something. BitCoin isn't one machine one vote. Voting power is distributed proportional to hashing power. Even then voting only decides which valid transactions get included in the blockchain. No large botnet, or large amount of hashing power, could seize coins from anyone, or create coins in any way other than taking mining rewards or transaction fees. Even if I had some magical ASIC computer with 99.999% of the network hash power I could not take a single cent out of your wallet. What you propose is so far away from BitCoin there is no way to there from here. This should be an altcoin to see if it really works. It least then we would have an altcoin that isn't just a recompile of bitcoin with very minor changes. Title: Re: Amateur hour Post by: sd on March 12, 2013, 06:27:54 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". I assume coins would be split so there are more in circulation. Yes it's exactly the same as moving the decimal place as far as value is concerned but it's still done by major companies all the time. See http://en.wikipedia.org/wiki/Stock_split Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 06:31:07 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". I assume coins would be split so there are more in circulation. Yes it's exactly the same as moving the decimal place as far as value is concerned but it's still done by major companies all the time. See http://en.wikipedia.org/wiki/Stock_split Title: Re: Amateur hour Post by: sd on March 12, 2013, 06:32:21 PM That assumes no other transactions on the network. As tx volume increases legit users will raise their fees to ensure they are included in blocks in a timely manner. That means you would need to start paying fees (and then increasing amount of fees) or find your tx excluded. However yes with a "principal" of 144,0000 BTC you could add 1,000 tx to each block assuming you also could afford sufficient tx fees to "buy" enough space for them. If you are going to troll the guy at least troll him, not some strawman misinterpretation if what he said. He said he could generate many of transactions. He did not say he could generate many transactions all of which would be included in the block chain in a timely manner. Title: Re: Amateur hour Post by: benjamindees on March 12, 2013, 06:33:59 PM Oh good, you don't want to fix bitcoin you want to create ripple 2.0. Go ahead. +1 Title: Re: Amateur hour Post by: prezbo on March 12, 2013, 06:34:02 PM That assumes Agreed. I was just trying to figure out how much one would need for it to be theoretically possible. 144000 btc is alot.Fees are optional and can be set to any level. Transaction priority is partly based on age, so your "old" spam trumps any "new" transaction with the same fee or less. That is false (or at best incomplete). Spammy tx are spammy regardless of age and thus always low priority and thus always require a fee to be included by miners or relayed by nodes using the reference client rules. How are you going to "fix" something you don't understand? That assumes no other transactions on the network. As tx volume increases legit users will raise their fees to ensure they are included in blocks in a timely manner. That means you would need to start paying fees (and then increasing amount of fees) or find your tx excluded. However yes with a "principal" of 144,0000 BTC you could add 1,000 tx to each block assuming you also could afford sufficient tx fees to "buy" enough space for them. Title: Re: Amateur hour Post by: Jan on March 12, 2013, 06:34:42 PM I love this forum.
Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 06:37:28 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. I am just saying that it is inevitable that the design and development move to a new level, so we, as a community, need to adopt the mindset that evolution must occur and figure out how to do that. Please show one piece of code you've actually written -> The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. Here is a more readable piece of code in Java if you are not into machine language: /** Number of combinations * In the case that items > slots this value is items! / (slots! * (items - slots)!) . * Goes up to Choose( 66, 33 ) = 7219428434016265740, the maximum that fits in a long. * This is an optimal implementation that uses factorization to reach the largest exact values possible. * Try Choose( 60, 30 ) in a web-based calculator, for example, and you will not get an exact answer. * This is because naive implementations do not use factorization. * @param items The count of unique things to be combined. * @param slots The number of slots or opportunities into which to combine them. * @return number of possible unique combinations or 0 in the event of an error or invalid input or -1 in the event of an overflow */ public final static long combinationCount( int items, int slots ){ if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; if( slots == items ) return 1; int extra = items - slots; if( extra > slots ){ slots = extra; extra = items - slots; // extra always has as many or fewer items than slots } int[] aiNumeratorFactors = new int[100]; for( int xNumeratorFactorial = items; xNumeratorFactorial > slots; xNumeratorFactorial-- ){ int[] factors = factor( xNumeratorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2]; System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length ); aiNumeratorFactors = aiNumeratorFactors_new; } aiNumeratorFactors[0]++; aiNumeratorFactors[aiNumeratorFactors[0]] = factors[xFactor]; } } int[] aiDenominatorFactors = new int[100]; for( int xDenominatorFactorial = extra; xDenominatorFactorial > 1; xDenominatorFactorial-- ){ int[] factors = factor( xDenominatorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiDenominatorFactors[0] == aiDenominatorFactors.length - 1 ){ // need to expand list int[] aiDenominatorFactors_new = new int[aiDenominatorFactors.length * 2]; System.arraycopy( aiDenominatorFactors, 0, aiDenominatorFactors_new, 0, aiDenominatorFactors.length ); aiDenominatorFactors = aiDenominatorFactors_new; } aiDenominatorFactors[0]++; aiDenominatorFactors[aiDenominatorFactors[0]] = factors[xFactor]; } } int[] aiNumeratorFactors_fitted = new int[aiNumeratorFactors[0]]; System.arraycopy( aiNumeratorFactors, 1, aiNumeratorFactors_fitted, 0, aiNumeratorFactors[0] ); aiNumeratorFactors = aiNumeratorFactors_fitted; int[] aiDenominatorFactors_fitted = new int[aiDenominatorFactors[0]]; System.arraycopy( aiDenominatorFactors, 1, aiDenominatorFactors_fitted, 0, aiDenominatorFactors[0]); aiDenominatorFactors = aiDenominatorFactors_fitted; java.util.Arrays.sort( aiNumeratorFactors ); java.util.Arrays.sort( aiDenominatorFactors ); long nTotal = 1; int xNumerator = 0; int xDenominator = 0; while( true ){ if( xNumerator == aiNumeratorFactors.length ) return nTotal; if( xDenominator < aiDenominatorFactors.length && aiNumeratorFactors[xNumerator] == aiDenominatorFactors[xDenominator] ){ xDenominator++; } else { if( Long.MAX_VALUE / nTotal < aiNumeratorFactors[xNumerator] ) return -1; // overflow nTotal *= aiNumeratorFactors[xNumerator]; } xNumerator++; } } Title: Re: Amateur hour Post by: acoindr on March 12, 2013, 06:39:38 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". I assume coins would be split so there are more in circulation. Yes it's exactly the same as moving the decimal place as far as value is concerned but it's still done by major companies all the time. See http://en.wikipedia.org/wiki/Stock_split The comparison of currency to stocks by sd isn't apt. The two are not compatible. But on another note, yes, stock splits are essentially psychological. The value effect has to do with our distorted, manipulated, inflationary market and financial system, but that's another story. EDIT: also, no, stocks can't be traded in fractions, at least not on any exchange I know of, but that fact is why stock splits for strong companies usually result in each share eventually regaining its pre-split price. Title: Re: Amateur hour Post by: sd on March 12, 2013, 06:51:17 PM The comparison of currency to stocks by sd isn't apt. The two are not compatible. Are you seriously saying that something about the nature of currencies means nobody would ever change shift the decimal point? Or are you just trolling me? 'Since 1960, governments of developing and transition economies have redenominated their currencies on approximately seventy occasions.' -- http://www.google.nl/url?sa=t&rct=j&q=remove%20zeros%20currency&source=web&cd=5&cad=rja&ved=0CEoQFjAE&url=http%3A%2F%2Fwww.unc.edu%2F~lmosley%2FAPSA%25202005.pdf&ei=zXc_UZLpO8iNOKvLgKgE&usg=AFQjCNEv2UciW5vxGEzB1j3kpjb-6Bh9Nw Title: Re: Amateur hour Post by: bzzard on March 12, 2013, 06:56:56 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. http://1.bp.blogspot.com/-lagoOeeappU/UQxsM3FKLoI/AAAAAAAAQp8/1EJFXqAsWbA/s1600/can_t-tell-if-trolling.jpgI have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 07:00:40 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Hey, I am only 140 IQ. You probably need somebody like 165 to solve the bitcoin problem. :-) As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Price stability is important to the economy for numerous reasons which can you read for yourself in the book "The Stability of Prices" by noted economist, Simon N. Patten. Title: Re: Amateur hour Post by: acoindr on March 12, 2013, 07:02:17 PM The comparison of currency to stocks by sd isn't apt. The two are not compatible. Are you seriously saying that something about the nature of currencies means nobody would ever change shift the decimal point? Or are you just trolling me? 'Since 1960, governments of developing and transition economies have redenominated their currencies on approximately seventy occasions.' -- http://www.google.nl/url?sa=t&rct=j&q=remove%20zeros%20currency&source=web&cd=5&cad=rja&ved=0CEoQFjAE&url=http%3A%2F%2Fwww.unc.edu%2F~lmosley%2FAPSA%25202005.pdf&ei=zXc_UZLpO8iNOKvLgKgE&usg=AFQjCNEv2UciW5vxGEzB1j3kpjb-6Bh9Nw No, I didn't say the nature of currencies means nobody would ever change or shift the decimal point. I said the comparison of currency to stocks isn't apt. Title: Re: Amateur hour Post by: MysteryMiner on March 12, 2013, 07:02:22 PM Quote As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. Yes it is amateur production. Bitcoin have no closed source, it does not ask for money and have no restrictive EULAs. It is not written by greedy turd.Quote Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). I see the results of proprietary closed source development every month's second Tuesday. Some vulnerabilities are not publicly known for years and remains unfixed for years afterwards. Most professionals working on closed source software make really bad design choices resulting in complete lack of security when bulletproof security is needed. Compared to small glitches in Bitcoin like recent one.Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. Quote It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. You don't understand how Bitcoin transaction fees works. You can create only so much transactions than you have bitcoins to spend. Invalid transactions will not be relayed further.Payment to development team have nothing to do with quality and possibilities of software. Best softwares out there are made by volunteers working on FOSS projects. And I know numerous occasions when developers were paid millions in cash and buggy .net code were deployed that did not even satisfy all requirements. Title: Re: Amateur hour Post by: acoindr on March 12, 2013, 07:10:35 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. I am just saying that it is inevitable that the design and development move to a new level, so we, as a community, need to adopt the mindset that evolution must occur and figure out how to do that. Please show one piece of code you've actually written -> The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. Here is a more readable piece of code in Java if you are not into machine language: /** Number of combinations * In the case that items > slots this value is items! / (slots! * (items - slots)!) . * Goes up to Choose( 66, 33 ) = 7219428434016265740, the maximum that fits in a long. * This is an optimal implementation that uses factorization to reach the largest exact values possible. * Try Choose( 60, 30 ) in a web-based calculator, for example, and you will not get an exact answer. * This is because naive implementations do not use factorization. * @param items The count of unique things to be combined. * @param slots The number of slots or opportunities into which to combine them. * @return number of possible unique combinations or 0 in the event of an error or invalid input or -1 in the event of an overflow */ public final static long combinationCount( int items, int slots ){ if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; if( slots == items ) return 1; int extra = items - slots; if( extra > slots ){ slots = extra; extra = items - slots; // extra always has as many or fewer items than slots } int[] aiNumeratorFactors = new int[100]; for( int xNumeratorFactorial = items; xNumeratorFactorial > slots; xNumeratorFactorial-- ){ int[] factors = factor( xNumeratorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2]; System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length ); aiNumeratorFactors = aiNumeratorFactors_new; } aiNumeratorFactors[0]++; aiNumeratorFactors[aiNumeratorFactors[0]] = factors[xFactor]; } } int[] aiDenominatorFactors = new int[100]; for( int xDenominatorFactorial = extra; xDenominatorFactorial > 1; xDenominatorFactorial-- ){ int[] factors = factor( xDenominatorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiDenominatorFactors[0] == aiDenominatorFactors.length - 1 ){ // need to expand list int[] aiDenominatorFactors_new = new int[aiDenominatorFactors.length * 2]; System.arraycopy( aiDenominatorFactors, 0, aiDenominatorFactors_new, 0, aiDenominatorFactors.length ); aiDenominatorFactors = aiDenominatorFactors_new; } aiDenominatorFactors[0]++; aiDenominatorFactors[aiDenominatorFactors[0]] = factors[xFactor]; } } int[] aiNumeratorFactors_fitted = new int[aiNumeratorFactors[0]]; System.arraycopy( aiNumeratorFactors, 1, aiNumeratorFactors_fitted, 0, aiNumeratorFactors[0] ); aiNumeratorFactors = aiNumeratorFactors_fitted; int[] aiDenominatorFactors_fitted = new int[aiDenominatorFactors[0]]; System.arraycopy( aiDenominatorFactors, 1, aiDenominatorFactors_fitted, 0, aiDenominatorFactors[0]); aiDenominatorFactors = aiDenominatorFactors_fitted; java.util.Arrays.sort( aiNumeratorFactors ); java.util.Arrays.sort( aiDenominatorFactors ); long nTotal = 1; int xNumerator = 0; int xDenominator = 0; while( true ){ if( xNumerator == aiNumeratorFactors.length ) return nTotal; if( xDenominator < aiDenominatorFactors.length && aiNumeratorFactors[xNumerator] == aiDenominatorFactors[xDenominator] ){ xDenominator++; } else { if( Long.MAX_VALUE / nTotal < aiNumeratorFactors[xNumerator] ) return -1; // overflow nTotal *= aiNumeratorFactors[xNumerator]; } xNumerator++; } } Presenting a code snippet means little. That's like someone who writes blueprints for a living showing a bathroom outline as proof he could engineer a skyscraper. A snippet means little without context and application. Title: Re: Amateur hour Post by: wtfvanity on March 12, 2013, 07:18:03 PM Hey, I am only 140 IQ. My penis is bigger than yours!!!!!!!!!!!! Title: Re: Amateur hour Post by: bitfair on March 12, 2013, 07:23:37 PM As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Your solution would incentivize a great flooding of traffic on the network -- more (spammy/useless) transactions would mean more money. Also it ignores the question of how coins come into existence in the first place. Please rethink your proposal. Title: Re: Amateur hour Post by: TalkingAntColony on March 12, 2013, 07:23:54 PM I wrote this bytecode while I was taking a dump just now. I believe it solves the max block size problem with a brilliant solution that requires an IQ of at least 140 to understand. If you deny the validity of my solution then you simply do not have the mental acuteness people like Blinken and myself are blessed with. I would develop it further but I have already done enough for you people.
Code: 41 20 70 75 72 65 6c 79 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 76 65 72 73 69 6f 6e 20 6f 66 20 65 6c 65 63 74 72 6f 6e 69 63 20 63 61 73 68 20 77 6f 75 6c 64 20 61 6c 6c 6f 77 20 6f 6e 6c 69 6e 65 0d 0a 70 61 79 6d 65 6e 74 73 20 74 6f 20 62 65 20 73 65 6e 74 20 64 69 72 65 63 74 6c 79 20 66 72 6f 6d 20 6f 6e 65 20 70 61 72 74 79 20 74 6f 20 61 6e 6f 74 68 65 72 20 77 69 74 68 6f 75 74 20 67 6f 69 6e 67 20 74 68 72 6f 75 67 68 20 61 0d 0a 66 69 6e 61 6e 63 69 61 6c 20 69 6e 73 74 69 74 75 74 69 6f 6e 2e 20 44 69 67 69 74 61 6c 20 73 69 67 6e 61 74 75 72 65 73 20 70 72 6f 76 69 64 65 20 70 61 72 74 20 6f 66 20 74 68 65 20 73 6f 6c 75 74 69 6f 6e 2c 20 62 75 74 20 74 68 65 20 6d 61 69 6e 0d 0a 62 65 6e 65 66 69 74 73 20 61 72 65 20 6c 6f 73 74 20 69 66 20 61 20 74 72 75 73 74 65 64 20 74 68 69 72 64 20 70 61 72 74 79 20 69 73 20 73 74 69 6c 6c 20 72 65 71 75 69 72 65 64 20 74 6f 20 70 72 65 76 65 6e 74 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 2e 0d 0a 57 65 20 70 72 6f 70 6f 73 65 20 61 20 73 6f 6c 75 74 69 6f 6e 20 74 6f 20 74 68 65 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 20 70 72 6f 62 6c 65 6d 20 75 73 69 6e 67 20 61 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 6e 65 74 77 6f 72 6b 2e 0d 0a 54 68 65 20 6e 65 74 77 6f 72 6b 20 74 69 6d 65 73 74 61 6d 70 73 20 74 72 61 6e 73 61 63 74 69 6f 6e 73 20 62 79 20 68 61 73 68 69 6e 67 20 74 68 65 6d 20 69 6e 74 6f 20 61 6e 20 6f 6e 67 6f 69 6e 67 20 63 68 61 69 6e 20 6f 66 0d 0a 68 61 73 68 2d 62 61 73 65 64 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2c 20 66 6f 72 6d 69 6e 67 20 61 20 72 65 63 6f 72 64 20 74 68 61 74 20 63 61 6e 6e 6f 74 20 62 65 20 63 68 61 6e 67 65 64 20 77 69 74 68 6f 75 74 20 72 65 64 6f 69 6e 67 0d 0a 74 68 65 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2e 20 54 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 6e 6f 74 20 6f 6e 6c 79 20 73 65 72 76 65 73 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 74 68 65 20 73 65 71 75 65 6e 63 65 20 6f 66 0d 0a 65 76 65 6e 74 73 20 77 69 74 6e 65 73 73 65 64 2c 20 62 75 74 20 70 72 6f 6f 66 20 74 68 61 74 20 69 74 20 63 61 6d 65 20 66 72 6f 6d 20 74 68 65 20 6c 61 72 67 65 73 74 20 70 6f 6f 6c 20 6f 66 20 43 50 55 20 70 6f 77 65 72 2e 20 41 73 0d 0a 6c 6f 6e 67 20 61 73 20 61 20 6d 61 6a 6f 72 69 74 79 20 6f 66 20 43 50 55 20 70 6f 77 65 72 20 69 73 20 63 6f 6e 74 72 6f 6c 6c 65 64 20 62 79 20 6e 6f 64 65 73 20 74 68 61 74 20 61 72 65 20 6e 6f 74 20 63 6f 6f 70 65 72 61 74 69 6e 67 20 74 6f 0d 0a 61 74 74 61 63 6b 20 74 68 65 20 6e 65 74 77 6f 72 6b 2c 20 74 68 65 79 27 6c 6c 20 67 65 6e 65 72 61 74 65 20 74 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 61 6e 64 20 6f 75 74 70 61 63 65 20 61 74 74 61 63 6b 65 72 73 2e 20 54 68 65 0d 0a 6e 65 74 77 6f 72 6b 20 69 74 73 65 6c 66 20 72 65 71 75 69 72 65 73 20 6d 69 6e 69 6d 61 6c 20 73 74 72 75 63 74 75 72 65 2e 20 4d 65 73 73 61 67 65 73 20 61 72 65 20 62 72 6f 61 64 63 61 73 74 20 6f 6e 20 61 20 62 65 73 74 20 65 66 66 6f 72 74 0d 0a 62 61 73 69 73 2c 20 61 6e 64 20 6e 6f 64 65 73 20 63 61 6e 20 6c 65 61 76 65 20 61 6e 64 20 72 65 6a 6f 69 6e 20 74 68 65 20 6e 65 74 77 6f 72 6b 20 61 74 20 77 69 6c 6c 2c 20 61 63 63 65 70 74 69 6e 67 20 74 68 65 20 6c 6f 6e 67 65 73 74 0d 0a 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 20 63 68 61 69 6e 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 77 68 61 74 20 68 61 70 70 65 6e 65 64 20 77 68 69 6c 65 20 74 68 65 79 20 77 65 72 65 20 67 6f 6e 65 Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 07:25:21 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. I am just saying that it is inevitable that the design and development move to a new level, so we, as a community, need to adopt the mindset that evolution must occur and figure out how to do that. Please show one piece of code you've actually written -> The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. Here is a more readable piece of code in Java if you are not into machine language: .... Presenting a code snippet means little. That's like someone who writes blueprints for a living showing a bathroom outline as proof he could engineer a skyscraper. A snippet means little without context and application. The guy just said he wanted to see ANY code I had written, so I showed 50 lines out of the nearly million lines I have written. As far as my "snippet" is concerned, if you can produce any better implementation of a combination counting algorithm, then we can talk about the shortcomings of my code. Title: Re: Amateur hour Post by: snaxion on March 12, 2013, 07:28:23 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. I am just saying that it is inevitable that the design and development move to a new level, so we, as a community, need to adopt the mindset that evolution must occur and figure out how to do that. Please show one piece of code you've actually written -> The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. Here is a more readable piece of code in Java if you are not into machine language: /** Number of combinations * In the case that items > slots this value is items! / (slots! * (items - slots)!) . * Goes up to Choose( 66, 33 ) = 7219428434016265740, the maximum that fits in a long. * This is an optimal implementation that uses factorization to reach the largest exact values possible. * Try Choose( 60, 30 ) in a web-based calculator, for example, and you will not get an exact answer. * This is because naive implementations do not use factorization. * @param items The count of unique things to be combined. * @param slots The number of slots or opportunities into which to combine them. * @return number of possible unique combinations or 0 in the event of an error or invalid input or -1 in the event of an overflow */ public final static long combinationCount( int items, int slots ){ if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; if( slots == items ) return 1; int extra = items - slots; if( extra > slots ){ slots = extra; extra = items - slots; // extra always has as many or fewer items than slots } int[] aiNumeratorFactors = new int[100]; for( int xNumeratorFactorial = items; xNumeratorFactorial > slots; xNumeratorFactorial-- ){ int[] factors = factor( xNumeratorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2]; System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length ); aiNumeratorFactors = aiNumeratorFactors_new; } aiNumeratorFactors[0]++; aiNumeratorFactors[aiNumeratorFactors[0]] = factors[xFactor]; } } int[] aiDenominatorFactors = new int[100]; for( int xDenominatorFactorial = extra; xDenominatorFactorial > 1; xDenominatorFactorial-- ){ int[] factors = factor( xDenominatorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiDenominatorFactors[0] == aiDenominatorFactors.length - 1 ){ // need to expand list int[] aiDenominatorFactors_new = new int[aiDenominatorFactors.length * 2]; System.arraycopy( aiDenominatorFactors, 0, aiDenominatorFactors_new, 0, aiDenominatorFactors.length ); aiDenominatorFactors = aiDenominatorFactors_new; } aiDenominatorFactors[0]++; aiDenominatorFactors[aiDenominatorFactors[0]] = factors[xFactor]; } } int[] aiNumeratorFactors_fitted = new int[aiNumeratorFactors[0]]; System.arraycopy( aiNumeratorFactors, 1, aiNumeratorFactors_fitted, 0, aiNumeratorFactors[0] ); aiNumeratorFactors = aiNumeratorFactors_fitted; int[] aiDenominatorFactors_fitted = new int[aiDenominatorFactors[0]]; System.arraycopy( aiDenominatorFactors, 1, aiDenominatorFactors_fitted, 0, aiDenominatorFactors[0]); aiDenominatorFactors = aiDenominatorFactors_fitted; java.util.Arrays.sort( aiNumeratorFactors ); java.util.Arrays.sort( aiDenominatorFactors ); long nTotal = 1; int xNumerator = 0; int xDenominator = 0; while( true ){ if( xNumerator == aiNumeratorFactors.length ) return nTotal; if( xDenominator < aiDenominatorFactors.length && aiNumeratorFactors[xNumerator] == aiDenominatorFactors[xDenominator] ){ xDenominator++; } else { if( Long.MAX_VALUE / nTotal < aiNumeratorFactors[xNumerator] ) return -1; // overflow nTotal *= aiNumeratorFactors[xNumerator]; } xNumerator++; } } Snippet war! Everyone post a snippet of what they have written. I will evaluate and declare a winner :) Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 07:28:59 PM I wrote this bytecode while I was taking a dump just now. I believe it solves the max block size problem with a brilliant solution that requires an IQ of at least 140 to understand. If you deny the validity of my solution then you simply do not have the mental acuteness people like Blinken and myself are blessed with. I would develop it further but I have already done enough for you people. Code: 41 20 70 75 72 65 6c 79 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 76 65 72 73 69 6f 6e 20 6f 66 20 65 6c 65 63 74 72 6f 6e 69 63 20 63 61 73 68 20 77 6f 75 6c 64 20 61 6c 6c 6f 77 20 6f 6e 6c 69 6e 65 0d 0a 70 61 79 6d 65 6e 74 73 20 74 6f 20 62 65 20 73 65 6e 74 20 64 69 72 65 63 74 6c 79 20 66 72 6f 6d 20 6f 6e 65 20 70 61 72 74 79 20 74 6f 20 61 6e 6f 74 68 65 72 20 77 69 74 68 6f 75 74 20 67 6f 69 6e 67 20 74 68 72 6f 75 67 68 20 61 0d 0a 66 69 6e 61 6e 63 69 61 6c 20 69 6e 73 74 69 74 75 74 69 6f 6e 2e 20 44 69 67 69 74 61 6c 20 73 69 67 6e 61 74 75 72 65 73 20 70 72 6f 76 69 64 65 20 70 61 72 74 20 6f 66 20 74 68 65 20 73 6f 6c 75 74 69 6f 6e 2c 20 62 75 74 20 74 68 65 20 6d 61 69 6e 0d 0a 62 65 6e 65 66 69 74 73 20 61 72 65 20 6c 6f 73 74 20 69 66 20 61 20 74 72 75 73 74 65 64 20 74 68 69 72 64 20 70 61 72 74 79 20 69 73 20 73 74 69 6c 6c 20 72 65 71 75 69 72 65 64 20 74 6f 20 70 72 65 76 65 6e 74 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 2e 0d 0a 57 65 20 70 72 6f 70 6f 73 65 20 61 20 73 6f 6c 75 74 69 6f 6e 20 74 6f 20 74 68 65 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 20 70 72 6f 62 6c 65 6d 20 75 73 69 6e 67 20 61 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 6e 65 74 77 6f 72 6b 2e 0d 0a 54 68 65 20 6e 65 74 77 6f 72 6b 20 74 69 6d 65 73 74 61 6d 70 73 20 74 72 61 6e 73 61 63 74 69 6f 6e 73 20 62 79 20 68 61 73 68 69 6e 67 20 74 68 65 6d 20 69 6e 74 6f 20 61 6e 20 6f 6e 67 6f 69 6e 67 20 63 68 61 69 6e 20 6f 66 0d 0a 68 61 73 68 2d 62 61 73 65 64 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2c 20 66 6f 72 6d 69 6e 67 20 61 20 72 65 63 6f 72 64 20 74 68 61 74 20 63 61 6e 6e 6f 74 20 62 65 20 63 68 61 6e 67 65 64 20 77 69 74 68 6f 75 74 20 72 65 64 6f 69 6e 67 0d 0a 74 68 65 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2e 20 54 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 6e 6f 74 20 6f 6e 6c 79 20 73 65 72 76 65 73 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 74 68 65 20 73 65 71 75 65 6e 63 65 20 6f 66 0d 0a 65 76 65 6e 74 73 20 77 69 74 6e 65 73 73 65 64 2c 20 62 75 74 20 70 72 6f 6f 66 20 74 68 61 74 20 69 74 20 63 61 6d 65 20 66 72 6f 6d 20 74 68 65 20 6c 61 72 67 65 73 74 20 70 6f 6f 6c 20 6f 66 20 43 50 55 20 70 6f 77 65 72 2e 20 41 73 0d 0a 6c 6f 6e 67 20 61 73 20 61 20 6d 61 6a 6f 72 69 74 79 20 6f 66 20 43 50 55 20 70 6f 77 65 72 20 69 73 20 63 6f 6e 74 72 6f 6c 6c 65 64 20 62 79 20 6e 6f 64 65 73 20 74 68 61 74 20 61 72 65 20 6e 6f 74 20 63 6f 6f 70 65 72 61 74 69 6e 67 20 74 6f 0d 0a 61 74 74 61 63 6b 20 74 68 65 20 6e 65 74 77 6f 72 6b 2c 20 74 68 65 79 27 6c 6c 20 67 65 6e 65 72 61 74 65 20 74 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 61 6e 64 20 6f 75 74 70 61 63 65 20 61 74 74 61 63 6b 65 72 73 2e 20 54 68 65 0d 0a 6e 65 74 77 6f 72 6b 20 69 74 73 65 6c 66 20 72 65 71 75 69 72 65 73 20 6d 69 6e 69 6d 61 6c 20 73 74 72 75 63 74 75 72 65 2e 20 4d 65 73 73 61 67 65 73 20 61 72 65 20 62 72 6f 61 64 63 61 73 74 20 6f 6e 20 61 20 62 65 73 74 20 65 66 66 6f 72 74 0d 0a 62 61 73 69 73 2c 20 61 6e 64 20 6e 6f 64 65 73 20 63 61 6e 20 6c 65 61 76 65 20 61 6e 64 20 72 65 6a 6f 69 6e 20 74 68 65 20 6e 65 74 77 6f 72 6b 20 61 74 20 77 69 6c 6c 2c 20 61 63 63 65 70 74 69 6e 67 20 74 68 65 20 6c 6f 6e 67 65 73 74 0d 0a 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 20 63 68 61 69 6e 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 77 68 61 74 20 68 61 70 70 65 6e 65 64 20 77 68 69 6c 65 20 74 68 65 79 20 77 65 72 65 20 67 6f 6e 65 Thats text, not code. Title: Re: Amateur hour Post by: MrCrabs on March 12, 2013, 07:31:04 PM I just fucking love this so much. I'm now late for work.
Title: Re: Amateur hour Post by: kjj on March 12, 2013, 07:32:39 PM The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): Welcome to ignore. Doesn't matter if this is truth or lie, either way you've conclusively demonstrated that you will never say anything worth hearing. Title: Re: Amateur hour Post by: acoindr on March 12, 2013, 07:33:50 PM The guy just said he wanted to see ANY code I had written, so I showed 50 lines out of the nearly million lines I have written. As far as my "snippet" is concerned, if you can produce any better implementation of a combination counting algorithm, then we can talk about the shortcomings of my code. Yeah, and if I walk up to the Sears Tower pull out a megaphone and start broadcasting "amateur hour", then some guy asks me to show a blueprint section of a bathroom as proof of my authority on the subject, and I present that ... ::) I didn't say the presented code snippet has shortcomings. Title: Re: Amateur hour Post by: Herodes on March 12, 2013, 07:35:58 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass.
Title: Re: Amateur hour Post by: scintill on March 12, 2013, 07:41:24 PM I wrote this bytecode while I was taking a dump just now. I believe it solves the max block size problem with a brilliant solution that requires an IQ of at least 140 to understand. If you deny the validity of my solution then you simply do not have the mental acuteness people like Blinken and myself are blessed with. I would develop it further but I have already done enough for you people. Code: 41 20 70 75 72 65 6c 79 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 76 65 72 73 69 6f 6e 20 6f 66 20 65 6c 65 63 74 72 6f 6e 69 63 20 63 61 73 68 20 77 6f 75 6c 64 20 61 6c 6c 6f 77 20 6f 6e 6c 69 6e 65 0d 0a 70 61 79 6d 65 6e 74 73 20 74 6f 20 62 65 20 73 65 6e 74 20 64 69 72 65 63 74 6c 79 20 66 72 6f 6d 20 6f 6e 65 20 70 61 72 74 79 20 74 6f 20 61 6e 6f 74 68 65 72 20 77 69 74 68 6f 75 74 20 67 6f 69 6e 67 20 74 68 72 6f 75 67 68 20 61 0d 0a 66 69 6e 61 6e 63 69 61 6c 20 69 6e 73 74 69 74 75 74 69 6f 6e 2e 20 44 69 67 69 74 61 6c 20 73 69 67 6e 61 74 75 72 65 73 20 70 72 6f 76 69 64 65 20 70 61 72 74 20 6f 66 20 74 68 65 20 73 6f 6c 75 74 69 6f 6e 2c 20 62 75 74 20 74 68 65 20 6d 61 69 6e 0d 0a 62 65 6e 65 66 69 74 73 20 61 72 65 20 6c 6f 73 74 20 69 66 20 61 20 74 72 75 73 74 65 64 20 74 68 69 72 64 20 70 61 72 74 79 20 69 73 20 73 74 69 6c 6c 20 72 65 71 75 69 72 65 64 20 74 6f 20 70 72 65 76 65 6e 74 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 2e 0d 0a 57 65 20 70 72 6f 70 6f 73 65 20 61 20 73 6f 6c 75 74 69 6f 6e 20 74 6f 20 74 68 65 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 20 70 72 6f 62 6c 65 6d 20 75 73 69 6e 67 20 61 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 6e 65 74 77 6f 72 6b 2e 0d 0a 54 68 65 20 6e 65 74 77 6f 72 6b 20 74 69 6d 65 73 74 61 6d 70 73 20 74 72 61 6e 73 61 63 74 69 6f 6e 73 20 62 79 20 68 61 73 68 69 6e 67 20 74 68 65 6d 20 69 6e 74 6f 20 61 6e 20 6f 6e 67 6f 69 6e 67 20 63 68 61 69 6e 20 6f 66 0d 0a 68 61 73 68 2d 62 61 73 65 64 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2c 20 66 6f 72 6d 69 6e 67 20 61 20 72 65 63 6f 72 64 20 74 68 61 74 20 63 61 6e 6e 6f 74 20 62 65 20 63 68 61 6e 67 65 64 20 77 69 74 68 6f 75 74 20 72 65 64 6f 69 6e 67 0d 0a 74 68 65 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2e 20 54 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 6e 6f 74 20 6f 6e 6c 79 20 73 65 72 76 65 73 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 74 68 65 20 73 65 71 75 65 6e 63 65 20 6f 66 0d 0a 65 76 65 6e 74 73 20 77 69 74 6e 65 73 73 65 64 2c 20 62 75 74 20 70 72 6f 6f 66 20 74 68 61 74 20 69 74 20 63 61 6d 65 20 66 72 6f 6d 20 74 68 65 20 6c 61 72 67 65 73 74 20 70 6f 6f 6c 20 6f 66 20 43 50 55 20 70 6f 77 65 72 2e 20 41 73 0d 0a 6c 6f 6e 67 20 61 73 20 61 20 6d 61 6a 6f 72 69 74 79 20 6f 66 20 43 50 55 20 70 6f 77 65 72 20 69 73 20 63 6f 6e 74 72 6f 6c 6c 65 64 20 62 79 20 6e 6f 64 65 73 20 74 68 61 74 20 61 72 65 20 6e 6f 74 20 63 6f 6f 70 65 72 61 74 69 6e 67 20 74 6f 0d 0a 61 74 74 61 63 6b 20 74 68 65 20 6e 65 74 77 6f 72 6b 2c 20 74 68 65 79 27 6c 6c 20 67 65 6e 65 72 61 74 65 20 74 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 61 6e 64 20 6f 75 74 70 61 63 65 20 61 74 74 61 63 6b 65 72 73 2e 20 54 68 65 0d 0a 6e 65 74 77 6f 72 6b 20 69 74 73 65 6c 66 20 72 65 71 75 69 72 65 73 20 6d 69 6e 69 6d 61 6c 20 73 74 72 75 63 74 75 72 65 2e 20 4d 65 73 73 61 67 65 73 20 61 72 65 20 62 72 6f 61 64 63 61 73 74 20 6f 6e 20 61 20 62 65 73 74 20 65 66 66 6f 72 74 0d 0a 62 61 73 69 73 2c 20 61 6e 64 20 6e 6f 64 65 73 20 63 61 6e 20 6c 65 61 76 65 20 61 6e 64 20 72 65 6a 6f 69 6e 20 74 68 65 20 6e 65 74 77 6f 72 6b 20 61 74 20 77 69 6c 6c 2c 20 61 63 63 65 70 74 69 6e 67 20 74 68 65 20 6c 6f 6e 67 65 73 74 0d 0a 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 20 63 68 61 69 6e 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 77 68 61 74 20 68 61 70 70 65 6e 65 64 20 77 68 69 6c 65 20 74 68 65 79 20 77 65 72 65 20 67 6f 6e 65 Thats text, not code. You're just not smart enough to recognize the machine for which it is also valid and useful bytecode. Need 165 IQ for that. Title: Re: Amateur hour Post by: Bitobsessed on March 12, 2013, 07:43:03 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass. Hey Blinkin! http://www.youtube.com/watch?v=wJcuYKyHEgs Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 07:45:54 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass. Hey, this isn't about me. I know you have some wierd fascination with me, but I didn't make the post to discuss myself. The point is that we had a block chain fork yesterday and it can be attributed to existing serious weaknesses in the QT client code, and a failure to properly test the 0.8 release. The question is how we can step up the professionalism of the development effort to improve the design, quality and testing of the code so it doesn't happen again. Title: Re: Amateur hour Post by: Herodes on March 12, 2013, 07:52:01 PM The point is that we had a block chain fork yesterday and it can be attributed to existing serious weaknesses in the QT client code, and a failure to properly test the 0.8 release. The question is how we can step up the professionalism of the development effort to improve the design, quality and testing of the code so it doesn't happen again. Then keep it professional. And contribute. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 07:58:07 PM Now, that I think about it, maybe the solution is to write an optional donation into the default client. If each transaction had a small donation to the development team, then they could potentially fund a larger operation, hire QC, etc.
Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 07:58:51 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Hey, I am only 140 IQ. You probably need somebody like 165 to solve the bitcoin problem. :-) As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Price stability is important to the economy for numerous reasons which can you read for yourself in the book "The Stability of Prices" by noted economist, Simon N. Patten. It is my belief that price stability will come with adoption. As more and more people begin using Bitcoin, the price will become more and more stable. I'd say with mass adoption, we'd see stability come close to that of Gold. I could be completely wrong - I am no expert - but this is what I currently believe we will see happen. Title: Re: Amateur hour Post by: Littleshop on March 12, 2013, 08:06:02 PM I wrote this bytecode while I was taking a dump just now. I believe it solves the max block size problem with a brilliant solution that requires an IQ of at least 140 to understand. If you deny the validity of my solution then you simply do not have the mental acuteness people like Blinken and myself are blessed with. I would develop it further but I have already done enough for you people. Code: 41 20 70 75 72 65 6c 79 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 76 65 72 73 69 6f 6e 20 6f 66 20 65 6c 65 63 74 72 6f 6e 69 63 20 63 61 73 68 20 77 6f 75 6c 64 20 61 6c 6c 6f 77 20 6f 6e 6c 69 6e 65 0d 0a 70 61 79 6d 65 6e 74 73 20 74 6f 20 62 65 20 73 65 6e 74 20 64 69 72 65 63 74 6c 79 20 66 72 6f 6d 20 6f 6e 65 20 70 61 72 74 79 20 74 6f 20 61 6e 6f 74 68 65 72 20 77 69 74 68 6f 75 74 20 67 6f 69 6e 67 20 74 68 72 6f 75 67 68 20 61 0d 0a 66 69 6e 61 6e 63 69 61 6c 20 69 6e 73 74 69 74 75 74 69 6f 6e 2e 20 44 69 67 69 74 61 6c 20 73 69 67 6e 61 74 75 72 65 73 20 70 72 6f 76 69 64 65 20 70 61 72 74 20 6f 66 20 74 68 65 20 73 6f 6c 75 74 69 6f 6e 2c 20 62 75 74 20 74 68 65 20 6d 61 69 6e 0d 0a 62 65 6e 65 66 69 74 73 20 61 72 65 20 6c 6f 73 74 20 69 66 20 61 20 74 72 75 73 74 65 64 20 74 68 69 72 64 20 70 61 72 74 79 20 69 73 20 73 74 69 6c 6c 20 72 65 71 75 69 72 65 64 20 74 6f 20 70 72 65 76 65 6e 74 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 2e 0d 0a 57 65 20 70 72 6f 70 6f 73 65 20 61 20 73 6f 6c 75 74 69 6f 6e 20 74 6f 20 74 68 65 20 64 6f 75 62 6c 65 2d 73 70 65 6e 64 69 6e 67 20 70 72 6f 62 6c 65 6d 20 75 73 69 6e 67 20 61 20 70 65 65 72 2d 74 6f 2d 70 65 65 72 20 6e 65 74 77 6f 72 6b 2e 0d 0a 54 68 65 20 6e 65 74 77 6f 72 6b 20 74 69 6d 65 73 74 61 6d 70 73 20 74 72 61 6e 73 61 63 74 69 6f 6e 73 20 62 79 20 68 61 73 68 69 6e 67 20 74 68 65 6d 20 69 6e 74 6f 20 61 6e 20 6f 6e 67 6f 69 6e 67 20 63 68 61 69 6e 20 6f 66 0d 0a 68 61 73 68 2d 62 61 73 65 64 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2c 20 66 6f 72 6d 69 6e 67 20 61 20 72 65 63 6f 72 64 20 74 68 61 74 20 63 61 6e 6e 6f 74 20 62 65 20 63 68 61 6e 67 65 64 20 77 69 74 68 6f 75 74 20 72 65 64 6f 69 6e 67 0d 0a 74 68 65 20 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 2e 20 54 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 6e 6f 74 20 6f 6e 6c 79 20 73 65 72 76 65 73 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 74 68 65 20 73 65 71 75 65 6e 63 65 20 6f 66 0d 0a 65 76 65 6e 74 73 20 77 69 74 6e 65 73 73 65 64 2c 20 62 75 74 20 70 72 6f 6f 66 20 74 68 61 74 20 69 74 20 63 61 6d 65 20 66 72 6f 6d 20 74 68 65 20 6c 61 72 67 65 73 74 20 70 6f 6f 6c 20 6f 66 20 43 50 55 20 70 6f 77 65 72 2e 20 41 73 0d 0a 6c 6f 6e 67 20 61 73 20 61 20 6d 61 6a 6f 72 69 74 79 20 6f 66 20 43 50 55 20 70 6f 77 65 72 20 69 73 20 63 6f 6e 74 72 6f 6c 6c 65 64 20 62 79 20 6e 6f 64 65 73 20 74 68 61 74 20 61 72 65 20 6e 6f 74 20 63 6f 6f 70 65 72 61 74 69 6e 67 20 74 6f 0d 0a 61 74 74 61 63 6b 20 74 68 65 20 6e 65 74 77 6f 72 6b 2c 20 74 68 65 79 27 6c 6c 20 67 65 6e 65 72 61 74 65 20 74 68 65 20 6c 6f 6e 67 65 73 74 20 63 68 61 69 6e 20 61 6e 64 20 6f 75 74 70 61 63 65 20 61 74 74 61 63 6b 65 72 73 2e 20 54 68 65 0d 0a 6e 65 74 77 6f 72 6b 20 69 74 73 65 6c 66 20 72 65 71 75 69 72 65 73 20 6d 69 6e 69 6d 61 6c 20 73 74 72 75 63 74 75 72 65 2e 20 4d 65 73 73 61 67 65 73 20 61 72 65 20 62 72 6f 61 64 63 61 73 74 20 6f 6e 20 61 20 62 65 73 74 20 65 66 66 6f 72 74 0d 0a 62 61 73 69 73 2c 20 61 6e 64 20 6e 6f 64 65 73 20 63 61 6e 20 6c 65 61 76 65 20 61 6e 64 20 72 65 6a 6f 69 6e 20 74 68 65 20 6e 65 74 77 6f 72 6b 20 61 74 20 77 69 6c 6c 2c 20 61 63 63 65 70 74 69 6e 67 20 74 68 65 20 6c 6f 6e 67 65 73 74 0d 0a 70 72 6f 6f 66 2d 6f 66 2d 77 6f 72 6b 20 63 68 61 69 6e 20 61 73 20 70 72 6f 6f 66 20 6f 66 20 77 68 61 74 20 68 61 70 70 65 6e 65 64 20 77 68 69 6c 65 20 74 68 65 79 20 77 65 72 65 20 67 6f 6e 65 Thats text, not code. Where do we begin? Most code is text. Being text therefore does not make it not code. Most people would not refer to the mentioned block as text anyhow, they would refer to it as hexidecimal code. Is it valid code that executes on something? That is above my IQ. :) Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 08:20:48 PM I wrote this bytecode while I was taking a dump just now. I believe it solves the max block size problem with a brilliant solution that requires an IQ of at least 140 to understand. If you deny the validity of my solution then you simply do not have the mental acuteness people like Blinken and myself are blessed with. I would develop it further but I have already done enough for you people. Code: 41 20 .... Thats text, not code. Where do we begin? Most code is text. Being text therefore does not make it not code. Most people would not refer to the mentioned block as text anyhow, they would refer to it as hexidecimal code. Is it valid code that executes on something? That is above my IQ. :) This is what the guys "code" translates to in ASCII: "A purely peer-to-peer version of electronic cash would allow online payments to be sent directly from one party to another without going through a financial institution. Digital signatures provide part of the solution, but the main benefits are lost if a trusted third party is still required to prevent double-spending. We propose a solution to the double-spending problem using a peer-to-peer network. The network timestamps transactions by hashing them into an ongoing chain of hash-based proof-of-work, forming a record that cannot be changed without redoing the proof-of-work. The longest chain not only serves as proof of the sequence of events witnessed, but proof that it came from the largest pool of CPU power. As long as a majority of CPU power is controlled by nodes that are not cooperating to attack the network, they'll generate the longest chain and outpace attackers. The network itself requires minimal structure. Messages are broadcast on a best effort basis, and nodes can leave and rejoin the network at will, accepting the longest proof-of-work chain as proof of what happened while they were gone" 0x41 is a capital "A", 0x20 is a space, etc. Title: Re: Amateur hour Post by: Severian on March 12, 2013, 08:30:39 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass. This is the second time I've had to post this in the past 12 hours. I think it should be the official motto of the forum: Walter: Am I wrong? The Dude: You're not wrong Walter. You're just an asshole. -The Big Lebowski Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 08:33:58 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Hey, I am only 140 IQ. You probably need somebody like 165 to solve the bitcoin problem. :-) As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Price stability is important to the economy for numerous reasons which can you read for yourself in the book "The Stability of Prices" by noted economist, Simon N. Patten. It is my belief that price stability will come with adoption. As more and more people begin using Bitcoin, the price will become more and more stable. I'd say with mass adoption, we'd see stability come close to that of Gold. I could be completely wrong - I am no expert - but this is what I currently believe we will see happen. Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. In practice what would happen is that as adoption increased the capitalization would increase, but the value of each bitcoin would remain stable. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. If we had increased the volume of the bitcoins outstanding by 6x then the price of each bitcoin would have remained relatively stable during the recent growth period. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 08:36:09 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass. This is the second time I've had to post this in the past 12 hours. I think it should be the official motto of the forum: Walter: Am I wrong? The Dude: You're not wrong Walter. You're just an asshole. -The Big Lebowski I hated that movie, except the part where he lit his groin on fire and crashed the car. Actually, when the cop threw the coffee cup at him, that was pretty funny too. Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 08:43:08 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Hey, I am only 140 IQ. You probably need somebody like 165 to solve the bitcoin problem. :-) As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Price stability is important to the economy for numerous reasons which can you read for yourself in the book "The Stability of Prices" by noted economist, Simon N. Patten. It is my belief that price stability will come with adoption. As more and more people begin using Bitcoin, the price will become more and more stable. I'd say with mass adoption, we'd see stability come close to that of Gold. I could be completely wrong - I am no expert - but this is what I currently believe we will see happen. Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. In practice what would happen is that as adoption increased the capitalization would increase, but the value of each bitcoin would remain stable. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. If we had increased the volume of the bitcoins outstanding by 6x then the price of each bitcoin would have remained relatively stable during the recent growth period. Ok, I understand that trading percentages of the currency would be the backend way of doing it, and the number of coins per percentage would change according to transaction volume. But I think you misunderstood the point I was attempting to make - apologies for not making it clear enough. How would you know what the true transaction volume is when people can create as many addresses as they like and send coins between them? Also, how would you know which address the Bitcoins were sent to vs which address was the change address? Also, how would this transaction volume determination be made and agreed upon in a decentralized manner? Title: Re: Amateur hour Post by: DataPlumber on March 12, 2013, 08:54:39 PM The point is that we had a block chain fork yesterday and it can be attributed to existing serious weaknesses in the QT client code, and a failure to properly test the 0.8 release. The question is how we can step up the professionalism of the development effort to improve the design, quality and testing of the code so it doesn't happen again. Actually, the bug was in the 0.7 client, and the problem wouldn't have been noticed if everyone had upgraded. Pool operators had to back the chain down to 0.7 compatibility because 0.7 wouldn't accept a valid block that 0.8 accepted, and reverting to broken behavior was, at the end of the day, less disruptive to the network.How mad can we be that a bug that had already been fixed, surfaced in an old client? Might make more sense to yell at the people running the old client. Or the wall, for all the good it'll do ya. The many threads of this discussion remind me of an old song lyric from The Police: Another suburban family morning Grandmother screaming at the wall We have to shout above the din of our Rice Krispies We can't hear anything at all Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 08:57:53 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Hey, I am only 140 IQ. You probably need somebody like 165 to solve the bitcoin problem. :-) As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Price stability is important to the economy for numerous reasons which can you read for yourself in the book "The Stability of Prices" by noted economist, Simon N. Patten. It is my belief that price stability will come with adoption. As more and more people begin using Bitcoin, the price will become more and more stable. I'd say with mass adoption, we'd see stability come close to that of Gold. I could be completely wrong - I am no expert - but this is what I currently believe we will see happen. Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. In practice what would happen is that as adoption increased the capitalization would increase, but the value of each bitcoin would remain stable. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. If we had increased the volume of the bitcoins outstanding by 6x then the price of each bitcoin would have remained relatively stable during the recent growth period. Ok, I understand that trading percentages of the currency would be the backend way of doing it, and the number of coins per percentage would change according to transaction volume. But I think you misunderstood the point I was attempting to make - apologies for not making it clear enough. How would you know what the true transaction volume is when people can create as many addresses as they like and send coins between them? Also, how would you know which address the Bitcoins were sent to vs which address was the change address? Also, how would this transaction volume determination be made and agreed upon in a decentralized manner? There is only a single multiplier which is known to all clients. Every time a transaction is confirmed it has a effect on the multiplier based on the previous multiplier, the size of the transaction, and the time of the last transaction. There is a field of mathematics called "queuing theory" which lets you determine transactional volumes and velocities and balance them. These equations can be used to ensure that the multiplier remains proportional to current global transactional volume. The adjustment is decentralized because it is part of the confirmation. When a transaction is confirmed the adjustment effect to the multiplier is determined at the same time and becomes part of the data of the transaction. Title: Re: Amateur hour Post by: wtfvanity on March 12, 2013, 09:15:19 PM Now, that I think about it, maybe the solution is to write an optional donation into the default client. If each transaction had a small donation to the development team, then they could potentially fund a larger operation, hire QC, etc. You first invented ripple 2.0 Now you've invented devcoin 2.0 Great ideas, people already thought of them and made them into alt chains. I'm doubting your forum post 140 IQ. But then again on the internet you can say whatever you want. My IQ is 999. Title: Re: Amateur hour Post by: glitch003 on March 12, 2013, 09:15:38 PM For such a genius, your code has some pretty glaring inefficiencies to it.
You could optimize this to a single if statement of the form if(items < 1 || slots < 1 || slots > items) return 0; if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; You allocate arrays at a size of 100 and implement your own inefficient array grow algorithm which is less efficient than using a datastructure that supports growing natively. int[] aiNumeratorFactors = new int[100]; And the array grow: if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2]; System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length ); aiNumeratorFactors = aiNumeratorFactors_new; } After inserting data into your arrays, you sort them. It would instead be more efficient to simply insert the data into the arrays in the right order. Essentially doing the sorting logic on insert instead of after the fact. java.util.Arrays.sort( aiNumeratorFactors ); java.util.Arrays.sort( aiDenominatorFactors ); Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 09:28:52 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Hey, I am only 140 IQ. You probably need somebody like 165 to solve the bitcoin problem. :-) As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Price stability is important to the economy for numerous reasons which can you read for yourself in the book "The Stability of Prices" by noted economist, Simon N. Patten. It is my belief that price stability will come with adoption. As more and more people begin using Bitcoin, the price will become more and more stable. I'd say with mass adoption, we'd see stability come close to that of Gold. I could be completely wrong - I am no expert - but this is what I currently believe we will see happen. Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. In practice what would happen is that as adoption increased the capitalization would increase, but the value of each bitcoin would remain stable. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. If we had increased the volume of the bitcoins outstanding by 6x then the price of each bitcoin would have remained relatively stable during the recent growth period. Ok, I understand that trading percentages of the currency would be the backend way of doing it, and the number of coins per percentage would change according to transaction volume. But I think you misunderstood the point I was attempting to make - apologies for not making it clear enough. How would you know what the true transaction volume is when people can create as many addresses as they like and send coins between them? Also, how would you know which address the Bitcoins were sent to vs which address was the change address? Also, how would this transaction volume determination be made and agreed upon in a decentralized manner? There is only a single multiplier which is known to all clients. Every time a transaction is confirmed it has a effect on the multiplier based on the previous multiplier, the size of the transaction, and the time of the last transaction. There is a field of mathematics called "queuing theory" which lets you determine transactional volumes and velocities and balance them. These equations can be used to ensure that the multiplier remains proportional to current global transactional volume. The adjustment is decentralized because it is part of the confirmation. When a transaction is confirmed the adjustment effect to the multiplier is determined at the same time and becomes part of the data of the transaction. The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who. Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon. You seem to want to simply ignore this glaring flaw in your argument for price stability. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 09:39:55 PM For such a genius, your code has some pretty glaring inefficiencies to it. You could optimize this to a single if statement of the form if(items < 1 || slots < 1 || slots > items) return 0; if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; This is done for clarity, not efficiency. Since the two tests are conceptually different, I separate them into different lines. The savings by combining the statements is not significant enough that it is preferable to the two-statement version. You allocate arrays at a size of 100 and implement your own inefficient array grow algorithm which is less efficient than using a datastructure that supports growing natively. int[] aiNumeratorFactors = new int[100]; And the array grow: if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2]; System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length ); aiNumeratorFactors = aiNumeratorFactors_new; } It is faster to do this. If you use collections class, like ArrayList, then each access must be through a method, as opposed to an array reference, which is much faster because it does not have call overhead. Also, if you read the source code to the add() method in ArrayList you can see that it does two internal calls making it much less efficient than my version. In fact, even the method ArrayList uses to expand its own array is slower than the direct memory allocation I do here, once again because of additional method calls in its ensureCapacity() method. After inserting data into your arrays, you sort them. It would instead be more efficient to simply insert the data into the arrays in the right order. Essentially doing the sorting logic on insert instead of after the fact. java.util.Arrays.sort( aiNumeratorFactors ); java.util.Arrays.sort( aiDenominatorFactors ); How do you know what the right order is? Each list of factors begins as a union of the factors of multiple numbers. For example, if you have 15! then you have factors for 15, factors for 14, factors for 13, 12, 11, 10, etc. So you have sets like {3, 5}{2, 7}{13}{2,2,3} etc. These sets must be made into a union: {3,5,2,7,13,2,23} and then sorted. When you are creating the union there is no way to know where each element will appear in the sorted array ahead of time. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 09:46:50 PM - Generate new bitcoins proportionally to the volume of transactions and distribute the new coins proportionately to existing holders of bitcoins; the whole mining thing is pointless and destabilizing. Please do explain what the point of distributing new coins proportionately to existing holders of coins? It's the equivalent of changing the decimal place and claiming you are 10 times richer because of it.For how smart you claim to be, you sure are disappointing me with your "solutions". P.S. I knew a guy on the internet who claimed he owned a lambo too. ;) Hey, I am only 140 IQ. You probably need somebody like 165 to solve the bitcoin problem. :-) As far as the mining is concerned, that was definitely the work of a 125. A much better idea is to increase the supply of coins proportionately to the transaction volume. This would result in price stability, an important characteristic of a currency which bitcoin currently lacks entirely. Note that the supply of bitcoins could also decrease if the transaction volume shrank. The way it should work is that the network continually adjusts the total supply of coins. Each holder does not hold coin totals, they hold a fraction of the total. So, your fraction never changes, but its valuation does depending on the volume of trades. Price stability is important to the economy for numerous reasons which can you read for yourself in the book "The Stability of Prices" by noted economist, Simon N. Patten. It is my belief that price stability will come with adoption. As more and more people begin using Bitcoin, the price will become more and more stable. I'd say with mass adoption, we'd see stability come close to that of Gold. I could be completely wrong - I am no expert - but this is what I currently believe we will see happen. Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. In practice what would happen is that as adoption increased the capitalization would increase, but the value of each bitcoin would remain stable. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. If we had increased the volume of the bitcoins outstanding by 6x then the price of each bitcoin would have remained relatively stable during the recent growth period. Ok, I understand that trading percentages of the currency would be the backend way of doing it, and the number of coins per percentage would change according to transaction volume. But I think you misunderstood the point I was attempting to make - apologies for not making it clear enough. How would you know what the true transaction volume is when people can create as many addresses as they like and send coins between them? Also, how would you know which address the Bitcoins were sent to vs which address was the change address? Also, how would this transaction volume determination be made and agreed upon in a decentralized manner? There is only a single multiplier which is known to all clients. Every time a transaction is confirmed it has a effect on the multiplier based on the previous multiplier, the size of the transaction, and the time of the last transaction. There is a field of mathematics called "queuing theory" which lets you determine transactional volumes and velocities and balance them. These equations can be used to ensure that the multiplier remains proportional to current global transactional volume. The adjustment is decentralized because it is part of the confirmation. When a transaction is confirmed the adjustment effect to the multiplier is determined at the same time and becomes part of the data of the transaction. The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who. Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon. You seem to want to simply ignore this glaring flaw in your argument for price stability. I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction. It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume. Title: Re: Amateur hour Post by: bbit on March 12, 2013, 09:49:55 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass. Sums up this whole thread in a nice neat package. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 09:56:14 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass. Sums up this whole thread in a nice neat package. At least my posts have some substance to them and feature complete sentences. Your 1500+ "heroic" posts consist almost entirely of one liners which are either insults, name calling or comments like "ROFL !!!!!!!". Title: Re: Amateur hour Post by: greyhawk on March 12, 2013, 10:00:53 PM Snippet war! Everyone post a snippet of what they have written. I will evaluate and declare a winner :) 10 PRINT "YOU GOT A BITCOIN!" 20 GOTO 10 Title: Re: Amateur hour Post by: acoindr on March 12, 2013, 10:03:14 PM Okay, you may know something about programming, but you appear to know nothing about monetary systems.
Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. Not true. To measure value you need to measure against something else. For obvious reasons bitcoins are commonly measured against dollars, but also other currencies and even precious metals like gold or silver. You cannot maintain a constant bitcoin value by simply modifying the number of bitcoins each account has. The number of bitcoins, as well as how fast they come into existence, is known. This is how a value for them was first established; a pizza was bought for about 10K bitcoins which established a dollar value for them. If the rate of bitcoins had been 10 times what it was then that pizza would likely to have been bought for 100K bitcoins, because that number relative to how many total that account holder had would have been commensurate. That's all the effect of increasing the number has; it means each individual bitcoin becomes worth less, not any constant value. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. No, it had nothing to do with transaction volume. It had to do with the fact the rate of bitcoins coming into existence was not enough to keep up with the demand of people wanting them. Did you say earlier you worked for the Fed? I would find that believable. Title: Re: Amateur hour Post by: bbit on March 12, 2013, 10:04:33 PM Blinken: No matter how skilled you are or pretend you are, it doesn't change the fact that you're a complete ass. Sums up this whole thread in a nice neat package. At least my posts have some substance to them and feature complete sentences. Your 1500+ "heroic" posts consist almost entirely of one liners which are either insults, name calling or comments like "ROFL !!!!!!!". I love it when I make my point. Your posts have ZERO! ZIP SUBSTANCE TO THEM! SO ROFL!!!!!!!!!!!!!!!!!!!!!! Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 10:08:13 PM Okay, you may know something about programming, but you appear to know nothing about monetary systems. Actually, I am published author on economics and I have had articles published by Mises.org. Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. Not true. To measure value you need to measure against something else. For obvious reasons bitcoins are commonly measured against dollars, but also other currencies and even precious metals like gold or silver. You cannot maintain a constant bitcoin value by simply modifying the number of bitcoins each account has. The number of bitcoins, as well as how fast they come into existence, is known. This is how a value for them is first established; a pizza was bought for about 10K bitcoins which established a dollar value for them. If the rate of bitcoins had been 10 times what it was then that pizza would likely to have been bought for 100K bitcoins, because that number relative to how many total that account holder had would have been commensurate. That's all the effect of increasing the number has; it means each individual bitcoin becomes worth less, not any constant value. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. No, it had nothing to do with transaction volume. It had to do with the fact the rate of bitcoins coming into existence was not enough to keep up with the demand of people wanting them. The proximate cause is, you are right, demand for the coins, but it is hard for the clients to know what the "demand" is. They can know the volume, however, so the volume can serve as a proxy for the current demand level. Did you say earlier you worked for the Fed? I would find that believable. That was a joke ;D. Title: Re: Amateur hour Post by: franky1 on March 12, 2013, 10:13:06 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. noting the highlighted text but instead you spend the exact same time reading threads unpaid but instead you spend the exact same time writing threads unpaid but instead you spend the exact same time whining about problems. how about solve it for free without breaking a sweat and then you will know with confidence your bitcoins funds are that much safer, that the holdings you have will repay themselves with even larger profits due to the stability you give bitcoins. which results in a pay day for the work you have done. which basically means you eventually get paid ! Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 10:14:07 PM Ok, that answers the last question. What about the two right before it that you conveniently avoided? The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who. Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon. You seem to want to simply ignore this glaring flaw in your argument for price stability. I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction. It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume. Here's an example of how to game your system. I plan to buy a car for 1,000 BTC. I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier. I now have 1,100 BTC. I send 1,000 BTC to the dealer, "saving" myself 100 BTC. Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly). Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe. I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years. I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time. This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time. Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something. I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin. Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling? And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral? Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer." And then they only have 80 coins, then 70, etc, because no one is buying anything? I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems. Title: Re: Amateur hour Post by: acoindr on March 12, 2013, 10:18:57 PM Okay, you may know something about programming, but you appear to know nothing about monetary systems. Actually, I am published author on economics and I have had articles published by Mises.org. Widespread adoption of bitcoins would certainly decrease price volatility, but nevertheless, price swings would still persist. In an economically proper crypto currency each client would maintain a constant, the value multiplier, just the way it now maintains the proof of work target. The value multiplier would determine how many bitcoins each address has by multiplying the wallet's fraction. Thus, the number of bitcoins you had would go up and down, but their value would remain relatively constant. Not true. To measure value you need to measure against something else. For obvious reasons bitcoins are commonly measured against dollars, but also other currencies and even precious metals like gold or silver. You cannot maintain a constant bitcoin value by simply modifying the number of bitcoins each account has. The number of bitcoins, as well as how fast they come into existence, is known. This is how a value for them is first established; a pizza was bought for about 10K bitcoins which established a dollar value for them. If the rate of bitcoins had been 10 times what it was then that pizza would likely to have been bought for 100K bitcoins, because that number relative to how many total that account holder had would have been commensurate. That's all the effect of increasing the number has; it means each individual bitcoin becomes worth less, not any constant value. For example, the capitalization of bitcoins has recently gone from $50 million to over $300 million, with a consequent increase in the value of each bitcoin. This is because the supply of bitcoins has not increased as fast as the volume of transactions has increased. No, it had nothing to do with transaction volume. It had to do with the fact the rate of bitcoins coming into existence was not enough to keep up with the demand of people wanting them. The proximate cause is, you are right, demand for the coins, but it is hard for the clients to know what the "demand" is. They can know the volume, however, so the volume can serve as a proxy for the current demand level. Did you say earlier you worked for the Fed? I would find that believable. That was a joke ;D. Again, you convince me you know nothing about monetary systems. If I'm not mistaken an author on Mises.org dismissed Bitcoin early on explaining it wasn't "backed by anything". And, no, transaction volume is not an accurate proxy for demand. In fact, anyone around Bitcoin any length of time would know a large skepticism people have about it is that not much of use can be bought with bitcoins. The transaction volume can be a fraction of what it is now while having the exact same demand that's keeping the price at about $40 on MtGox. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 10:44:01 PM Ok, that answers the last question. What about the two right before it that you conveniently avoided? The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who. Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon. You seem to want to simply ignore this glaring flaw in your argument for price stability. I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction. It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume. Here's an example of how to game your system. I plan to buy a car for 1,000 BTC. I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier. I now have 1,100 BTC. I send 1,000 BTC to the dealer, "saving" myself 100 BTC. Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly). Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe. I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years. I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time. This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time. Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something. I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin. Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling? And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral? Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer." And then they only have 80 coins, then 70, etc, because no one is buying anything? I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems. You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000. Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage. Title: Re: Amateur hour Post by: SgtSpike on March 12, 2013, 10:50:42 PM Ok, that answers the last question. What about the two right before it that you conveniently avoided? The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who. Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon. You seem to want to simply ignore this glaring flaw in your argument for price stability. I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction. It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume. Here's an example of how to game your system. I plan to buy a car for 1,000 BTC. I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier. I now have 1,100 BTC. I send 1,000 BTC to the dealer, "saving" myself 100 BTC. Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly). Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe. I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years. I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time. This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time. Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something. I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin. Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling? And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral? Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer." And then they only have 80 coins, then 70, etc, because no one is buying anything? I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems. You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000. Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage. You said that in practice, even if someone tried to game it, the daily changes might be 0.5% or less. I don't have enough of a predictive spirit to know whether that is true, which is why I think this would be an interesting experiment, to see what would really happen. If the multiplier doesn't change quickly enough, it won't be a true enough indicator of economic activity, and the price could vary greatly. If the multiplier changes too quickly, it would be too easy to game. There would certainly need to be some sort of balance between the two. If the vendor sets up a link to an exchange, it doesn't matter if they sell 100 items or 10,000, it's the same amount of work to set up said link. Not really a game-changer IMO. You still haven't really touched on how you would initially distribute a currency like this. If not through mining, then how? Title: Re: Amateur hour Post by: sd on March 12, 2013, 11:32:16 PM The comparison of currency to stocks by sd isn't apt. The two are not compatible. Are you seriously saying that something about the nature of currencies means nobody would ever change shift the decimal point? Or are you just trolling me? 'Since 1960, governments of developing and transition economies have redenominated their currencies on approximately seventy occasions.' -- http://www.google.nl/url?sa=t&rct=j&q=remove%20zeros%20currency&source=web&cd=5&cad=rja&ved=0CEoQFjAE&url=http%3A%2F%2Fwww.unc.edu%2F~lmosley%2FAPSA%25202005.pdf&ei=zXc_UZLpO8iNOKvLgKgE&usg=AFQjCNEv2UciW5vxGEzB1j3kpjb-6Bh9Nw No, I didn't say the nature of currencies means nobody would ever change or shift the decimal point. I said the comparison of currency to stocks isn't apt. In the context of moving the decimal point so the number of units of a thing a person has changes whilst the value they hold doesn't change you are saying that currencies and stocks behave differently. You are either mistaken or deliberately trolling. Title: Re: Amateur hour Post by: Blinken on March 12, 2013, 11:49:51 PM Ok, that answers the last question. What about the two right before it that you conveniently avoided? The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who. Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon. You seem to want to simply ignore this glaring flaw in your argument for price stability. I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction. It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume. Here's an example of how to game your system. I plan to buy a car for 1,000 BTC. I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier. I now have 1,100 BTC. I send 1,000 BTC to the dealer, "saving" myself 100 BTC. Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly). Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe. I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years. I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time. This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time. Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something. I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin. Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling? And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral? Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer." And then they only have 80 coins, then 70, etc, because no one is buying anything? I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems. You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000. Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage. You said that in practice, even if someone tried to game it, the daily changes might be 0.5% or less. I don't have enough of a predictive spirit to know whether that is true, which is why I think this would be an interesting experiment, to see what would really happen. If the multiplier doesn't change quickly enough, it won't be a true enough indicator of economic activity, and the price could vary greatly. If the multiplier changes too quickly, it would be too easy to game. There would certainly need to be some sort of balance between the two. If the vendor sets up a link to an exchange, it doesn't matter if they sell 100 items or 10,000, it's the same amount of work to set up said link. Not really a game-changer IMO. You still haven't really touched on how you would initially distribute a currency like this. If not through mining, then how? Well, in the beginning one person would have the entire pool which could be started at some convenient number of coins, say 1000. Then the Adam would pay some of them to Eve, say 250. So on and so forth. Now, in thinking about this, I see there is a mistake in my plan because if the multiplier were applied to all coins equally then Eve's pool (imagine she held onto it) would always be worth 25% of the total which would mean her wallet would grow in value. So, to make it work we need to only apply the multiplier to the coins being transacted. That way the value of Eve's coins stays the same if she holds onto them. Now, as you said above this seems to create a situation where you can increase the number of coins you have just by doing fake transactions, but this is not strictly true because remember that the multiplier can be positive or negative, so if you did your transaction during a downturn then the value of the coins might decrease slightly instead of increase. In any case, the hope would be that the change on any one transaction would be so small that it would not be worth creating fake transactions. In fact, using a transaction processing fee linked to the multiplier might prevent the benefit entirely. You can see one of the advantages of this system compared to bitcoins the way they are now: if Eve were to hold onto her btc which the capitalization grew, her 25% could turn into millions of dollars even though the original value of the transaction might be, say $20. But with a multiplier her coins will never be worth more than the original $20, because they are price stable. Title: Re: Amateur hour Post by: sd on March 12, 2013, 11:51:05 PM You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000. Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage. You are proposing an exchange rate mechanism that can only be based on inputs that can be gamed by false transactions. There is no way a cryptocurrency can tell the difference between a hedge fund buying ten thousand coins for a few million and me buying a single pizza from a guy on these forums for the same number of coins. It can't tell the entire transaction thoughput of visa worth billions from a bunch of kids gambling fractions of a cent on something like satoshidice. The Eurozone tried an exchange rate mechanism and it fell apart. And that's with knowledgeable people actively managing it. Title: Re: Amateur hour Post by: glitch003 on March 12, 2013, 11:58:06 PM For such a genius, your code has some pretty glaring inefficiencies to it. You could optimize this to a single if statement of the form if(items < 1 || slots < 1 || slots > items) return 0; if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; This is done for clarity, not efficiency. Since the two tests are conceptually different, I separate them into different lines. The savings by combining the statements is not significant enough that it is preferable to the two-statement version. You allocate arrays at a size of 100 and implement your own inefficient array grow algorithm which is less efficient than using a datastructure that supports growing natively. int[] aiNumeratorFactors = new int[100]; And the array grow: if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2]; System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length ); aiNumeratorFactors = aiNumeratorFactors_new; } It is faster to do this. If you use collections class, like ArrayList, then each access must be through a method, as opposed to an array reference, which is much faster because it does not have call overhead. Also, if you read the source code to the add() method in ArrayList you can see that it does two internal calls making it much less efficient than my version. In fact, even the method ArrayList uses to expand its own array is slower than the direct memory allocation I do here, once again because of additional method calls in its ensureCapacity() method. After inserting data into your arrays, you sort them. It would instead be more efficient to simply insert the data into the arrays in the right order. Essentially doing the sorting logic on insert instead of after the fact. java.util.Arrays.sort( aiNumeratorFactors ); java.util.Arrays.sort( aiDenominatorFactors ); How do you know what the right order is? Each list of factors begins as a union of the factors of multiple numbers. For example, if you have 15! then you have factors for 15, factors for 14, factors for 13, 12, 11, 10, etc. So you have sets like {3, 5}{2, 7}{13}{2,2,3} etc. These sets must be made into a union: {3,5,2,7,13,2,23} and then sorted. When you are creating the union there is no way to know where each element will appear in the sorted array ahead of time. Ok, post the code for your factor() method so that I can create a runnable demo. I will prove to you that I can make your code run faster. Title: Re: Amateur hour Post by: Rincewind on March 12, 2013, 11:59:09 PM Well, in the beginning one person would have the entire pool which could be started at some convenient number of coins, say 1000. Then the Adam would pay some of them to Eve, say 250. So on and so forth. Now, in thinking about this, I see there is a mistake in my plan because if the multiplier were applied to all coins equally then Eve's pool (imagine she held onto it) would always be worth 25% of the total which would mean her wallet would grow in value. This would make Adam the first man in history to keep 75% of his wealth away from his wife, and Eve the first woman in history to hold onto everything she did manage to get. Title: Re: Amateur hour Post by: Jason on March 13, 2013, 12:20:47 AM Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage. You bring up an interesting point, and the market has already come up with a solution for this with futures contracts. Instead of worrying about fluctuations in the value of bitcoin, it should be possible to place your bitcoins in escrow and make a deal with a broker to pay you some price for your bitcoins on some pre-agreed date. The value for the price should be at least equal to the value on the date you place the coins in escrow plus the money market interest rate you could get at a bank, potentially more. Now the person entering into a contract with you to buy the coins would be taking the risk if the value dropped, but I think there is plenty of demand to do this given the price history for the past several years. I'm not sure what effect this would have on the volatility of BTC at the exchanges (I suspect it would reduce it, but that's just a guess), but it would relieve merchants from having to worry about it and even allow them to make some small returns on their coins rather than paying a company like bitpay to convert their bitcoins into fiat currency on a daily (or more frequent) basis. Title: Re: Amateur hour Post by: snaxion on March 13, 2013, 12:33:59 AM Snippet war! Everyone post a snippet of what they have written. I will evaluate and declare a winner :) 10 PRINT "YOU GOT A BITCOIN!" 20 GOTO 10 On the leaderboard, we have Greyhawk. Title: Re: Amateur hour Post by: acoindr on March 13, 2013, 12:36:43 AM In the context of moving the decimal point so the number of units of a thing a person has changes whilst the value they hold doesn't change you are saying that currencies and stocks behave differently. You are either mistaken or deliberately trolling. sd, I believe what we have here is a hang up due to semantics. Let me quote your earlier text: I assume coins would be split so there are more in circulation. Yes it's exactly the same as moving the decimal place as far as value is concerned but it's still done by major companies all the time. See http://en.wikipedia.org/wiki/Stock_split Bold emphasis mine. By saying "exactly the same" as far as value is concerned and including that major companies do it all the time you suggest to the reader the consequences of moving the decimal for currency and stocks is the same. It is not. If you double the amount of currency in a system the per unit purchasing power of each holder is essentially reduced by half, but if amount of currency is doubled equally among holders net purchasing power stays the same; so all you've done is change the numbers, not value. I'm sure we agree. If you do a 2 for 1 stock split of a strong company then the total market value of the shares each holder has will be roughly the same since the market will value each share at half the pre-split price; again all you've done is change the numbers, not value. To this point I'm sure we are in agreement. However, as time goes on the holders of currency maintain the same net purchasing power, yet something different happens for owners of stock split shares; what usually happens is they find by doing absolutely nothing the value of each of their shares regains its pre-split price, making them twice as wealthy in shares as they were. This is due to the external affect of the market (notably, in an inflationary environment). So while stock split holders gain wealth, holders of a doubled currency do not. That is a key difference. There are also other factors which may severely affect market price such as company mismanagement etc. This is why I said the comparison of stocks to currency isn't apt. But this appears to be over semantics. If I reword your text as follows I believe we are in complete agreement: "Yes it's exactly the same as moving the decimal place as far as [initial] value is concerned but it's still done by major companies all the time." I hesitated to respond because I don't want to distract from the exchange between Blitzen and glitch003 so I'll repost the challenge of the latter: Ok, post the code for your factor() method so that I can create a runnable demo. I will prove to you that I can make your code run faster. Title: Re: Amateur hour Post by: thezerg on March 13, 2013, 01:58:32 AM OP
I am spending my time writing this not because I care anything about you but because I am offended at your graceless attitude towards our current devs who are working hard and doing a great job. And they should know that "we the people" are merely amused by people like you. On intelligence: You seem to have no contextual social awareness. So if you are smart it is only in narrow subdomains. And you seem to have actually taken an IQ test and are boasting your scores; 2 behaviors rarely exhibited by the group in which you claim membership. Domain knowledge (hamiltonian cycle etc) is no measure of intelligence as it is easily acquired but you seem unaware of this. You seem to be unaware of the massive gaps in your own proposals. You seem to have no real understanding of project longevity -- of how the evolution of the importance and criticality of a project creates problems. You are completely unwilling to contribute, but you seem to be unable to recognize that all projects and contributors juggle similar time constraints and so often the implemented solution is not optimal, simply expedient. And some shortcuts which are irrelevant when bitcoin is valued at .02 can become very important when it is 50 bucks. Your ideas... have already been considered and implemented in alt-coins as some have suggested. At least the ones that aren't totally stupid. ignore the hard problems... like how to spontaneously derive a trust metric using an algorithm that cannot be defeated even if examined. Also, adjusting the balance in everybody's account rather then the price of goods will fool absolutely nobody. And FYI, Bitcoin transfer or txn volume has no causal correlation to the price of a bitcoin in USD and only a large-time statistical correlation. And the price of BTC/USD vs BTC/silver vs BTC/web hosting are also not correlated so your single adjustment cannot hold more then one commodity steady. And it cannot even do that, because you are suggesting a maximum adjustment of what was it, .5% but we are seeing 25% volatility on a daily basis. You have made absolutely zero consideration of self-interested (i.e. antagonistic) agents. And miss completely obvious strategies like "calculate the same algorithm (its FOSS) just before the network does. If it is going to reduce your coins, sell to another currency/commodity, if it will increase them buy coins." You have obviously only coded in an environment where all the programs are essentially considered to be benignly working towards the same goal -- that is, a normal corporate project. When you were asked what you have done, a reasonable response would have been to point to a large OSS project that you have contributed to instead of your silly code snippets that have no applicability. In the end you present yourself as rude and stupid. Truly this is amateur hour -- you are presenting yourself as such. At the same time, thx for the laughs! Title: Re: Amateur hour Post by: SgtSpike on March 13, 2013, 04:54:44 AM Ok, that answers the last question. What about the two right before it that you conveniently avoided? The fact of the matter is, there is no way to determine true transaction volume without knowing who is sending to who. Therefore, this multiplier could be manipulated by anyone at any time for any reason, and would not be a reliably corollary for supply (and therefore price) to base itself upon. You seem to want to simply ignore this glaring flaw in your argument for price stability. I don't see why it is necessary to discriminate the change address. When a node confirms a transaction it has complete knowledge of the amounts of bitcoins involved in the transaction. It is true that clients can create spurious volume by ping ponging transactions back and forth, but I accept that as a possible source of error. In truth, we can imagine transactions of different importance. For example, two parties might be doing a business deal, but another transaction might be some guy juggling the coins in his accounts to tidy them up. The multiplication metric does not attempt to judge how "worthy" a transaction is, it just gauges the overall volume. Here's an example of how to game your system. I plan to buy a car for 1,000 BTC. I send that 1,000 BTC on a wild goose chase across many many different addresses, to generate false transaction volume and increase the multiplier. I now have 1,100 BTC. I send 1,000 BTC to the dealer, "saving" myself 100 BTC. Because the transaction volume was false, I am left (at some point in the future when the multiplier re-adjusts) with 91 BTC, and the dealer is left with 909 BTC (roughly). Regardless, I think your idea has merit as an experimental altcoin (it IS an interesting idea), just not exactly in the way you describe. I think you still need a reasonable way to distribute currency at the beginning that doesn't just involve a multiplier (the way you describe it, it would be a 100% premine with a single person holding on to all of the currency until they decided to distribute it how they choose), but creates some method of distributing new currency to new users across many years. I think that transaction volume should be indicated in "Altcoin days destroyed" instead of straight-up transaction volume over a given period of time. This would prevent, to an extent, gaming of the system, though holders of large numbers of Altcoin days could theoretically game the system one time. Maybe they put Altcoin days up for sale to be destroyed upon the date and time of the highest bidder's choosing or something. I also think that some people might be more concerned with coins being added or taken from their account on an unpredictable basis than they would be of the price fluctuations inherent in Bitcoin. Would people rather have a fluctuating number of coins in their wallet based on a best estimate of transaction volume, or would they rather have a fluctuating price based on free market buying and selling? And finally, couldn't a decrease in transaction volume, which would cause people to lose coins from their wallets, theoretically feedback to itself in a deflationary spiral? Something along the lines of, "Well, I only have 90 coins instead of 100 that I had yesterday, so I'm not going to buy that computer." And then they only have 80 coins, then 70, etc, because no one is buying anything? I mean, I'm not making the argument that Bitcoin doesn't also have the same potential problem, but this doesn't fix potential deflation-related problems. You are right, there is a psychological effect of, gee I had 100 btc yesterday, and today I only have 90, but the dollar value should remain roughly the same if the multiplier is doing its job. So if your 100 btc were worth $1000, then your 90 btc should be worth approximately the same, $1000. Note that in practice I would expect the multiplier to change slowly, so that daily changes in your btc count might only be 0.5% or less. Compare that to the situation today where the value of bitcoins is bouncing up and down 15% every day. Right now it is hard for vendors to use bitcoins because they have to have a live link to an exchange to keep their prices in sync, which is a big hassle and uncertainty. With a stability multiplier the vendor can set a single price in btc and the value will remain constant over a long period of time. No need to be constantly updating your prices. For a vendor with thousands of items in inventory that is a game changing advantage. You said that in practice, even if someone tried to game it, the daily changes might be 0.5% or less. I don't have enough of a predictive spirit to know whether that is true, which is why I think this would be an interesting experiment, to see what would really happen. If the multiplier doesn't change quickly enough, it won't be a true enough indicator of economic activity, and the price could vary greatly. If the multiplier changes too quickly, it would be too easy to game. There would certainly need to be some sort of balance between the two. If the vendor sets up a link to an exchange, it doesn't matter if they sell 100 items or 10,000, it's the same amount of work to set up said link. Not really a game-changer IMO. You still haven't really touched on how you would initially distribute a currency like this. If not through mining, then how? Well, in the beginning one person would have the entire pool which could be started at some convenient number of coins, say 1000. Then the Adam would pay some of them to Eve, say 250. So on and so forth. Now, in thinking about this, I see there is a mistake in my plan because if the multiplier were applied to all coins equally then Eve's pool (imagine she held onto it) would always be worth 25% of the total which would mean her wallet would grow in value. So, to make it work we need to only apply the multiplier to the coins being transacted. That way the value of Eve's coins stays the same if she holds onto them. Now, as you said above this seems to create a situation where you can increase the number of coins you have just by doing fake transactions, but this is not strictly true because remember that the multiplier can be positive or negative, so if you did your transaction during a downturn then the value of the coins might decrease slightly instead of increase. In any case, the hope would be that the change on any one transaction would be so small that it would not be worth creating fake transactions. In fact, using a transaction processing fee linked to the multiplier might prevent the benefit entirely. You can see one of the advantages of this system compared to bitcoins the way they are now: if Eve were to hold onto her btc which the capitalization grew, her 25% could turn into millions of dollars even though the original value of the transaction might be, say $20. But with a multiplier her coins will never be worth more than the original $20, because they are price stable. It seems like the longer this discussion continues, the more elementary the mistakes you are making in your logic. Title: Re: Amateur hour Post by: notme on March 13, 2013, 07:20:25 AM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks. WTF is a Mercier cycle? I know Hamiltonian cycles, but I've never heard of a Mercier cycle, and google (regular and scholar) doesn't have a clue either. Also, just because you make that much now doesn't mean you need that much. What you're trying to say is you are greedy and aren't willing to give up your cushy paycheck to push forward the state of the art of public technology. You'd rather suck the teat of the corporate monstrosity and empower the already powerful. I hope you have some survival skills for when the shit hits the fan. You may be okay if you are with a defense contractor, but your conscience won't be. Title: Re: Amateur hour Post by: Blowfeld on March 13, 2013, 08:18:44 AM The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. Here is a more readable piece of code in Java if you are not into machine language: /** Number of combinations * In the case that items > slots this value is items! / (slots! * (items - slots)!) . * Goes up to Choose( 66, 33 ) = 7219428434016265740, the maximum that fits in a long. * This is an optimal implementation that uses factorization to reach the largest exact values possible. * Try Choose( 60, 30 ) in a web-based calculator, for example, and you will not get an exact answer. * This is because naive implementations do not use factorization. * @param items The count of unique things to be combined. * @param slots The number of slots or opportunities into which to combine them. * @return number of possible unique combinations or 0 in the event of an error or invalid input or -1 in the event of an overflow */ public final static long combinationCount( int items, int slots ){ if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; if( slots == items ) return 1; int extra = items - slots; if( extra > slots ){ slots = extra; extra = items - slots; // extra always has as many or fewer items than slots } int[] aiNumeratorFactors = new int[100]; for( int xNumeratorFactorial = items; xNumeratorFactorial > slots; xNumeratorFactorial-- ){ int[] factors = factor( xNumeratorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiNumeratorFactors[0] == aiNumeratorFactors.length - 1 ){ // need to expand list int[] aiNumeratorFactors_new = new int[aiNumeratorFactors.length * 2]; System.arraycopy( aiNumeratorFactors, 0, aiNumeratorFactors_new, 0, aiNumeratorFactors.length ); aiNumeratorFactors = aiNumeratorFactors_new; } aiNumeratorFactors[0]++; aiNumeratorFactors[aiNumeratorFactors[0]] = factors[xFactor]; } } int[] aiDenominatorFactors = new int[100]; for( int xDenominatorFactorial = extra; xDenominatorFactorial > 1; xDenominatorFactorial-- ){ int[] factors = factor( xDenominatorFactorial ); if( factors == null ) return 0; // an error has occurred for( int xFactor = 1; xFactor <= factors[0]; xFactor++ ){ // add factors to numerator factors list if( aiDenominatorFactors[0] == aiDenominatorFactors.length - 1 ){ // need to expand list int[] aiDenominatorFactors_new = new int[aiDenominatorFactors.length * 2]; System.arraycopy( aiDenominatorFactors, 0, aiDenominatorFactors_new, 0, aiDenominatorFactors.length ); aiDenominatorFactors = aiDenominatorFactors_new; } aiDenominatorFactors[0]++; aiDenominatorFactors[aiDenominatorFactors[0]] = factors[xFactor]; } } int[] aiNumeratorFactors_fitted = new int[aiNumeratorFactors[0]]; System.arraycopy( aiNumeratorFactors, 1, aiNumeratorFactors_fitted, 0, aiNumeratorFactors[0] ); aiNumeratorFactors = aiNumeratorFactors_fitted; int[] aiDenominatorFactors_fitted = new int[aiDenominatorFactors[0]]; System.arraycopy( aiDenominatorFactors, 1, aiDenominatorFactors_fitted, 0, aiDenominatorFactors[0]); aiDenominatorFactors = aiDenominatorFactors_fitted; java.util.Arrays.sort( aiNumeratorFactors ); java.util.Arrays.sort( aiDenominatorFactors ); long nTotal = 1; int xNumerator = 0; int xDenominator = 0; while( true ){ if( xNumerator == aiNumeratorFactors.length ) return nTotal; if( xDenominator < aiDenominatorFactors.length && aiNumeratorFactors[xNumerator] == aiDenominatorFactors[xDenominator] ){ xDenominator++; } else { if( Long.MAX_VALUE / nTotal < aiNumeratorFactors[xNumerator] ) return -1; // overflow nTotal *= aiNumeratorFactors[xNumerator]; } xNumerator++; } } Snippet war! Everyone post a snippet of what they have written. I will evaluate and declare a winner :) While I agree with a few things blinken has to say, this is ridiculous. The following code should emulate blinken's bloatware. Complete with returning zero on invalid inputs and returning -1 on overflow. Code: #include <stdio.h> Here is the test harness: Code: void testcombin(long int n, long int m) And here is the test output: Code: 2 choose -1 = 0 Title: Re: Amateur hour Post by: markm on March 13, 2013, 08:46:14 AM So java is bloatware compared to C ? This is news?
Or could the java have been written as concisely without loss of efficiency? -MarkM- Title: Re: Amateur hour Post by: Monster Tent on March 13, 2013, 10:56:48 AM You dont think that as bitcoin scales the velocity of developer incentives would also scale ?
Or do you envisage a network the size of visa having only 1 dev still being paid from donations ? Title: Re: Amateur hour Post by: markm on March 13, 2013, 11:00:37 AM What, visa has two paid devs?!?! Cheaters! No wonder they're ahead of us. No fair!
-MarkM- Title: Re: Amateur hour Post by: Blinken on March 13, 2013, 02:28:18 PM For such a genius, your code has some pretty glaring inefficiencies to it. You could optimize this to a single if statement of the form if(items < 1 || slots < 1 || slots > items) return 0; if( items < 1 || slots < 1 ) return 0; if( slots > items ) return 0; Ok, post the code for your factor() method so that I can create a runnable demo. I will prove to you that I can make your code run faster. Here is the code for factor: /** Factor a number. * Example: 24 will return { 4, 2, 2, 2, 3 } where 4 is the number of factors and 2 x 2 x 2 x 3 = 24 * @param iNumberToFactor * @return The factors in a one-based array.
public final static int[] factor( int iNumberToFactor ){ if( iNumberToFactor < 1 ) return null; int iCapacity = 100; int[] factors = new int[iCapacity + 1]; int xPrime = -1; int iMaxFactor = (int)(java.lang.Math.sqrt( (double)iNumberToFactor )) + 1; int iRemainder = iNumberToFactor; while( true ){ xPrime++; if( primes[xPrime] > iMaxFactor || primes[xPrime] == iRemainder || iRemainder % primes[xPrime] == 0 ){ if( factors.length == iCapacity + 1 ){ // expand buffer iCapacity *= 2; int[] factors_new = new int[iCapacity + 1]; System.arraycopy( factors, 0, factors_new, 0, factors.length ); factors = factors_new; } factors[0]++; if( primes[xPrime] > iMaxFactor ){ factors[factors[0]] = iRemainder; } else { factors[factors[0]] = primes[xPrime]; } if( primes[xPrime] > iMaxFactor || primes[xPrime] == iRemainder ){ int[] factors_exact_size = new int[factors[0] + 1]; System.arraycopy( factors, 0, factors_exact_size, 0, factors[0] + 1); return factors_exact_size; } iRemainder /= primes[xPrime]; xPrime = -1; } } } Factor depends on a table of primes which is this: final public static int[] primes = { 2, 3, 5, 7, 11, 13, 17, 19, 23, 29, 31, 37, 41, 43, 47, 53, 59, 61, 67, 71, 73, 79, 83, 89, 97, 101, 103, 107, 109, 113, 127, 131, 137, 139, 149, 151, 157, 163, 167, 173, 179, 181, 191, 193, 197, 199, 211, 223, 227, 229, 233, 239, 241, 251, 257, 263, 269, 271, 277, 281, 283, 293, 307, 311, 313, 317, 331, 337, 347, 349, 353, 359, 367, 373, 379, 383, 389, 397, 401, 409, 419, 421, 431, 433, 439, 443, 449, 457, 461, 463, 467, 479, 487, 491, 499, 503, 509, 521, 523, 541, ..... 49667, 49669, 49681, 49697, 49711, 49727, 49739, 49741, 49747, 49757, 49783, 49787, 49789, 49801, 49807, 49811, 49823, 49831, 49843, 49853, 49871, 49877, 49891, 49919, 49921, 49927, 49937, 49939, 49943, 49957, 49991, 49993, 49999 }; } I have not included the entire table because it is large, but you can easily fill in the missing values yourself from online sources. Title: Re: Amateur hour Post by: Blinken on March 13, 2013, 02:37:32 PM The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. While I agree with a few things blinken has to say, this is ridiculous. The following code should emulate blinken's bloatware. Complete with returning zero on invalid inputs and returning -1 on overflow. Code: #include <stdio.h> Here is the test harness: Code: void testcombin(long int n, long int m) And here is the test output: Code: 2 choose -1 = 0 Title: Re: Amateur hour Post by: DobZombie on March 13, 2013, 02:39:16 PM As a professional software developer... Wait, I think I've seen this advert before! [quote Television] As a busy mum... [/quote] That's it!! Title: Re: Amateur hour Post by: Blinken on March 13, 2013, 02:41:07 PM Right now, I not planning on re-arranging my life to take an unpaid position as a bitcoin developer. You don't need to be unpaid. If your abilities are as good as you claim you should be able to find plenty of people willing to donate.For example, just look at how quickly the OSX packaging for Armory bounty was raised. That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks. WTF is a Mercier cycle? I know Hamiltonian cycles, but I've never heard of a Mercier cycle, and google (regular and scholar) doesn't have a clue either. Hamiltonian cycle: https://encrypted-tbn0.gstatic.com/images?q=tbn:ANd9GcT4kQb_W1ZTcvHQMrZdE7ibiSYW85gTQZ_AdynTjPPINHWZlWsK Mercier cycle: http://www.sodapopgirl.net/wp-content/uploads/mercier1-480x428.jpg Title: Re: Amateur hour Post by: finway on March 13, 2013, 02:42:52 PM CoinHunter ?
Title: Re: Amateur hour Post by: TalkingAntColony on March 13, 2013, 02:46:10 PM Can we rename this thread to "Guy tries to prove his superiority on the internet and casually propose pet theories while trolls troll and others waste time responding"
Title: Re: Amateur hour Post by: Anduck on March 13, 2013, 03:04:16 PM If you have the abilities and interest in btc, Bitcoin indeed would need everything rewritten and very well documented. Or something.
Title: Re: Amateur hour Post by: wtfvanity on March 13, 2013, 04:11:24 PM Can we rename this thread to "Guy tries to prove his superiority on the internet and casually propose pet theories while trolls troll and others waste time responding" Sure Title: Re: Amateur hour Post by: Blowfeld on March 13, 2013, 06:07:02 PM That is very good. I did not think of using Euclid's algorithm. I should send you a bitcoin for that one. Thank you. The address is in my signature.Title: Re: Amateur hour Post by: WishIStartedSooner on March 13, 2013, 06:29:13 PM That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. You can blow 8 grand in two weeks? that's sickening. (yea, i know there's plenty of people who are even more spoiled. this is still sickening) Maybe you do "contribute more to society" for what you earn, but the fact that you take THAT amount of money for granted kinda makes me wanna punch you. 8 grand in two weeks is way, way more than plenty enough to live happily on. Title: Re: Amateur hour Post by: AsymmetricInformation on March 13, 2013, 06:44:35 PM That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. You can blow 8 grand in two weeks? http://25.media.tumblr.com/tumblr_m5kmdp6l1k1r5rawlo1_500.gif Title: Re: Amateur hour Post by: WishIStartedSooner on March 13, 2013, 07:27:42 PM That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. You can blow 8 grand in two weeks? http://25.media.tumblr.com/tumblr_m5kmdp6l1k1r5rawlo1_500.gif valid point. I probably just got trolled. But a fine job it was as I totally got all emotional about it. Intense anger is a good feeling to have once in a while though. It kind of felt a little bit like an adrenaline rush. As I read deeper into the thread I am pleased to see others point out this ridiculousness. Title: Re: Amateur hour Post by: Blinken on March 13, 2013, 07:36:32 PM That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. You can blow 8 grand in two weeks? http://25.media.tumblr.com/tumblr_m5kmdp6l1k1r5rawlo1_500.gif valid point. I probably just got trolled. But a fine job it was as I totally got all emotional about it. Intense anger is a good feeling to have once in a while though. It kind of felt a little bit like an adrenaline rush. As I read deeper into the thread I am pleased to see others point out this ridiculousness. I am all emotional, too. You make me weepy, Asymmetric. Title: Re: Amateur hour Post by: Blowfeld on March 13, 2013, 08:06:01 PM That's a nice thought, but I checked out the donations to the Armory address and it came to about 200 bitcoins. That would last me about 2 weeks. You can blow 8 grand in two weeks? that's sickening. (yea, i know there's plenty of people who are even more spoiled. this is still sickening) Maybe you do "contribute more to society" for what you earn, but the fact that you take THAT amount of money for granted kinda makes me wanna punch you. 8 grand in two weeks is way, way more than plenty enough to live happily on. $4000 per week for a good contract programmer is not at all unusual, assuming they are paying their own taxes, health insurance, liability insurance, IRA/401K contributions, etc., etc., etc. Sometimes the contracting organization stiffs you. Sometimes you underbid and have to work 3x as long to get the job done. Sometimes you have to work crazy long hours. Rarely are you under contract 52 weeks a year. And never do you have any job security. OTOH, you can probably hire a code monkey for about $1k per week. You get what you pay for. Title: Re: Amateur hour Post by: Killdozer on March 13, 2013, 10:06:20 PM Hey man the code looks nice, but you claim to make that much money and be that good and still you think your time is worth spent on this forum trying to prove yourself?
Title: Re: Amateur hour Post by: WishIStartedSooner on March 13, 2013, 10:22:56 PM just something about the way he said that pissed me off.
like he was implying that to take a pay cut down to 16000 a month would descend him into ABJECT POVERTY, and hes too good for that... some people live off that in a YEAR. other people live off like 32,000 a year and WORK THEIR ASS OFF EVERYDAY at important work that needs to get done as well (not to imply that anyone in this thread doesnt). blinken, if you want to contribute to bitcoin, come up with a better excuse than the pay cut for not doing so. also, regarding the SF policemen, thats also kind of sickening. but i hear the cost of living in newyork and calif isvery very high, so that amount per year might seem like alot more from where im sitting than it might be. i acknowledge that. but its all good, im pretty close to achieving a halfway decent lifestyle myself after years of hard work (not near the excesses described here but im happy with the progress), so im not upset anymore. but i just wanted to remind you that you are very fortunate indeed. be thankful. Title: Re: Amateur hour Post by: markm on March 13, 2013, 11:38:25 PM Aha, I figured it out! He's sick of that line of work and looking for a job as a PR person, like Josh and MPOE-PR! ;):D
-MarkM- Title: Re: Amateur hour Post by: DataPlumber on March 14, 2013, 03:49:59 AM Hey man the code looks nice, but you claim to make that much money and be that good and still you think your time is worth spent on this forum trying to prove yourself? +1Title: Re: Amateur hour Post by: Blinken on March 14, 2013, 02:08:58 PM That is very good. I did not think of using Euclid's algorithm. I should send you a bitcoin for that one. Thank you. The address is in my signature.Title: Re: Amateur hour Post by: allthingsluxury on March 14, 2013, 04:52:07 PM Not again :O
Title: Re: Amateur hour Post by: herzmeister on March 14, 2013, 05:12:22 PM yup, I guess the Bitcoin source clearly isn't enterprisey (http://www.urbandictionary.com/define.php?term=enterprisey) enough. Here's a good shining example of a critical real world application showing how to do it right:
* http://code.google.com/p/fizzbuzz/ * http://code.google.com/p/fizzbuzz/source/browse/#svn%2Ftrunk%2Ftrunk Title: Re: Amateur hour Post by: freequant on March 14, 2013, 07:14:50 PM The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. Congrats, this is a really inefficient piece of code: - you are loading the data from memory byte by byte... Ever heard of 64-bit registers and corresponding mem access instructions, and subsequent sequences of mask and shifts without loop? - you do the operations byte by byte. I mean, of course because you load the data byte by byte... But see, if you had loaded 8 bytes at once in a 64-bit register, you could have substracted '0x30 30 30 30 30 30 30 30' all at once, in one single instruction. Then you wouldn't need to test anymore the lower boundary, because the operation will project the valid range [0x30:0x39] to [0x00:0x09] that you can use directly, and lower invalid range [0x00:0x2F] to [0xD0:0xFF] which is greater than 0x09 and will therefore fail the upper boundary test. You'll get a carry on previous digit when that happens so you may need to backtrack a little bit, in particular if previous digits were 0, but that will happen only once for the last dword of the chain because we are at the exit condition anyway. And that is if you aren't using SIMD instructions... - and even assuming you want to do it sequentially, you are testing each digit against its boundaries with 2x CMP (against 0x30 and 0x39), and then after you found the digit is valid, you do sub 0x30... Wasteful. If you had done the sub rightaway at the beginning, you could test the sign flag, and you didn't need to do a CMP 0x30. - you increment the source index ESI at each loop... but you don't use it to address your mem access, instead of which you also increment EDX that you dereference directly. - you.. well... enough.. This is probably one of the most inefficient implementation of atoi I have seen ever. The fact you bothered writing it in machine code directly is both self-explanatory for poor performance, and baffling because: 1) it totally underperforms what the most crapy compiler on earth would have achieved 2) you would have got exactly the same results by writing it in ASM directly and assembling it (which I suspect you did anyway) 3) you wasted a stupendous amount of time doing it 4) this is totally vain to say the least Not sure what you are trying to prove, and to whom you are trying to prove it. But if it's a question of ego, I definitely recommand that you undertake the creation of a new alt-coin that will demonstrate your ideas. That way you can prove to yourself and to everyone here that having a high IQ yields a bit more than a nice mensa certificate to put on your wall and added bragging power in troll threads. Code: ┌─[x]─────────────────────────── /tmp/blop ────────────────────────────────5───┐ Title: Re: Amateur hour Post by: SgtSpike on March 14, 2013, 07:20:58 PM ^^ I thoroughly enjoyed that. :D
Title: Re: Amateur hour Post by: paraipan on March 14, 2013, 07:36:29 PM Title: Re: Amateur hour Post by: Blowfeld on March 14, 2013, 09:18:55 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. @Blinken: ty for the BC. @all: Do people actually disagree with the 4 paragraphs written above, or do you just disagree with the person who made the comments? It's sad that the vast majority of posts on these forums are attacking the person, rather than critiquing the message. And it's not just this message, its virtually every posting to every topic on this board. And I suspect that is part of the reason there is an insufficiency of developers. [Name any successful open source project where those who offer constructive criticism are attacked like this.] While I may be guilty, too, in my handful of posts, I have tried to object to the action or the process or the result, rather than the person. Earlier in this thread, I referred to "Blinken's Bloatware". Fact is, given the algorithm he was using, it was good. But compared to a different algorithm, it was bloatware. Blinken manned up and acknowledged with cold hard bitcash. I happen to think SD is spamming the blockchain, and I happen to think their traffic should be blocked. But I also know anybody else can spam the blockchain in a similar way. [Blinken: just clone SD *and* provide your customers with a highly customizable bot to place their bets. Several forms of Martingale. Charts and stats on recent numbers chosen by your Oracle. And a single "spin" button or "auto" button to start things rolling. Etc. When you are rich, send me some more BC. ;D ] Blocking SD is just a way of buying some time, while the development team works out a solution. I know it isn't a permanent fix. My longer-term idea is to have the client analyze the blockchain in a crude attempt to determine common ownership. [It is very hard to maintain anonymity for a regular user. It's even harder for a commercial enterprise who must advertise their address(es) to receive business.] The first few transactions between any pair of users is free or cheap. But if A and B keep exchanging coins, that becomes spam, and the price should go up. [More precisely, if there's a cycle that rotates coins, that's spam.] This lets Sister Theresa's charities receive their tiny donations. This lets commercial clearinghouses exchange BC with their 10000 customers per day. But mainly, this makes SD hire a programmer to rework their model, and the rework might as well be something that's easy on the blockchain. I'm not going to suggest this, because I know what kind of attacks will come my way. If Bitcoin is going to be a currency of the future, many problems need to be addressed. Blinken's ideas are generally sound. If Goldman Sachs, D B Shaw, and others are paying their "quants" upwards of $10M per year, how much should the Bitcoin community be paying its best thinkers and developers, eh? It is very difficult to understand the nuances of the BC protocol, because it is poorly documented. "The code is the standard." Despite this, the Bitcoin community has been given at least two scholarly papers (one from a University and one from Microsoft). High-quality research. Free. But little action. When someone does make a reasonable suggestion, the response is often "That's coin protocol XXX. That's not Bitcoin. Go invent your own protocol." Those kinds of responses are completely unproductive. About 2.5 days ago, the blockchain forked. A few centralized miners were able to put Bitcoin back on track. But they left an orphan chain *25 blocks long*. Let me repeat: "A handful of miners orphaned a chain of 25 blocks." If a few miners can do this, what do you think the NSA could do? Or any other major corporation or government? If Bitcoin becomes a real global currency, and if some nefarious outfit starts to manipulate the blockchain, I can easily see the US Government joining in the mining "to stabilize" the currency. But, I can just as easily see the US Government determining Bitcoin addresses used by the Taliban or WikiLeaks, and saying "no spend transactions from those addresses". If someone mines a block that includes such a transaction, Uncle Sam mines two blocks that make the first one an orphan. If anybody doesn't think this could happen you have *no idea* of the NSA's capabilities. They could do this tomorrow. I don't know how to solve this problem. It may be the fatal flaw in Bitcoin. The heroic action 2.5 days ago was not in the best short-term interests of the miners who switched, but I reckon they were both benevolent and they thought it was in their best long-term interests. Next time, they might not be so heroic. Or next time, the centralized mining pool operators might decide their self-interest overrides the interest of the community. Centralized mining may be a fatal flaw in Bitcoin. Title: Re: Amateur hour Post by: Blinken on March 14, 2013, 10:52:34 PM The Fed doesn't pay me enough to put up with this, but ok... here is byte code for x86 that translates either a decimal or hexadecimal string to a binary value (yes, I actually wrote the byte code, and yes, I can read and write x86 machine encodings in hex): 31C053515657555231F68A0280F8307C1080F8397F0B2C3083C6015083C201EBE9C7C50A000000C 7C10100000031DB89F783FE00741058F7E101C383EE0189C8F7E589C1EBEB89D85A01FA5D5F5E59 5BC331C053515657555231F68A0280F8307C0980F8397F042C30EB0C80F8417C1080F8467F0B2C4 B83C6015083C201EBDBC7C510000000EB9F The decimal reader is at offset 0 and expects a non-digit terminated string at an address in the EDX register. The hex reader is at offset 136 and expects the same input. Both routines return the answer in EAX register. Total bytes: 136. Congrats, this is a really inefficient piece of code: .... [see post for details] * This is for a generic 32-bit machine, so 64-bit instructions do not apply. Also, I can only hand write a small set of core instructions. I haven't learned the encodings for system or extended instructions. * I used no assembler to write the machine code. I wrote the encodings directly. * EDX has to be updated at the end because it maintains a pointer to the text stream; if the string bytes are successfully converted to a value, then EDX must be incremented * The goal in this code snippet was to minimize code size and use a simple, easy-to-understand algorithm * It is true I could have combined the subtraction and comparison to save an instruction. * To your allegation that this code "underperforms" compiler-generated/library atoi(), I would answer that just the source code alone of a typical library atoi is about 300 lines of C code, equating to about 1000+ bytes (probably more) of machine code. My code has 136 bytes. As far as speed is concerned, I would expect a runtime library's type checking and procedure call setup/teardown alone to have a longer runtime than my code, never mind the actual conversion. * I am not trying to "prove" anything. I posted the code in answer to a previous post that asked me to post *ANY* code that I had written, so I answered that by posting both machine code and source code that I had written. Title: Re: Amateur hour Post by: GernMiester on March 14, 2013, 11:08:37 PM As a professional software developer this may be an opportune time to point out that the bitcoin code is an amateur production. I have the greatest respect for Gavin and others that have donated untold hours to make bitcoin into a reality and I know from experience how tough self-funded development is. Nevertheless, make no mistakes, the current incarnation of Bitcoin has a lot of ill-conceived design points and implementation weaknesses (as we have seen from the events of the last 24 hours). Aside from the blunder that just resulted in a blockchain fork, there is a much larger, related issue looming on the horizon, which is the inability of the design to process large numbers of transactions. It is ludicrous we have people whining about "Satoshi Dice" creating numerous transactions. I could sit down and write a software component that could easily generate billions of transactions without breaking a sweat once it is deployed to a few thousand boxes, if I so chose, and yet you are concerned about Satoishi Dice generating a few million transactions. The problem of high-volume transaction handling needs to be answered at a new level which is, unfortunately, way above the paygrade of the current development team. I thought it worked like this. Make it better, provide the developers a look, if it is truly revolutionary it will be added or it will be implemented to fix a bug(s). Not - Hey amateurs, neat thing you have hear, I respect you and all but your wrong. Bye...... Title: Re: Amateur hour Post by: markm on March 14, 2013, 11:29:06 PM @all: Do people actually disagree with the 4 paragraphs written above, or do you just disagree with the person who made the comments? To me, the observations /assertions themselves were so banal, so already well know, so that is what everyone has been saying all along, that it did not even occur to me that they required any response from me. -MarkM- Title: Re: Amateur hour Post by: freequant on March 15, 2013, 03:28:14 AM @all: Do people actually disagree with the 4 paragraphs written above, or do you just disagree with the person who made the comments? It's sad that the vast majority of posts on these forums are attacking the person, rather than critiquing the message. And it's not just this message, its virtually every posting to every topic on this board. And I suspect that is part of the reason there is an insufficiency of developers. [Name any successful open source project where those who offer constructive criticism are attacked like this.] IMO, most of the drama in this thread stems from OP's failure to deliver his initial message objectively and professionally without letting subjective views and value judgements creep in, and subsequent failure to support his views without acting defensive and taking things personally. Running a large scale software project isn't only a matter of technical skills, and also requires great communication skills and maturity. Beside, reading OP's initial message, I don't feel that he operates at the right level of distance conceptually. While technical issues raised are valid, they are not new and have been discussed many times. And proposed solutions are focused on technical aspects and ignore the strategic reality that Bitcoin was designed to create and maintain a stable consensus between all involved parties whereby defending the current status quo is always the most profitable outcome. The only way to get any change done from within the protocol is to manage to tilt the equilibrium point to another neighbouring spot not too far that has the same or better perceived outcome for all parties, and hope you don't let too many people behind (that's exactly what happened when the dev team organized a rollback to 0.7). More than technical skills, this requires a lot of wisdom, and the ability to see the problem from multiple opposing point of views. In this respect the current dev team has proven very effective. AFAIK, that's the only way things are going to change ever for Bitcoin: minute and careful small steps, with major communication campains and full backing of the community. The most effective way to work around this feature / limitation is to go the external route: create a alt-chain. If it survives until the point where it is traded for Bitcoin with a high liquidity, Bitcoin will inherit the new properties by equivalence through the exchange rate. This is why you always got and will always get replies like "create your alt-coin or stfu" when you propose to move Bitcoin to a state that is simply not reachable. That's the only known valid answer, and it has been made quite a few times to OP in this thread with varying degrees of tactfulness. Now if OP is going to take all his ideas, organize them into a coherent framework, and create a new thread in the alt-coin section, we can have a constructive discussion. Title: Re: Amateur hour Post by: BitPirate on March 15, 2013, 03:49:47 AM Why I'm the Best Programmer in the World (http://www.codinghorror.com/blog/2004/08/why-im-the-best-programmer-in-the-world.html)
I can only imagine how burned out Gavin et al must feel reading this shit. Also, the "Satoshi is Dead" thread. Of course he's not dead... he just didn't want to put up with this ineffectual whining. 50M bitcoins vs giving your life to being attacked by inane idiots. I have my own small open source community project, and experience the same e=penis waving constantly -- people downloading and using something for free and bitching about it being "low quality", without actually providing any objective analysis, let alone help. (Help I do get tends to involve people shoehorning in features they need then doing a runner). It's ridiculous. Furthermore, IME, most "professional" coding efforts are an order of magnitude more horrible than "amateur" work. Bitcoin is a fantastic and amazingly prescient software vision. Someone had the foresight to make it a reality, and people have the tenacity to keep it stable and running -- and there is a market confidence of nearly half a billion US dollars behind them. The OP did not and could not do any of these things. Title: Re: Amateur hour Post by: acoindr on March 15, 2013, 04:00:02 AM Blinken's ideas are generally sound. LOL :D Which ideas were those again, exactly? Title: Re: Amateur hour Post by: acoindr on March 15, 2013, 05:49:36 PM It's ridiculous. Furthermore, IME, most "professional" coding efforts are an order of magnitude more horrible than "amateur" work. I just read that line. +1 That's not always the case, of course (Blinken certainly appears to know what he is doing) but earning a good salary for programming certainly isn't always a measure of superiority over programmers that don't. BTW, Blinken what I do consider a great measurement of intelligence mixed with programming ability are things like Google's Code Jam (https://code.google.com/codejam/) and the Netflix Prize (http://en.wikipedia.org/wiki/Netflix_Prize). Those are tests not winnable by simply learning by rote. The qualification round for Google's 10th Code Jam actually starts April 12, 2013. If you compete and make it anywhere near the finals then you'll have my respect. Considering the prize is $15,000 (plus a likely Google job offer) for what amounts to about 1 day worth of coding the pay scale isn't likely beneath many. Title: Re: Amateur hour Post by: acoindr on March 15, 2013, 08:23:37 PM One last thing, Blinken. You're obviously intelligent, very much so it seems, but Bitcoin has attracted many intelligent people to it. So around here your published IQ is probably in good company. It doesn't do well to challenge such a group and not expect to get checked, hard. I think you could offer the project/effort much of value, but you might re-think your approach to introducing your ideas. More flies with honey than vinegar and all that.
Title: Re: Amateur hour Post by: Herodes on March 15, 2013, 10:22:27 PM If a few miners can do this, what do you think the NSA could do? How do we know that NSA or any other 3-letter agency did not create bitcoin ? Title: Re: Amateur hour Post by: SgtSpike on March 15, 2013, 10:29:52 PM If a few miners can do this, what do you think the NSA could do? How do we know that NSA or any other 3-letter agency did not create bitcoin ? We don't. Title: Re: Amateur hour Post by: Herodes on March 16, 2013, 01:17:06 AM If a few miners can do this, what do you think the NSA could do? How do we know that NSA or any other 3-letter agency did not create bitcoin ? We don't. I'm not saying they did. But we can't rule out the possibility either. Many thinks the USD is a failing currency. Bitcoin is growing, and it's growing fast. How do we know that at one point, some datacenter on US soil will not have a majority of the hashing power, and that rules will be enforced upon the Bitcoin network ? Gavin already gave his talk to the CIA, and he agreed to not talk about what happened there, and I understand that's usual procedure. I don't know what the penality would be for not complying with that. I don't even know if this was a demand from them in the first place, but surely if Gavin values personal freedom he should never again visit any governmental agency and agree to contracts where full disclosure is not allowed. I do trust Gavin, but at the same time we learned that Gavin bows to authority pressure. What about the other devs, what are their connections, and how would they react if governmental officials brought them in for questioning, asking them to cooperate. These people have lives, they have wifes and kids, they would probably want the least amount of trouble. Now that Coinbase is taking over a lot of the business of MtGox, there's even more juicy targets on US soil. The truth is that we don't know. But one thing is for certain - having monetary power and control is something nation states want to have, so it's only a question of time before big players jumps in, and the bigger bitcoin grows, the juicer target it becomes. Too far fetched ? Both the Internet (http://www.computerhope.com/jargon/a/arpanet.htm) itself and TOR (http://www.networkworld.com/community/blog/no-conspiracy-theory-needed-tor-created-us-go) was created by the US govt. By using bitcoin and local exchanges, it would be simple for us agents to aquire cash behind 'enemy lines' as well. And large amounts of money can be moved anywhere there's internet connection, which is another plus. Not saying anything conclusively either way, but we should not rule out the possibility of something of this being possible. I probably went off topic anyway. Title: Re: Amateur hour Post by: Gavin Andresen on March 16, 2013, 07:55:21 PM Gavin already gave his talk to the CIA, and he agreed to not talk about what happened there... No, that is not true.The only condition of my visit to the CIA was that I not use the fact that I visited there in any type of advertising. Well, that and to abide by their normal security while I was there: no cell phone or other electronic devices allowed, no trying to wander off by myself unescorted. I am completely free to talk about what happened, and if you buy me a beer sometime I'd be happy to answer any questions you have. Just not here, too many trolls and I've already spent too much time before and after the trip trying (and failing) to keep the conspiracy theories in check. Title: Re: Amateur hour Post by: tvbcof on March 16, 2013, 10:31:40 PM Gavin already gave his talk to the CIA, and he agreed to not talk about what happened there... No, that is not true.The only condition of my visit to the CIA was that I not use the fact that I visited there in any type of advertising. Well, that and to abide by their normal security while I was there: no cell phone or other electronic devices allowed, no trying to wander off by myself unescorted. I am completely free to talk about what happened, and if you buy me a beer sometime I'd be happy to answer any questions you have. Just not here, too many trolls and I've already spent too much time before and after the trip trying (and failing) to keep the conspiracy theories in check. I didn't notice any particular conspiracy theories that got much traction. I'm about as prone to conspiracy theories (or hypotheses) as anyone and I saw nothing necessarily nefarious or extraordinary by your visit. I do think that you and Hearn in particular seem, outwardly at least, a little to prone to write off corp/gov class threats to the Bitcoin solution as it exists today. But I see nothing to be lost by giving the presentation you described and have always admired the way you handled it vis-a-vis communications with the Bitcoin community. Title: Re: Amateur hour Post by: Herodes on March 16, 2013, 10:48:53 PM Gavin already gave his talk to the CIA, and he agreed to not talk about what happened there... No, that is not true.The only condition of my visit to the CIA was that I not use the fact that I visited there in any type of advertising. Well, that and to abide by their normal security while I was there: no cell phone or other electronic devices allowed, no trying to wander off by myself unescorted. I am completely free to talk about what happened, and if you buy me a beer sometime I'd be happy to answer any questions you have. Just not here, too many trolls and I've already spent too much time before and after the trip trying (and failing) to keep the conspiracy theories in check. Would definately buy you a beer whenever I get to the states. Do you have a program searching for your name on the forum since you seem always to pop in at the right times ? :) Title: Re: Amateur hour Post by: jbreher on March 17, 2013, 03:54:34 AM Gavin already gave his talk to the CIA, and he agreed to not talk about what happened there... No, that is not true.The only condition of my visit to the CIA was that I not use the fact that I visited there in any type of advertising. Well, that and to abide by their normal security while I was there: no cell phone or other electronic devices allowed, no trying to wander off by myself unescorted. I am completely free to talk about what happened, and if you buy me a beer sometime I'd be happy to answer any questions you have. Just not here, too many trolls and I've already spent too much time before and after the trip trying (and failing) to keep the conspiracy theories in check. Would definately buy you a beer whenever I get to the states. Do you have a program searching for your name on the forum since you seem always to pop in at the right times ? :) I think the NSA alerts him when his name pops up. . . . . . . . . . I keeed! I keeeed! Title: Re: Amateur hour Post by: Raoul Duke on March 17, 2013, 04:38:30 AM yup, I guess the Bitcoin source clearly isn't enterprisey (http://www.urbandictionary.com/define.php?term=enterprisey) enough. Here's a good shining example of a critical real world application showing how to do it right: * http://code.google.com/p/fizzbuzz/ * http://code.google.com/p/fizzbuzz/source/browse/#svn%2Ftrunk%2Ftrunk Not as enterprisey as this one https://github.com/Herzult/SimplePHPEasyPlus Title: Re: Amateur hour Post by: ralree on March 17, 2013, 06:52:37 AM OP's ignore link is getting pretty yellow. I just added to that. Goodnight sweet prince.
Title: Re: Amateur hour Post by: moni3z on March 17, 2013, 08:25:51 PM +1 OP ignore for obvious trolling on cruise control
|
