Bitcoin Forum
January 26, 2020, 08:40:54 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 [277] 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 ... 873 »
5521  Bitcoin / Bitcoin Discussion / Re: Bitcoin Unlimited Got Nothing To Do With Bitcoin It's Just An Altcoin It's A SCA on: March 23, 2017, 06:15:34 PM
If he really would want to help for Bitcoin then he would support Segwit and donate for development, instead of supporting Real Bitcoin he created fake Bitcoin and advertise it as an hardork, he is just trying to steal what Satoshi Nakamoto and Original Bitcoin did in 10 years.
If he really wanted to help, he would talk to Core about a compromise involving the continuation of Bitcoin as BTC but with changes to Core's code.  I don't think that Core have handled this very well.

consensus meeting december 2015
segwit +2mb hardfork
compromised agreed

early 2016 core devs backtracked and renigged.. by pretended to be just janitors and not involved with contributing to core..

P.S core did not exist prior to 2013 - core do not own bitcoin. they are just one brand amungst many, that use bitcoin. not own it

P.S segwit was an altcoin running under the blockstream-elements brand from 2014-mid 2016....
5522  Bitcoin / Bitcoin Discussion / Re: Bitcoin Unlimited Got Nothing To Do With Bitcoin It's Just An Altcoin It's A SCA on: March 23, 2017, 06:09:12 PM
segwit is a complete rewrite and requirs people to move funds to diffreny keypairs..

block formation, tx and cobebase does not match the original bitcoin.
it wants to be incorporated without even nodes vote.

seems segwit is the altcoin and dynamics (of any brand) currently running on the main net is just a possible upgrade that people can accept or reject.

BU for instance has been running for 2 years has set no deadlines, made no threats and has not even screamed to change the algo.

yet segwit has.
if anything, its segwits drama and tantrums which have affected things like peoples speculation of the price. by making deadlines bribes, blackmails and threats.
oh remember who made the exchange announcement.. yep segwit supporters calling bu an alt.
oh remember who wants to pull the bilaterate split granade.. yep segwit supporters
ph remember who decided segwit should be voted by pools and not full community.. yep segwit supporters..

all while the dynamic block implementations prod along doing nothing just letting people have an open free decentralised choice of atleast half a dozen implementations/brands that are compatible..

but wait. segwit wants only blockstream(core) to be king.. says alot about which choice is actually open diverse and decentralised.

5523  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 23, 2017, 05:19:50 PM
one day
carlton: forks are bad

next day
carlton: just fork already

next day
carlton: forks are bad

just admit it.. dynamic implementations want consensus. its core that is going to pull the contentious split granade pin, no one else

dynamic implementations have made no threats of banning, changing algo or any deadlines. its just a free open choice and only activates if there is consensus.

if people really want to know what will happen if dynamic accepting pools were to rock the boat without consensus
Quote
2017-01-29 06:59:12 Requesting block 000000000000000000cf208f521de0424677f7a87f2f278a1042f38d159565f5
2017-01-29 06:59:15 ERROR: AcceptBlock: bad-blk-length, size limits failed (code 16)

about 3 seconds of drama.. and its over and in the trash no harm no foul.

it wont matter if the block was 250byte over limit 1mb over limit or 3terrabyte over limit.. 3 seconds later.. its in the trash.

dynamics has no contentious crap. it only works by consensus.
only core using a lower than 95% bip9(yep they can do that), UASF or algo change will cause contentious split

P.S dont blame the pools for being the only vote power of segwit..... core choice that way by going soft.
5524  Bitcoin / Bitcoin Discussion / Re: BTC vs BTU on: March 23, 2017, 04:05:27 PM
-Sewit fix malebility bug that is stoping many development fot BTC

only solved if EVERYONE.. well after activation. moves their funds from native keypairs to segwit keypairs. because only segwit keypair users are disarmed.. not the entire network
but malicious spammers will stick to native keys.. why would they choose to disarm themselves??
meaning malleability will still continue after segwit activates

