Bitcoin Forum
March 16, 2013, 05:52:45 AM *
News: The bug appears to be resolved now. Merchants can accept transactions. Mining on 0.8 is OK, but you should not increase the target block size from the default. More info.
 
   Home   Help Search Donate Login Register  
Pages: 1 2 3 4 5 6 7 8 9 10 All
  Print  
Author Topic: In re Bitcoin Devs are idiots  (Read 4340 times)
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 01:24:05 AM
 #1

This matter was apparently for the first time discussed here, which is in itself ridiculously late, but the recent events illustrate the need of having the various issues much more clearly delineated.

Recently Bitcoin came close to unmitigated disaster, in the following way: Gavin diplomatically suggested that miners increase their block size, from the previous magic number of "250k" to something they themselves pick. This approach is flawed: the solution to the problem of having a magic number in the code is not passing the responsibility of choosing it to a larger group. It may work politically, in the sense that where large, vague groups are responsible for a bad move nobody will ever be hung. It does not work practically.

This point does not begin to get sufficient emphasis: stop thinking politically, stick to thinking practically. The political importance, usefulness or competence of a dev is nil. This is not your job, and more importantly this is one of the things you suck at the most. A casual skim through the -dev sessions is ample proof for this, more ridiculous dickwad posturing and knowshitism has never before been seen (outside of the mailing lists of some meanwhile failed open source projects). Snap out of it. Stick to writing code.

But we digress: as a result of a number of miners implementing their own version of a magic miner, a number of large blocks were created and mined by them, as long as they ran 0.8. Miners running 0.7 failed to mine these same blocks, and a fork developed.

The reason is that Bitcoin code sucks. It's not that "the blocksize", it's not that "the database", it's not that "nobody could have foreseen their using a plane like a rocket". That shit does not belong in this discussion, passing the buck is not and cannot be accepted in Bitcoin. The reason is that Bitcoin code sucks, and Bitcoin code sucks because people want to be Bitcoin devs, people want to call each other Bitcoin devs, people want to participate in idle irc chatter as if they in fact were Bitcoin devs, but those same people do not have either the ability or intellectual resources to write dependable, usable, good, clean code.

This is a problem, and this problem needs to be resolved, preferably by the people who are causing it. You know yourselves, I won't name and shame. Fix your heads. You won't be getting much more warning.

Today will go down in history as the day when Bitcoin nearly died, and its fate depended on BTC-Guild staying online. Stop and think for a minute. What are you doing here? Why are you here, really?

Advertisement: Your ad here.
misterbigg
Hero Member
*****
Offline Offline

Posts: 867



View Profile WWW

Ignore
March 12, 2013, 01:31:38 AM
 #2

Talk about armchair quarterbacking. How easy it is for someone to just sit back and point the finger. Have you seen the Bitcoin software? Do you understand C++ code? It's complicated, and the rules which have evolved in response to strengthening the network are not so easily factored into neat code compartments.

Instead of bitching why don't you write your own client that has clean code?

JonSnow
Jr. Member
**
Online Online

Posts: 39


CryptoCurrent


View Profile WWW

Ignore
March 12, 2013, 01:32:09 AM
 #3

Likewise, misterbigg.

CryptoCurrent - buy bitcoins anonymously by bank deposit or cash overnight (USPS or FedEx shipping prepaid & provided by us)!
PGP Key | Forum Thread
1CryptoCo47ZHjDzphSw6rVtesYjSB5hAA
Bowjob
Sr. Member
****
Online Online

Posts: 410



View Profile

Ignore
March 12, 2013, 01:35:22 AM
 #4

Mhm.. Sell?

When I speak the truth, I will use red.
Bitcoin Megastore - Bitcoinwear and so much more!
152mAXabBVjB58bASMzZEJzPPU84gEgjZR
xcsler
Jr. Member
**
Offline Offline

Posts: 71



View Profile

Ignore
March 12, 2013, 01:42:50 AM
 #5

What doesn't kill you makes you stronger.

"I don't care about the busts. I am riding this pig wherever it takes me. If it tanks, I'll have a helluva story to tell. I'm sick of half measures. I'm swinging for the fences and if I strike out, so be it.  I won't be some mediocre drone living a life of quiet desperation. I believe in Bitcoin and I'm going for broke, knowing the risks." -billyjoeallen, bitcointalk.org
pizzaman1337
Jr. Member
**
Offline Offline

Posts: 14


View Profile

Ignore
March 12, 2013, 01:45:00 AM
 #6

This matter was apparently for the first time discussed here, which is in itself ridiculously late, but the recent events illustrate the need of having the various issues much more clearly delineated.

Recently Bitcoin came close to unmitigated disaster, in the following way: Gavin diplomatically suggested that miners increase their block size, from the previous magic number of "250k" to something they themselves pick. This approach is flawed: the solution to the problem of having a magic number in the code is not passing the responsibility of choosing it to a larger group. It may work politically, in the sense that where large, vague groups are responsible for a bad move nobody will ever be hung. It does not work practically.

This point does not begin to get sufficient emphasis: stop thinking politically, stick to thinking practically. The political importance, usefulness or competence of a dev is nil. This is not your job, and more importantly this is one of the things you suck at the most. A casual skim through the -dev sessions is ample proof for this, more ridiculous dickwad posturing and knowshitism has never before been seen (outside of the mailing lists of some meanwhile failed open source projects). Snap out of it. Stick to writing code.

But we digress: as a result of a number of miners implementing their own version of a magic miner, a number of large blocks were created and mined by them, as long as they ran 0.8. Miners running 0.7 failed to mine these same blocks, and a fork developed.

The reason is that Bitcoin code sucks. It's not that "the blocksize", it's not that "the database", it's not that "nobody could have foreseen their using a plane like a rocket". That shit does not belong in this discussion, passing the buck is not and cannot be accepted in Bitcoin. The reason is that Bitcoin code sucks, and Bitcoin code sucks because people want to be Bitcoin devs, people want to call each other Bitcoin devs, people want to participate in idle irc chatter as if they in fact were Bitcoin devs, but those same people do not have either the ability or intellectual resources to write dependable, usable, good, clean code.

This is a problem, and this problem needs to be resolved, preferably by the people who are causing it. You know yourselves, I won't name and shame. Fix your heads. You won't be getting much more warning.

Today will go down in history as the day when Bitcoin nearly died, and its fate depended on BTC-Guild staying online. Stop and think for a minute. What are you doing here? Why are you here, really?

MPOE-PR, what are you doing here? Why are you really here?

Has MPEx considered hiring "good" programmers to work on the bitcoin code?
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 01:48:47 AM
 #7

MPOE-PR, what are you doing here? Why are you really here?

Has MPEx considered hiring "good" programmers to work on the bitcoin code?

Considered, yes. One problem is the centralization issue stemming from that approach. The one correct way to handle Bitcoin development is exactly as designed: independent devs doing it. The problem is that instead of doing it they spend their time opining on things that utterly ain't their business.

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 01:49:10 AM
 #8

Time to deversify into Ripple ledger chain, lol

Seriously, the bug was in old 0.7 version but it got a chance to manifest only because of an incomplete .8 rollout WHILE at the same time suggestion was made to increase soft block size limit.

Lesson: do only ONE major change at a time and let the dust settle before moving to the next one

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
misterbigg
Hero Member
*****
Offline Offline

Posts: 867



View Profile WWW

Ignore
March 12, 2013, 01:52:33 AM
 #9

Devs handled this like fucking pros. Bullish for bitcoin.

justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 01:52:57 AM
 #10

MPOE-PR, what are you doing here? Why are you really here?

Has MPEx considered hiring "good" programmers to work on the bitcoin code?

Considered, yes. One problem is the centralization issue stemming from that approach. The one correct way to handle Bitcoin development is exactly as designed: independent devs doing it. The problem is that instead of doing it they spend their time opining on things that utterly ain't their business.
What's stopping your company from hiring one developer to do nothing but code cleanups and submitting them to GitHub? There's nothing centralized about that.

paraipan
Hero Member
*****
Offline Offline

Posts: 3542


Firstbits: 1pirata


View Profile WWW

Ignore
March 12, 2013, 01:52:59 AM
 #11

Damn, you had to be the one to bring the bad news...  Undecided

Be back in a minute, have to patch some software.

BTCitcoin: An Idea Worth Spending - Q&A with bitcoins on Rugatu

Buy bitcoins with ukash on http://mercabit.eu - Top-up your mobile phone on http://bit2mobile.com - Check my rep
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 01:59:07 AM
 #12

What's stopping your company from hiring one developer to do nothing but code cleanups and submitting them to GitHub? There's nothing centralized about that.

Because cleanups would require very deep reaching changes. If we hired a cleanup dev his #1 task would be "find and remove all magic numbers anywhere in the codebase". Meanwhile listen to these idiots:

Quote
gavinandresen petertodd: what would you think of a max block size set so a crappy broadband user of today could still validate and mine everything, with a limit set to increase by 20% a year (the approximate rate of bandwidth increase these days) ?

MORE MAGIC NUMBERS.

It looks more like a lost cause than anything. And no, the fact that "we're fixing it" does not impress me in the slightest, and NO, they're not handling it "like pros".

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 02:01:44 AM
 #13

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
NegativeNancy
Jr. Member
**
Offline Offline

Posts: 32


View Profile

Ignore
March 12, 2013, 02:03:00 AM
 #14

I guess that's your cue to leave. Don't let the door hit you on the way out!
justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 02:03:55 AM
 #15

Because cleanups would require very deep reaching changes.
And?

If you say you know what the problem is, and have the ability to correct it, why complain about it unless you're going to do something?

MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 02:04:47 AM
 #16

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

That would be correct. It's a huge issue.

Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 02:08:25 AM
 #17

Because cleanups would require very deep reaching changes.

Then you should develop your own cryptocoin with code that even a blind man could read. It sounds like you already have it figured out.

This is an experiment. Something like Bitcoin has never been done before. I don't recall getting any guarantee when I got my coins or sent transactions, do you?


"The synonym of usury is ruin." -Samuel Johnson
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 02:11:06 AM
 #18

Because cleanups would require very deep reaching changes.

Then you should develop your own cryptocoin with code that even a blind man could read. It sounds like you already have it figured out.

This is an experiment. Something like Bitcoin has never been done before. I don't recall getting any guarantee when I got my coins or sent transactions, do you?

This (and the rest of the mindless crap) has nothing to do with the matter. A guarantee or no guarantee doesn't make the lift eyelid insert fork person any less of an idiot.

Let's try and stick to the topic.

lophie
Full Member
***
Online Online

Posts: 155


Hashes to hashes, fiat to dust.


View Profile

Ignore
March 12, 2013, 02:12:28 AM
 #19

On 2011 an external factor made Bitcoin nose dive...... Imagine what would happen this time.... Don't kid yourselves like some people in the IRC room. This is the biggest problem Bitcoin ever faced and it is waaaaay bigger than the MTGox. hack.

I am not pulling out I am just pissed off Bitcoin will suffer greatly because the DEVS MADE A MISTAKE! you dont freaking PUSH such things without proper testing. EVER HEARD OF TESTNET!!!!!!

"Every Satoshi is exactly like the other Satoshi. this is how we raise all of the Satoshies"
Tip Jars - Thank you ^_^ :  BTC: 1LophieEaKWKtqGWoTDp5TDhB7rGjneHep
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 02:13:47 AM
 #20


Let's try and stick to the topic.

The topic is you calling a group pf people idiots that are doing something you can't do.

"The synonym of usury is ruin." -Samuel Johnson
bullioner
Jr. Member
**
Offline Offline

Posts: 98


View Profile

Ignore
March 12, 2013, 02:14:17 AM
 #21

What's stopping your company from hiring one developer to do nothing but code cleanups and submitting them to GitHub? There's nothing centralized about that.

The whole attitude of only having a single full implementation.  
ldrgn
Jr. Member
**
Offline Offline

Posts: 72


View Profile

Ignore
March 12, 2013, 02:15:24 AM
 #22

First off: BTC development is a free market.  This is the tragedy of the commons.  If MP is unsatisfied with the code he should stop leeching like a welfare queen and pay for development.

Secondly, maybe it's time to consider Google Chrome-esque updating for BTC clients?  There was already a game-breaking bug like this years ago with the integer overflow problem.  It really only improves the security of the network.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 02:15:57 AM
 #23

On 2011 an external factor made Bitcoin nose dive...... Imagine what would happen this time.... Don't kid yourselves like some people in the IRC room. This is the biggest problem Bitcoin ever faced and it is waaaaay bigger than the MTGox. hack.

I am not pulling out I am just pissed off Bitcoin will suffer greatly because the DEVS MADE A MISTAKE! you dont freaking PUSH such things without proper testing. EVER HEARD OF TESTNET!!!!!!

No cause we're too cool for testnet and elbow grease, gotta spend 16 hours a day on -dev talking about what we think of Satoshi Dice and how many whales fatass Gmaxwell could swallow whole.

justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 02:16:14 AM
 #24

I am not pulling out I am just pissed off Bitcoin will suffer greatly because the DEVS MADE A MISTAKE! you dont freaking PUSH such things without proper testing. EVER HEARD OF TESTNET!!!!!!
The problem was with the old version of bitcoin. The mistake appears to have been not waiting for enough of the network to upgrade to the new version before enabling block sizes that were supposed to have been legal all this time.

bullioner
Jr. Member
**
Offline Offline

Posts: 98


View Profile

Ignore
March 12, 2013, 02:18:46 AM
 #25

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

Yes.  This will be the death of Bitcoin.  When a fully specified crypto currency comes along, it will leave Bitcoin behind.  "The implementation is the protocol specification" is wrong, and at Internet scale it is very wrong.
lophie
Full Member
***
Online Online

Posts: 155


Hashes to hashes, fiat to dust.


View Profile

Ignore
March 12, 2013, 02:22:58 AM
 #26

JGarzick warned us about this  Roll Eyes. He literally suggested we leave the blocksize ALONE. BTW to all who defends the devs.Why do you want us to praise them when they do it right and now since they were total idiots you defend them? Have some consistency!

0.8 was a mistake. Fix it. Say you are sorry and were idiots. Bear the price nosedive and suck it up. Sleep it off.

- Lophie

"Every Satoshi is exactly like the other Satoshi. this is how we raise all of the Satoshies"
Tip Jars - Thank you ^_^ :  BTC: 1LophieEaKWKtqGWoTDp5TDhB7rGjneHep
Largo
Jr. Member
**
Offline Offline

Posts: 64



View Profile

Ignore
March 12, 2013, 02:25:13 AM
 #27

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

Yes.  This will be the death of Bitcoin.  When a fully specified crypto currency comes along, it will leave Bitcoin behind.  "The implementation is the protocol specification" is wrong, and at Internet scale it is very wrong.

That and the fact that we didnt even have an emergency plan for things like this, everyone just meeting in irc and it even took like 30mins for the first forum thread to show up. What a joke.

But then, i dont blame the devs, they are doing a great job, maybe we just need more people working on it?
I would have no problem paying like 1% of my Bitcoin earnings as donation to people working on Bitcoin.


https://easycoin.net/ - Bitcoin Wallet - Because Bitcoin doesnt have to be rocket science | http://easycoinsayj7p5l.onion/ - EasyCoin on Tor
http://shopsat2dotfotbs.onion/ - Create your own .onion store with full bitcoin integration
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 02:29:39 AM
 #28

The topic is you calling a group pf people idiots that are doing something you can't do.

Seriously now. Try and think things through before you post them. What difference does what I can or cannot do make in this discussion?

Eiii
Jr. Member
**
Offline Offline

Posts: 23


View Profile

Ignore
March 12, 2013, 02:33:34 AM
 #29


Let's try and stick to the topic.

The topic is you calling a group pf people idiots that are doing something you can't do.

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.
Maged
Global Moderator
Hero Member
*
Offline Offline

Posts: 2548


View Profile

Ignore
March 12, 2013, 02:35:32 AM
 #30

That and the fact that we didnt even have an emergency plan for things like this, everyone just meeting in irc and it even took like 30mins for the first forum thread to show up. What a joke.
We do. We just never considered this specific possibility, so we were limited to the fallback plan: Emergency rule change

Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 02:37:16 AM
 #31

What difference does what I can or cannot do make in this discussion?

You're either a jackass braying by the side of the road or you're fixing the jackass's wagon. Which one are you?

"The synonym of usury is ruin." -Samuel Johnson
100x
Jr. Member
**
Offline Offline

Posts: 46


View Profile

Ignore
March 12, 2013, 02:37:29 AM
 #32


Let's try and stick to the topic.

The topic is you calling a group pf people idiots that are doing something you can't do.

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.

It's actually fucking amazing that this is first MAJOR bug in 4 years. Have you ever written a line of code? These people are very good at what they do. And consider the fact that until the foundation starting pay Gavin a few months ago, it was entirely unpaid volunteer work. Bitcoin is one the most innovate things that has happened in the past 1000 years. Jesus, show some fucking appreciation.

Only coins moved in the last 3 or 4 hours are in any danger at all. And most likely those transactions will be completely confirmed soon when the miners all switch to 0.7 and the two chains converge.

Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 02:39:04 AM
 #33

It's actually fucking amazing that this is first MAJOR bug in 4 years.

Amen.

"The synonym of usury is ruin." -Samuel Johnson
ldrgn
Jr. Member
**
Offline Offline

Posts: 72


View Profile

Ignore
March 12, 2013, 02:43:13 AM
 #34

that this is first MAJOR bug in 4 years.

Except for the integer overflow bug and all those CVEs, sure.  You can't even say "this is the first prolifically visible major bug in 4 years" as the integer overflow bug holds that title.
lophie
Full Member
***
Online Online

Posts: 155


Hashes to hashes, fiat to dust.


View Profile

Ignore
March 12, 2013, 02:50:07 AM
 #35

Only coins moved in the last 3 or 4 hours are in any danger at all. And most likely those transactions will be completely confirmed soon when the miners all switch to 0.7 and the two chains converge.

Till now 12 blocks have passed. which is alot. Don't belittle the problem if I dined in mez grill 1 hours ago paying with Bitcoin. Then an hour later I double spent the coins with a v0.7 bitcoind. The transaction WILL NOT BE REVERSE ABLE as it got buried in a block and WILL be buried in two VERY soon, and I would SUCCESSFULLY pulled off double spent  without the need for 51% of the network to make it "possible"

Good luck promising the people this will never happen again and convincing the new comers that txs are irreversible. The mass follow adoption it is the few who follows over deep understanding and non-inflected belief in the system. You just lost the majority of the "normal" users today. Make no mistake about it, this IS the new nose dive of Bitcoin.

And how do you think this will look since we just passed the all time high..... expect news flashes... "It happened again" and "The future money that keeps on falling whenever it got high!".

"Every Satoshi is exactly like the other Satoshi. this is how we raise all of the Satoshies"
Tip Jars - Thank you ^_^ :  BTC: 1LophieEaKWKtqGWoTDp5TDhB7rGjneHep
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 02:52:03 AM
 #36

