Amateur hour

[SgtSpike]

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.

[SgtSpike]

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.

You require $216,000/year to subside?  

[deepceleron]

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.

[Jaw3bmasters]

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

[Piper67]

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.

You require $216,000/year to subside?  

Of course he does. He's a "professional"... with a nice troll for an avatar, which should've been the first clue.

[bbit]

I'm laughing at this thread! 

[Blinken]

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.

You require $216,000/year to subside?  

When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks.

[Piper67]

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.

You require $216,000/year to subside?  

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!

[jl2012]

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

[DataPlumber]

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.

[SgtSpike]

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.

You require $216,000/year to subside?  

When you know the difference between a Hamiltonian cycle and a Mercier cycle you get paid the big bucks.

And apparently have to spend as much to survive too!   

[Blinken]

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.

[tvbcof]

...

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.)

[sd]

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.

[jl2012]

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!

[Blinken]

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.

[wtfvanity]

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.

[Herodes]

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.

[prezbo]

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.

[Timo Y]

Bitcoin has fewer bugs than most professional software I've used.