when you realise the activation itself is not the defence but using segwit keys is disarming the volunteer who moves to segwit keys. you realise segwit has not 100% fixed malleability.

-segwit allows to use LN special channels taht are ultra fast in transfers low amounts so you won't ever border with 10min block at shop
multisig private offchain trades are done now.. segwit is not actually needed for LN function. its just an empty cry by core to find any excuse to sell people on segwits half promises
5525  Bitcoin / Bitcoin Discussion / Re: BTC vs BTU on: March 23, 2017, 03:55:34 PM
eg. bitcoin block every 10 minutes+-... 12.5 btc reward "yay" block size 1mb +-
change to block every 1 minute 1.25btc reward per block "yay" block size 1mb (same same but different) scaled 10 fold.

1. messing with this involves
a. changing the reward mechanism - ugly thought, distrust that if it can be changed to 1.25 easily .. it can also be changed to 200000000000000 easily
b. changing the difficulty mechanism - ugly thought, 10x less hashpower required .. 10x more vulnerable to hash attack
c. changing the reward halving events from every 210k blocks to 2.1m blocks
d. issues with propagation

thats alot of rule changes just to still get 10mb every 10 minutes.. (data passing down cables over 10 minute average, no matter how you play with it as either 1x10 or 10x1)

ok lets delve into 1.d.
imagine it takes 10 seconds to get a block, validate it and ready to relay it out.
in 60 seconds the data has relayed through 6 'hops' of nodes.

..
but remember the block timing is not an exact science of 10min.. its an average. some blocks are solved in 2min some in 40 minutes.

so if we went to a 1minute average.. some blocks can be solved in 20 seconds.
meaning some nodes havnt even got the first block before the second block is trying to get around the network..
.. see the issue..?

this is why 10mins was suggested.. enough time to propagate around and have breathing room before the next block pops up even if that block was lucky to be solved in 2 minutes.
that cant be said for a lucky block of 20 seconds

and finally
2. even 1min is still too long for those complaining about the 10min queue when spending at the grocery store checkout argument
5526  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 23, 2017, 03:30:24 PM
We can achieve on-chain scaling by making the transactions smaller, or other more intelligent ways. Blocksize changes are stupid when those things do more with less blockspace.

and once segwit activates with the hope of getting all them 46m UTXO over to segwit keys to get to the possible tx count(without spam attacking to reduce) of ~4500tx/block... then what

you cant resegwit a segwit to double up again..

oh and the 1mb limit was about limiting bloat

but think rationally

segwits 2.1mb of full data is still 2.1mb of data...
its not 1mb data. its 2.1mb data.

(eg if the 'internet cant cope with 2mb' then the internet cant cope with 2mb)

pretending segwit helps FULL nodes by keeping a 1mb block limit. is not the truth a FULL node is handling 2.1mb
the 1mb is for old now lite clients that might aswell just be SPV clients. segwit isnt helping FULL nodes
5527  Bitcoin / Bitcoin Discussion / Re: BU is closed source??? WTF? on: March 23, 2017, 02:35:45 PM
Isn't releasing closed source patches a temporary solution? They will only do that initially and next day source code will be made public.
But by closed source development they broke some rules. I hope BU developers are aware of that. They are still using QT libraries.

guess you just read gmaxwells script
What BU did was also technically a license violation of some of the libraries.

Of which specific libraries was this a license violation?
Of which specific libraries was this a license violation?
QT.
5528  Bitcoin / Bitcoin Discussion / Re: On a need of judgement in bitcoin governance on: March 23, 2017, 02:26:20 PM
that's not how I see it.

thats because the core devs have gone soft and avoided talking to the bosses and instead asked the secretary to change the company.

however even going soft the workers are now waiting for the secretary to unofficially find out what the bosses want to do before the secretary tells the workers what's acceptable. and now the workers are finger point at the secretary blaming the secretary for not approving their new product straight away.