that this is first MAJOR bug in 4 years.

Except for the integer overflow bug and all those CVEs, sure.  You can't even say "this is the first prolifically visible major bug in 4 years" as the integer overflow bug holds that title.

Actually, to be more precise: this is a major bug rather than yet another opportunity for the disgusting circlejerk of patting each other on the back precisely because I said something.

I don't care and I don't want to hear stupid stories and even more stupid justification. This sort of incompetence is not acceptable for a half billion dollar thing.

If you earnestly believe this is the best you can do, leave.

lophie
Full Member
***
Online Online

Posts: 155


Hashes to hashes, fiat to dust.


View Profile

Ignore
March 12, 2013, 02:56:05 AM
 #37

Or keep your ideas to yourself and the forums. DONT SUBMIT (to the code base) THEM

"Every Satoshi is exactly like the other Satoshi. this is how we raise all of the Satoshies"
Tip Jars - Thank you ^_^ :  BTC: 1LophieEaKWKtqGWoTDp5TDhB7rGjneHep
meebs
Sr. Member
****
Offline Offline

Posts: 346


View Profile

Ignore
March 12, 2013, 03:05:11 AM
 #38

ladies and gentlemen:

this is why the "bankers" make a LOT of money. they are EXTREMELY good at what they do and WAY more money is on the line every hour vs what bitcoin deals with in a year.


If you enjoyed the advice I gave, feel free to toss over some loose change Smiley
1P67xUSyCchQSwngptRVBKso4mMEZMGALZ
Eiii
Jr. Member
**
Offline Offline

Posts: 23


View Profile

Ignore
March 12, 2013, 03:05:21 AM
 #39


Let's try and stick to the topic.

The topic is you calling a group pf people idiots that are doing something you can't do.

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.

It's actually fucking amazing that this is first MAJOR bug in 4 years.

I don't disagree, but it's disappointing and discouraging that apparently this situation-- which is an important, obvious one!-- wasn't tested before the changes were rolled out. The best thing that can come from this is hopefully developers will be much more careful about these kinds of changes in the future.
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 03:07:39 AM
 #40

ladies and gentlemen:

this is why the "bankers" make a LOT of money. they are EXTREMELY good at what they do

Manipulate governments and markets, spread disinformation through the media and rig the currency to their benefit?

Ya, bankers are experts.

"The synonym of usury is ruin." -Samuel Johnson
lophie
Full Member
***
Online Online

Posts: 155


Hashes to hashes, fiat to dust.


View Profile

Ignore
March 12, 2013, 03:13:19 AM
 #41

ladies and gentlemen:

this is why the "bankers" make a LOT of money. they are EXTREMELY good at what they do

Manipulate governments and markets, spread disinformation through the media and rig the currency to their benefit?

Ya, bankers are experts.

Don't forget debt re-hypothication and lemon dancing debt between banks for interest. We are quite pissed off with what is happening but make no mistake sir. Banks are playing another league. This is the pro league.

"Every Satoshi is exactly like the other Satoshi. this is how we raise all of the Satoshies"
Tip Jars - Thank you ^_^ :  BTC: 1LophieEaKWKtqGWoTDp5TDhB7rGjneHep
NegativeNancy
Jr. Member
**
Offline Offline

Posts: 32


View Profile

Ignore
March 12, 2013, 03:13:33 AM
 #42

I don't care and I don't want to hear stupid stories and even more stupid justification. This sort of incompetence is not acceptable for a half billion dollar thing.

If you earnestly believe this is the best you can do, leave.
That's not how it works. If you don't think it's acceptable, you either help fix the problem (something tells me you're not up to that) or YOU leave. If you think the devs are idiots, then I guess the biggest idiot is you, for investing in their work. Toodles.
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 03:18:32 AM
 #43

Banks are playing another league. This is the pro league.

Banks only play that league because they have the guns and the force of law. Recognizing that thugs are good at what they do doesn't mean that it has to be admired or emulated.

"The synonym of usury is ruin." -Samuel Johnson
gyverlb
Sr. Member
****
Offline Offline

Posts: 499



View Profile

Ignore
March 12, 2013, 03:19:03 AM
 #44

Only coins moved in the last 3 or 4 hours are in any danger at all. And most likely those transactions will be completely confirmed soon when the miners all switch to 0.7 and the two chains converge.

Till now 12 blocks have passed. which is alot. Don't belittle the problem if I dined in mez grill 1 hours ago paying with Bitcoin. Then an hour later I double spent the coins with a v0.7 bitcoind.

Won't work. All the 0.7 bitcoind node would have seen your previous transaction and would reject the new one. And some people here call the bitcoin devs idiots? They don't even know how the network works.

P2pool guide: https://bitcointalk.org/index.php?topic=153232.0 // Trade at bitcoin.de, it's cheaper: https://www.bitcoin.de/r/f8ugqr
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Ignoring people repeatedly using logical fallacies in debates: myrkul, Rudd-O.
lophie
Full Member
***
Online Online

Posts: 155


Hashes to hashes, fiat to dust.


View Profile

Ignore
March 12, 2013, 03:23:58 AM
 #45

Only coins moved in the last 3 or 4 hours are in any danger at all. And most likely those transactions will be completely confirmed soon when the miners all switch to 0.7 and the two chains converge.

Till now 12 blocks have passed. which is alot. Don't belittle the problem if I dined in mez grill 1 hours ago paying with Bitcoin. Then an hour later I double spent the coins with a v0.7 bitcoind.

Won't work. All the 0.7 bitcoind node would have seen your previous transaction and would reject the new one. And some people here call the bitcoin devs idiots? They don't even know how the network works.

Smaller window, still possible. and BTW freshmen in software engineering knows that you shouldn't push a change without proper inspection and testing. that is what the testnet is for. My knowledge doesn't matter. Even if I was a monkey. What they did in 0.8 is IDIOCY.

"Every Satoshi is exactly like the other Satoshi. this is how we raise all of the Satoshies"
Tip Jars - Thank you ^_^ :  BTC: 1LophieEaKWKtqGWoTDp5TDhB7rGjneHep
gyverlb
Sr. Member
****
Offline Offline

Posts: 499



View Profile

Ignore
March 12, 2013, 03:33:21 AM
 #46

Smaller window, still possible. and BTW freshmen in software engineering knows that you shouldn't push a change without proper inspection and testing.
And true engineers in computer science know that no amount of inspection and testing is enough when you want something perfect. Lookup "formal verification" and see for yourself that nobody gives any guarantee in the software industry because it would be so damn costly.

P2pool guide: https://bitcointalk.org/index.php?topic=153232.0 // Trade at bitcoin.de, it's cheaper: https://www.bitcoin.de/r/f8ugqr
Tip: 17bdPfKXXvr7zETKRkPG14dEjfgBt5k2dd
Ignoring people repeatedly using logical fallacies in debates: myrkul, Rudd-O.
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Posts: 9263



View Profile

Ignore
March 12, 2013, 03:40:06 AM
 #47

Smaller window, still possible. and BTW freshmen in software engineering knows that you shouldn't push a change without proper inspection and testing. that is what the testnet is for. My knowledge doesn't matter. Even if I was a monkey. What they did in 0.8 is IDIOCY.

You do realize that the flaw was in 0.7 right.  Of course you tested this in v0.7 on testnet six months and posted a bug report right?  v0.7 has always had this flaw.  It wasn't detected or reported by anyone.

FastCash4Bitcoins No Exchanges; no Excuses; just Fast Payouts.  Over 275,000 BTC purchased.  (Support)
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 03:53:21 AM
 #48

Smaller window, still possible. and BTW freshmen in software engineering knows that you shouldn't push a change without proper inspection and testing. that is what the testnet is for. My knowledge doesn't matter. Even if I was a monkey. What they did in 0.8 is IDIOCY.

You do realize that the flaw was in 0.7 right.  Of course you tested this in v0.7 on testnet six months and posted a bug report right?  v0.7 has always had this flaw.  It wasn't detected or reported by anyone.

And the REASON it was neither detected nor reported is that some idiots THOUGHT it was a good idea to come up with a magic number and limit everything to 250k.

Just as SOMEONE thought it was a good idea to run Bitcoin with a plaintext wallet for 2 years.

The difference between the former and the latter is that I didn't say anything then, because back then nobody of any consequence gave two shits about your little bullshit project here.

And in fact, you probably to this day think running the wallet plaintext was ok.

Reality check. Seriously.

justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 03:59:46 AM
 #49

The difference between the former and the latter is that I didn't say anything then, because back then nobody of any consequence gave two shits about your little bullshit project here.
Then do something about it. Your business depends on this infrastructure so since you're so big you should be able to spare some investment into fixing the problems, not just identifying them.

conv3rsion
Jr. Member
**
Offline Offline

Posts: 78


View Profile

Ignore
March 12, 2013, 04:01:06 AM
 #50



Reality check. Seriously.

You know what, talk is fucking cheap. You can bitch all day, or you can put some resources into pushing forward this little experiment of ours. You think the code sucks, or that there are painfully obvious flaws like unencrypted wallet files that go unaddressed for way too long? Fix it.

It's completely open.

Stop bitching, and fix it.
behindtext
Jr. Member
**
Offline Offline

Posts: 28


View Profile

Ignore
March 12, 2013, 04:10:18 AM
 #51

seems like a pretty clear-cut case of insufficient test coverage.

when testing code, it is especially important to test the corner cases. this sounds like one of those corners, even without looking at the details of the issue.
markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 12, 2013, 04:34:31 AM
 #52

seems like a pretty clear-cut case of insufficient test coverage.

when testing code, it is especially important to test the corner cases. this sounds like one of those corners, even without looking at the details of the issue.

Yeah but apparently bitcoin millionaires cannot afford to get test suites made so it kind of sits there waiting for hard working coders and developers to find some spare time to work on such things.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 04:43:01 AM
 #53

seems like a pretty clear-cut case of insufficient test coverage.

when testing code, it is especially important to test the corner cases. this sounds like one of those corners, even without looking at the details of the issue.

Yeah but apparently bitcoin millionaires cannot afford to get test suites made so it kind of sits there waiting for hard working coders and developers to find some spare time to work on such things.

-MarkM-

Quote
15:49  gavinandresen ACTION resists the urge to talk about max block size??? must??? get??? work??? done...

Spare me the circlejerking. If there's time to be flaming Bitcoin users because they're not using Bitcoin "correctly" then there is time to stfu, swallow cox and work the testnet to the bone.

lophie
Full Member
***
Online Online

Posts: 155


Hashes to hashes, fiat to dust.


View Profile

Ignore
March 12, 2013, 04:52:07 AM
 #54

I was here and there on IRC and since the storm started to settle and I started to really look at things the way they are without the nervousness.

I would like to apologize to you all. Especially the devs, They did good and saved the day. thank you. And I am sorry for calling you idiots. You rock. Keep it up  Smiley

"Every Satoshi is exactly like the other Satoshi. this is how we raise all of the Satoshies"
Tip Jars - Thank you ^_^ :  BTC: 1LophieEaKWKtqGWoTDp5TDhB7rGjneHep
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 04:56:05 AM
 #55

there is time to stfu, swallow cox and work the testnet to the bone.

So we can surmise that you didn't find this bug either because you were also busy talking?

"The synonym of usury is ruin." -Samuel Johnson
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 05:04:46 AM
 #56

there is time to stfu, swallow cox and work the testnet to the bone.

So we can surmise that you didn't find this bug either because you were also busy talking?

Yes, you can surmise exactly that. IT IS MY JOB. I AM DOING MY JOB.

Guess who isn't, and guess what that makes them.

coqui33
Jr. Member
**
Offline Offline

Posts: 63



View Profile WWW

Ignore
March 12, 2013, 05:06:02 AM
 #57

MPOE-PR: You seem to be under the mistaken impression that the hard fork was caused by something in 0.8. Not so. The block that 0.7 choked on was a valid block. The bug was lurking in 0.7 all along, and was merely uncovered by a 0.8 miner's block. You might as well blame the physician who taps your kneecap to check reflexes, for the bone cancer that he unexpectedly discovers there.

Armed Citizens and the Law -- NRA-certified firearms instructor
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 05:08:12 AM
 #58

I AM DOING MY JOB.

Maybe you should just be quiet until the grownups fix your toy.

"The synonym of usury is ruin." -Samuel Johnson
Monster Tent
Hero Member
*****
Offline Offline

Posts: 787



View Profile

Ignore
March 12, 2013, 05:11:04 AM
 #59

Windows 8 hacked users forced to downgrade to Vista.   Tongue

pera
Jr. Member
**
Offline Offline

Posts: 13



View Profile WWW

Ignore
March 12, 2013, 05:16:13 AM
 #60

Yes, you can surmise exactly that. IT IS MY JOB. I AM DOING MY JOB.

Guess who isn't, and guess what that makes them.
Yeah, I know what you mean... your website have been down for weeks now Tongue

キタ━━━━(゚∀゚)━━━━ッ!!
gmaxwell
Staff
Hero Member
*****
Offline Offline

Posts: 1125


View Profile

Ignore
March 12, 2013, 05:18:22 AM
 #61

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation
This was actually a good example of something a spec wouldn't help (though would still be good to have). The inconsistent behavior here arose out of 0.8 not faithfully implementing some implicit behavior in BDB. The behavior in question is not anywhere in the Bitcoin code itself, nor is it visible at the interface of BDB and Bitcoin.  If there were a spec it would make no mention of it— and yet the network would be broken all the same.

The key thing is that in a distributed consensus system the most important definition of right is "consistent", this is paramount to all other concerns. A spec is helpful to the extent that it makes it easier to achieve a bit identical consistent behavior in the validation of blocks across all nodes, but because the spec itself can't be executed a spec can never guarantee consistency, at least not in the real world. (well, unless the spec is code— which is effectively what we have, for worse or better)


(And seriously, shad0wbitz etc. Act like an adult here. Your comments are very uncool.)

Were my comments helpful to you?  I take donations at: 1GMaxweLLbo8mdXvnnC19Wt2wigiYUKgEB
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 05:21:19 AM
 #62

MPOE-PR: You seem to be under the mistaken impression that the hard fork was caused by something in 0.8. Not so. The block that 0.7 choked on was a valid block. The bug was lurking in 0.7 all along, and was merely uncovered by a 0.8 miner's block. You might as well blame the physician who taps your kneecap to check reflexes, for the bone cancer that he unexpectedly discovers there.

I am not under any suck mistaken impression. Please read what's actually being said, it will help.

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases. This could have easily been avoided by simply not relying on magic numbers. It will ever be the case that whenever code contains arbitrary numbers based on arbitrary assumptions that code will break spectacularly.

gweedo
Hero Member
*****
Offline Offline

Posts: 2672

Java, PHP, HTML/CSS Programmer for Hire!


View Profile

Ignore
March 12, 2013, 05:24:12 AM
 #63

MPOE-PR I am calling for Gavin to not get paid this month by the foundation, I would think your with me on that. Someone needs to take blame for this bug.

Donations: http://qcl.me/gweedo| http://www.BitcoinLister.com- A Simple Bitcoin Directory!
justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 05:24:20 AM
 #64

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases.
Maybe it wasn't the size of the block that was the problem.

https://bitcointalk.org/index.php?topic=152131.msg1614374#msg1614374

Monster Tent
Hero Member
*****
Offline Offline

Posts: 787



View Profile

Ignore
March 12, 2013, 05:28:57 AM
 #65

Bitcoin is still beta software and untill recently no one got paid to do work on it.

MPOE-PR should stfu and contribute.

I bet they havent even donated to the bitcoin foundation  Tongue

Hurr Durr look how much money we made off free software.

MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 05:29:25 AM
 #66

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases.
Maybe it wasn't the size of the block that was the problem.

https://bitcointalk.org/index.php?topic=152131.msg1614374#msg1614374

That one requires more explanation for sure. What exactly?

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 05:33:09 AM
 #67

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation
This was actually a good example of something a spec wouldn't help (though would still be good to have). The inconsistent behavior here arose out of 0.8 not faithfully implementing some implicit behavior in BDB. The behavior in question is not anywhere in the Bitcoin code itself, nor is it visible at the interface of BDB and Bitcoin.  If there were a spec it would make no mention of it— and yet the network would be broken all the same.

The key thing is that in a distributed consensus system the most important definition of right is "consistent", this is paramount to all other concerns. A spec is helpful to the extent that it makes it easier to achieve a bit identical consistent behavior in the validation of blocks across all nodes, but because the spec itself can't be executed a spec can never guarantee consistency, at least not in the real world. (well, unless the spec is code— which is effectively what we have, for worse or better)


I respectfully disagree.  

A real protocol specification would enable a whole ecosystem of alternative and interoperable implementations to appear in Scala, Java, Go, C, etc.  

These implementations would NOT use the same flawed 3rd party libraries and there would be a real diversity in Bitcoin land, instead of the monoculture of C++ with all of its "magic" and "folklore".

Once no individual implementation had large enough fraction of the hash rate, then such forks would NOT occur, instead, bugs in a given implementation would only affect some miners, merchants & users but the chain would be just fine.

Let us hope and pray that eventually there will be some effort ( funded perhaps by the Bitcoin Foundation ) to extract and publish such a spec from the C++ hairball formal enough for viable alternative implementations to appear and to interoperate.


Cheers ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Posts: 9263



View Profile

Ignore
March 12, 2013, 05:35:40 AM
 #68

MPOE-PR: You seem to be under the mistaken impression that the hard fork was caused by something in 0.8. Not so. The block that 0.7 choked on was a valid block. The bug was lurking in 0.7 all along, and was merely uncovered by a 0.8 miner's block. You might as well blame the physician who taps your kneecap to check reflexes, for the bone cancer that he unexpectedly discovers there.

I am not under any suck mistaken impression. Please read what's actually being said, it will help.

The presence of a 250k arbitrary block limit prevented the underlying problem of the db from being discovered until that moment when a perfect storm composed out of a db upgrade and the limit removal created two almost equal miner bases. This could have easily been avoided by simply not relying on magic numbers. It will ever be the case that whenever code contains arbitrary numbers based on arbitrary assumptions that code will break spectacularly.

That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms.   It appears the number of transactions being changed as a result of the block validation crossed some "magic code" not in the Bitcoin source code but undocumented in some implementations of BDB.

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.   Nobody was saying/thinking oh yeah if you make a block with more than x transaction it will abort, cause a rollback, and result in a rejection.  It was a landmine.  

FastCash4Bitcoins No Exchanges; no Excuses; just Fast Payouts.  Over 275,000 BTC purchased.  (Support)
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 05:35:50 AM
 #69

Bitcoin is still beta software and untill recently no one got paid to do work on it.

MPOE-PR should stfu and contribute.

I bet they havent even donated to the bitcoin foundation  Tongue

