Gold collapsing. Bitcoin UP.

[adamstgbit]

a protocol defines the rules by which information is communicated / interpreted. yes i think its safe to say bitcoin is a protocol. bitcoin core is 1 application that uses the protocol, BU is an other.

generally protocols dont change, they must stay as is (or at least backward compatible ) or all the applications that use it will break if it changes, this is where hard forks are bad comes from. they are bad, but a softfork that quietly makes your node ... non-usable ? ... is just as bad.

HOWEVER, the blocksize is hardly a "protocol breaking change" nothing changes in respect to the way things are communicated / interpreted. IMO the blocksize limit is/should be an APPLICATION specific limit, an implementation detail, BU's EC quite appropriately makes blocksize application specific.

 

[awemany]

No, no predictions from me now

Sometimes, talking to someone on reddit feels like talking to Greg by proxy, especially considering the odd delays in the brief answers by the other side, the plausible sounding but easily debunkable 'very-techy-sounding' bullshit, and on top of that, with my second last answer, evoking some sudden downvoting of my posts (Hi Greg, you weren't just summoned to help out Tulip-Stefan, now were you? ):

 

[albin]

@adamstgbit

My counterargument would be, sure Bitcoin uses a protocol, but isn't Bitcoin something a little different, because it has a persistent shared data store and therefore exists an a specific instance of that protocol?

 

[Richy_T]

Yes. "Bitcoin" has several different applications. Just as Lego could be Lego blocks or the Lego corporation or a few other things.

 

[Richy_T]

I'll just point out that there is no written protocol, just the reference implementation. Which is, unfortunately, a pretty bad way to do things and is partly responsible for this mess. The "reference client" contains many things that aren't part of the protocol. Is the 1MB limit? Arguably it is, arguably it isn't but the truth seems to lie somewhere in between.

It's unfortunate that more clarification on the intention wasn't demanded from Satoshi. Though it seems to me that his two-line patch implies it was not intended to be written in stone and even allows a grace period for anyone who is serious about running a node to get their act together.

 

[awemany]

On these OKex tokens. Is it just me, or are the conditions are again weird, vague as fuck and biased towards Core winning?

The discussion on reddit sounds pretty neutral:

https://www.reddit.com/r/btc/comments/76pm18/okex_policy_of_segwit2x_hardfork/

However the discussed bit of "If the hardfork occurs then BT1 will be renamed as BTC. " is indeed pretty weird.

So is "If hardfork occurs, OKEx will release BT2 based on users’ holding amount of BTC at a ratio of 1:1"

What does 'release' mean? Why is it 'release' here and not 'converted'?

As the terms are so that BT1 will become BTC no matter what, aren't the BT1 tokens basically bound to be just priced == 1 BTC?!

With that part, the whole thing doesn't really make sense to me.

Honestly, both this and the bitfinex contract sound like an attempt to take money from naive bigblockers.

As pecuniology on reddit said (paraphrasing): A futures market is in principle quite simple and any language that introduces more complicated post-hoc conditions is a red flag.

Exchanges in the western world, please provide a fair, well-defined futures contract! It can't be that hard, can it?

I am wondering whether exchanges like Coinbase refrain from doing this because they have a say in the outcome as well (as a bigger S2X participant).

Could there be a potential legal reason for 2x-supporting exchanges to stay clear of this?

(But then, not supporting 2x is having a say in the outcome as well - this appears fundamentally symmetrical in that regard ...)

 

[adamstgbit]

@Richy_T

right, we've all heard how it would be helpful to draw up a protocol spec. but this might not be very useful right now, because its probably going to change quite a bit, as we scale... Also i am a firm believer that source code is the best spec, if the code is clean as fuck ( which i'm sure it isn't for bitcoin...), then a spec becomes redundant.

@albin
I get what you're saying, maybe we could say that "bitcoin(BTC) exists Regardless of any one specific instance of its own protocol", BTCs are defined at a lower level then the protocol itself! the data that the evolving protocol produces IS bitcoin.
so you're right, bitcoin is NOT a protocol, in essence bitcoin is a distributed leger, that happens to use protocol to append and interpret itself.
an analogy... the WWW isn't a protocol its a collections of pages sheared and interpreted using a protocol.
bitcoin isn't TCP or HTTP, its raw data.
lol

 

[adamstgbit]

On these OKex tokens. Is it just me, or are the conditions are again weird, vague as fuck and biased towards Core winning?

The discussion on reddit sounds pretty neutral:

https://www.reddit.com/r/btc/comments/76pm18/okex_policy_of_segwit2x_hardfork/

However the discussed bit of "If the hardfork occurs then BT1 will be renamed as BTC. " is indeed pretty weird.

So is "If hardfork occurs, OKEx will release BT2 based on users’ holding amount of BTC at a ratio of 1:1"

What does 'release' mean? Why is it 'release' here and not 'converted'?

As the terms are so that BT1 will become BTC no matter what, aren't the BT1 tokens basically bound to be just priced == 1 BTC?!

With that part, the whole thing doesn't really make sense to me.

Honestly, both this and the bitfinex contract sound like an attempt to take money from naive bigblockers.

As pecuniology on reddit said (paraphrasing): A futures market is in principle quite simple and any language that introduces more complicated post-hoc conditions is a red flag.

Exchanges in the western world, please provide a fair, well-defined futures contract! It can't be that hard, can it?

I am wondering whether exchanges like Coinbase refrain from doing this because they have a say in the outcome as well (as a bigger S2X participant).

Could there be a potential legal reason for 2x-supporting exchanges to stay clear of this?

(But then, not supporting 2x is having a say in the outcome as well - this appears fundamentally symmetrical in that regard ...)

holy crap this is SUPER biased towards core.
the way i read it, CORE == BC1 == BTC, no matter what happens, it appears as tho they dont even think its a possibility that core does not survive as is...

this is nutty.... a fair futures contract is SIMPLE.

1) you can convert BTC to BC1 + BC2 or convert BC1 +BC2 to BTC
2) during the fork BTC trading is no more
3) 666hours after the fork, whichever has more market cap ( BC1 or BC2 ) magically Becomes BTC and the other token remains.
4) if the fork doesn't happen at all, #1 is true indefinitely.

 