core shot themselves in the foot by thinking they could bypass the bosses/nodes by going soft. they thought they dont need boos/node approval..
but are now having a finger pointing exercise blaming the pools.. whn it was core that gave pools the vote knowing that pools wont vote without knowing the nodes could handle it and accept it...
the pools wont risk having their work orphaned by nodes, just because core threaten them
5529  Bitcoin / Bitcoin Discussion / Re: On a need of judgement in bitcoin governance on: March 23, 2017, 02:17:59 PM
nodes=boss
pools=secretary.. collating data of bosses and workers expenses
devs=workers.. being janitors maintaining the current company and making new product proposals...

secretary needs bosses approval otherwise secretaries work just ends up in the orphan bin, wasting secretaries time if it doesnt meet bosses standards.
devs need the bosses consent to use the new proposals and expand the company. or reject it and keep the company going in the same direction.

right now dynamic workers made a proposal to the bosses and just leaving it to the bosses to consent or not. no threats no deadlines
right now core workers made a proposal to the bosses andmad threats to support their proposal or they will initiate a strike if the bosses dside to go with dynamics proposal
5530  Bitcoin / Bitcoin Discussion / Re: BUgcoin strikes back on: March 23, 2017, 01:57:52 PM
You're pushing a CLEARLY sub-standard version of Bitcoin, that has MAJOR ramifications for security and decentralisation.

and then
i want 3 miners to control the [core] network and that's all! ( Because that's how many miners will be left [with core] once BU kicks in[with 17] )

sparta is happy with a more centralised mining network and cores more centralised TIER network

hypocrisy at its best.

core only want core nodes to be the upstream TIER of full validation nodes. leaving other implementations in a cess pool of down stream filtered, prunned, no witness, stripped block, half relay network.
where by people need to move funds to new keypairs that are incompatible and not validate to the cesspool of second tier nodes but blindly accepted due to a loophole.

dynamics can move the blocksize and bu, xt, classic bitcoinec and many other implementations can all work side by side as PEERS (core too if they just change a few lines of code)
all on the same level playing field (the actual definition of decentralised) of full validation. no need to strip data out or move users to new keypairs to achieve anything. things just move on

bu for instance has not been well peer reviewed because the cough independent cough devs are too far up gmaxwells ass that they wont independently review BU's tweaks to CORES original 0.12 code. they would rather attack it and say "no one spotted a bug that used to be in core but was patched in 0.13)

its funny when an cough independent cough dev prefers to shout its not been independently peer reviewed, rather than review it himself and help.. just makes himself look bad by admitting he is not independent

will everyone put ego's aside, forget which kings ass you wish to kiss and everyone actually start thinking about the network fundamentals.
5531  Bitcoin / Bitcoin Discussion / Re: Bitcoin Exchanges Unveil Emergency Hard Fork Contingency Plan on: March 23, 2017, 12:56:54 PM
now would pools jump to 2mb where there might be hit by that bug AND say 5 other propagation issues aswell all in one swoop of mega F*ck-ups and then have to tear up and remake a 1mb block with half as many tx's to try again..
or wrongly guess that it must be an issue at 2mb so try 1.9mb and have that block too throwing a tantrum in the orphanage, then try 1.8 and so on all creating orphan tantrums trying to find a new 'sweetspot' that is acceptable(to potential knitpicker: yes i know bitcoin doesnt have an actual 'orphanage' place, im just entertaining wordplay of 'orphan drama' to entertain the imaginations of people with short attention span)
Are you saying that the network participants should put *trust* into the miners in hopes that they don't centralize in order to reduce orphans, but rather produce smaller blocks? Cheesy

what are you even on about "centralize"
the pools earn more by competing.
1. jumping to 2mb instantly makes propagation delays and loses the competitive advantage. so pools will move in small increments to keep their competitive advantage
2. no point jumping to 2mb because there may be several bugs and if going to 2mb then down hoping to find a sweet spot can cost them multiple blocks of wasted time.. can cause many orphans.. due to bugs and propagation.
3. going up from 1mb in small amounts reduces orphan risks and keeps a good grasp of acceptable propagation times.