Hurr Durr look how much money we made off free software.

Never donated, never will donate. Things don't work like "here's a foundation we made, give us money".

For that matter, we didn't go to Taaki's stupidferences either.

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 05:39:27 AM
 #70

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.  It was a landmine. 

Does this not argue for a diversity of implementations with different underlying 3rd party libraries ? Clearly it does. But this cannot happen until and unless there is actually a formal-enough spec to enable those to be written w/o ever "groking" all that C++ folklore, which is a moving target anyways ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 05:41:18 AM
 #71

That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms. 

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.  It was a landmine. 

Notwithstanding that blocks of 1mb should have been accepted if valid, the limit prevented too many of them from being made.

If the limit had been removed at a reasonable time, those blocks would have occasionally been made, and the overall problem would have been much contained.

I would like to also point out that the alexkravets idea re specification is sound. The only way forward for the dev team, provided they wish to preserve a shred of dignity, is a. immediately start work on specification, which is the only priority, and release no further versions until such specification is complete and b. immediately start work on removing all magic numbers and assorted code smelliness from their UNreference implementation of crap, and not release any further version before they've released a clean one.

In that order.

DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Posts: 9263



View Profile

Ignore
March 12, 2013, 05:44:58 AM
 #72

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.  It was a landmine.  

Does this not argue for a diversity of implementations with different underlying 3rd party libraries ? Clearly it does. But this cannot happen until and unless there is actually a formal-enough spec to enable those to be written w/o ever "groking" all that C++ folklore, which is a moving target anyways ...

I agree on that 100%.  It is inevitable that to survive Bitcoin will need to be move beyond a monoculture.  Right now all the clients share the same "DNA".  If there is a fatal genetic flaw in it then the network will not survive.   This time the "landmine" was accidental, next time it may be planted.

FastCash4Bitcoins No Exchanges; no Excuses; just Fast Payouts.  Over 275,000 BTC purchased.  (Support)
Atruk
Sr. Member
****
Offline Offline

Posts: 369



View Profile

Ignore
March 12, 2013, 05:49:04 AM
 #73

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.  It was a landmine. 

Does this not argue for a diversity of implementations with different underlying 3rd party libraries ? Clearly it does. But this cannot happen until and unless there is actually a formal-enough spec to enable those to be written w/o ever "groking" all that C++ folklore, which is a moving target anyways ...

I agree on that 100%.  It is inevitable that to survive Bitcoin will need to be move beyond a monoculture.  Right now all the clients share the same "DNA".  If there is a fatal genetic flaw in it then the network will not survive.   This time the "landmine" was accidental, next time it may be planted.
That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms. 

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.  It was a landmine. 

Notwithstanding that blocks of 1mb should have been accepted if valid, the limit prevented too many of them from being made.

If the limit had been removed at a reasonable time, those blocks would have occasionally been made, and the overall problem would have been much contained.

I would like to also point out that the alexkravets idea re specification is sound. The only way forward for the dev team, provided they wish to preserve a shred of dignity, is a. immediately start work on specification, which is the only priority, and release no further versions until such specification is complete and b. immediately start work on removing all magic numbers and assorted code smelliness from their UNreference implementation of crap, and not release any further version before they've released a clean one.

In that order.

Whoa... All of this... Agreement...

1DRNiHyAVRRiWJ5jWbnqgatritzQrrZKqw
cho
Jr. Member
**
Offline Offline

Posts: 46


Boar with me


View Profile

Ignore
March 12, 2013, 05:51:36 AM
 #74

MPOE-PR, your attitude makes me sick.
You've been yelling and calling developers names without having even understood what the technical issue is.
You pretend you deserve a perfect codebase and do not even spend resources towards this goal.
My opinion it that your childish rants hurt good-willed and hard-working people.
If your job is politics, then my opinion is that you suck at that job, because bitcoin as a whole does not benefit from someone technically incompetent throwing random blame around.

I, for one, do want to give a bucket of congrats to the devs for all the work done so far and for the quick response to the current problem.

One thing is interesting in this thread, it's the need for a formal spec of the protocol. alexkravets nails it real good in his posts.

1KEWxTkXPgfB9MdHJcfyoVnfHRnYEHQJPw
TradeFortress
Hero Member
*****
Offline Offline

Posts: 1625


Web developer | Also check out btcinvest!


View Profile

Ignore
March 12, 2013, 05:52:05 AM
 #75

Today will go down in history as the day when Bitcoin nearly died, and its fate depended on BTC-Guild staying online. Stop and think for a minute. What are you doing here? Why are you here, really?
No, it won't. If no action were taken people will just need to upgrade to 0.8.

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 05:54:38 AM
 #76

There is another 10+ hidden genetic flaws either in the C++ code itself or in one of the underlying libraries.

Imagine that next time instead of a fork split that can be healed, we end up leaking private key information through some side channel because of some bug in SSL libraries and the leakage gets embedded in the blockchain somehow ?

Such leakage cannot be repaired ... that will NOT be fixable and will simply lead to loss of confidence and extinction.

There's hundreds of deadly scenarios you can imagine here ...

Is anybody in the blessed circle of C++ magicians listening to this ?  

Bitcoin Foundation, is there any plan to extract the spec ?

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
TradeFortress
Hero Member
*****
Offline Offline

Posts: 1625


Web developer | Also check out btcinvest!


View Profile

Ignore
March 12, 2013, 05:56:01 AM
 #77

There is another 10+ hidden genetic flaws either in the C++ code itself or in one of the underlying libraries.

Imagine that next time instead of a fork split that can be healed, we end up leaking private key information through some side channel because of some bug in SSL libraries and the leakage gets embedded in the blockchain somehow ?

Such leakage cannot be repaired ... that will NOT be fixable and will simply lead to loss of confidence and extinction.

There's hundreds of deadly scenarios you can imagine here ...

Is anybody in the blessed circle of C++ magicians listening to this ?  

Bitcoin Foundation, is there any plan to extract the spec ?

SOMEHOW? Private keys? They're all on your client and are never transferred anywhere else.

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 06:04:27 AM
 #78

SOMEHOW? Private keys? They're all on your client and are never transferred anywhere else.

Read up on http://en.wikipedia.org/wiki/Side_channel_attack ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 12, 2013, 06:06:36 AM
 #79

seems like a pretty clear-cut case of insufficient test coverage.

when testing code, it is especially important to test the corner cases. this sounds like one of those corners, even without looking at the details of the issue.

Yeah but apparently bitcoin millionaires cannot afford to get test suites made so it kind of sits there waiting for hard working coders and developers to find some spare time to work on such things.

-MarkM-

Quote
15:49  gavinandresen ACTION resists the urge to talk about max block size??? must??? get??? work??? done...

Spare me the circlejerking. If there's time to be flaming Bitcoin users because they're not using Bitcoin "correctly" then there is time to stfu, swallow cox and work the testnet to the bone.

No problem, I'll leave Gavin to it and get on with doing other stuff that isn't already on the paid developer's to-do list.

LIke altcoins maybe, since bitcoin is already on the paid developer's to-do list.

Hmm, or Open Transactions maybe. So much to do, so little time to do it all.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
niko
Hero Member
*****
Offline Offline

Posts: 1625



View Profile

Ignore
March 12, 2013, 06:08:31 AM
 #80

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

That would be correct. It's a huge issue.
It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?

They're there, in their room.
Your mining rig is on fire, yet you're very calm.
markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 12, 2013, 06:20:42 AM
 #81

Lets drop the bug for bug compatible idea too while we're at it.

Tolerate any existing buggy blocks over 120 blocks old or that predate the last hardcoded checkpoint or something but don't make a religion of emulating the bugs going forward.

BDB shouldn't even be part of the spec, the spec should abstract the actual database implementation details and just maybe talk about whether it should have atomic transactions, whether we should be able to roll those back, under what circumstances to roll them back and so on.

Enshrining some bug in some particular implementation of "database back end" should be anathema, our spec should basically be telling us "BDB isn't up to spec, don't use versions of it that aren't able to perform as we need them to".

-MarkM-


Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 06:24:45 AM
 #82

The spec should simply describe exact format and formal-enough semantics of all valid network messages.

That's it.  

Need examples of such specs ?

1. TCP/IP
2. HTTP/1.1 (with extensions)
3. TLS

etc.

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
shamaniotastook
Jr. Member
**
Offline Offline

Posts: 27



View Profile

Ignore
March 12, 2013, 06:27:24 AM
 #83

This matter was apparently for the first time discussed here, which is in itself ridiculously late, but the recent events illustrate the need of having the various issues much more clearly delineated.

Recently Bitcoin came close to unmitigated disaster, in the following way: Gavin diplomatically suggested that miners increase their block size, from the previous magic number of "250k" to something they themselves pick. This approach is flawed: the solution to the problem of having a magic number in the code is not passing the responsibility of choosing it to a larger group. It may work politically, in the sense that where large, vague groups are responsible for a bad move nobody will ever be hung. It does not work practically.

This point does not begin to get sufficient emphasis: stop thinking politically, stick to thinking practically. The political importance, usefulness or competence of a dev is nil. This is not your job, and more importantly this is one of the things you suck at the most. A casual skim through the -dev sessions is ample proof for this, more ridiculous dickwad posturing and knowshitism has never before been seen (outside of the mailing lists of some meanwhile failed open source projects). Snap out of it. Stick to writing code.

But we digress: as a result of a number of miners implementing their own version of a magic miner, a number of large blocks were created and mined by them, as long as they ran 0.8. Miners running 0.7 failed to mine these same blocks, and a fork developed.

The reason is that Bitcoin code sucks. It's not that "the blocksize", it's not that "the database", it's not that "nobody could have foreseen their using a plane like a rocket". That shit does not belong in this discussion, passing the buck is not and cannot be accepted in Bitcoin. The reason is that Bitcoin code sucks, and Bitcoin code sucks because people want to be Bitcoin devs, people want to call each other Bitcoin devs, people want to participate in idle irc chatter as if they in fact were Bitcoin devs, but those same people do not have either the ability or intellectual resources to write dependable, usable, good, clean code.

This is a problem, and this problem needs to be resolved, preferably by the people who are causing it. You know yourselves, I won't name and shame. Fix your heads. You won't be getting much more warning.

Today will go down in history as the day when Bitcoin nearly died, and its fate depended on BTC-Guild staying online. Stop and think for a minute. What are you doing here? Why are you here, really?

With all due respect, MPOE, i do realize i am a newbie here, but my conscience forces me to make two observations of fact, and one suggestion.

Fact 1: The developers are NOT idiots. If they were, you and 80,000 other's would not be so engrossed in the going's on here.

Fact 2: You do have some valid points, but they are overshadowed by your lack of constructive criticism and insistence on personal character attacks on the developers intelligence. They are human! What they have accomplished should be praised.

One suggestion: from experience, i have learned that if you're smart enough to identify a problem, then your'e smart enough to identify at least ONE possible solution--not necessarily, THE solution, but A solution. And depending upon your experience, understanding of the problem domain and ability to organize effectively, you actually have the responsibility to move the initiative forward. leadership is not born into someone, or granted by top-down organizations--where everyone fits nicely in a box on some org-chart hanging on the wall--but simply belongs to she/he who is running the fastest. so my suggestion would be to let your frustration and passion turn into something positive. put together some testing framework suggestions, work with developers to setup qa and staging environments, write detailed explanations of required unit tests and work with developers to push those changes..whatever it takes to realize your vision! I'ld wager that if you took up such an initiative with the same spirit you carry on this petty attack, you would be a significant part of what is sure to be the coming bitcoin revolution we all know is inevitable at some point. united, that time is now. divided, forget it!

Shaman
Atruk
Sr. Member
****
Offline Offline

Posts: 369



View Profile

Ignore
March 12, 2013, 06:34:11 AM
 #84

BDB shouldn't even be part of the spec, the spec should abstract the actual database implementation details and just maybe talk about whether it should have atomic transactions, whether we should be able to roll those back, under what circumstances to roll than back and so on.

Enshrining some bug in some particular implementation of "database back end" should be anathema, our spec should basically be telling us "BDB isn't up to spec, don't use versions of it that aren't able to perform as we need them to".


This. So much this. Dublin Core and RDF/RDA container formats are excellent examples of standards that in all of their lenitive documentation provide an example of moving the database details out of the software implementation.

1DRNiHyAVRRiWJ5jWbnqgatritzQrrZKqw
jgarzik
Staff
Hero Member
*****
Offline Offline

Posts: 2498


View Profile

Ignore
March 12, 2013, 06:38:36 AM
 #85

It is always entertaining to watch non-contributors opine about completely obvious solutions that the devs are silly to have overlooked.

The interesting thing about bitcoin is its organic nature.  The bitcoin codebase, warts and all, was dumped into the Internet's collective lap.  Reality does not give anyone a chance to pause, wait for a specification to be polished, to wait for every single edge case to be tested (if that were even possible), etc.

Almost half a billion dollars in market cap, and the dev team is still largely unpaid volunteers, trailing behind events, cleaning up the messes reality leaves behind.


Jeff Garzik, bitcoin core dev team

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
jgarzik
Staff
Hero Member
*****
Offline Offline

Posts: 2498


View Profile

Ignore
March 12, 2013, 06:41:23 AM
 #86

BDB shouldn't even be part of the spec, the spec should abstract the actual database implementation details and just maybe talk about whether it should have atomic transactions, whether we should be able to roll those back, under what circumstances to roll than back and so on.

Enshrining some bug in some particular implementation of "database back end" should be anathema, our spec should basically be telling us "BDB isn't up to spec, don't use versions of it that aren't able to perform as we need them to".


This. So much this. Dublin Core and RDF/RDA container formats are excellent examples of standards that in all of their lenitive documentation provide an example of moving the database details out of the software implementation.

This idea is from an alternate world where you don't have to worry about breaking existing users' software and data to the point that they cannot spend their own money.

Bug-for-bug compatibility is not a choice made joyfully and willingly.

Engineers always prefer a clean slate, a clean interface.  That works here, only with a little help from science fiction's time machines.


Jeff Garzik, bitcoin core dev team

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 06:43:49 AM
 #87

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

That would be correct. It's a huge issue.
It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?

Sez MP:

Quote
I am willing to help, both by providing funding and by consulting pro bono on things I might have a clue about. These often enough are not coding, as I'm not a programmer. Nevertheless I would gladly strive to help avoid the sorts of strategic mistakes we've seen at work so far here.

I don't think this would necessarily constitute a lead role, and moreover if we focus on getting things right rather than propping egos and stroking issues leading might not even be so desperately needed. Let sense lead, not common but actual sense.

Maybe it's time to do a headcount, start a project... specified Bitcoin is certainly better than code-centralized Bitcoin.

shamaniotastook
Jr. Member
**
Offline Offline

Posts: 27



View Profile

Ignore
March 12, 2013, 06:49:54 AM
 #88

BDB shouldn't even be part of the spec, the spec should abstract the actual database implementation details and just maybe talk about whether it should have atomic transactions, whether we should be able to roll those back, under what circumstances to roll than back and so on.

Enshrining some bug in some particular implementation of "database back end" should be anathema, our spec should basically be telling us "BDB isn't up to spec, don't use versions of it that aren't able to perform as we need them to".


This. So much this. Dublin Core and RDF/RDA container formats are excellent examples of standards that in all of their lenitive documentation provide an example of moving the database details out of the software implementation.

This idea is from an alternate world where you don't have to worry about breaking existing users' software and data to the point that they cannot spend their own money.

Bug-for-bug compatibility is not a choice made joyfully and willingly.

Engineers always prefer a clean slate, a clean interface.  That works here, only with a little help from science fiction's time machines.



jgarzik, i completely agree...i would be more inclined to take their criticisms seriously if they were actual contributors. but then again, i am not a contributor either (yet). Nevertheless, the core developers at least deserve the respect they've worked so hard to earn! None of this would even matter without them. i guess now is the time for the 'rats' to abandon ship, while the 'crew' works to right the ship and keep her afloat! Smiley
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 06:53:20 AM
 #89

This idea is from an alternate world where you don't have to worry about breaking existing users' software and data to the point that they cannot spend their own money.

Bug-for-bug compatibility is not a choice made joyfully and willingly.

Engineers always prefer a clean slate, a clean interface.  That works here, only with a little help from science fiction's time machines.

It's ok Jeff, if this new thing will have to be the Real Bitcoin then this new thing WILL be the Real Bitcoin.

Point blank: money will never tolerate the sort of crap that has been pouring out of devtroop for the past while. I don't care you(*)'ve been dorking around with it for years and nobody told you it's wrong, that doesn't make it right, that just makes the little coven irrelevant enough.

If current Bitcoin can't be made into good Bitcoin then sucks for current Bitcoin, it is no different from Novacoin or whatever flavor of the week failed altchain.

(*) Impersonal you. Very, very impersonal you. As in, I'm not talking about you (and I'm not talking about Gavin - in fact, you know who I'm talking about).

markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 12, 2013, 07:19:46 AM
 #90

It's ok [you], if this new thing will have to be the Real Bitcoin then this new thing WILL be the Real Bitcoin.

[...SNIP...]

(*) Impersonal you. Very, very impersonal you. As in, I'm not talking about you (and I'm not talking about Gavin - in fact, you know who I'm talking about).

Thank you. I do not think I am actually far afield from Gavin, as I am pretty sure I have read him and/or other core devs discussing blockchain validator tools each of which would validate a certain range (by "height") of blocks.

In other words, no time machine going back and changing the historical past, just no repeating of the errors of the past in the future.

Basically the spec that tells us certain configurations, versions or implementations of BDB are not up to spec would be the spec for the new thing, the Real Bitcoin. The fact that the Satoshi node wasn't up to that spec gets enshrined not in the historically non-normative block-creation spec/code going forward but, rather, in the normative "validate a certain period of blockchain history's blocks" blockchain-checkers that I read some core devs discuss once upon a time.

An RFC could comment on details where certain builds of the Satoshi client on certain platforms failed to meet the new thing spec, and block heights could be targetted for the block height at which such builds will be orphaned, unsupported, deprecated, unable to function as part of "the Real Bitcoin" aka the new thing from that point on.

This is all old news / old ideas to Gavin et al I am pretty darn sure, which is why I am not in a panic over block sizes nor was in a panic yesterday evening over certain builds of Berkely DB on certain platforms in certain builds of the Satoshi node failing to perform to [ex]spec[tation].

So nyah nyah nyah circle jerk time group hugs for the geeks and techies, sorry if the PR folk aren't into that. Smiley

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
TradeFortress
Hero Member
*****
Offline Offline

Posts: 1625


Web developer | Also check out btcinvest!


View Profile

Ignore
March 12, 2013, 07:24:38 AM
 #91

SOMEHOW? Private keys? They're all on your client and are never transferred anywhere else.

Read up on http://en.wikipedia.org/wiki/Side_channel_attack ...
It's practically impossible for that to happen unless you have access to the hardware. In which case, your wallet is screwed.

