Gold collapsing. Bitcoin UP.

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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.
 
  • Like
Reactions: AdrianX and Norway

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
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.
 

freetrader

Moderator
Staff member
Dec 16, 2015
2,806
6,088
@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.
 

adamstgbit

Well-Known Member
Mar 13, 2016
1,206
2,650
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

Active Member
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

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
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

Well-Known Member
Aug 28, 2015
2,097
5,797
bitco.in
@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.
 

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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.
 
Last edited:

solex

Moderator
Staff member
Aug 22, 2015
1,558
4,693
@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

Well-Known Member
Mar 13, 2016
1,206
2,650
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

Moderator
Staff member
Aug 22, 2015
1,558
4,693
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

Well-Known Member
Aug 26, 2015
5,257
12,995
>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

Moderator
Staff member
Aug 22, 2015
1,558
4,693
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.
 
Last edited:

warboat

New Member
Nov 24, 2018
10
17
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.
 
Last edited:

cypherdoc

Well-Known Member
Aug 26, 2015
5,257
12,995
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

Well-Known Member
Mar 13, 2016
1,206
2,650
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?