oh and if you think that going from 1mb to 2mb in small increments of 250bytes would take years.. and thats your real argument im betting.
your wrong. it can take a month of safe testing the water with least orphan risks and least cost to pools and their competitive edge.
increments of 1kb can get to 2mb in a week and increments of 0.25mb can get to 2mb in under an hour

so relax. its best to be safe.. rather then have been waiting years just to get a chance and then try to rush things in 1 block or 1 hour.
1 extra month of good practice safe increments isnt gonna kill bitcoin. but jumping straight to 2mb could cause another 2013 event.
pools are smart enough to know this
5532  Bitcoin / Bitcoin Discussion / Re: Bitcoin Exchanges Unveil Emergency Hard Fork Contingency Plan on: March 23, 2017, 12:45:22 PM
This thing might have been answered several times but still I cannot understand why do we need a hardfork when softfork is available,  aside from that, is  it really necessary that a hardfork is needed In order to upgrade bitcoin features?  Sorry for being so noob about this but I do believe that there is a strong reason why these exchanges are so against the hardfork.

though soft methods are available. where by the pools get to vote.
nodes matter. if there are not a good amount of nodes validating the data diversely than data could be corrupted by one party saying "follow me" and non validators blindly accept them. this is a risk

nodes are important. and we should not aimlessly let the node count be turned into a TIER network of one brand setting the rules and other brands playing pass the parcel of data its not checking.

some soft methods are acceptable because its not changing anything fundamental and still allows the PEER network to check the data and strike off blocks it doesnt approve of.

however in a TIER network some nodes are nothing more then unreliable data stores. so worthless as a security measure and thus no point being a node.

when something rule changing occurs its always best to have good node acceptability first for security purposes of avoiding corruption and to give pools confidence that what pools build will be accepted with full validation.

core however bypassed letting full nodes have a vote on what should be valid. by implying a TIER network where core implementations validate the block that core set new rules to. and then core will strip that block and twist the data to blindly pass other nodes.. not as valid or invalid.. just out of scope of other nodes tests would pass or fail, so blindly kept not due to being fully validated but by not triggering certain old alerts.

this is dangerous.
also by making it easier to do soft patches. is a network security risk because thats where trojan horse attacks can happen even more easily..
by simply not triggering the rules due to finding the hole in the defence to continue unnoticed

core think its good because it allows them an easier life.. but it makes it an easier life for attackers too
5533  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 12:04:45 PM
im just addressing your comment about you and other peoples bad maths of block times

EG
imagine a room
4 tables and groups of people sat at each table.

they are all given a set of  6dice
they have to roll them until someone gets 1,1,1,1,1,1

the red table could get it in 10 minutes.
it does not mean that because red get it in 10 minutes that the brown table would take 20 minutes or the purple table would take 30 minutes or the blue table would take 40 minutes

they could all be seconds apart but because red won, that round only red counts so no one cares about the other 3 tables times.
next round, starts again, this time the brown and blue table both get it but based on how many shakes to get it was just one extra shake in favour of brown. they are shown as doing the slightly miniscule extra amount of work so they win.. other 3 table are not counted.

now then.. if you evict the red and blue from the room.. this does not suddenly make the groups any slower. infact it helps them as there is less competition to beat them by seconds. so now brown and purple can get more blocks more often because there are less competitors to lose against by seconds

..
also a note
the difficulty is not set by "network hashrate" nor is the speed of say red table or blue tables shakes/dice helping brown or purple.
they all have different dice and doing their own work
infact the faster red and blue shake the less chance brown and purple get because red and blue could beat them by seconds.
its not the faster red and blue shake the more thy help brown and purple. (increase of network does not help the work of a single team)

in short
when antpool wins a block. its because of the work done by antpool and antpool only... the other hashrates of the other pools did not jump into their pool to help antpool. antpool alone made a bloke with thir own 600peta. not the networks many exa..

when red wins a diceround. its because of the work done by red and red only the other shakes of the other tables did not jump into the red table to help the red table. the red table alone shook the correct dice combination first with their own teams hands not all the hands of the room.

