Gold collapsing. Bitcoin UP.

[awemany]

@albin: Are you talking about this?
@Justus Ranvier : Yeah, it is a fucking chaos on reddit, also with the BCH vs. BTC battle. So many new folks as well.

 

[albin]

@awemany

Yes, couldn't be a more clear call to start a witchhunt.

 

[awemany]

@albin: Yes. What is also interesting is this psychological shaming tactic for just questioning the motives behind this.

As in "Don't dare to even THINK that this could be a false flag."

It is actually a tactic by which oppressive ideologies tend to operate.

 

[Richy_T]

If you can't tell whats application specific Vs protocol, simply by looking at the code, then the code is "dirty" and needs cleaning.

what is "lazy" is not caring about super clean code, and then saying " oh its ok we'll just write a document which spells out the what the protocol specs" That is the easy way out, the hard way (the better way ) is to have code so bloody clean that the "protocol specs" can almost be automatically generated by just printing out a few .h files.

I disagree. With code-as-spec, firstly, you are holding your coders to unobtainable levels of correctness. It's virtually impossible to eliminate assumptions, particularly those based around languages and system environments. Endianness is one that is well understood but there are others. Then you have ambiguities which may not have been intended but crept in and will likely cause problems in implementations. Then there are bugs. But are there bugs? The code is the spec so what happens is according to spec always. And how are you supposed to write a test rig when the code is being tested against itself? Yes, the code did what the code did, 100% compliance first go.

Written specs exist for a reason. They lay out exactly what an application is supposed to do to comply. It can do more and still comply. It can sometimes do less and still comply. You can write a test rig against it, run your application through and see what breaks and later, when you make changes, run that through again and see what you screwed up. Written specs, if done properly, also follow a specific format so that it is known that the spec fully covers what needs to be covered.

Take, for example, a well known problem with Bitcoin a while back, it used BDB in compiling. That was the spec, that was what it did. When a different version of BDB came out, Bitcoin did what the spec did and used BDB. Only BDB had changed, different code was generated and chaos ensued. A well written spec would have revealed that before it was an issue.

There's a reason there are written specs, just as there is a reason programmers write in pseudocode and not directly into the language of preference. It's a practice that simply produces better results.
[doublepost=1508198921][/doublepost]

e.g. wallet format would belong in separate specs (client specific).

This is one of my bugbears. wallet.dat is fine for an internal format but the wallet file as handled by the user should absolutely be in a well-established, open, preferably text-based format (JSON, XML, whatever). There's no excuse for schlepping binary blobs around in the modern world. (They sort of implemented exporting private keys but it's not ideal). Though I'm not sure why it hasn't gone to HD wallets by now anyway.

 

[jbreher]

you can write code in such a way that the code itself is documentation, and i dont mean adding comments everywhere, rather the structure of the code and the names of things is written such that it clearly spells out everything.

Sorry, but that is simply correct if and only if there will only ever be one single implementation of the protocol. In any instance where interoperability is a concern, the proper approach is to define the protocol independent of any particular code implementation. Which is the reason why nearly every significant protocol is governed by a standalone document.
[doublepost=1508201089][/doublepost]

http://www.urbandictionary.com/define.php?term=insanity

Get some *perspective*, man! We can't even _start_ 'doing the same thing' until the upcoming Coinbase dump occurs.

 

[adamstgbit]

@Richy_T

I appreciate your argument, but i feel compelled to continue to argue my view.

you are holding your coders to unattainable levels of correctness.

not really, the spec is in the wording of the functions classes and methods
example:

class TX, has method isVaild() which looks like
{
isSigValid()
isCRCValid()
isInputsSpendable()
isOutputOK()
}
in this case i dont know if there's any bugs, but i do know the spec... for a TX to be valid it has to have a valid sig, crc, valid inputs... etc

IMO, more often than not there's WAY more bugs in the spec itself then the code.

a spec is good for a relatively high level view of the system as a whole, and maybe some detail here and there. somthing you draw up and give careful thought to, at the very beginning. once its rotted away and no longer reflects the reality of the code, maybe you go fix it up just so you have that high level view which is useful to pull out when you want to make a major change a year later.

Sorry, but that is simply correct if and only if there will only ever be one single implementation of the protocol. In any instance where interoperability is a concern, the proper approach is to define the protocol independent of any particular code implementation. Which is the reason why nearly every significant protocol is governed by a standalone document.

