Gold collapsing. Bitcoin UP.

[cypherdoc]

I've already told you I'm spending my time as I think it's most effective.

that's just weird. i remember your entree here quite clearly just a few years back. probing, questioning, learning the code; nothing wrong with that. and then all your efforts going into hard forking BCH away from BTC. and then simply to walk away. i'd think there'd be nothing more "effective" than supporting/nurturing BCH/ABC. and i'm not interested in what you're doing now so stop pretending that's what i'm getting at. it's the mere acts of doing what you've done that make me wonder. maybe you just wanted to divide the community? oh well. i'll try not to bring it up again.

 

[freetrader]

Who said anything about walking away from BCH, @cypherdoc?

This is either all in your head, or you're trying hard to construct a narrative here.

I'll just carry on doing what I think is most effective to put Bitcoin Cash (BCH) in a good position. It's in my own interest, but I hope it will be useful to others too.

 

[awemany]

@cypherdoc:

. maybe you just wanted to divide the community?

LOL, for real? You really suspect freetrader of dividing the community? If there's something I find absurd, then it is this.

 

[freetrader]

@awemany: His concern is legitimate to an extent (since I'm still anon). What he doesn't know is that I had been monitoring Bitcoin developments for a long time until I had had thoroughly enough of Core's course and decided to get involved and active myself.

In other words, pat yourselves on the back, Core devs, you caused me (a frustrated user) to roll up my sleeves.

Initially I thought it would be damn near hopeless to get involved in a fork, because I didn't know the (horrid) code at all, but thanks to @rocks and others, I got over that bump and of course the work to create a small, viable fork is not that complex to someone who has been in software development before. And lucky I found the BU community here who are a bunch of doers who also took me up and helped me when I needed it.

There are interesting parts of the story between 2016 and today which the time to tell isn't right now.

 

[Norway]

You don't have to ask me, you can just ask him. I he's got a different definition of maximalist, then that's his beer, isn't it?

Well, he coined the term you are using.
[doublepost=1543359544][/doublepost]

That's fake news. Some of us even went "Bagatell berserk".

Even I did

 

[adamstgbit]

Maybe my answer to @molecular can help you:

one of SV's talking points is "locking down the protocol".
thanks this helps.

locking down the protocal, but at the same time pushing the limit to 128MB, ironic! I agree uping the limit is hardly a protocol change, but its a change and i'm sure its not the only change SV is making / will make. I guess every change they make will have to not effect "the core protocol" ( a self imposed limitation i am 99% sure they will inevitably break -_- )

I think bitcoin is not ready to have its protocol "locked down", give it a few years, get the tech in there to allow for huge blocks and then Lock it down.


i asked: how is ABC not respecting the ideas expressed in the white paper?

Intending to replace the Merkle tree with a Merklix tree is a big change that makes many people uncomfortable. The sort of thing that needs to be tested out properly on a testnet for a long time, also to give other client & library developers a chance to catch up and catch bugs.

I dont see how this impl. detail changes the big picture... but.. i'll just say that:
i'm not afraid of making changes. i hope their is a process that limits "ops!!" moments.
but by and large i am For any change that poeple can mostly agree on.
i am NOT in favor of waiting for everyone to do the testing they need to do, so everyone feels comfortable.

I guess i have my reasoning more or less figured out. i am in favor of ABC because change is good, change is necessary.

but at the same time, i think its great the SV split off. now i dont even have to care is my reasons are good or not, i have a stake in both schools of thought.

may the best Bitcoin be bitcoin!

 

[go1111111]

If Bob believes most miners are building on Alice's block (not his), he knows that it's a race pitting his hash against the hash of all the other miners. That's a race not worth running.
[doublepost=1543343909][/doublepost]To be clear: we're talking about Bob mining on his block versus most other miners mining on Alice's block.

This is wrong. Bob has found a block at height k, and someone else has already found and propagated a block at height k. Bob knows that other miners won't switch to his block at k unless he finds another block at k+1 before the rest of the network finds a block at k+1. Bob has two choices:

(1) Mine on top of the block someone else found at height k. If he finds the next block, he gets 12.5 BCH (just the ones from block k+1). If he doesn't find the next block he gets nothing.

(2) Keep mining on his own block. If he finds the next block, he gets 25 BCH (from blocks k, and k+1). If he doesn't find the next block he gets nothing.

Either way he's going up against the rest of the network. By sticking with his own block at k he can double his expected value.

 

[AdrianX]

Pieter Wuille makes an easy argument in favor of "doing nothing is safer" while looking out for Bitcoin as p2p cash, especially with that Segwit thing:

@freetrader He just needed more time to understand that limiting transaction capacity actually limits transaction capacity and limited transaction capacity limits use and ultimately growth. Some developers are good in some arias of life but a little slow in others. Apart from that oversight on his part, he's correct.

At the beginning of this 1MB limit debate, I described my self as a conservitive, and some one wrongly assosiated those who wanted to remove the block limit as progresives and those who wanted to keep it as conservatives. The conservative approach is the prudent approach if it takes 4 years to get 50% of the hashrate to remove the limit that is the correct way to do it.

Giving up because the Banks (aka DCG) asked you too is the wrong way. Forking new consensus rules every 6 months is turning out to be a disaster. (Mr conservative predicted it on the day it was announced) Fitting the disaster triggered on a fork day.

 

[AdrianX]

@Peter R
Are you counting internal orphans?

nChain and Co have thrown out all the innovations done by BU on their march to version 0.1.

I don't think they were using any block competition or parallel validation. Those BU innovations from a couple of years ago would have mitigated the orphans while keeping the incentives that make bitcoin work. nChain have thrown the baby out with the bath water.

To me, it seems they are brute forcing the block relay with hardware as opposed to optimizing block relay for scale. Scaling is a combined approach it is multidiscipline.

The relevant data needs to be looked at through the lense of what is curently posable. If I get inspired I'll give it a crack, It is primarily about being relevant. Both Pater and his nemesis are corect, you just have to make up unstated asumptions to justify a position.
[doublepost=1543367261][/doublepost]

There is some truth in it. First time people can build on bitcoins without developers interrupting in some way

One can only hope.

 

[BCH King]

most other miners mining on Alice's block.

How can Bob tell?

 

[adamstgbit]

bob asks.

 

[cypherdoc]

and yes, i'm escalating the rhetoric b/c a bunch of you clowns have been at that for weeks now. don't worry, i can hang.

this is exactly the type of truculent language i've been watching for weeks now.

i'm sure many of you are wondering about my more aggressive tone here as well. one of the people the main person i was referring to was @freetrader.

 

[solex]

@freetrader He just needed more time to understand that limiting transaction capacity actually limits transaction capacity and limited transaction capacity limits use and ultimately growth. Some developers are good in some arias of life but a little slow in others. Apart from that oversight on his part, he's correct.

Wuille's dubious part in this history cannot be whitewashed away. He knew full well that Bitcoin was limited in its use and growth, which is why he write this in Feb 2013:

My suggestion would be a one-time increase to perhaps 10 MiB or 100 MiB blocks (to be debated), and after that an at-most slow exponential further growth. This would mean no for-eternity limited size, but also no way for miners to push up block sizes to the point where they are in sole control of the network. I realize that some people will consider this an arbitrary and unnecessary limit, but others will probably consider it dangerous already. In any case, it's a compromise and I believe one will be necessary.

Later he joined Blockstream and progressively revised his view, by proposing BIP103 with just the slow exponential growth, then finally SegWit, which went live and is today providing about 1.1MB equivalent. Presumably he has long been putting Blockstream's interests above that of the Bitcoin ecosystem.

[PS. I believe we are going in circles on this forum.]

 

[adamstgbit]

This is wrong. Bob has found a block at height k, and someone else has already found and propagated a block at height k. Bob knows that other miners won't switch to his block at k unless he finds another block at k+1 before the rest of the network finds a block at k+1. Bob has two choices:

(1) Mine on top of the block someone else found at height k. If he finds the next block, he gets 12.5 BCH (just the ones from block k+1). If he doesn't find the next block he gets nothing.

(2) Keep mining on his own block. If he finds the next block, he gets 25 BCH (from blocks k, and k+1). If he doesn't find the next block he gets nothing.

Either way he's going up against the rest of the network. By sticking with his own block at k he can double his expected value.

hmmm

it might be in the best interest of the miner to do (2) cuz he stands to gain double.
say he has 1% hash rate. then he has a 1% chance of finding the next block, in both cases.
why would he take a 1% chance of making 12.5 when he can take a 1% chance of making 25??

 

[solex]

BU faces a tough decision. are you going to implement rolling 10 block checkpoints to stay compatible with ABC? as unwriter states, if a chain split can be exploited, one day it will.

The next BU release will not have rolling checkpoints. Obviously, this change had no prior public discussion or consultation with other dev teams. One mitigating factor is that the BU client tracks all valid chaintips.

 

[cypherdoc]

>One mitigating factor is that the BU client tracks all valid chaintips.

can you explain? how does that mitigate reorgs and more importantly, how does that keep it in concensus with ABC? unless you mean that it keeps copies of all chains and will jump automatically to the longer one even in case of a reorg.

 

[solex]

As you know, BU has the emergent consensus logic for handling block size limit disagreement, and this requires tracking multiple forks and making the longest active. It's not a given that an exploit of the rolling checkpoint change will always fork BU off, unless the attack is sustained long-term.

_edit_ re-orgs are not prevented. The fallback is manual config to track the majority fork, and instructions will be posted in such situation. If a BU member wants to raise a BUIP proposal about this, then they can.

 

[warboat]

ABC checkpointing only works at micro level. In realistic terms, it only protects you from Nakamoto Consensus by auto-forking you from it. As a miner, if you find out you are mining the shorter PoW chain because your ABC codebase told you to, you are likely to switch off checkpointing so you don't waste hashpower and risk burning money in the hope that your codebase overuled shitsplit sustains long enough for you to liquidate your mining rewards. Checkpointing is a micro-game bluff that does not work at the macro level.

Checkpointing is the code equivalent of propaganda.

 

[cypherdoc]

uncertainty due to lack of understanding plus a vivid imagination, I guess.



I would've just removed the blocksize limit entirely myself, knowing full well that miners can and would sort out the technicalities (optimizations, block transmission innovations etc) themselves in a safe manner. It had to stay there in a relative "safe zone" imo because some people shat their pants over the prospect of removing it. So the road BCH (ABC) is on regarding blocksize is a compromise in my view, but a workable one. In case ABC devs deny raising/removing it in time we can always fork. To fork now over blocksize is idiotic, but what can you do... it's a viable governance mode. Comes at huge cost, though. Look at the mess!

thought i'd post this as there's just too much shit and suspicion (on all sides) going on around here. i'm sure the conspiracy theories abound. i just heard one that blew my mind:

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA512

i am cypherdoc and i'm back
Nov 27, 2018
-----BEGIN PGP SIGNATURE-----

iQIzBAEBCgAdFiEEeER0TxRH+T8f2YR8rk07282h0AkFAlv+BMYACgkQrk07282h
0AlZCw//Y+4tO6erxwMkEZzw9FF9o0oZ/SmRvMopW6+iS9MGPVGEmifDI2qUybMe
ygSgWFVydf5iH1HzCAdmKfBvGxu3UEPUqzS/Z2dYYAf7A1IiXEFyqZEv7+hmr6w1
5KqKLHwTS1wdkr0eklf6FTgZD+uOW1yxVjOF9A09xxC38Xkem3EkXM1Qm7lgF5fC
SbtjgRhu9LebKJGbKOBCL/l6dTO7mUk5MyBWhxInPYcM3W+G4FKAUCS1DdoKqyLV
Hd/I06iVJr4/0mMIZjTQz/nZM8UGJbhvfWYIvuqRe8RHBI07sDDfdzIabnB+Cnlm
m+bSVuLNAsFp56eNBPfA3yLWWFOoQUBHx7bk5zlvBFW5olIw7n7LoygMJUAKr0//
ldjrc88zulwlic4PAJvTt6DayMb9ZTw8XlbHnYdy70EjWPdWLAiS16DnOzX/xilc
emiqlcsnU7KDy1n7lrLUsy2JCQL0Nd9xYz6ExnSgUXltSjDIPgPIpxfzVyrIfqOQ
FJysXacHgHggonx+vBlKKgoMPbeVwEZjE66UIJEJuSl/7qiXeDz8GksTyOxGsh5p
+tLVm4bZYqNLGHAG2dFdOtkvNj5XOAs9cQYhNBspopXOtywsink6z/zyjwrkp0Vo
qfE1Kuo638kAlywxF8uhS2iD4b0se7VnnWi83wTixtKO/e0Pu+Q=
=oONH
-----END PGP SIGNATURE-----

 

[adamstgbit]

ABC checkpointing only works at micro level. In realistic terms, it only protects you from Nakamoto Consensus by auto-forking you from it. As a miner, if you find out you are mining the shorter PoW chain because your ABC codebase told you to, you are likely to switch off checkpointing so you don't waste hashpower and risk burning money in the hope that your codebase overuled shitsplit sustains long enough for you to liquidate your mining rewards. Checkpointing is a micro-game bluff that does not work at the macro level.

Checkpointing is the code equivalent of propaganda.

what if, as a minner you find that you are minning on the chain you wana be mining, even after an attack, thanks to checkpointing, what do you do then?