its a competition of different pools/tables doing their OWN work. competing against each other.. not a collusion of a single pool/room all shaking/hashing one thing
5534  Bitcoin / Bitcoin Discussion / Re: Why Bitcoin won’t hardfork like Ethereum on: March 23, 2017, 11:32:39 AM
dynamic nodes and pools wont trigger unless there is safe majority of three things
1. node acceptance
2. merchant acceptance
3. pools keeping the data secure by high chainwork (laymens combination of hashrate and height)

however
core could release their rage (BIP9 at lower than 95%, UASF or change of algo) and make a contentious attack against dynamic implementations

this is why all the brands which have the ability to accept blocks over 1mb have refused gmaxwells invitation to split away. because the dynamic block implementations will only trigger when there is consensus.
this is why all the brands that have the ability to accept blocks over 1mb have not set any deadlines. not bribed the community with txdata twisting code using new keypairs and blockdata structures to offer discounts, not included nuclear banhammer code to make threats.

they have instead for the last couple years just plodded along allowing the community to freely choose or not choose the many diverse implementations that allow over 1mb base block.

and thats what scares core the most to feel so threatened by the community that they needed to avoid community consensus by going soft and avoid a node vote.. but also shooting themselves in the foot by giving just pools the vote. but pools are smart enough to wait to see (unofficially) what the nodes want to do.(pools wont vote unless clear high node/merchant flags are being waved)
5535  Bitcoin / Bitcoin Discussion / Re: Bitcoin Exchanges Unveil Emergency Hard Fork Contingency Plan on: March 23, 2017, 11:03:48 AM
they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb -straight off. they will see if there are unknown bugs/orphan risks etc
-snip-
Slow increments will not reveal all possible exploits. They will be revealed once someone attempts to use them, at which time damage has already started occuring.

lets say there was another Leveldb 2013 episode, but this time at 1.2mb
the pools dont know its 1.2 yet though

now would pools jump to 2mb where there might be hit by that bug AND say 5 other propagation issues aswell all in one swoop of mega F*ck-ups and then have to tear up and remake a 1mb block with half as many tx's to try again..
or wrongly guess that it must be an issue at 2mb so try 1.9mb and have that block too throwing a tantrum in the orphanage, then try 1.8 and so on all creating orphan tantrums trying to find a new 'sweetspot' that is acceptable(to potential knitpicker: yes i know bitcoin doesnt have an actual 'orphanage' place, im just entertaining wordplay of 'orphan drama' to entertain the imaginations of people with short attention span)
or logically

start in small increments. and when hitting 1.200250mb.. the block causes orphans. so they just take 1tx (250bytes) out of their list and try again. knowing to not pass 1.2mb while things get sorted.
then later when sorted they go again. safely knowing at most its only going to cause minimal disruption... rather then several orphans of going straight to 2mb and haviing to work its way down trying to find a sweet spot. without instantly knowing whats a good or bad size to run with(apart from 1mb again)
5536  Bitcoin / Bitcoin Discussion / Re: Even now in 2017, why is bitcoin *still* not accepted as a major currency? on: March 23, 2017, 02:38:22 AM
Doesn't make any sense TBH. We should've seen it starting to replace conventional currencies by now.
Revolutions happen not at the speed we like but at the speed they can, bitcoin is gaining ground slowly, I think almost everyone in the forum would like this to be faster but it is what it is and we don't have too much of a choice but to wait for it.

wait for who/what

oh for bitcoin to grow legs and a voicebox and walk into your local store and have a word with the manager..

remember YOU being here having bitcoin makes YOU part of bitcoin. if YOU want YOUR local store to accept bitcoin YOU and people near YOU and YOUR local store need to be the arms and legs and voicebox for bitcoin.

bitcoin protocol is just code. not a sentient being.

i done my part i can buy food pay bills etc and helped a few businesses and individuals with bitcoin. i havnt needed to look at my fiat bank balance since 2012-2013