good point.
but really no one should be arguing that taking time to write clean code is not worth it.
truth is a reference client's implementation details WILL be heavily relied upon, by other programmers, spec or no spec.
and clean code WILL avoid bugs, and make future dev easier.
i dont believe for a second someone could make a spec which leaves 0 ambiguity, and if they mange to pull it of, a year later that same spec would be pretty rotted.

This may be impractical because as others mentioned, things are moving, forking, etc. - very dynamic right now. But there's a lot that isn't changing, and that could be properly spec'd.

this is as far as i'd take it:

bitcoin spec 2017:
max 21million coins
coins are divisible up to 8 decimals**

**this spec might soon be deprecated

LMAO, i joke...

 

[Zarathustra]

A breakthrough of anonymous cryptocurrency (Monero et al.) would mean that everybody becomes a potential hostage for ransom demand.

I can't see a solution to this problem. Neither a community nor a society can work on the basis of anonymity.

 

[awemany]

With the current rate at which 2x:1x futures are popping up, surely one exchange must get it right eventually. Sigh.

Here's Huobi.

On the plus side, this sounds very neutral - and I don't know about their blocksize affiliation. But again, why the heck do they make the tokens completely dependent upon which chain they will call Bitcoin?

Is it really so damn complicated and difficult to make the futures dependent upon easily measurable chain state?

I don't care what you call or not call Bitcoin - simply pay out my 2x tokens on the >1MB SHA256-secured chain that resulted from the S2X fork block!

 

[awemany]

The fundamental incompatibility of soft forks with the notion of "full nodes are important" is what really gets the small blockers squirming on reddit right now.

Try it!

 

[molecular]

As I was responsible for the term 'full Norway' let me explain myself. I meant dumping all my BTC for BCH. Perhaps "Bagatell berserk" would be better!

/me looks at cash price.

So who here went *Bagatell berserk*?!?

(like the expression)

My opinion regarding "code as spec": it's a dumb idea. Code is way too specific. It even specifies things that are opaque even to the most acute reader (examples: the DAO debacle, level-db (or was it bdb upgrade?) bitcoin fork). A good specification can be intentionally vague at certain points to leave some room for implementors.

I've written quite a few specs myself and I think I did a good job most of the time (also got feedback to that extent). It's a fine line between nailing down critical details to avoid feature creep and reduce the possibility for false assumptions (about the "unsaid") versus being overly verbose and restricting implementation freedoms and/or flexibility in form/function (let alone wasting time/cost resources). However, these were all "application specifications", not "protocol specifications". I have close to no experience with these (except on the implementation-side) and I wont go into the case of Bitcoin now. Bitcoin is a bit special in this regard, that much is clear.

 

[AdrianX]

A breakthrough of anonymous cryptocurrency (Monero et al.) would mean that everybody becomes a potential hostage for ransom demand.

I can't see a solution to this problem. Neither a community nor a society can work on the basis of anonymity.

The problem is not that we need anonymity, it's we have a right to live free of judgment, given you can't stop people from judging your behaviors social status etc the next best thinking is keeping information private.

That said there are lots of benefits to making some information public and segregating other information for individuals, corporations and society as a whole , ultimately I think bitcoin offers us the best of both worlds. If you want a public company and protection of the state make your information public and pay tax, if you don't that's your problem.
[doublepost=1508255567][/doublepost]

The fundamental incompatibility of soft forks with the notion of "full nodes are important" is what really gets the small blockers squirming on reddit right now.

Try it!

I don't think many can see the cognitive disconnect. My BU node does not get segregated signatures so Segwit rules are degrading bitcoin, solution I need to upgrade to Segwit rules agreed by the BTC authorities, and the old bitcoin rules are obsolete.

 

[Richy_T]

once its rotted away and no longer reflects the reality of the code,

This is part of the point. There is no "the code". If you have multiple implementations, there are several different "code"s and if one of them is going off and doing its own thing to the degree that it is no longer compliant with the spec, then it is simply no longer compliant. Other implementations can point to the spec. If "the code" is the spec then other implementations can suddenly find themselves out-of-spec with no warning. It's as much about change control and how standards evolve as anything.

Playing fast-and-loose with code and spec is fine in the early stages but when a standard "grows up", it needs to be formalized.

 

[AdrianX]

/me looks at cash price.

So who here went *Bagatell berserk*?!?

I'm waiting to see what happens with 2X and to see if there is a 1X fork, I'll make a trade and then after that I'll wait to see what happens 6 months out and make another trade.