Bitcoin does not transfer the private keys anywhere, you also do not know when someone is making a transaction, only when someone pushes a transaction.

makomk
Hero Member
*****
Online Online

Posts: 919


View Profile

Ignore
March 12, 2013, 12:44:54 PM
 #92

It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?
You really, really don't get it. We can't have a protocol spec becasue the existing client has a whole bunch of unspecified and unintended behaviour that no-one knows about, and any divergence from that behaviour by any major implementation will result in fiascos like this one. This problem could just as easily have been caused by a independent third-party implementation of the client. The developers have been finding and documenting all the corner cases as thoroughly as possible, but some of them are - like this one - really subtle and hard to spot. I'm not sure anyone's managed to fully work out the circumstances under which 0.7 will fail to accept a block due to this bug.

Quad XC6SLX150 Board: 860 MHash/s or so.
SIGS ABOUT BUTTERFLY LABS ARE PAID ADS
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 02:44:54 PM
 #93

The interesting thing about bitcoin is its organic nature.  The bitcoin codebase, warts and all, was dumped into the Internet's collective lap.  Reality does not give anyone a chance to pause, wait for a specification to be polished, to wait for every single edge case to be tested (if that were even possible), etc.

I'm not a coder but even I know this. It is what it is. Whoever wrote the code wrote it as proof of concept and then they went back and explained what they did. That's Bitcoin, like or not.

I have to say you all are very patient in the face of the spoiled brat brigade that are yelling for you all to modify their hot rod while the mechanics marvel at how its staying on the road in the first place.

"The synonym of usury is ruin." -Samuel Johnson
coqui33
Jr. Member
**
Offline Offline

Posts: 63



View Profile WWW

Ignore
March 12, 2013, 04:01:06 PM
 #94

MPOE-PR: Please do think from what I posted above that I defend the decision to forcibly accept the 0.7 fork and abandon the 0.8 fork, in violation of the bitcoin protocol's founding principle that greater hashing power always wins a dispute. Nobody asked me, of course, since I am neither developer nor mining pool manager. But as I see it, the final decision had two strong drawbacks and one weak upside.

The first strong drawback is that the decision forced a patch on clean efficient code (0.8 ) to conform to buggy slow code (0.7). In my experience this is never a good idea over the long pull.

Second, the decision burned up developers' political influence. A handful of developers used their deservedly high community respect to force a decision on the 0.8 miners. So be it. But the next emergency will see developer influence greatly reduced in consequence.

The weak upside? The decision prevented thousands of 0.7 users suffering crashes as their wallets choked on the offending block. This would have forced users around the world to stop dithering and upgrade to 0.8 immediately. So? What would have been wrong with that?

Armed Citizens and the Law -- NRA-certified firearms instructor
behindtext
Jr. Member
**
Offline Offline

Posts: 28


View Profile

Ignore
March 12, 2013, 04:10:59 PM
 #95

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation
This was actually a good example of something a spec wouldn't help (though would still be good to have). The inconsistent behavior here arose out of 0.8 not faithfully implementing some implicit behavior in BDB. The behavior in question is not anywhere in the Bitcoin code itself, nor is it visible at the interface of BDB and Bitcoin.  If there were a spec it would make no mention of it— and yet the network would be broken all the same.

The key thing is that in a distributed consensus system the most important definition of right is "consistent", this is paramount to all other concerns. A spec is helpful to the extent that it makes it easier to achieve a bit identical consistent behavior in the validation of blocks across all nodes, but because the spec itself can't be executed a spec can never guarantee consistency, at least not in the real world. (well, unless the spec is code— which is effectively what we have, for worse or better)


I respectfully disagree.  

A real protocol specification would enable a whole ecosystem of alternative and interoperable implementations to appear in Scala, Java, Go, C, etc.  

These implementations would NOT use the same flawed 3rd party libraries and there would be a real diversity in Bitcoin land, instead of the monoculture of C++ with all of its "magic" and "folklore".

Once no individual implementation had large enough fraction of the hash rate, then such forks would NOT occur, instead, bugs in a given implementation would only affect some miners, merchants & users but the chain would be just fine.

Let us hope and pray that eventually there will be some effort ( funded perhaps by the Bitcoin Foundation ) to extract and publish such a spec from the C++ hairball formal enough for viable alternative implementations to appear and to interoperate.


Cheers ...

suffice it to say there are hella layering violations in bitcoind and that is *bad* for bugs. can't really blame the devs tho, unless they helped write the original client from whence they inherited said issues.
jgarzik
Staff
Hero Member
*****
Offline Offline

Posts: 2498


View Profile

Ignore
March 12, 2013, 04:20:32 PM
 #96

Second, the decision burned up developers' political influence. A handful of developers used their deservedly high community respect to force a decision on the 0.8 miners. So be it. But the next emergency will see developer influence greatly reduced in consequence.

Read the chat logs before speaking about topics of which you know little.

The miners were not "forced" to do anything.  They could have chosen to stay on the 0.8 side of the fork.

Each miner (really, pool operator) votes with their collective hash power, deciding whether or not to support a mining-related decision like this.


Jeff Garzik, bitcoin core dev team

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Posts: 9263



View Profile

Ignore
March 12, 2013, 04:21:28 PM
 #97

in violation of the bitcoin protocol's founding principle that greater hashing power always wins a dispute.

It was never a founding principal for greater hashing power to resolve hard forks.  Hard forks by definition can't EVER be resolved by hashing power.  If a single node remains on an incompatible fork it exists as a parallel implementation of Bitcoin.  Creating a precedent for using hashing power to fork the network is horribly dangerous and will lead to intentionally putting bugs into the codebase to force a fork for profit.

Quote
The decision prevented thousands of 0.7 users suffering crashes as their wallets choked on the offending block. This would have forced users around the world to stop dithering and upgrade to 0.8 immediately. So? What would have been wrong with that?

You are completely uninformed.  v0.7 nodes didn't crash they simply rejected the block.  The risk is that v0.7 nodes would be vulnerable to attacks by double spends, 51% attacks and accepting newly generated coins from the incompatible v0.7 generation blocks.

The rational for rolling back to v0.7 was to prevent massive chaos, and loss of confidence and scammers and fraudsters looted the users of running older nodes.  Nobody is saying we will remain on BDB forever but the transistion can be better managed.

A v0.81 can be released which uses the new db format but prevents incompatible blocks.  older version users can be strongly encouraged to upgrade to the new version and warned of potential risks in staying with incompatible older version.  Where a vast super majority (not of miners but of ALL stakeholders, users, exchanges, merchants, service providers) are on the new platform a final critical warning can be released notifying users of older version they face significant risk of being forked away if they don't upgrade and then the incompatible block rules can be introduced.

TL/DR a planned transition instead of a "fork it and if people get fucked in the chaos, well too bad" attitude.  Which do you think will destroy trust in the Bitcoin network?

FastCash4Bitcoins No Exchanges; no Excuses; just Fast Payouts.  Over 275,000 BTC purchased.  (Support)
bullioner
Jr. Member
**
Offline Offline

Posts: 98


View Profile

Ignore
March 12, 2013, 04:38:15 PM
 #98

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation
This was actually a good example of something a spec wouldn't help (though would still be good to have). The inconsistent behavior here arose out of 0.8 not faithfully implementing some implicit behavior in BDB. The behavior in question is not anywhere in the Bitcoin code itself, nor is it visible at the interface of BDB and Bitcoin.  If there were a spec it would make no mention of it— and yet the network would be broken all the same.

The key thing is that in a distributed consensus system the most important definition of right is "consistent", this is paramount to all other concerns. A spec is helpful to the extent that it makes it easier to achieve a bit identical consistent behavior in the validation of blocks across all nodes, but because the spec itself can't be executed a spec can never guarantee consistency, at least not in the real world. (well, unless the spec is code— which is effectively what we have, for worse or better)


I respectfully disagree.  

A real protocol specification would enable a whole ecosystem of alternative and interoperable implementations to appear in Scala, Java, Go, C, etc.  

These implementations would NOT use the same flawed 3rd party libraries and there would be a real diversity in Bitcoin land, instead of the monoculture of C++ with all of its "magic" and "folklore".

Once no individual implementation had large enough fraction of the hash rate, then such forks would NOT occur, instead, bugs in a given implementation would only affect some miners, merchants & users but the chain would be just fine.

Let us hope and pray that eventually there will be some effort ( funded perhaps by the Bitcoin Foundation ) to extract and publish such a spec from the C++ hairball formal enough for viable alternative implementations to appear and to interoperate.
Cheers ...

A agree with you, but based on statements by Jeff, Gavin, and Mike, this will not happen.  If we want a well specified crypto currency with a wealth of implementations, we are going to have to create it.  Bitcoin is not that, and it is not going to become that.
bullioner
Jr. Member
**
Offline Offline

Posts: 98


View Profile

Ignore
March 12, 2013, 04:39:14 PM
 #99

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with either the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.  It was a landmine. 

Does this not argue for a diversity of implementations with different underlying 3rd party libraries ? Clearly it does. But this cannot happen until and unless there is actually a formal-enough spec to enable those to be written w/o ever "groking" all that C++ folklore, which is a moving target anyways ...

Not going to happen within Bitcoin.  If we want such a thing, we are going to have to create it, and it is not Bitcoin.
bullioner
Jr. Member
**
Offline Offline

Posts: 98


View Profile

Ignore
March 12, 2013, 04:42:55 PM
 #100


I would like to also point out that the alexkravets idea re specification is sound. The only way forward for the dev team, provided they wish to preserve a shred of dignity, is a. immediately start work on specification, which is the only priority, and release no further versions until such specification is complete and b. immediately start work on removing all magic numbers and assorted code smelliness from their UNreference implementation of crap, and not release any further version before they've released a clean one.

In that order.

Whoa... All of this... Agreement...

Nope, not going to happen in Bitcoin.  And that will be its downfall.  The well specified crypto currency will have long term advantages that could well ensure it wins in the market, despite Bitcoin's first mover advantage.
bullioner
Jr. Member
**
Offline Offline

Posts: 98


View Profile

Ignore
March 12, 2013, 04:46:59 PM
 #101

It is always entertaining to watch non-contributors opine about completely obvious solutions that the devs are silly to have overlooked.

The interesting thing about bitcoin is its organic nature.  The bitcoin codebase, warts and all, was dumped into the Internet's collective lap.  Reality does not give anyone a chance to pause, wait for a specification to be polished, to wait for every single edge case to be tested (if that were even possible), etc.

Almost half a billion dollars in market cap, and the dev team is still largely unpaid volunteers, trailing behind events, cleaning up the messes reality leaves behind.

There are many examples of protocols which only became specified after an implementation as in widespread use.  Look at HTTP, look at ssh, look at OpenPGP.  These all have organic ecosystems of implementations, and were all specified after an implementation went into widespread use.  It is simply part of the maturation process.  Crypto currency is no different.  Lacking a spec actually prevents the "organic" nature you speak of, the same way that any other single-implementation unspecified "protocol" does.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 04:47:47 PM
 #102

It's practically impossible for that to happen unless you have access to the hardware. In which case, your wallet is screwed.

Bitcoin does not transfer the private keys anywhere, you also do not know when someone is making a transaction, only when someone pushes a transaction.

Isn't there some website somewhere you should be fixing for 27 Bitcoins?

You really, really don't get it. We can't have a protocol spec becasue the existing client has a whole bunch of unspecified and unintended behaviour that no-one knows about, and any divergence from that behaviour by any major implementation will result in fiascos like this one. This problem could just as easily have been caused by a independent third-party implementation of the client. The developers have been finding and documenting all the corner cases as thoroughly as possible, but some of them are - like this one - really subtle and hard to spot. I'm not sure anyone's managed to fully work out the circumstances under which 0.7 will fail to accept a block due to this bug.

No, it is you that doesn't (really, really) get it. What you're displaying is precisely the sort of idiocy this thread was named for.

No matter how inconvenient it may be on the short term, for a plethora of reasons chief among which is the fact that some IDIOTS lose the jealously-preserved mystique of being "they who understand the nonsense they created for the purpose of having something only they can understand", specification HAS TO BE DONE.

Do you grasp this? Bitcoin will never exist as a toy for five idiots. You will never get to matter inasmuch as what you want to do is have this little black box the world reveres that only you are allowed to peer inside. This is not how the world works, currently (and past about 1800 or so). This is not how the world should work, either.

Specifying the code does not "result in fiascoes like this one". Your idiotic codebase results in in fiascoes like this one. Specification is the way out of it, and most importantly specification is the way out of having you idiots create fiascoes like this one randomly, one at a time, for the unforeseeable future.

Incredible how stupid self-centered people can be, seriously now.

I'm not a coder but even I know this. It is what it is. Whoever wrote the code wrote it as proof of concept and then they went back and explained what they did. That's Bitcoin, like or not.

I have to say you all are very patient in the face of the spoiled brat brigade that are yelling for you all to modify their hot rod while the mechanics marvel at how its staying on the road in the first place.

Enough with the nonsense. You are missing the point by about a mile.

MPOE-PR: Please do think from what I posted above

I do not really know what to make of your reply above. In any case, it'd seem consensus is emerging that indeed the devs are idiots (should you wish to more politely define that as "strategically myopic" or whatever other phrase). It'd seem the consensus also is emerging that indeed the way forward is,

Quote
A. immediately start work on specification, which is the only priority, and release no further versions until such specification is complete

B. immediately start work on removing all magic numbers and assorted code smelliness from the UNreference implementation of crap, and not release any further version before a clean implementation was released

The order is important, all that's left is for the devs to obey. Which is exactly what happens, in the real world, among sane people and where actual developers are involved. If we have a brigade of spoiled brats pretending to be devs here then indeed we have a problem.

A agree with you, but based on statements by Jeff, Gavin, and Mike, this will not happen.  If we want a well specified crypto currency with a wealth of implementations, we are going to have to create it.  Bitcoin is not that, and it is not going to become that.

As it happens, nobody asked them.

bullioner
Jr. Member
**
Offline Offline

Posts: 98


View Profile

Ignore
March 12, 2013, 04:53:23 PM
 #103


This. So much this. Dublin Core and RDF/RDA container formats are excellent examples of standards that in all of their lenitive documentation provide an example of moving the database details out of the software implementation.

This idea is from an alternate world where you don't have to worry about breaking existing users' software and data to the point that they cannot spend their own money.

Bug-for-bug compatibility is not a choice made joyfully and willingly.

Engineers always prefer a clean slate, a clean interface.  That works here, only with a little help from science fiction's time machines.

No, this is not about it being "clean".  Obviously if you specify a protocol after it's gone into widespread use, you have to consider compatibility issues.  The specification can be as complex as it needs to be to accommodate the mess, of course.

A protocol can still evolve from unspecified to specified if it's not a clean slate.  Many have.  Most of the successful protocols in use on the Internet evolved through a design phase to semi widespread use, then were specified and really took off.  I don't know of any long term successful protocols that remained unspecified for long.  Maybe some of the Adobe proprietary crap, but I assume that will die off soon.  Please learn a lesson from the hundreds of successful protocols in use today.  You are not special.  Yes, I know.  No, you're not special.
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 04:59:35 PM
 #104

Enough with the nonsense. You are missing the point by about a mile.

The point: Someone's going to throw a fit until the perfect cryptocurrency is developed by someone else because Bitcoin sucks so much.

No, I think many can see the point of this thread.

"The synonym of usury is ruin." -Samuel Johnson
justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 05:03:40 PM
 #105

I've suggested this before but maybe it's worth mentioning again.

Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.

Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.

I don't have enough programming skill to do this, but I'd donate to anyone who does.

Peter Lambert
Sr. Member
****
Offline Offline

Posts: 351

mentis supra materia


View Profile

Ignore
March 12, 2013, 05:13:15 PM
 #106

What's stopping your company from hiring one developer to do nothing but code cleanups and submitting them to GitHub? There's nothing centralized about that.

Because cleanups would require very deep reaching changes. If we hired a cleanup dev his #1 task would be "find and remove all magic numbers anywhere in the codebase".

You keep saying you want to get rid of magic numbers, how would you limit the size of blocks? Or would you just have unlimited block sizes?

This space for rent. PM for details.
coqui33
Jr. Member
**
Offline Offline

Posts: 63



View Profile WWW

Ignore
March 12, 2013, 05:19:15 PM
 #107

Read the chat logs before speaking about topics of which you know little.
I read the logs. Better yet: I was present, observing on #bitcoin-dev from the start of the incident until about 2 am EDT this morning.

The miners were not "forced" to do anything.  They could have chosen to stay on the 0.8 side of the fork. Each miner (really, pool operator) votes with their collective hash power, deciding whether or not to support a mining-related decision like this.

I agree. Perhaps "forced" had the wong connotation. It was obviously persuasion, not coercion. My point is merely that you and the other respected developers used your influence to persuade the 0.8 miners to abandon the 0.8 fork. I simply suggest that this consumed some of your store of influence for future emergencies.

v0.7 nodes didn't crash they simply rejected the block.  The risk is that v0.7 nodes would be vulnerable to attacks by double spends, 51% attacks and accepting newly generated coins from the incompatible v0.7 generation blocks. ...
Not calling this horrible outcome for 0.7 users a "crash" is semantics. Call it what you will. It would have forced 0.7 users to upgrade immediately.

TL/DR a planned transition instead of a "fork it and if people get fucked in the chaos, well too bad" attitude.  Which do you think will destroy trust in the Bitcoin network?
Yes. I heard you make the same argument last night. The answer is not cut and dried. Should we "fuck" the users a little bit now (by making them upgrade immediately) or should we patch clean efficient code (0.8 ) to protect buggy slow code (0.7), thus risking a more serious "fucking" in the future?

Do not misunderstand. In the heat of the moment I might well have made the same decision as you. But decisions have consequences: (1) Bad code was protected and (2) influence born of community respect was spent. By being aware of those consequences, you might be better prepared to guard against their potential repercussions.

Armed Citizens and the Law -- NRA-certified firearms instructor
smtp
Jr. Member
**
Offline Offline

Posts: 90


View Profile

Ignore
March 12, 2013, 05:22:56 PM
 #108

Sorry, I can't resist. Such a good pattern/model/submission:
ladies and gentlemen:

this is why the "bankers" make a LOT of money. they are EXTREMELY good at what they do

Manipulate governments and markets, spread disinformation through the media and rig the currency to their benefit?

Ya, bankers are experts.

Well, our current bitcoin-world has also their "bankers", but they are called "miners".  Grin

Whether they manipulate governments and markets, spread disinformation through the media, ... I can't judge (and personally I don't believe it)., but surely they are experts at their basic job:
They can be specified/defined for validation of transcations and get paid for this -- exactly like real-world bankers -- and monopolize this work! Undecided

smtp
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 05:31:04 PM
 #109