[Richy_T]

right, we've all heard how it would be helpful to draw up a protocol spec. but this might not be very useful right now, because its probably going to change quite a bit, as we scale... Also i am a firm believer that source code is the best spec, if the code is clean as fuck ( which i'm sure it isn't for bitcoin...), then a spec becomes redundant.

The problem is, for something to be functional, there needs to be more than just minimal code. Then it becomes a question of how much of the actual code is the spec. Take for example, SMTP. The earliest common implementation of this was sendmail. Sendmail is hugely complex and configurable. If sendmail was the reference client, would other email MTAs have to implement all that functionality to be considered compatible? That would be ridiculous. Instead we have RFC 821, RFC 5321 and friends which describe the protocol and any software which implements that is considered compatible, regardless of language used, back-end databases or underlying systems or libraries.

Bitcoin Core contains code which obfuscates files to guard against poorly written anti-virus software. Is that part of the spec? It uses specific versions of BDB for wallet files. Is that part of the spec? It does uPnP. Is that part of the spec? So when it comes to a 1MB block size limit, we have endless arguments and disagreements when a written spec would have trivially resolved it all. Having a "reference client" was just laziness, I'm afraid to say. It may have worked for bitTorrent but that was a different beast entirely (and even that has seen several protocol upgrades).

You are correct that this may be a bad time to do it. Though the fork which does it first may find that it gives that version of the protocol quite the boost. I think the comfort of being the "one true implementation" of Bitcoin has caused stagnation. The wallet is still a piece of shit for example and many useful innovations are simply not addressed.

 

[adamstgbit]

@Richy_T

thats where the "super clean code" helps, you can define interfaces that define and implement the very low level protocol and have other interfaces which use this interface (with "is a" or "has a" relationship).
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.

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.

clean code is extremely hard to do.

 

[awemany]