if everyone done something in their area the butterfly effect would see faster results.
if everyone sat on their hand waiting for bitcoin sentient protocol to do it all....... well.. you can wait as long as you like
5537  Bitcoin / Bitcoin Discussion / Re: Bitcoin Exchanges Unveil Emergency Hard Fork Contingency Plan on: March 23, 2017, 02:21:34 AM
Well, no, it does not make it clearer. However, it is peripheral to my point. Which is that it is unlikely that BU miners will creep up initially. They will likely go straight to 2MB. For as long as it takes to clear the transaction backlog. For such would deliver a demonstrably better user experience (faster cheaper transaction processing) relative to the other chain.

Yes, further increases may be likely to be more incremental in nature.


they would actually creep up in increments, thats the smart thing. (as the 500k berkely locks/levelbdb upgrade drama has taught the community)
they done so in the past.(policy.h v0.7 0.5mb, policy.h v0.8 0.75mb, now 0.999mb)

but here is where your missing a few idea's

moving at say 250byte a block increments, means they can reasonably safely get to 2mb in about a month.
so it wont be 2mb activation day .. and it wont be 2mb by 2020 by being slow about the increments.

250byte per block increments = 4 weeks-ish
500byte per block increments = 2 weeks-ish
1kb per block increments = a week-ish

they may even once say the first few blocks above 1mb havnt caused issues. increment it in 0.25mb increments. taking possibly a day or less to get to 2mb... but one thing is for sure they wont just jump to 2mb straight off. they will see if there are unknown bugs/orphan risks etc

so not that long when you think about it
5538  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 02:00:06 AM
in the post from like an hour ago which u revised
I posted and ran to the store, returned, and revised.
When it posted, I noticed you answered even though before I started
your comment was not there.


Quote
Very high consensus can't make two surviving chains.

actually it can.
an altcoin can be made by just 1 node deciding it wll do its own thing if it wanted to.
an altcoin can be made by majority banning and splitting that last 5% minority.

but then that minority have to ask themselves is there a good enough reason to try keeping it going.
(so many scenarios running through my mind.. kinda hard to summarise it all)

a few things we are sure of
1. BU wont trigger unless safe majority of node and pool (no threats, no time bombs, no blackmails. just plod along and let nature handle it)
2, core will have the triggers, time bombs and threats and could trigger while things are contentious, forcing the issue
still too early to tell

If a handful of non-mining nodes are still active, that does not count toward chain status.

In the event we are talking about, there must be some miners. If there is 1 miner/pool with
a "reasonable" amount of hash power, where that single miner has the ability to mine till a
difficultly adjustment within the next year or so, then it is still alive. The question then comes
down to whether they can afford to do so. The answer is very likely that they can not and as
such, the minority chain will die. If it takes that single miner 500 years to get to the difficultly
adjustment, even though the whole community likely left them behind, that chain survives and
will work its way out of the "difficulty snare".

Bitcoin versus Altcoin status can not be determined on "longest chain/most work" because one
day that could be used against the community in an obviously malicious way, IMO.


i think im going to drive your mind crazy now.. Cheesy sorry in advance

5% of pool consensus of blocks does not mean 5% hashpower.
5% of pool consensus of blocks does not mean 20x longer to make a block once going at it with 95% less competition...

save re-writing it
the maths does not work that linearly.

EG if there are 4 pools of equal hash. it does not mean take one away and the time moves to 20 minutes.
because the competition may have only been only seconds behind getting their own solution.

bitcoins are not mined based on the combined hashpower of the network.
each pool makes their own effort. and the "75%" [others] mentioned [as threshold] is not 1 pools.

here this image will make it a bit clearer

as you can see 75% of blocks is just HALF the network hashrate in this example,(top half of image) but the block
timings still are reasonable whichever way you play it(bottom half when they have split)


ok im gonna take a break.. (brain switched off in 3.2.1)
5539  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 01:38:11 AM
in the post from like an hour ago which u revised
Quote
Very high consensus can't make two surviving chains.

actually it can.