They can be specified/defined for validation of transcations and get paid for this -- exactly like real-world bankers -- and monopolize this work! Undecided

Anyone can be a miner. Rothschild and cohorts are born to their monopoly.

"The synonym of usury is ruin." -Samuel Johnson
smtp
Jr. Member
**
Offline Offline

Posts: 90


View Profile

Ignore
March 12, 2013, 05:36:22 PM
 #110

They can be specified/defined for validation of transcations and get paid for this -- exactly like real-world bankers -- and monopolize this work! Undecided

Anyone can be a miner. Rothschild and cohorts are born to their monopoly.
The first sentence is as realistic as anyone can become a banker! *LOL*

smtp
markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 12, 2013, 05:36:30 PM
 #111

I think the job meant was pool operator, not miner as in, often enough, a mere hasher who does not even see the blocks being hashed. Such "miners" are more like bank tellers or even just folks who host an ATM machine for profit than actual bankers.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
Severian
Hero Member
*****
Offline Offline

Posts: 983



View Profile WWW

Ignore
March 12, 2013, 05:40:18 PM
 #112

The first sentence is as realistic as anyone can become a banker!

That depends on whether or not you actually  consider the local branch manager as a banker. He's just an errand boy for bankers. Even Jamie Dimon is just a glorified boy Friday for the those that actually control the issuing of currency and credit in the US.

"The synonym of usury is ruin." -Samuel Johnson
DeathAndTaxes
Donator
Hero Member
*
Offline Offline

Posts: 9263



View Profile

Ignore
March 12, 2013, 05:47:40 PM
 #113

Yes. I heard you make the same argument last night. The answer is not cut and dried. Should we "fuck" the users a little bit now (by making them upgrade immediately) or should we patch clean efficient code (0.8 ) to protect buggy slow code (0.7), thus risking a more serious "fucking" in the future?

Do not misunderstand. In the heat of the moment I might well have made the same decision as you. But decisions have consequences: (1) Bad code was protected and (2) influence born of community respect was spent. By being aware of those consequences, you might be better prepared to guard against their potential repercussions.

You are intentionally ignoring the real consequence.  It isn't that users are "forced to upgrade".  Devs have recommended security upgrades in the past.   It is that users who didn't upgrade (possibly because they are unaware) would have been easily "robbed".  Downgrading v0.8 has no lasting security implications.  Allowing the network to remain forked presented a real threat to the security of user's transactions.  It would be asinine to chose anything over the security of the network.  The news of this fork has been relatively muted.  Can you imagine if the decision to force through v0.8 had been made and thousands of users were robbed for millions of dollars worth of Bitcoins in 51% attack, accepting bogus generated coins, and even trivial no-hash power double spends. 

Which presents a real THREAT to the trust in the network.   The need to upgrade or lack thereof is a strawman.   My guess is you will now make another strawman attack about needing to upgrade as you have done twice now.  Don't worry I won't see it so you an "winz the internets".

FastCash4Bitcoins No Exchanges; no Excuses; just Fast Payouts.  Over 275,000 BTC purchased.  (Support)
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 06:02:29 PM
 #114

What's stopping your company from hiring one developer to do nothing but code cleanups and submitting them to GitHub? There's nothing centralized about that.

Because cleanups would require very deep reaching changes. If we hired a cleanup dev his #1 task would be "find and remove all magic numbers anywhere in the codebase".

You keep saying you want to get rid of magic numbers, how would you limit the size of blocks? Or would you just have unlimited block sizes?

This issue has already been discussed, and consensus has already been reached.

I agree. Perhaps "forced" had the wong connotation. It was obviously persuasion, not coercion. My point is merely that you and the other respected developers used your influence to persuade the 0.8 miners to abandon the 0.8 fork. I simply suggest that this consumed some of your store of influence for future emergencies.

Let's elaborate on that a little. Bitcoin's #1 pool is trading while insolvent at the present time because it just got hit by the double whammy of:

1. Oh, you made the mistake of updating to our most recent version? Well here you go, redownload the chain, pay submitted work as if difficulty were negative for a while. That's what hot wallets and autopayments are for right?

2. Oh, you made the mistake of updating to our most recent version? Well...revert. Oh, you need an old chain because the new chain you just paid half your house for is no good? Awww. Here, lose 16 blocks on top of the 1.1k BTC you lost before. We really want you to lose the whole house, not just half of it.

The entire "miners vote" is a sham and a total red weasel currently. Miners don't vote, miners just sheepishly follow around because "devs say so". And incidentally, a willingness to do the soviet thing and pretend this sort of crap is covered by "popular vote" when no actual voting took place speaks volumes as to the moral integrity of the pretenders. Ugly stuff.

If the miners had half a clue they'd have told Idiot Co-op exactly where to stuff it, and here's the beauty of it: with the arrival of ASICs and their significant capital cost, the odds that the sort of feelgood ninnies currently involved in mining will still be around are nil.

This is what money does, it shakes out the deadwood and culls the herd. Next time you do something because "Mike" said you should may very well be the last time you get to do anything. That little tidbit isn't too likely to pass unnoticed seeing how universal the conservation instinct is.

In other words: next time this happens devteam is gone, for the simple reason that miners will not revert, or even talk to those "devs" again.

bitcoinBull
Hero Member
*****
Offline Offline

Posts: 1080



View Profile

Ignore
March 12, 2013, 06:02:55 PM
 #115

That is not correct.  v0.7 nodes accepted a 1MB block on testnet.  The issue was more complex then just the size of the block.  By the protocol the block which was rejected by some nodes SHOULD have been accepted.  The 250kb soft limit was simply a default for block construction.  Even with it in place nodes should have accepted properly constructed blocks up to the 1MB limit.  It also appears not all v0.7 nodes were affected.  Some accepted the problem block and some didn't.  The defect/limit in BDB wasn't documented and didn't occur in all versions/platforms.   It appears the number of transactions being changed as a result of the block validation crossed some "magic code" not in the Bitcoin source code but undocumented in some implementations of BDB.

v0.7 reliance on BDB caused it to be fundamentally broken/flawed. Its actions weren't consistent with the documented protocol, the higher level source code, or anyone's understanding/expectation of what should have happened.   Nobody was saying/thinking oh yeah if you make a block with more than x transaction it will abort, cause a rollback, and result in a rejection.  It was a landmine.  

The problem was lack of a DB_CONFIG file in the bitcoin application directory. Without that file, BDB simply chose to use default settings. The default setting of 10000 for set_lk_max_locks is not enough to handle larger blocks with many transactions (inputs and outputs). Easy fix.

Protect your mtgox funds against common trojans. How to use 2-factor auth on mtgox, even without a smartphone
College of Bucking Bulls Knowledge
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 06:07:35 PM
 #116

The problem was lack of a DB_CONFIG file in the bitcoin application directory. Without that file, BDB simply chose to use default settings. The default setting of 10000 for set_lk_max_locks is not enough to handle larger blocks with many transactions (inputs and outputs). Easy fix.

Oh no, Berkeley is broken. How could you say Bitcoin Devs are just clueless? What heresy is this!

Take it to the BDB forums!

smtp
Jr. Member
**
Offline Offline

Posts: 90


View Profile

Ignore
March 12, 2013, 06:43:58 PM
 #117

I think the job meant was pool operator, not miner as in, often enough, a mere hasher who does not even see the blocks being hashed. Such "miners" are more like bank tellers or even just folks who host an ATM machine for profit than actual bankers.
Yes, the common/general "banker"-word can surely subdivided in many specific categories. Currently "miners" can't really, perhaps only into these 2 (raw miner, pool operator), but as longer as mining evolutes as more specific sub-work jobs will show up, like in bank-business, IMHO. Compare bitcoin-age with bank-business, say, 1000 years ago. :-)
But nevertheless, the general/principle equivalence/relation "banker" <--> "miner" holds perfectly. Probably, the miner-community likes to avoid the word "banker" for themselves because of psychological reasons. Wink
smtp
smtp
Jr. Member
**
Offline Offline

Posts: 90


View Profile

Ignore
March 12, 2013, 07:02:17 PM
 #118

Yes. I heard you make the same argument last night. The answer is not cut and dried. Should we "fuck" the users a little bit now (by making them upgrade immediately) or should we patch clean efficient code (0.8 ) to protect buggy slow code (0.7), thus risking a more serious "fucking" in the future?

Do not misunderstand. In the heat of the moment I might well have made the same decision as you. But decisions have consequences: (1) Bad code was protected and (2) influence born of community respect was spent. By being aware of those consequences, you might be better prepared to guard against their potential repercussions.

You are intentionally ignoring the real consequence.  It isn't that users are "forced to upgrade".  Devs have recommended security upgrades in the past.   It is that users who didn't upgrade (possibly because they are unaware) would have been easily "robbed".  Downgrading v0.8 has no lasting security implications.  Allowing the network to remain forked presented a real threat to the security of user's transactions.  It would be asinine to chose anything over the security of the network.  The news of this fork has been relatively muted.  Can you imagine if the decision to force through v0.8 had been made and thousands of users were robbed for millions of dollars worth of Bitcoins in 51% attack, accepting bogus generated coins, and even trivial no-hash power double spends.  

Which presents a real THREAT to the trust in the network.   The need to upgrade or lack thereof is a strawman.   My guess is you will now make another strawman attack about needing to upgrade as you have done twice now.  Don't worry I won't see it so you an "winz the internets".

Hmm .. the bug (or do you call it a hidden feature?)  effectively touched bitcoin-miners and not directly(!) bitcoin-users. So the other obvious solution, which Pieter also suggested at first, was to push the longer chain, the one which grew faster and not to conceal/press effectively bitminers to do an effectively 51%-attack for the "good" of the network on this chain, because the 0.7-fork is "correct". This dubious politic is highly questionable, IMHO. On the other hand, effectively convincing/forcing miners to switch to 0.8 would surely have had the advantage of a much more equal code base for almost all miners afterwards.

Appendum: Again a very important issue, which reflects a real-time behaviour is: how can one estimate which approach (if we restrict us two only these 2 alternatives) will succeed significant earlier?

smtp
sturle
Sr. Member
****
Offline Offline

Posts: 415


View Profile

Ignore
March 12, 2013, 07:22:05 PM
 #119

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.
It's actually fucking amazing that this is first MAJOR bug in 4 years.
AND, as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all!  It is in some versions of BDB on some platforms.  The developers wisely chose a better database for 0.8, but unfortunately the bug manifested itself in a bad way (it could have been worse, e.g. if the bug in BDB made remote code execution or altering old blocks possible) before almost all nodes had upgraded.

AFAIK none of the current developers are involved in BDB development, and BDB was chosen by Satoshi.  Satoshi made a few errors, but I wouldn't call him an idiot.  Shut up or do a better job.
justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 07:25:16 PM
 #120

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.
It's actually fucking amazing that this is first MAJOR bug in 4 years.
AND, as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all!  It is in some versions of BDB on some platforms.  The developers wisely chose a better database for 0.8, but unfortunately the bug manifested itself in a bad way (it could have been worse, e.g. if the bug in BDB made remote code execution or altering old blocks possible) before almost all nodes had upgraded.
I've seen at least one thread claiming that it's not a bug in BDB as much as a misconfiguration.

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 07:34:54 PM
 #121

It is always entertaining to watch non-contributors opine about completely obvious solutions that the devs are silly to have overlooked.

The interesting thing about bitcoin is its organic nature.  The bitcoin codebase, warts and all, was dumped into the Internet's collective lap.  Reality does not give anyone a chance to pause, wait for a specification to be polished, to wait for every single edge case to be tested (if that were even possible), etc.

Almost half a billion dollars in market cap, and the dev team is still largely unpaid volunteers, trailing behind events, cleaning up the messes reality leaves behind.

I am not sure how to read your post.  Are you suggesting the current state of affairs is a good thing or a bad thing ?  Obviously the original Satoshi client was a fact on the ground.  And "reality" hasn't given anybody a chance to pause, but can we not take a small time out now and actually define a 1.0 spec and THEN implement a backwards compatible version from 0.8 today to that 1.0 ?

It's not like every pull request on GitHub is a do-it-now-or-bitcoin-dies urgent fix, actually most of them are trying to refactor, fix & alter the existing single implementation, and some like pruning and bloom filters add huge new features with *more* latent semantics sprinkled around the C++ instead of being in the spec.

I hope the gods on mount Bitcoin Foundation are listening once in a while, but Bitcoin's monoculture of a single "magical" C++ implementation whose code serves as the spec cannot go on forever.

I wanted to create an independent implementation from scratch in Scala, but soon realized that not only there wasn't enough documentation for protocol messages on the wiki, but worse, their semantics were constantly moving targets, potentially with every github pull request being committed.  At that point I gave up.

I haven't heard of a from scratch C-based libbitcoin library much lately ... not sure if its author also had to throw in the towel after a while ... that would just be sad.