For now I've held most of the coins mined since 2011 and I've slowly been buying BCH with that stash. I have about 8% left to convert to BCH, I'm just buying the dips. This pump being a nice surprise, but not unexpected, I was looking at Kraken only yesterday it would have just take about 100BTC to buy BCH up to the 0.07's , I was thinking what would happen if someone tried this and am I glad someone did.

 

[adamstgbit]

This is part of the point. There is no "the code". If you have multiple implementations, there are several different "code"s and if one of them is going off and doing its own thing to the degree that it is no longer compliant with the spec, then it is simply no longer compliant. Other implementations can point to the spec. If "the code" is the spec then other implementations can suddenly find themselves out-of-spec with no warning. It's as much about change control and how standards evolve as anything.

Playing fast-and-loose with code and spec is fine in the early stages but when a standard "grows up", it needs to be formalized.

should we have a central authority that writes the spec?


is it OK that an implementation of bitcoin to mix protocol specific code with its own application specific things? YA but only if that implementation is never used as a spec. The problem with bitcoin is that the reference client is the spec and its code is not clean. Solve the problem by either, creating a separate spec, or by rewriting the code so that the spec is clear to see. I think that since clean code has benefits beyond making a separate spec not so useful, its the better choice.

 

[molecular]

@AdrianX

I'm waiting to see what happens with 2X and to see if there is a 1X fork, I'll make a trade and then after that I'll wait to see what happens 6 months out and make another trade.

After having met you irl I actually believe you are able to act in this rational, analytical, controlled way ;D

For now I've held most of the coins mined since 2011 and I've slowly been buying BCH with that stash. I have about 8% left to convert to BCH, I'm just buying the dips. This pump being a nice surprise, but not unexpected, I was looking at Kraken only yesterday it would have just take about 100BTC to buy BCH up to the 0.07's , I was thinking what would happen if someone tried this and am I glad someone did.

Kudos for holding for that long. Not easy. I haven't managed to do that.

I've been suspecting for a couple of days we might have reached a bottom with accumulation happening (have been doing that myself) looking at BCH/BTC on bittrex mostly and the low sentiment all around. There could be more downward pressure if/when more BCH become accessible to userbases in bulk or some large organizations exit their positions and also in case of an EDA (but to a lesser extent), but it seems there is a sizeable group of buyers with enough positive outlook on Cash to build a floor here. I wouldn't mind going yet another story deeper personally so I could improve my average buying price.

 

[Richy_T]

should we have a central authority that writes the spec?

The fact is that we do. There is even some attempt at formalizing this with BIPs. Where do we go from there?

Good luck on getting Core to write clean code too. They like the level of control that keeping it messy gives them. Just look at the assert() issue which affected BU caused by the fact that disabling asserts was disabled due to critical code being within them (if I understand the situation correctly) and that's "too hard" to sort out. A lot of things are "too hard" for Core apparently. Look at how compact blocks were delayed until x-thin was actually a thing.

 

[adamstgbit]

The fact is that we do. Where do we go from there?

Scrap the reference client and create a lib called BitcoinProtocolInterface written completely separately from any application. bitcoin core devs do not have a GUI to play with, they solely play with this "BitcoinProtocolInterface" lib, that other applications use. the lib can be copied and forked, either to port it to other platforms or to fork bitcoin. "the spec" is the most widely used implementation of BitcoinProtocolInterface lib

edit addendum:
the spec(aka the lib) will necessarily BE bitcoin, but you could have 2 different bitcoins fork away from each other who both use the same underlying lib. for example bitcoin-clients( miner clients or full-node-clients) start to disagree on blocksize, somthing the protocol(aka the lib) doesn't specify!

fuck that sounds good in my head.

 

[Richy_T]

@adamstgbit Now, that I can get behind. I have wanted a totally modular Bitcoin for a while now.

 

[awemany]

2x is a soft fork.

 

[solex]

Scrap the reference client and create a lib called BitcoinProtocolInterface written completely separately from any application. bitcoin core devs do not have a GUI to play with, they solely play with this "BitcoinProtocolInterface" lib, that other applications use. the lib can be copied and forked, either to port it to other platforms or to fork bitcoin. "the spec" is the most widely used implementation of BitcoinProtocolInterface lib..

@adamstgbit Now, that I can get behind. I have wanted a totally modular Bitcoin for a while now.

Is there any mileage in BU formally offering a bounty for this?