an altcoin can be made by just 1 node deciding it wll do its own thing if it wanted to.
an altcoin can be made by majority banning and splitting that last 5% minority will do its own thing if it wanted to.
an altcoin can be made by the last 5% minority banning and splitting themselves do its own thing if it wanted to.

but then that minority have to ask themselves is there a good enough reason to try keeping it going.

(so many scenarios running through my mind.. kinda hard to summarise it all)

a few things we are sure of
1. BU and other lik minded peers wont trigger unless safe majority of node and pool (no threats, no time bombs, no blackmails. just plod along and let nature handle it)
2, core will have the triggers, time bombs and threats and could trigger while things are contentious, forcing the issue or at consensus. but its core rocking the boat more than anything else

still too early to tell

I do not agree. I think an altcoin is always an altcoin until there is one chain.
If there is a bilateral split, the spiting chain will always be an altcoin since that
breaks the Consensus Mechanisms.

So, if both chains survive in a non-bilateral situation, the determination of altcoin
status can not be determined. I think one must die to truly determine who is
the "Bitcoin". If an implementation wishes to be the "new protocol" the old must
die, it can not be "the most hash currently". It must be finalized in general and
for the economies.
its not a simpl "hash wins"

it is about nodes, network confidence of majority nodes and also which merchants allow deposits of it.

funny part is..
by the exchanges saying they will accept bu (and if controversially call it BTU/BCU or consensus call it bitcoin and segwit BCC/SWcoin)
they are actually helping BU and other dynamics to be accepted as "the bitcoin" in a majority event
remember BU wont trigger itself unless it it has the 3.. hash, nodes and merchants.

other matter is.
BU is just one implementation. if a base blocksize limit movement trigger does occur. many implementations(classlic xt) would work with it.
core is just one implementation. if a segwit block trigger does occur. many implementations(btcc, knots) would work with it.

so its not strictly a BU event or a BU chain.. its more of a

dynamic peer vs segwit tier
rather than
bu vs core

but thats just confusing the matters more.
5540  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 01:21:34 AM
So back to the OP, I should have stated this:

Altcoins, in the OPs intention, are only created by hardforks. Softforks can't make altcoins two surviving chains.

SegWit would only be an "altcoin" if there was a hardfork with two surviving chains. and segwit was minority
whereby BU and a flock of other implementations of consensus (classic, xt, and other adjustable blocksize PEER imps) become bitcoin
due to having majority of hash, nodes and merchant acceptance

core could kill off its minority chain and then just add a few lines to be dynamic and join the PEER network of many implementation



BU would only be an "altcoin" if there was a hardfork with two surviving chains. and BU was minority
whereby segwit and a flock of other implementations of consensus (classic, xt, and other imps running as downstream second TIER) become bitcoin
due to having majority of hash, nodes and merchant acceptance

BU could kill off its minority chain without any code changes can just join segwit as a downstream second tier of many implementations
BU could kill off its minority chain and can with segwit code additions join segwit as a upstream first tier with core

i removed this line:
If BU survives and the minority chain dies off, BU transforms from altcoin into "Bitcoin".
because if BU had majority. its already bitcoin along with the other implementations (where segwit is the altcoin or just dead)

theres still some irregularities even with the FTFY summary. due to when/if core triggers their bip9/UASF/PoW change, and which markets treat it as such. and as highlighted if there remained 2 chains or not. or the opposing implementations give in to join the peer or tier network
but its close enough
Pages: « 1 ... 227 228 229 230 231 232 233 234 235 236 237 238 239 240 241 242 243 244 245 246 247 248 249 250 251 252 253 254 255 256 257 258 259 260 261 262 263 264 265 266 267 268 269 270 271 272 273 274 275 276 [277] 278 279 280 281 282 283 284 285 286 287 288 289 290 291 292 293 294 295 296 297 298 299 300 301 302 303 304 305 306 307 308 309 310 311 312 313 314 315 316 317 318 319 320 321 322 323 324 325 326 327 ... 873 »
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!