holy crap this is SUPER biased towards core.
the way i read it, CORE == BC1 == BTC, no matter what happens, it appears as tho they dont even think its a possibility that core does not survive as is...

Right so and that's very weird market, isn't it? IOW: We split into two coins: One will always be the winner and be convertible to BTC no matter what. The other one will be convertible to BTC (actually maybe not even convertible, but "releasable", whatever that means), in case S2X wins.

Does that mean when I hold both and S2X wins, I have against OKex to give me twice the amount of BTC? So, instant free coin doubling perpetuum mobile? A weird bet against the exchange (with them as the arbiter... ) built into what should only be a futures market? ?!?!

As far as I can see, their BC2 token would be priced basically as the chance to litigate successfully against OKex on this contract + the stupidity noise factor. Other than that, I see absolutely no reason why this would be straight at zero.

 

[adamstgbit]

@awemany
OKex doing this just goes to show how segwit2x will lose. there's such a strong backlash going on its not even funny... the market is being forced into picking BC1, because picking BC2 means betting that most poeple being smart enough to see past the BS, which soounds like a really bad bet.... so now EVERYONE is going to pick BC1 simply because they think thats what everyone else is going to do!
core has successfully taken over BTC.

 

[freetrader]

you can write code in such a way that the code itself is documentation

Unless you're Donald Knuth, you don't, and no-one at Core is Donald Knuth. I don't think literate programming caught on much in the real world, and I don't see it as a substitute for well-written requirements and design docs.

"Super clean code" - @adamstgbit that has no relation to the real world of Bitcoin clients in 2017, so even if if were the case, it would be a hypothetical that doesn't help right now.

My 2c here is that one would need to pick the consensus as it exists at one point in time (for ease, let's pick the pre-2x fork state where max block size is still 1MB), and "freeze" those parts into a spec.
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. Implementation specific stuff - anything that various full clients that follow the same chain might do differently, e.g. wallet format would belong in separate specs (client specific).

On reflection, the OKEx terms for their BT1 and BT2 don't seem too bad. The bias towards BT1 -> BTC seems a little unfortunate, and I would have wished they had come up with a better resolution of which one gets the ticker after some defined conditions (e.g. most accumulated difficulty after two weeks).

 

[satoshis_sockpuppet]

I think the " I was attacked" with no evidence will be the next smear campaign. " I can't release info about the attack because it would make me more unsafe."

 

[albin]

All the usual disclaimers, obviously nobody deserves to have false reports filed on them, yadda yadda yadda, but his quotes in the local news pieces are straight Captain Ahab monomaniacal shit. Whoever did this is an idiot if they expected it to silence him, Lopp could not be happier to be attached to self-aggrandizing drama.

 

[adamstgbit]

I don't think literate programming caught on much in the real world

certainly not in the bitcoin world.

look i dont write "super clean code" myself, so I'm a hypocrite when i say this, but, "cleanliness is next to godliness!"

LOL

 

[Justus Ranvier]

Speaking of false flags and other forms of forum mischief, /u/btcnewsupdates is an account whose post history should be scrutinized.

 

[jbreher]

what's your rationale that it WILL balance?

HeynofairIaskedfirst

Whatevs. Just seems to me that as long as *some* hashpower stays on 'round the clock, the native difficulty will drop enough such that the EDA doesn't get triggered.

Your turn.
[doublepost=1508185028][/doublepost]

I now fully support Bitcoin Cash, having seen the initial support it has gained from the remaining Bitcoin community, it is in many ways the best chance to fulfil the vision of Satoshi with the Bitcoin name.

About time - jzeesh!

jk - welcome to the smart side

 

[albin]

Speaking of false flags and other forms of forum mischief, /u/btcnewsupdates is an account whose post history should be scrutinized.

I have an uneasy feeling that this has something to do with midmagic.

 

[adamstgbit]

HeynofairIaskedfirst

Whatevs. Just seems to me that as long as *some* hashpower stays on 'round the clock, the native difficulty will drop enough such that the EDA doesn't get triggered.

Your turn.

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