Guys, the time for heroics is great, but if you want Bitcoin to be Money of IP (as it's being advertised) then it has to be a network/message protocol spec that people can go away and implement in language X and interoperated with you.

In this Bitcoin will either follow in the successful tradition of TCP/IP, SMTP, HTTP, TLS, etc or it will be a series of heroic battles by "the community" to "save bitcoin" from future "genetic defects" found in its sole C++ implementation or one of third party libraries.

Cheers ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 07:44:11 PM
 #122

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation
This was actually a good example of something a spec wouldn't help (though would still be good to have). The inconsistent behavior here arose out of 0.8 not faithfully implementing some implicit behavior in BDB. The behavior in question is not anywhere in the Bitcoin code itself, nor is it visible at the interface of BDB and Bitcoin.  If there were a spec it would make no mention of it— and yet the network would be broken all the same.

The key thing is that in a distributed consensus system the most important definition of right is "consistent", this is paramount to all other concerns. A spec is helpful to the extent that it makes it easier to achieve a bit identical consistent behavior in the validation of blocks across all nodes, but because the spec itself can't be executed a spec can never guarantee consistency, at least not in the real world. (well, unless the spec is code— which is effectively what we have, for worse or better)


I respectfully disagree.  

A real protocol specification would enable a whole ecosystem of alternative and interoperable implementations to appear in Scala, Java, Go, C, etc.  

These implementations would NOT use the same flawed 3rd party libraries and there would be a real diversity in Bitcoin land, instead of the monoculture of C++ with all of its "magic" and "folklore".

Once no individual implementation had large enough fraction of the hash rate, then such forks would NOT occur, instead, bugs in a given implementation would only affect some miners, merchants & users but the chain would be just fine.

Let us hope and pray that eventually there will be some effort ( funded perhaps by the Bitcoin Foundation ) to extract and publish such a spec from the C++ hairball formal enough for viable alternative implementations to appear and to interoperate.
Cheers ...

A agree with you, but based on statements by Jeff, Gavin, and Mike, this will not happen.  If we want a well specified crypto currency with a wealth of implementations, we are going to have to create it.  Bitcoin is not that, and it is not going to become that.

If core developers are firm in this, i.e. their refusal to even entertain having a spec extracted from C++ warts and all, then we'll just have to live with sadness for a while ... until somebody like Ripple comes along and "does it right" ... we'll see how this goes ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 07:44:14 PM
 #123

AND, as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all!  It is in some versions of BDB on some platforms.

You are wrong. Devs'/devzombs' first reaction was that "BDB bug" because a. they are idiots and b. they think their shit doesn't stink.

Fact of the matter is, they just failed to configure the BDB. Because a.

Nice trying to hide behind the Jesus of your faith, but it won't wash.

And to add to #114 above, seems OKpay got swindled for 10k or so too.

How much money do you expect people to contribute to the "propping dev arrogance" fund? The unencrypted wallet cost millions. This thing costs however much. How much more is needed? How long are we going to hear "it's not our fault" and "Satoshi did it"?

smtp
Jr. Member
**
Offline Offline

Posts: 90


View Profile

Ignore
March 12, 2013, 07:44:58 PM
 #124

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.
It's actually fucking amazing that this is first MAJOR bug in 4 years.
AND, as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all!  It is in some versions of BDB on some platforms.  The developers wisely chose a better database for 0.8, but unfortunately the bug manifested itself in a bad way (it could have been worse, e.g. if the bug in BDB made remote code execution or altering old blocks possible) before almost all nodes had upgraded.
I've seen at least one thread claiming that it's not a bug in BDB as much as a misconfiguration.
It is a question of wording - if we assume everybody knows all facts: you may call it a bug in bitcoin, that the BDB was used misconfigured.

Anyway, no need to insult people here from the very beginning of the thread - but this seems also a characteristic of this bitcoin forum(s) that this is tolerated. :-(

smtp
cho
Jr. Member
**
Offline Offline

Posts: 46


Boar with me


View Profile

Ignore
March 12, 2013, 07:46:33 PM
 #125

[...]It'd seem consensus is emerging that indeed the devs are idiots (should you wish to more politely define that as "strategically myopic" or whatever other phrase). It'd seem the consensus also is emerging that indeed the way forward is,

As far I've read (which includes this whole thread of course), consensus is emerging that the devs are doing a good to very good job overall. You are the only one calling them idiots in this thread, which is wrong, insensitive, and counter-productive. Most of your comments let me think you have no idea what quality management is in software engineering, and what "0 defect" means in this field. You might wonder why Amazon cloud can be unreachable during a whole, why Gmail can lose mails and be unable to restore them from backups, and why NASA shuttles crash.
I would advise you to stop calling people names because they are not delivering that free unicorn to you.

1KEWxTkXPgfB9MdHJcfyoVnfHRnYEHQJPw
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 07:48:03 PM
 #126

I hope the gods on mount Bitcoin Foundation are listening once in a while, but Bitcoin's monoculture of a single "magical" C++ implementation whose code serves as the spec cannot go on forever.

I would say you grossly overestimate the importance of some irrelevant foundation thingee. It's a case of Rome, Alabama talking itself into the "center of Christian faith".

[...]It'd seem consensus is emerging that indeed the devs are idiots (should you wish to more politely define that as "strategically myopic" or whatever other phrase). It'd seem the consensus also is emerging that indeed the way forward is,

As far I've read (which includes this whole thread of course), consensus is emerging that the devs are doing a good to very good job overall. You are the only one calling them idiots in this thread, which is wrong, insensitive, and counter-productive. Most of your comments let me think you have no idea what quality management is in software engineering, and what "0 defect" means in this field. You might wonder why Amazon cloud can be unreachable during a whole, why Gmail can lose mails and be unable to restore them from backups, and why NASA shuttles crash.
I would advise you to stop calling people names because they are not delivering that free unicorn to you.

Then you need to learn to read.

And re "heroics": there were no heroics involved here. The in extremis forcing of a downgrade is not heroic. People doing it are not cool.

It is idiocy, and the people doing it were idiots. Yes, they had no choice. Guess why they had no choice, and guess who puts themselves in the situation of having no choice.

Let me make this perfectly clear: the current hard fork is the death of Bitcoin unless the consensus reached here (ie, no more bitcoin client releases until spec, first release code-cleaning release) is implemented exactly.

This is not up for discussion, it is a fact.

mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 12, 2013, 08:00:09 PM
 #127

MPOE-PR, what are you doing here? Why are you really here?

Has MPEx considered hiring "good" programmers to work on the bitcoin code?

Considered, yes. One problem is the centralization issue stemming from that approach. The one correct way to handle Bitcoin development is exactly as designed: independent devs doing it. The problem is that instead of doing it they spend their time opining on things that utterly ain't their business.

And did you ever pay these independant devs for fixing shit for you for free?
Are they your wage slaves so you can demand that they do work for you or anyone else?
Have you ever discussed your issues with the development team in a calm and adult manner?
Do you even have the capacity to understand what you ask of them? (your tone tells me you're oblivious)
How much further does your understanding of the problem go besides: "It's fucked up! fixitfixitfixitfixit!!@@!@!!!!" ?

And how would you consider devs being independend if you expect them to give in to your tantrums?
Reality is you need the devs and you have absolutely nothing to say about what they do or how they do it. That is why you come crying here on the forum to get souls for your case. Boehoe. You are turning a technical thing into a political thing. Which is quite ironic because it is exactly what you accuse the developers of. I wonder why you so readily wield tools that you want to deny others.

In any case, if you don't like bitcoin go make your own. Bitcoin does not need you. But you propably won't because you are enjoying the benefits that are made possible by the bitcoin development team and the community that emerged around the system?

As usual a lot of dumb arrogant shit packaged in expensive words.
 Roll Eyes
cho
Jr. Member
**
Offline Offline

Posts: 46


Boar with me


View Profile

Ignore
March 12, 2013, 08:01:49 PM
 #128

[...]It'd seem consensus is emerging that indeed the devs are idiots (should you wish to more politely define that as "strategically myopic" or whatever other phrase). It'd seem the consensus also is emerging that indeed the way forward is,

As far I've read (which includes this whole thread of course), consensus is emerging that the devs are doing a good to very good job overall. You are the only one calling them idiots in this thread, which is wrong, insensitive, and counter-productive. Most of your comments let me think you have no idea what quality management is in software engineering, and what "0 defect" means in this field. You might wonder why Amazon cloud can be unreachable during a whole, why Gmail can lose mails and be unable to restore them from backups, and why NASA shuttles crash.
I would advise you to stop calling people names because they are not delivering that free unicorn to you.

Then you need to learn to read.

And re "heroics": there were no heroics involved here. The in extremis forcing of a downgrade is not heroic. People doing it are not cool.

It is idiocy, and the people doing it were idiots. Yes, they had no choice. Guess why they had no choice, and guess who puts themselves in the situation of having no choice.

Let me make this perfectly clear: the current hard fork is the death of Bitcoin unless the consensus reached here (ie, no more bitcoin client releases until spec, first release code-cleaning release) is implemented exactly.

This is not up for discussion, it is a fact.

Or you need to learn to read. I'm not sure that sentence brings us anywhere.
Same thing with "This is not up for discussion, it is a fact". This sentence only serves to prove your lack of open-mindedness.

Why are you speaking about the word "heroics" ? Did I mention it ?
I still disagree with you about the devs being idiots, this mistake was human, and mistakes DO happen, whatever the amount of ressources and good will you throw at development.



1KEWxTkXPgfB9MdHJcfyoVnfHRnYEHQJPw
alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 08:02:34 PM
 #129

I've suggested this before but maybe it's worth mentioning again.

Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.

Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.

I don't have enough programming skill to do this, but I'd donate to anyone who does.

This would definitely be the first step out of the current insanity and finally bring some layering into the code base client UI === depends on ==> bitcoind but zero backward pointing dependencies.

This would be the first step on the long journey to the promised land of the BPS (Bitcoin Protocol Specification)

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
ikbrunel
Jr. Member
**
Offline Offline

Posts: 18


View Profile

Ignore
March 12, 2013, 08:03:51 PM
 #130

I endorse writing a specification over new client releases.
Timo Y
Staff
Hero Member
*****
Offline Offline

Posts: 812



View Profile

Ignore
March 12, 2013, 08:06:23 PM
 #131

MPOE-PR:

Irrespective of them being idiots or not, the bitcoin devs owe nothing to you.

Don't look a gift horse in the mouth. If you feel strongly that something needs to be done urgently, then start a Kickstarter campaign to hire a team of "real" developers to clean up the code and write a specification.
RodeoX
Hero Member
*****
Offline Offline

Posts: 1952


The revolution will be monetized!


View Profile

Ignore
March 12, 2013, 08:07:06 PM
 #132

This is like saying Garry Kasparov is a shitty chess player. Then saying "By the way, I don't know how to play chess."

Will work for bitcoin: 13dh6dNZ3FcXSnJRG8tBCUTvaaRaxgx7rn
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 08:19:42 PM
 #133

Let me take the opportunity to clarify some points of apparent confusion:

And did you ever pay these independant devs for fixing shit for you for free?

This question is malformed. If you are asking me whether they owe me, the answer is yes.

Are they your wage slaves so you can demand that they do work for you or anyone else?

Yes, they are. This is what being a developer means in this context: that you are a servant. A slave, if you prefer that terminology. One who obeys. An inferior. A steward. Nobody, politically speaking. I'm running out of alternative ways to put this, but I would hope you get the idea.

If someone is interested in becoming politically relevant, being part of the dev team is not only a waste of his time, it's a waste of everyone's time. That a number of the more socially inept kids are doing this (Amir Scarface Taaki, who has meanwhile thankfully been ejected, Weirdo Luke, Gregory Pointless Maxwell and on and on) doesn't make it workable. It just doesn't work.

If someone is interested in becoming rich, being part of the dev team is not only a waste of his time, but a waste of everyone's time. It's just not how it works. Being part of the dev team is being part of the slaves, the servants, the stewards, the however you'd call them. This abject social position does not entitle them to immunity for their fuck-ups in any case. You may dislike that, and that's fine, but your likes and dislikes have no power to change this world.

Have you ever discussed your issues with the development team in a calm and adult manner?

You are not entitled to place limitations on the manner of my discourse. The correct question to ask here is, MP recently published an article about the problems in Bitcoin. Have the developers read it and noted this fact?

Do you even have the capacity to understand what you ask of them? (your tone tells me you're oblivious
How much further does your understanding of the problem go besides: "It's fucked up! fixitfixitfixitfixit!!@@!@!!!!" ?)
And how would you consider devs being independend if you expect them to give in to your tantrums?

I would guess you probably haven't actually understood what's being discussed here at all. As a rule of thumb that may serve you well in the future: whenever things happen that don't make sense to you, it's likely because you've not understood what's actually happening. It's rarely because the people involved are wrong. This is because you are stupid.

As to the matter of "testing":

Quote
sipa   jgarzik: have we seen a block which affected 5000 transaction index entries?
jgarzik   sipa: I don't think so

Fuck you.

This is not testing. Stop releasing new clients, you don't have the license to do it, idiots.

mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 12, 2013, 08:21:00 PM
 #134

It is idiocy, and the people doing it were idiots.

But who is the bigger idiot?
The idiot making the flawed software or the idiot trusting the software?
LOL.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 08:24:35 PM
 #135

Don't look a gift horse in the mouth.

You are too stupid to be here. Please leave.

This is like saying Garry Kasparov is a shitty chess player. Then saying "By the way, I don't know how to play chess."

See above.

But who is the bigger idiot?
The idiot making the flawed software or the idiot trusting the software?
LOL.

Try and stay on topic. Trying to find "bigger idiots" doesn't help anything, which is why politicians do it all the time.

VeeMiner
Full Member
***
Offline Offline

Posts: 221


new generation miner


View Profile

Ignore
March 12, 2013, 08:30:51 PM
 #136

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

Yes.  This will be the death of Bitcoin.  When a fully specified crypto currency comes along, it will leave Bitcoin behind.  "The implementation is the protocol specification" is wrong, and at Internet scale it is very wrong.

this is fixable though

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 08:33:40 PM
 #137

There should be no need for a Kickstarter campaign at this point, one of the reasons for Bitcoin Foundation's existence is to "standardize bitcoin". I don't know how many coins they already collected from their Enterprise / Corporate members, but I hope that not all of them are spent on Gavin's salary and publicity tours.  Some should go towards funding the serious effort of extracting and publishing

BPS (Bitcoin Protocol Specification) version 1.0 and then targeting version 1.0 against the spec rather than declaring it to *be* the spec.

BPS 1.0 will be the Cambrian Explosion event of alternative implementations with the gene pool finally diversified across languages and dev teams.

P.S. Anecdotally, I personally know an extremely competent C++ programmer (who posts frequently in the forum) who is basically "already rich enough to retire" and who holds huge amount of bitcoins and who really really wanted to contribute to http://github.com/bitcoin/bitcoin but had to give up after seeing all the magic of that magic kingdom with all the magical creatures who live there, i.e.

It would take about a week to do a proper local setup including testnet before you can even beging to be confident in any of your own lines NOT to feel ashamed submitting it as a pull request.  Sadly, he gave up.

Yet, the real point is this once we have BPS, only then we can "let 1000 flowers bloom" until then it's all a circle-jerk, sorry.


Cheers ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
avoid3d
Jr. Member
**
Offline Offline

Posts: 91


View Profile

Ignore
March 12, 2013, 08:38:01 PM
 #138

I guess that's your cue to leave. Don't let the door hit you on the way out!

+1

avoid3d - Pierre Hugo
1avoid9FDvP15aKNyPGgJPcxfzMFM4Af6
alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 08:39:11 PM
 #139

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

Yes.  This will be the death of Bitcoin.  When a fully specified crypto currency comes along, it will leave Bitcoin behind.  "The implementation is the protocol specification" is wrong, and at Internet scale it is very wrong.

this is fixable though

It IS fixable.  Let's see if this the latest episode provides enough motivation for devs and Bitcoin Foundation to start even talking about BPS 1.0, so far there's been clear lack of any will for a spec, instead all the usual ("we are all just victims of the original C++ hairball dropped on us by Satoshi", or "there is too many bugs we cannot ever fix b/c some ancient client might depend on them" are brought out and reheated over and over again)

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 08:40:07 PM
 #140

this is fixable though

It is only fixable if fixed.

cho
Jr. Member
**
Offline Offline

Posts: 46


Boar with me


View Profile

Ignore
March 12, 2013, 08:41:08 PM
 #141

Yes, they are. This is what being a developer means in this context: that you are a servant. A slave, if you prefer that terminology. One who obeys. An inferior. A steward. Nobody, politically speaking. I'm running out of alternative ways to put this, but I would hope you get the idea.

If someone is interested in becoming politically relevant, being part of the dev team is not only a waste of his time, it's a waste of everyone's time. That a number of the more socially inept kids are doing this (Amir Scarface Taaki, who has meanwhile thankfully been ejected, Weirdo Luke, Gregory Pointless Maxwell and on and on) doesn't make it workable. It just doesn't work.

If someone is interested in becoming rich, being part of the dev team is not only a waste of his time, but a waste of everyone's time. It's just not how it works. Being part of the dev team is being part of the slaves, the servants, the stewards, the however you'd call them. This abject social position does not entitle them to immunity for their fuck-ups in any case. You may dislike that, and that's fine, but your likes and dislikes have no power to change this world.

I'm amazed at your ability to spit on the very people that did the job and brought you a piece of software you are relying on daily.
In essence, your reasoning seems to be the following :
- Dev job does not make you rich
- Thus, devs are lower-class humans, slaves
- You are in the political class
- Thus, you are a higher-class human
- From this you deduce that devs are entitled to free work for you, and if that free work is not perfect, you are entitled to call them names.

Until this last post of yours I hadn't understood you have the brain level of a 5 year old child. No no no sorry, I know a lot of 5 year old children with higher moral grounds. More accurately, you are at the level of a 12 to 18 months baby, a period of life at which you still think other people should definitely satisify all your needs just because they are "the outside" of your persona.



1KEWxTkXPgfB9MdHJcfyoVnfHRnYEHQJPw
mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 12, 2013, 08:45:17 PM
 #142

Let me take the opportunity to clarify some points of apparent confusion:

And did you ever pay these independant devs for fixing shit for you for free?

This question is malformed. If you are asking me whether they owe me, the answer is yes.
HAHA.
If they owe you then why cant you settle this on a personal matter?
Why the neeed for public support, why the call to arms?
Quote


Are they your wage slaves so you can demand that they do work for you or anyone else?

Yes, they are. This is what being a developer means in this context: that you are a servant. A slave, if you prefer that terminology. One who obeys. An inferior. A steward. Nobody, politically speaking. I'm running out of alternative ways to put this, but I would hope you get the idea.
Where do you get that idea from? Where is the contract that the bitcoin devs need to take this position in the way you describe so overly?
And what would enforce this status?
Quote
If someone is interested in becoming politically relevant, being part of the dev team is not only a waste of his time, it's a waste of everyone's time. That a number of the more socially inept kids are doing this (Amir Scarface Taaki, who has meanwhile thankfully been ejected, Weirdo Luke, Gregory Pointless Maxwell and on and on) doesn't make it workable. It just doesn't work.
This is inherent to such an open project like bitcoin.
People, including programmers, will have political opinions.
Anyone can contribute to the source and it shows deep misunderstanding of open source development when someone bluntly demands something of the development process without actually actively participating in it.

Quote
If someone is interested in becoming rich, being part of the dev team is not only a waste of his time, but a waste of everyone's time. It's just not how it works. Being part of the dev team is being part of the slaves, the servants, the stewards, the however you'd call them. This abject social position does not entitle them to immunity for their fuck-ups in any case. You may dislike that, and that's fine, but your likes and dislikes have no power to change this world.
I call them the creatives, the makers.
You're a shitty user and you have no actual power over the ones you call slaves.
You are nothing without them and you know it.
Show some respect.

Quote

Have you ever discussed your issues with the development team in a calm and adult manner?

You are not entitled to place limitations on the manner of my discourse.
The correct question to ask here is, MP recently published an article about the problems in Bitcoin. Have the developers read it and noted this fact?

No, but i can take note of it and form an opinion.
You seem to communicate rather single sidedly, preferably by pamfletting. On an open platform like internet that actually deters from a direct discussion or participation.

Quote

Do you even have the capacity to understand what you ask of them? (your tone tells me you're oblivious
How much further does your understanding of the problem go besides: "It's fucked up! fixitfixitfixitfixit!!@@!@!!!!" ?)
And how would you consider devs being independend if you expect them to give in to your tantrums?

I would guess you probably haven't actually understood what's being discussed here at all. As a rule of thumb that may serve you well in the future: whenever things happen that don't make sense to you, it's likely because you've not understood what's actually happening. It's rarely because the people involved are wrong. This is because you are stupid.

As to the matter of "testing":

Quote
sipa   jgarzik: have we seen a block which affected 5000 transaction index entries?
jgarzik   sipa: I don't think so

Fuck you.

This is not testing. Stop releasing new clients, you don't have the license to do it, idiots.

I understand perfectly what is being discussed. And i know it hurts when someone holds up a mirror so i don't mind the swearing.
And as usual you neatly cycle around the difficult part.

How do you expect devs to be independent if you demand stuff from them?
Slaves are not independent, they are slaves.
justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 08:45:31 PM
 #143

this is fixable though

It is only fixable if fixed.
Does MPEx prefer problem to be fixed, or remain unfixed?

VeeMiner
Full Member
***
Offline Offline

Posts: 221


new generation miner


View Profile

Ignore
March 12, 2013, 08:50:28 PM
 #144

There should be no need for a Kickstarter campaign at this point, one of the reasons for Bitcoin Foundation's existence is to "standardize bitcoin". I don't know how many coins they already collected from their Enterprise / Corporate members, but I hope that not all of them are spent on Gavin's salary and publicity tours.  Some should go towards funding the serious effort of extracting and publishing

BPS (Bitcoin Protocol Specification) version 1.0 and then targeting version 1.0 against the spec rather than declaring it to *be* the spec.

BPS 1.0 will be the Cambrian Explosion event of alternative implementations with the gene pool finally diversified across languages and dev teams.

P.S. Anecdotally, I personally know an extremely competent C++ programmer (who posts frequently in the forum) who is basically "already rich enough to retire" and who holds huge amount of bitcoins and who really really wanted to contribute to http://github.com/bitcoin/bitcoin but had to give up after seeing all the magic of that magic kingdom with all the magical creatures who live there, i.e.

It would take about a week to do a proper local setup including testnet before you can even beging to be confident in any of your own lines NOT to feel ashamed submitting it as a pull request.  Sadly, he gave up.

Yet, the real point is this once we have BPS, only then we can "let 1000 flowers bloom" until then it's all a circle-jerk, sorry.


Cheers ...

I agree with you mate, this should be done, we need BPS and it should be possible to fund it through the foundation.

It's sad that people that want to help out are discouraged by other developers.

mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 12, 2013, 08:50:46 PM
 #145

Try and stay on topic. Trying to find "bigger idiots" doesn't help anything, which is why politicians do it all the time.

I'm sorry, but i couldn't find a more adept swaxription of the situation.
You call the devs idiots, but you are the one that trusts that software or peoples intelligence or motivation will never fail.
If you were NOT an idiot yourself you could have known that software development never is perfect, open source development even more so.
Assuming you're not REALY an idiot i can only think that you must have known the risks when you invested your energy to build something on the substrate of bitcoin.
And if you knew then you should STFU.
grau
Full Member
***
Offline Offline

Posts: 245


View Profile

Ignore
March 12, 2013, 08:53:25 PM
 #146

It IS fixable.  Let's see if this the latest episode provides enough motivation for devs and Bitcoin Foundation to start even talking about BPS 1.0, so far there's been clear lack of any will for a spec, instead all the usual ("we are all just victims of the original C++ hairball dropped on us by Satoshi", or "there is too many bugs we cannot ever fix b/c some ancient client might depend on them" are brought out and reheated over and over again)

I went through the self imposed pain of implementing the protocol from scratch and learned the hard way that the behavior of the Satoshi client is not captured by any written sources other than its code.

Documenting the protocol is a major effort and it would have to be code rather than text in quite a few details to be precise, but I think it is doable and should be done.

Yes, the foundation should fund the effort.

Author of the bitsofproof supernode, the scalable, modular Bitcoin implementation. https://github.com/bitsofproof/supernode/wiki. Donations: 13xhxy21to93Lrb7d4ssZVaMnFtQVvRkSk
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 08:54:24 PM
 #147

this is fixable though

It is only fixable if fixed.
Does MPEx prefer problem to be fixed, or remain unfixed?

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 09:00:07 PM
 #148

It IS fixable.  Let's see if this the latest episode provides enough motivation for devs and Bitcoin Foundation to start even talking about BPS 1.0, so far there's been clear lack of any will for a spec, instead all the usual ("we are all just victims of the original C++ hairball dropped on us by Satoshi", or "there is too many bugs we cannot ever fix b/c some ancient client might depend on them" are brought out and reheated over and over again)

I went through the self imposed pain of implementing the protocol from scratch and learned the hard way that the behavior of the Satoshi client is not captured by any written sources other than its code.

Documenting the protocol is a major effort and it would have to be code rather than text in quite a few details to be precise, but I think it is doable and should be done.

Yes, the foundation should fund the effort.


+1. See latest emails in bitcoin-dev mailing lists (another little refuge where "big guys" and "magicians" hangout)

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 12, 2013, 09:00:52 PM
 #149

this is fixable though

It is only fixable if fixed.
Does MPEx prefer problem to be fixed, or remain unfixed?

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.

That, at least, is a reasonable wish.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 09:02:42 PM
 #150

Documenting the protocol is a major effort and it would have to be code rather than text

No, it would not.

Learn to separate design and implementation already, it's software design junior fodder.

Timo Y
Staff
Hero Member
*****
Offline Offline

Posts: 812



View Profile

Ignore
March 12, 2013, 09:07:20 PM
 #151

Don't look a gift horse in the mouth.

You are too stupid to be here. Please leave.


Yeah, that's really persuasive.
justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 09:07:29 PM
 #152

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.
Is MPEx going to do anything to help make this happen other than talk about it?

mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 12, 2013, 09:08:57 PM
 #153

Documenting the protocol is a major effort and it would have to be code rather than text

No, it would not.

Learn to separate design and implementation already, it's software design junior fodder.

I want to point out to you that a successfull definition of entropy is the shortest possible computer code that produces a certain output.

So yes, it may very well be.

The onus is on you to show that all of bitcoins core code can easily be compiled into human language.
alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 12, 2013, 09:20:16 PM
 #154

Guys,

Let's not muddy the waters here ...

There Shalt Be a Spec.  That's all there is to it.


The only question is what kind of pressure needs to be brought to bare and where to expedite that process.

Your target list of people to pressure / influence is here https://bitcoinfoundation.org/about/board  *especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.

Cheers ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 09:20:48 PM
 #155

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.
Is MPEx going to do anything to help make this happen other than talk about it?

See post #87 earlier.

The onus is on you to show that all of bitcoins core code can easily be compiled into human language.

You are very, very confused about how this "onus" thing works. Perhaps you'd be best served by following the advice given to usagi.

For that matter, the point you only seem to have grasped in #149 had in fact been my position since about #71. Try reading what I say twice before talking to me (or if you already are reading it twice, read it thrice from now on).

*especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.

*falls over laughing*

Yeah dood, totally. Once Bitcoin is specced properly Wall Street will move to Silicon Valley Bank. I can see it in mobodick's onus.

justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 09:30:26 PM
 #156

See post #87 earlier.

Fair enough.

There Shalt Be a Spec.  That's all there is to it.


The only question is what kind of pressure needs to be brought to bare and where to expedite that process.
Incorrect. The only question is who is willing to do it, and who is willing to support them.

I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.

MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 09:48:57 PM
 #157

Incorrect. The only question is who is willing to do it, and who is willing to support them.

I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.

To quote here:

Quote
<mircea_popescu> jurov anyway, the problem isn't as much the drama, but moreover that a single-source codebase is both non-bitcoiny and suspect.
<mircea_popescu> but i think if we can get one (or ideally multiple) people to summarize the code
<mircea_popescu> we can pretty much derive a spec from there.
<mircea_popescu> this wouldn't take much longer than a few weeks for a first draft, which can then be argued and refined
<mircea_popescu> in my experience any devteam resists such an effort like cats resist washing, because coders love to write but hate having to read code.
<mircea_popescu> hiowever, once it's complete there's a few day's worth of facepalming and going "wait, we are doing W?HAT ?!"
<mircea_popescu> after which everything's much better.
<mod6> this is a solid plan.
<mircea_popescu> mod6 in experience it tends to work.
<mircea_popescu> of course it has to first get the cat into the washing machine.

There wouldn't really be need for much testnetting, at least originally (ie, for the first draft).

What there's need for is people to sit down with a cup of coffee and a (preferably printed) copy of the code and just read it through. This can be done in bits as long as the bits aren't arbitrarily segmented (it's ok to summarize a procedure, it's not ok to summarize between lines 520 and 545). Once we have a few of these completed we're already very far down the road.

Then the work of merging them into a spec emerges, where a lot of arguments will for sure be had ("no, it doesn't do that"/"yes it does") at which point there may be a need to whip out the testnets but not necessarily. Then a ton of drama and hurt feelers, and then that's it, once everyone is beaten into a pulp we have the spec.

Ideally this would include people other than the current dev team, not because the current dev team is made of idiots (which mostly it is) but because people tend to read what they think should be there and in general skip over the unflattering bits.

In fact this can be started today.

mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 12, 2013, 09:57:39 PM
 #158

The position of MPEx is that the current dev team should release no further versions until a. Bitcoin is specified and b. The codebase is cleaned up.
Is MPEx going to do anything to help make this happen other than talk about it?

See post #87 earlier.

The onus is on you to show that all of bitcoins core code can easily be compiled into human language.

You are very, very confused about how this "onus" thing works. Perhaps you'd be best served by following the advice given to usagi.

For that matter, the point you only seem to have grasped in #149 had in fact been my position since about #71. Try reading what I say twice before talking to me (or if you already are reading it twice, read it thrice from now on).

No, you are just very very confused about the position you take in this matter.
What i make of your point is that you want some specification. What i call you out on is your critique directed at grau's idea that the algorithm may not be easily specified at all. The normal situation is that not every problem can be specified easily. So please demonstrate why the bitcoin software can. The burden is yours.

Quote

*especially* Peter Vessenes (last one on the list) because he's also in charge of CoinLab and its future big wholesale deals with Wall Street hedge funds investing into bitcoin through Coinlab will live or die based on convincing them that Bitcoin can grow up and become an actual internet standard (i.e. BSP 1.0) and not just remain a C++ hairball with attendants.

*falls over laughing*

Yeah dood, totally. Once Bitcoin is specced properly Wall Street will move to Silicon Valley Bank. I can see it in mobodick's onus.

I'm sorry, but i was still holding up the mirror..
 Roll Eyes
justusranvier
Hero Member
*****
Offline Offline

Posts: 1607



View Profile WWW

Ignore
March 12, 2013, 10:03:28 PM
 #159

Incorrect. The only question is who is willing to do it, and who is willing to support them.

I am willing to donate bitcoins, and to help test changes by compiling and running a node on testnet.

To quote here:

Quote
<mircea_popescu> jurov anyway, the problem isn't as much the drama, but moreover that a single-source codebase is both non-bitcoiny and suspect.
<mircea_popescu> but i think if we can get one (or ideally multiple) people to summarize the code
<mircea_popescu> we can pretty much derive a spec from there.
<mircea_popescu> this wouldn't take much longer than a few weeks for a first draft, which can then be argued and refined
<mircea_popescu> in my experience any devteam resists such an effort like cats resist washing, because coders love to write but hate having to read code.
<mircea_popescu> hiowever, once it's complete there's a few day's worth of facepalming and going "wait, we are doing W?HAT ?!"
<mircea_popescu> after which everything's much better.
<mod6> this is a solid plan.
<mircea_popescu> mod6 in experience it tends to work.
<mircea_popescu> of course it has to first get the cat into the washing machine.

There wouldn't really be need for much testnetting, at least originally (ie, for the first draft).

What there's need for is people to sit down with a cup of coffee and a (preferably printed) copy of the code and just read it through. This can be done in bits as long as the bits aren't arbitrarily segmented (it's ok to summarize a procedure, it's not ok to summarize between lines 520 and 545). Once we have a few of these completed we're already very far down the road.

Then the work of merging them into a spec emerges, where a lot of arguments will for sure be had ("no, it doesn't do that"/"yes it does") at which point there may be a need to whip out the testnets but not necessarily. Then a ton of drama and hurt feelers, and then that's it, once everyone is beaten into a pulp we have the spec.

Ideally this would include people other than the current dev team, not because the current dev team is made of idiots (which mostly it is) but because people tend to read what they think should be there and in general skip over the unflattering bits.

In fact this can be started today.
Another approach is to write the spec while refactoring the reference implementation into something more documentable. Any superfluous functionality than can be removed from bitcoind and moved to the clients is less functionality a fully-compliant alternate implementation is required to implement.

I've suggested this before but maybe it's worth mentioning again.

Split bitcoind and bitcoin-Qt into completely independent components. Bitcoind stores a local copy of the blockchain, connects to the p2p network, relays blocks and transactions, and serves blockchain information to clients only. Bitcoin-Qt is a client application only that connects to a trusted bitcoind node. The default installation would install them in a pair, with bitcoind running all the time as a unix daemon (Windows service) and Bitcoin-Qt started on demand. Only one instance of bitcoind is needed on a typical home LAN, all the clients can just connect to it.

Once this is done Bitcoin-Qt can just focus on being the best client it can be, while bitcoind can focus on the blockchain and p2p network. It should also be extended to serve MultiBit, Armory and Electrum. Once the reference implementation is fully refactored into a client/server application it should make any attempt to develop an alternate implementation easier.

I don't have enough programming skill to do this, but I'd donate to anyone who does.

This would definitely be the first step out of the current insanity and finally bring some layering into the code base client UI === depends on ==> bitcoind but zero backward pointing dependencies.

This would be the first step on the long journey to the promised land of the BPS (Bitcoin Protocol Specification)

MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 12, 2013, 11:06:19 PM
 #160

Another approach is to write the spec while refactoring the reference implementation into something more documentable. Any superfluous functionality than can be removed from bitcoind and moved to the clients is less functionality a fully-compliant alternate implementation is required to implement.

Yes, but the disadvantage of that method is the (possible? probable?) leak of things that don't belong into the spec draft. In general doing multiple things at the time should be avoided as much as possible.

niko
Hero Member
*****
Offline Offline

Posts: 1625



View Profile

Ignore
March 12, 2013, 11:23:04 PM
 #161

It is also a huge issue that those suggesting we need the protocol spec are brushed off with the "you don't get it" nonsense by elitist devs.
Bits and pieces, some expired, are scattered around Wiki. Is that the best we can do?
@MP: would you be willing to lead the effort of formulating the current protocol spec?
You really, really don't get it. We can't have a protocol spec becasue the existing client has a whole bunch of unspecified and unintended behaviour that no-one knows about, and any divergence from that behaviour by any major implementation will result in fiascos like this one. This problem could just as easily have been caused by a independent third-party implementation of the client. The developers have been finding and documenting all the corner cases as thoroughly as possible, but some of them are - like this one - really subtle and hard to spot. I'm not sure anyone's managed to fully work out the circumstances under which 0.7 will fail to accept a block due to this bug.
You're right, I really don't get it.  "Any divergence from that behavior... will result in fiascos like this one." Breaking news: this little fiasco was the result of a bug in the reference client, not any "divergence" of alternative implementations. You want to base a technology handling billions of dollars on a black box that, according to your words, "has a whole bunch of unspecified and unintended behavior that no-one knows about"Huh FYI, someone will get to know some of these things, and some of that will become zero-day exploits. If your kind of sentiment and irrational justifications continues to prevail among developers, I am going all out of Bitcoin. I still don't understand how any sane person can try to defend voodoo black box approach to defining the protocol.

They're there, in their room.
Your mining rig is on fire, yet you're very calm.
Uglux
Jr. Member
**
Offline Offline

Posts: 73



View Profile

Ignore
March 13, 2013, 12:10:46 AM
 #162

Incredible how stupid self-centered people can be, seriously now.
Careful with this. You are being the very same thing, claiming "to know the one and only truth":

This is not how the world works, currently (and past about 1800 or so). This is not how the world should work, either.

But your later proposals seem to be quite constructive...Only your "idiot-anger" is obscuring the view on things maybe sometimes. Nonetheless I agree with you, that this incident should be used as an opportunity to rethink/improve the "development process".

1NFQUq8aLvcNW5KKWX8VeFHktzsPo8Y7yf
MooC Tals
Full Member
***
Offline Offline

Posts: 230



View Profile

Ignore
March 13, 2013, 01:17:33 AM
 #163

On 2011 an external factor made Bitcoin nose dive...... Imagine what would happen this time.... Don't kid yourselves like some people in the IRC room. This is the biggest problem Bitcoin ever faced and it is waaaaay bigger than the MTGox. hack.

I am not pulling out I am just pissed off Bitcoin will suffer greatly because the DEVS MADE A MISTAKE! you dont freaking PUSH such things without proper testing. EVER HEARD OF TESTNET!!!!!!


Maybe we should have a form of crowd funding to keep them interested. We do need competent people working on this in a decentralized manner. I'm not saying they are not. I'm saying lets give them something thats a bit of an incentive.

As far as I am concerned they did a great job and need praise. They worked together and put aside their differences. That is something I enjoyed hearing about.

I'm amazed to see this get this far and as my thoughts on humanity go, well they're  less than impressive. My only concern is when bitcoin gets really big and greed begins to corrupt.

As for calling Dev idiots is quite harsh, maybe more foolish would be a better word.

enquirer
Full Member
***
Offline Offline

Posts: 118


View Profile

Ignore
March 13, 2013, 01:45:01 AM
 #164

Studied the IRC logs, and it was Luke Jr who first uttered the 4 letter word starting with F, first proposed a viable solution, and first took practical steps to alleviate the problem. However crazy that guy appears to be, he's extremely smart. But I sometimes think his religious and tonal rants are just trolling.
misterbigg
Hero Member
*****
Offline Offline

Posts: 867



View Profile WWW

Ignore
March 13, 2013, 01:50:31 AM
 #165

Two points:

1. Even if the OP is making a valid point, the way in which shim resorts to insults and name calling cheapens the discussion and only serves to further soil their reputation (if that's even possible).

2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process is a significant threat to the growth of Bitcoin.

I've put together a description of the development of the Gnutella protocol as an example of what Bitcoin development could and should be, here:

What Bitcoin Could Learn From Gnutella

100x
Jr. Member
**
Offline Offline

Posts: 46


View Profile

Ignore
March 13, 2013, 03:10:46 AM
 #166

Two points:

1. Even if the OP is making a valid point, the way in which shim resorts to insults and name calling cheapens the discussion and only serves to further soil their reputation (if that's even possible).

2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process is a significant threat to the growth of Bitcoin.


To the OP, while misterbigg cannot resist revealing his hypocritical nature with point 1 (happens to everyone eventually Cheesy), he is also 100% correct. This thread would be so much more productive if you could act in a more civilized manner. By carefully laying out your insightful arguments (you seem to have several) in a constructive fashion, we could have a useful discussion, discern important steps moving forward, and make progress in improving bitcoin. Instead you resort to taunts, name-calling, arrogance, and general pompous asshat dickery. I hope you can realize how much more we could accomplish and how much happier everyone would be if you acted like less of a douchebag.

That being said, thank you for being persistent on a few important points. It seems very evident now that a formal specification will have to be prepared. We need to remove all confusion regarding implementation, catch any remaining bugs, and allow for much easier development of alternative clients. It also seems like we have some motivated individuals (other than core dev team) with skills and determination to lend to this effort, which will be very beneficial.

The core dev team has done an absolutely amazing job this far, but as life goes, it usually takes unexpected adversity for necessary growth to occur. And now, rather than later, is a much better time for said growing pains.
misterbigg
Hero Member
*****
Offline Offline

Posts: 867



View Profile WWW

Ignore
March 13, 2013, 03:29:03 AM
 #167

...you seem to have several...

I second that. I would love to put MPOE-PR on ignore but unfortunately mixed in with the vitriol are valid points. Bitcoin is not served by having a representative of a Bitcoin business act like an immature jerk.

MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 13, 2013, 03:38:25 AM
 #168

To the OP, while misterbigg cannot resist revealing his hypocritical nature

I'm not too concerned with that muppet's posturing. In general it's enough to point out his shady past and he goes away (at least for a little bit).

This thread would be so much more productive if you could act in a more civilized manner.

Understand something here: I am not interested in the problems of coding. It's not what we do, MPEx has its plate full (very, very full) just trying to bring some sense into Bitcoin finance. We can't be doing everything nor do we wish to do everything. The idea is that other people, blessed with the relatively much more common skillset of computer programming, keep an eye on things and at least grosso modo keep nonsense to a low roar.

By the time I have to talk about Bitcoin coding issues the ball has been dropped so far by so many people so many times it's not even funny anymore. So let's have a simple fix: PEOPLE QUIT BEING IDIOTS and I'll be happy to never have to post in this subsection of the forum ever again.

And conversely, when you see me talking here you know SHTF. Badly so.

Now go ahead have your useful discussion, discern important steps moving forward and make progress in improving Bitcoin.

That being said, thank you for being persistent on a few important points.

You're welcome. Hopefully it's the last time the world's greatest currency has to be thus helped by idiots like me. You know?

kjj
Hero Member
*****
Offline Offline

Posts: 2685


Bitcoin Foundation - Lifetime Member


View Profile

Ignore
March 13, 2013, 03:48:09 AM
 #169

Holy fuck!  I'm talking WAY, WAY, WAY, WAY beyond my area of expertise.  I hope that I don't get humiliated by like 90 guys that actually understand what I'm talking about.

Shit.  You all beat me to it.

p2pcoin: a USB/CD/PXE p2pool miner - 1N8ZXx2cuMzqBYSK72X4DAy1UdDbZQNPLf - todo
niko
Hero Member
*****
Offline Offline

Posts: 1625



View Profile

Ignore
March 13, 2013, 04:53:16 AM
 #170

(Snip)
2. The lack of significant alternative implementations, lack of technical specifications, the developers' show of disdain for formal standards, and the apathy of the Bitcoin Foundation towards better process
is a significant threat to the growth of Bitcoin.
(Snip)
It appears that some of developers' disdain for formalization of the protocol is rooted in self-interest to keep the heart of Bitcoin accessible to them exclusively. This may be related to several things - from elitist, self-centered power trips (some of them are cocky to say the least) to emotional attachment to their "child" and consequential need to protect the child from the chaos of inevitable promiscuity of the adulthood. Either way, it's pathological. Even if they are right in that Bitcoin is too young to be let in the wild for anyone to play with, they ought to work on helping it develop and grow healthy, rather than possesively protect it by letting it degenerate into an ever-worsening hairball of poorly documented details and unexpected consequences.

Seriously, if in the next three months I don't see serious and productive effort to formalize and specify the current protocol and future use cases, I'm out of here. It will only be a matter of time before chaotic, "organic" patching of old and new features leads to a total disaster.


They're there, in their room.
Your mining rig is on fire, yet you're very calm.
benjamindees
Hero Member
*****
Offline Offline

Posts: 1571


View Profile

Ignore
March 13, 2013, 05:44:53 AM
 #171

However crazy that guy appears to be, he's extremely smart. But I sometimes think his religious and tonal rants are just trolling.

Did you know that Chinese weights (before metric) were based on a hexadecimal system?  I wonder how many merchants are still used to that system.

None of the Bitcoin developers are "idiots".  And they all have their own interests.  Luke just seems to be a bit more open about his, and takes a lot of crap for it.

Civil Liberty Through Complex Mathematics
sturle
Sr. Member
****
Offline Offline

Posts: 415


View Profile

Ignore
March 13, 2013, 08:12:49 AM
 #172

Right now there's no question that they deserve to be called idiots. What's happening now was easily preventable and shouldn't have ever happened under any circumstances.
It's actually fucking amazing that this is first MAJOR bug in 4 years.
AND, as all critics ignore because they are clueless and it invalidates their criticism, the bug isn't in bitcoin at all!  It is in some versions of BDB on some platforms.  The developers wisely chose a better database for 0.8, but unfortunately the bug manifested itself in a bad way (it could have been worse, e.g. if the bug in BDB made remote code execution or altering old blocks possible) before almost all nodes had upgraded.
I've seen at least one thread claiming that it's not a bug in BDB as much as a misconfiguration.
It is a question of wording - if we assume everybody knows all facts: you may call it a bug in bitcoin, that the BDB was used misconfigured.
What configuration will work in all cases?  This may be impossible to tell, because it is impossible to prove if bitcoind and all it's components works correctly in all cases.  This follows from The Halting Problem described by Alan Turing.

Testing and avoiding bugs is important, but it is just as important to handle situations like this when they occur, and I think this one was handled very well.  A hard fork with two parallel blockchains going on forever was avoided.  Because bugs will happen.  No amount of testing or algorithm proving can eliminate all bugs.

Anyway, no need to insult people here from the very beginning of the thread - but this seems also a characteristic of this bitcoin forum(s) that this is tolerated. :-(
I have this user on ignore.  I am not alone, as you can see from the piss yellow background of his ignore link.  Nothing even remotely clueful, interesting or constructive comes from his keyboard.
marcus_of_augustus
Hero Member
*****
Offline Offline

Posts: 2266



View Profile

Ignore
March 13, 2013, 08:34:45 AM
 #173

It is not a bug. It is entirely predictable behaviour if anybody had bothered to read the documentation and run the test ... at any time in the last 4 years. (Including satosi nakamoto or mike hearn)

The max lock limit was hit ... do some reading on BDB tutorial.

https://bitcointalk.org/index.php?topic=152208.0

http://www.stanford.edu/class/cs276a/projects/docs/berkeleydb/ref/lock/max.html

markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 13, 2013, 08:43:35 AM
 #174

Yes, but, the max lock limit impacts the size of blocks you can handle, because larger blocks are able to touch more transactions thus need more locks.

So presumably the size of blocks to allow miners to create should, if your theory of predictability holds water, be computable from the number of locks, in which case the -blockmaxsize RPC call ought not to have allowed miners to specify a block max size large enough to need more locks than the BDB had been configured to permit.

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
ShadowOfHarbringer
Hero Member
*****
Offline Offline

Posts: 1651


Bringing har to you since 1952


View Profile

Ignore
March 13, 2013, 08:48:35 AM
 #175

This matter was apparently for the first time discussed here, which is in itself ridiculously late, but the recent events illustrate the need of having the various issues much more clearly delineated.

(...) blah blah blah (...)

(...) some bullshit (...)

From the posts of yours i would rather say that you are an idiot, not the devs. And a troll.

This is an open source project for a reason. Use the source, luke.
If you don't like the default Bitcoin client, make a better one yourself. Or pay for the features you want.

(Or you could just shut up & die).

1NLWBAD7ZD82fJDDawKfp5RAKSR8YWWYd3
Hate forced fees ? Use "No Forced TX Fee" Bitcoin Client fork. Now updated to v0.7.2 !
Centralization is bad for btc. Try other exchanges: BitStamp.net Btc.de InterSango.com Btc-e.com
marcus_of_augustus
Hero Member
*****
Offline Offline

Posts: 2266



View Profile

Ignore
March 13, 2013, 08:50:50 AM
 #176

Yes, but, the max lock limit impacts the size of blocks you can handle, because larger blocks are able to touch more transactions thus need more locks.

So presumably the size of blocks to allow miners to create should, if your theory of predictability holds water, be computable from the number of locks, in which case the -blockmaxsize RPC call ought not to have allowed miners to specify a block max size large enough need more locks than the BDB had been configured to permit.

-MarkM-


I think that size of the block (total size of all tx) and number of locks required is only loosely correlated ... so raising the block size limit made it more likely that the default lock limit would be hit, but not predictably.

If you constructed a block just so, i.e. it has more than 5000 locks required, it will predictably recreate a defective block.

In fact, if you were a malicious mining pool operator you could do that now with a pre-0.8 version and fork the chain the same as 0.8.

Bitcoin is vulnerable in the current state ... security through obscurity it seems, because someone would need to be arsed to figure out how these lock limits work so they can attack the chain.

I could go on but I think I might be saying too much already.

markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 13, 2013, 09:05:28 AM
 #177

There is a max number of inputs and/or outputs a block of a specified size could possibly contain, so that, plus the number of transactions it itself contains, bounds the number of transactions it could possibly touch. Double that to account for needing to process two blocks at the same time when doing a re-org. Then add some fudge factor, or double again or something, to account for any margin of error you think your calculations might have.

Hopefully the configuration even lets you specify the page size you want BDB to use, so that you don't have to know the block size of the underlying block-device in order to do these calculations.

As to being arsed, it is only an experiment and only involves less than a billion dollars or so so yeah, time enough for that when the experiment has determined whether there is any point in building a real implementation of something along the lines of what the experiment is attempting. Smiley Cheesy

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 13, 2013, 10:51:05 AM
 #178

Instead you resort to taunts, name-calling, arrogance, and general pompous asshat dickery.


LOOOOOOOL
General pompous asshat dickery is EXACTLY what i have against MPOE-PR!

Generally the pompousness is dripping off of the OP in a peculiarly dickery matter.

And once such a tone is set you can expect people to pick up on it.
So if you want to address general pompous asshat dickery you may very well want to start at the root of the problem, the OP.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 13, 2013, 09:02:24 PM
 #179

In fact, if you were a malicious mining pool operator you could do that now with a pre-0.8 version and fork the chain the same as 0.8.

Probably not, because all the pre-.8 clients would uniformly reject that block, which includes most of the miners since they've downgraded. A lock-blocking block could be manufactured just fine, but it would not likely end up as anything more than a 1 block deep orphan.

jgarzik
Staff
Hero Member
*****
Offline Offline

Posts: 2498


View Profile

Ignore
March 13, 2013, 09:19:43 PM
 #180

(copied from misterbigg's thread)

As Pieter wrote on bitcoin-development list,

Quote
The protocol is whatever the network enforces - and that is some mix of versions of the reference client right now, but doesn't need to remain that way.

I would very much like to have a text book of rules that is authorative, and every client that follows it would be correct. Unfortunately, that is not how a consensus system works. All (full) clients validate all rules, and all must independently come to the same solution. Consensus is of utmost importance, more than some theoretical "correctness". If we'd have a specification document, and it was discovered that a lot of nodes on the network were doing something different than the document, those nodes would be buggy, but it would be the specification that is wrong.

Or restated:  The fundamental problem being solved by bitcoin at a technical level, on a daily basis, is the distributed consensus problem (link).

We fully support the writing of specifications and documentation, which you can see here
    https://en.bitcoin.it/wiki/Protocol_specification

And changes to the existing protocol are formally documented here,
    https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals

Ultimately the operational definition of consensus comes from what the network accepts/expects, not a theoretical paper.  Specification practices are healthy as a manual, human-based method of achieving consensus on network protocol rules.  Alternate client implementations (c.f. heterogeneous environment) are another good practice.

But the collective software rules are always the final specification, by definition.  That is what bitcoin does, achieve consensus.

A few other observations:

Gnutella had a business and project environment with co-motivated individuals working on a few key codebases.  The reference codebase in bitcoin, in contrast, has one paid developer (Gavin@BF) and a few part time unpaid volunteers.

All the big bitcoin businesses seem to either (a) contribute to BF, (b) use bitcoind without contributing back any testing/dev/specification resources, or (c) do their own thing entirely, not contributing back any testing/dev/specification resources.

Bitcoin is a thing, an invention, not a funded project with a built-in set of professionals paid to ensure full spec/dev/test engineering effort.  If you want something, DO IT.  You cannot expect the engineering resources to do X to magically appear, just because you complained on an Internet forum.

In an unfunded open source project, arguing all day about the lack of full-engineering-team rigor is entirely wasted energy.  Blame the dev team if that is your favorite target, that will not magically create extra time in the day or extra manpower to accomplish these extra tasks being demanded by non-contributors.

The time spent whining about what an unfunded effort fails to do could be better spent, say, creating a test network of full nodes running all known bitcoind versions, 0.3 through present.  And test, test, test changes through that.


Jeff Garzik, bitcoin core dev team

Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
markm
Hero Member
*****
Offline Offline

Posts: 3096



View Profile WWW

Ignore
March 13, 2013, 09:28:10 PM
 #181

Okay, so, requirements specification:

1) Without producing zero-day exploits,

2) The network achieves consensus as to which blockchain fork is the "correct" one,

3) By means of ...

-MarkM-

Browser-launched Crossfire client now online (select CrossCiv server for Galactic  Milieu)
Free website hosting with PHP, MySQL etc: http://hosting.knotwork.com/
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 13, 2013, 09:52:50 PM
 #182

Pieter is wrong. Point blank. It would be the implementation, not the specification, that is broken.

But the collective software rules are always the final specification, by definition.  That is what bitcoin does, achieve consensus.

This is a red herring. In a heterogenous environment your statement would stand. In a broken single-implementation that you folks have by now become painfully unable to maintain, this is not at all true. Currently, the "rules" is what you manage to con irresponsible pool operators into implementing (and they ARE irresponsible, and mining power should not be concentrated with the sort of clueless noobs either, but that is a different discussion).

Again, the fact that you happen to be buddy-buddy with Tammany Hall Guild does NOT lend your mistaken, misguided and ultimately idiotic pseudosolutions the veneer of some sort of democratic or distributed process. Claiming otherwise is at the very best naive, but even then it's awfully selfinterested naiveté.

Stop claiming that the broken code you people keep spewing is "solving" anything. It is not, and especially not lofty things such as the dcp. So far you have trouble configuring the world's simplest, cheapest and most widely deployed database system.

And when that failure of yours comes to bite you in the ass the response is that BDB was buggy? At this level one could hire a better dev team just by trolling general ubuntu support forums and teaming up all the douches with unanswered support questions.

Forget the delusions of grandeur. See a and b above, #71.

Okay, so, requirements specification:

1) Without producing zero-day exploits,

2) The network achieves consensus as to which blockchain fork is the "correct" one,

3) By means of ...

-MarkM-

...by means of having a specification that is independently implemented so that broken implementations such as each and every version so far produced of this so called "reference" client fail to cause the massive problems that they have so far caused on each and every release.

I'm not sure this is getting through the fog of their own farts, but the group of power rangers has so far:

1. Not produced one single brilliant solution to any actual problem.
2. Stepped in a majority of the holes, landmines and caltrops available.

1 is of particular concern, especially because it is so easily disprovable.

alexkravets
Full Member
***
Offline Offline

Posts: 114



View Profile WWW

Ignore
March 13, 2013, 10:08:00 PM
 #183

Just an FYI, "the real" to-spec-or-not-to-spec discussion has probably moved back into its newly re-activated "canonical" BPS Thread

Here https://bitcointalk.org/index.php?topic=134318.msg1621672#msg1621672

Cheers ...

Alex Kravets         def redPill = 'Scala
[[ brutal honesty is the best policy ]]
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 13, 2013, 10:17:48 PM
 #184

Just an FYI, "the real" to-spec-or-not-to-spec discussion has probably moved back into its newly re-activated "canonical" BPS Thread

Here https://bitcointalk.org/index.php?topic=134318.msg1621672#msg1621672

Cheers ...

Due to the recent changes implemented by theymos I would not trust to post in a thread I've not started. Sorry.

kuzetsa
Full Member
***
Offline Offline

Posts: 213


View Profile

Ignore
March 14, 2013, 06:26:01 AM
 #185

Another way to state the real problem: There is no Bitcoin Protocol Spec, most semantics buried in the hairball of the C++ reference implementation

That would be correct. It's a huge issue.


500 Internal Server Error
Chris Weber
Jr. Member
**
Offline Offline

Posts: 25


View Profile

Ignore
March 14, 2013, 07:55:48 AM
 #186

@MPOE-PR
What about making the reference some text sticking to RFC rules? I really think this is not easy but worth the effort.
You even could go for support of the BF to do this.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 14, 2013, 10:52:42 AM
 #187

Holy fuck!  I'm talking WAY, WAY, WAY, WAY beyond my area of expertise.  I hope that I don't get humiliated by like 90 guys that actually understand what I'm talking about.

Shit.  You all beat me to it.

Smartass, this thread is actually earlier than the devteam announcement. Stopped to think about that for a second?

@MPOE-PR
What about making the reference some text sticking to RFC rules? I really think this is not easy but worth the effort.
You even could go for support of the BF to do this.

That's kinda the plan, roughly speaking.

mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 14, 2013, 11:14:10 AM
 #188


By the time I have to talk about Bitcoin coding issues the ball has been dropped so far by so many people so many times it's not even funny anymore. So let's have a simple fix: PEOPLE QUIT BEING IDIOTS and I'll be happy to never have to post in this subsection of the forum ever again.


Noone is actually forcing you to talk about this stuff. Using bitcoin is entirely your own choice and your own risk.
Unless you actually contribute you're nothing but a joke when you bitch about stuff not being fixed.
Fix it yourself or STFU and GTFO...

Nobody needs you.
Let me rephrase this:
The bitcoin community does not need you or your bitching.
In fact, i bet this community will be better off without narcissistical personalities like yours that see idiots everywhere except in the mirror.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 14, 2013, 05:39:27 PM
 #189

Noone is actually forcing you to talk about this stuff. Using bitcoin is entirely your own choice and your own risk.
Unless you actually contribute you're nothing but a joke when you bitch about stuff not being fixed.
Fix it yourself or STFU and GTFO...

Nobody needs you.
Let me rephrase this:
The bitcoin community does not need you or your bitching.
In fact, i bet this community will be better off without narcissistical personalities like yours that see idiots everywhere except in the mirror.

I thought we got past the "gift horse in the mouth" argument a while back.

Attacking me doesn't make idiots less idiotic.

rebroad
Jr. Member
**
Offline Offline

Posts: 11



View Profile

Ignore
March 15, 2013, 12:10:07 PM
 #190

What does this even mean? "independent devs doing it". Dependent on what/whom? If you'd had 100 variants of the original Satoshi client all being developed and bug fixed separately and 100 variants of the mining software all being developed and bug fixed separately then we'd have had many more hardforks by now, with no-one really knowing anymore which is the true bitcoin. Do you go by the first version of the client which allowed anyone to give themselves a billion (well, a lot) bitcoins? Or some arbitrary version someone developed based on that? It simply wouldn't work. Bitcoin needs a majority client in order to not hard fork, and therefore in this sense, it can never be decentralised. The developers of this majority client will always have the power and can make decisions to change what bitcoin is whenever they like. For example, let's say they decide to increase the blocksize from 1MB to 10MB. Who's going to stop them? The users downloading bitcoin-qt? I suspect not. Most people just download it and use it without caring what changes are going on. Yes, we were supposed to be able to vote with our feet, but the people who actually do that are usually in the minority and so will lose.

Considered, yes. One problem is the centralization issue stemming from that approach. The one correct way to handle Bitcoin development is exactly as designed: independent devs doing it. The problem is that instead of doing it they spend their time opining on things that utterly ain't their business.
mobodick
Hero Member
*****
Offline Offline

Posts: 1127



View Profile

Ignore
March 15, 2013, 12:39:33 PM
 #191

Noone is actually forcing you to talk about this stuff. Using bitcoin is entirely your own choice and your own risk.
Unless you actually contribute you're nothing but a joke when you bitch about stuff not being fixed.
Fix it yourself or STFU and GTFO...

Nobody needs you.
Let me rephrase this:
The bitcoin community does not need you or your bitching.
In fact, i bet this community will be better off without narcissistical personalities like yours that see idiots everywhere except in the mirror.

I thought we got past the "gift horse in the mouth" argument a while back.

Attacking me doesn't make idiots less idiotic.

I don't argue a given horse.
I argue that if someone volunteers to do programming for a whole community you should give them some respect. The more because you do not or cannot do this work. This whole community, including you, voluntarily uses the fruits of their labour mostly without compensating them.
 Calling them idiots and slaves like you did is just pretty fucking disrespectfull.
MPOE-PR
Hero Member
*****
Offline Offline

Posts: 2596



View Profile

Ignore
March 15, 2013, 07:33:14 PM
 #192

What does this even mean? "independent devs doing it". Dependent on what/whom? If you'd had 100 variants of the original Satoshi client all being developed and bug fixed separately and 100 variants of the mining software all being developed and bug fixed separately then we'd have had many more hardforks by now, with no-one really knowing anymore which is the true bitcoin. Do you go by the first version of the client which allowed anyone to give themselves a billion (well, a lot) bitcoins? Or some arbitrary version someone developed based on that? It simply wouldn't work. Bitcoin needs a majority client in order to not hard fork, and therefore in this sense, it can never be decentralised. The developers of this majority client will always have the power and can make decisions to change what bitcoin is whenever they like. For example, let's say they decide to increase the blocksize from 1MB to 10MB. Who's going to stop them? The users downloading bitcoin-qt? I suspect not. Most people just download it and use it without caring what changes are going on. Yes, we were supposed to be able to vote with our feet, but the people who actually do that are usually in the minority and so will lose.

Considered, yes. One problem is the centralization issue stemming from that approach. The one correct way to handle Bitcoin development is exactly as designed: independent devs doing it. The problem is that instead of doing it they spend their time opining on things that utterly ain't their business.

I don't hold myself responsible for your endless string of presupositions. You think they're true, that's fine, I don't happen to care and it doesn't happen to matter.

I don't argue a given horse.
I argue that if someone volunteers to do programming for a whole community you should give them some respect. The more because you do not or cannot do this work. This whole community, including you, voluntarily uses the fruits of their labour mostly without compensating them.
 Calling them idiots and slaves like you did is just pretty fucking disrespectfull.

I am giving them *some* respect.

Rehashing a defeated (and mostly nonsensical) argument in new terms doesn't lead it more credence.

Pages: 1 2 3 4 5 6 7 8 9 10 All
  Print  
 
Jump to:  

Hosting provided by Private Internet Access, a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.18 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!