Bitcoin Forum
January 25, 2020, 05:23:25 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 328 ... 873 »
5541  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 22, 2017, 10:23:40 PM
well you did add the "non-contentious".. rather than just ask about soft..
but here goes.

Quote
for clarity

soft and hard is simply:
soft: pool only vote
hard: nodes and pools vote

below these umbrella terms is what could happen.. in both hard and soft it can either continue as one chain. or bilateral split
softfork: consensus - >94% pools no banning/ignoring of minority. result: small 5% orphan drama then one chain. minority unsynced and dead
softfork: controversial - >50% pools no banning/ignoring of minority. result: long big% orphan drama then one chain. minority unsynced and dead
softfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

hardfork: consensus - >94% nodes, then >94% pools no banning/ignoring of minority. result: 5% orphan drama then one chain. minority unsynced / dead
hardfork: controversial - >50% nodes, then >50% pools no banning/ignoring of minority. result: big% orphan drama then one chain. minority unsynced / dead
hardfork: bilateral split - intentionally ignoring/banning opposing rules and not including them. result: 2 chains

in short PoolA simply ignore and automatically reject blocks of certain version. and they just build on their own.
What you are describing is what I and others call a bilaterial hardfork-- where both sides reject the other.

I tried to convince the authors of BIP101 to make their proposal bilateral by requiring the sign bit be set in the version in their blocks (existing nodes require it to be unset). Sadly, the proposals authors were aggressively against this.

The ethereum hardfork was bilateral, probably the only thing they did right--

by pools doing this. they can keep building their own without halting just by looking at the version and declining it. without even validating its tx contents

what you will find it that there are 2 chains. growing forever.. but because its soft. the non-minin nodes(hard) will get confused be and swapping between the two dependant on height (non-mining node mega orphan drama(causing hard controversy) which then forces the nodes to pick a side just so the nodes dont see the orphan drama causing a hard bilatral split.. or remain with the orphan controversy mega orphan drama of endlessly swapping

but with or without non-mining nodes the pools are building 2 chains and not fighting, just ignoring each other
5542  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 22, 2017, 10:08:44 PM
SegWit would only be an "altcoin" if there was a hardfork with two surviving chains.
Altcoins, in the OPs intention, are only created by hardforks. Softforks can't make altcoins.

yes they can
and thats where the fake sales pitch of the reddit script writers have fooled you

by only talking about the best case scenario of soft
and worse case of hard.. but not mentioning all the options

I don't go on reddit.

Can you explain to me how two surviving chains could exist in a non-contentious softfork?

see now your twisting things

soft can be consensus meaning no split.. or contentious possibly split or bilateral guaranteed

by you intentionally saying non-contentious.. your baiting...
try
"Can you explain to me how two surviving chains could exist in a non-consenus softfork?

and your answer is bip9 has code in it to trigger banning and orphaning..
oh and UASF does too.. i think you can guess what the S stands for
5543  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 22, 2017, 09:49:11 PM
SegWit would only be an "altcoin" if there was a hardfork with two surviving chains.
Altcoins, in the OPs intention, are only created by hardforks. Softforks can't make altcoins.

yes they can
and thats where the fake sales pitch of the reddit script writers have fooled you

by only talking about the best case scenario of soft
and worse case of hard.. but not mentioning all the options
5544  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 22, 2017, 09:27:15 PM
Becouse Bitcoin is the legit one, not like this BU that is a joke with lot of bugs and issues.. I am an amateur talking here but history shown that people want the safe side not the bug side..

you think core is perfect..
hmmm 8 years of orphans - https://blockchain.info/orphaned-blocks  (if perfect there should never be a orphan)
major orphan event in 2013

even now
https://github.com/bitcoin/bitcoin/issues

oh and need we forget. if core is soo perfect then segwit is not needed because there is nothing to "fix"

20 billion dollar and say: Go have fun I don't care what you do with my money..
you do know there is not actually 20 billion in fiat sat around in bank accounts with bitcoins name on it
5545  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 22, 2017, 09:24:44 PM
We can have both. core wants to attack any chain which isn't BU though.

Obviously supporters of each side are going to call the other side the "altcoin".

remember core have been REKTing xt, classic, bu and bitcoinj

yet BU want consensus of all diverse nodes working together.
its core with the ban hammer and blackmails (bip9, UASF, PoW algo change) not the other way round
5546  Bitcoin / Bitcoin Discussion / Re: Why not treat BU as Alt? on: March 22, 2017, 06:46:59 PM
But the reason why I would like to see a "BU altcoin" is that it would be a way to test it thoroughly "in the wild". As many Core supporters (including me) have doubts that its consensus will work as expected, it would be the opportunity to the BU team to show that it works well. In this case it's even possible that at the end Core adopts it and the "original BTC" would come with BU rules.

cough testnet cough

run it on testnet.. oh look now you have your own separate network to test it in the wild
5547  Bitcoin / Bitcoin Discussion / Re: can someone point me to hard (objective) technical evidence AGAINST SegWit? on: March 22, 2017, 06:42:05 PM
Also interesting to note that bitcoin switched back to BerkeleyDB after bugs in LevelDB were found and peoples' databases were getting corrupted...

impoosible (sarcasm)
core are immortal and indestructible gods.
they are needed or bitcoin would die

core never make mistakes. and everyone should(sarcasm again) run core, get rid of diversity, give core their Tier network and then bow down to the overlord of perfection.

P.S sipa was involved in the 2013 transistion from berkely to leveldb and didnt spot the lock bug. hmm. sipa, oh yea the head honcho of segwit..
5548  Bitcoin / Bitcoin Discussion / Re: WIP Lightning Network wallet (video) on: March 22, 2017, 06:16:11 PM
Lightning works best in situations where you trust the vendor


Reason: replay attacks can be done with Lightning. Vendors, particularly physical shops that aren't leaving town any time soon, are a perfect fit, as they would also prefer the instant funds clearing Lightning gives you (there are no blocks to wait for with Lightning, so confirmations are no longer an issue)


That's it. Notice how it doesn't take a whole page to elucidate this Cheesy

told you this months ago. starbucks/walmart becomes the new bitcoin BANK2.0 with 3-5day maturityCLTV after confirm.. and revoke CSV chargeback facility

i even told you a few attack/blackmail methods too to trigger such CSV revokes and blackmailing for higher INchannel fee's by refusing to sign

ofcourse DCG(blockstreams corporate partner) would hope to be the hub between alot of services to rake in the funds to cover blockstreams $70m debt and coinbases $6m and all the other debts
5549  Bitcoin / Bitcoin Discussion / Re: WIP Lightning Network wallet (video) on: March 22, 2017, 05:43:58 PM
dont get me wrong, LN has a niche for certain usecases.. but should be treated as a voluntary side service. not the end solution to bitcoin
It's a much quicker and better way of sending transactions, so if you believe that BU is a better way of sending transactions can't we just treat that as a "voluntary side service" and use the original coin instead?  There's no legitimate situation in which people would just rather have a worse transaction for the sake of it.

you have no clue what bitcoin is about.. and have been drawn into a debate that seems to have gone over your head.
maybe spend less time on reddit and more time learning bitcoin consensus. and think about bitcoin onchain vs offchain(this topic).

this topic is about LN. but to correct your BU fails.. BU will not trigger unless it has full community consensus. thats why for the last 2 years and counting it has just been plodding along making no threats, setting no deadlines and not provoking.

however its core that have threatened banning nodes, orphaning blocks and splitting the network (bip9/UASF/PoW algo change) if core doesnt get their TIER network core want.
sticking to consensus. BU would work as part of a PEER network with many implementations (bar official core(blockstream) releases) so if BU gets majority BU is only part of bitcoin where there is still only one chain, like now.. of many brands happy to accept the new settings and keeping the network diverse by not having a king, where they all validate and work on the same level playing field.

if core trigger.. there will be altcoins where if core get majority it owns bitcoin. as the upper filter TIER treating any other node as unneeded second TIER nodes in a cesspool of stripped block(no witness) nodes, prunned block nodess and spv nodes.



but to address your theory that LN is quicker..
LN: deposit into multisig 10min-30min. make payment 1sec.. withdraw (2week N-lock) followed by 3-5day CLTV delay = nearing 3 weeks before you can spend your change with someone onchain...

onchain: send payment to recipient 10min-30min. = 30min before you can spend your change with someone onchain.

read my first paragraph reply of previous post as to why not everyone needs/will want to use LN (hint, only spending once a fortnight)
5550  Bitcoin / Bitcoin Discussion / Re: WIP Lightning Network wallet (video) on: March 22, 2017, 05:34:40 PM
OK, Franky here is the challenge :

Give me the use cases where you think LN would work nicely in your opinion.
Where will SegWit and the LN not work for you?
What would be your ideal end solution for this scaling issue?
Where will BU address issues that are not being addressed by SegWit and the LN? {Where in your opinion would BU do it better?}
You obviously feel strongly about this... so let's take the dev's out of this issue and just concentrate on the code and what it might bring to the
table.

as for LN
niche market:
those multi spending every day: faucet raiders, satoshidice instant gambling etc
where LN fails to meet market need:
those only buying a weekly shop of groceries or occasional monthly remittance/rent payment.

EG if onchain cost $0.30 each and LN payment was $0.01 and default channel lock was 2 weeks.
niche:
if you gamble once a day. you might aswell voluntarily use LN because LN will cost you $0.74 to deposit, pay for 14 payments and withdraw(close channel). onchain would be $4.20 for 14 tx's
fail:
if you only pay rent every fortnight. you might aswell just stay onchain and pay $0.30. because LN will cost you $0.61 to deposit, pay and withdraw


segwit "promises" wont be achieved.. native malicious tx users would see to that. they wont voluntarily move their funds to segwit keypairs to foolishly disarm themselves..
malleable tx's will still occur, sigops, and just general tx spam will still fill up the base block preventing utility of the weight due to lack of segwit keypair users getting txdata into the baseblock.
plus:
there are 46million!! native UTXO's to 'spend' if you ever hope to achieve everyone moving over to segwit keys to then block off native key utility and actually get the promises.(never gonna happen)

as for malleation. well inside a LN its not just one person signing.. its 2 people.
so if a malicious person signed. their channel counterparty can double quadruple check what and HOW it was signed to see if malleation was used. and then sign their half. obviously the honest guy isnt going to sign the same tx later (malleated then non malleated).. thus the malicious party cant double spend because LN itself makes them reliant on the other person, thus unable to quickly push another tx with higher fee out to override the first one. as their counterparty wont allow it(by not signing).
meaning malleation is solved simply because its a multisig rather than a single sig requirement, making LN a malleability defence in itself without segwit required

to mitigate sigop and data bloat spam.. limit the txmaxsigoplimits. EG  increase the blocksigoplimit. but bring the txsigop back down to 4000. or even less.
its kind of foolish to have a v0.12: 20k blocksigop limit and a 4000tx limit. meaning block cant take anymore tx if 5tx's max out blocklimt (5*4k=20k).
its kind of foolish to have a v0.14: 80k blocksigop limit and a 16000tx limit. meaning block cant take anymore tx if 5tx's max out blocklimt (5*16k=80k).
have it as a v0.14.1: 80k blocksigop limit and a 2000tx limit. meaning block cant take no more if 40tx's max out.(40*2k=80k).
(personally id have gone with 500 txsigop limit. not 4k-16k, that way atleast more tx's get into a block with only quadratic milisecond delays)

also reduce the 0.4mb 'large tx'data bloat) allowance.. why oh why oh why does anyone need 20%(sigop) or 40%(bloat) of a whole blocks limits. for a single tx.. seriously.. thats just asking for abuse.

as for LN in general. the dont re-use address 'side channel' attack is still a risk of LN exploitation(they see many sigs to attempt to figure out privkey) and segwit has not mitigated and has no fix for that

also imagine the promoted LN hop (where people are falsely promised a get rich quick by making profit simply being LN hope nodes)

alice< >daisy < >chris< >eddie< >bob

imagine it cost $0.01 per hop
alice wants to pay bob, but needs to pay daisy $0.03  to cover daisy($0.01 ) and chris($0.01 ) and eddie($0.01) to ensure everyone agrees to get the payment to bob

now imagine the hub

alice< >daisy< >chris
          ^   ^
          v    v
     eddie   bob

now daisy is a hub. alice can now pay bob for just $0.01 fee because eddie and chris are not needed as intermediaries(hop). only daisy is

if you think people will pay $0.03+ to remain decentralised.. when commercial hubs are more direct...with less counterparty issues/disconnects/issues/blackmail risks.. and ofcourse only 1sat.. you will see that LN will become just a massive HUB(bank) where daisy signs the second half of the (bank:cheque) payment for everyone.
P.S cheaper for alice.. but chris and eddie no longer get their $0.01 each when alice wants to pay bob because chris/eddie are not required. only daisy is

so for everyone thinking they are going to earn lots of money just running a LN node.. think again. spenders will bypass the stranger danger risks of hops that can blackmail/revoke and play games. avoid the unneeded extra expense and instead just use a hub instead

also LN is utilising other banking features of 3-5day fund availability after channel close(withdrawal) confirmation CLTV and ofcourse revokes(chargebacks) during that cltv maturity period by using CSV revoke codes

also LN has other issues. you cannot predict the ONCHAIN fee weeks in advance. so what may seem cheap to just throw $5 into an LN this week because you might want coffee at the weekend.. costs you maybe $0.3 to open a channel, $0.01 to pay starbucks and $0.70 to close a channel due to rampant onchain fee leading up to the weekend.

which messes up the $4.29 coffee you were hoping for. because starbucks needs another 40cents to close the channel because the onchain fee is now 70cent not 30 cents
(ln concepts have already envisioned people needing to deposit upto $6 ontop of what people hope to spend just to be used as a separate refundable amount to cover possible close channel onchain tx fee's and also INchannel hop/hub fee.. which rules out utility for the less privileged third world classes who could of benefited from only needing to deposit 20hours labour($1) to buy groceries.

so we should not be pushing LN as the final result and end goal of scaling. because then bitcoin is just SWIFT.NEFTS or RTGS of the banking world where people no longer own their assets due to it all being locked under 'daisy's' control (needs her signature and her morals to not hit a CSV revoke funds button)


overall.
solutions.
stop giving tx's such obsurd txsigop limts of 20% of block limit.
re invent a new priority formulae that actually is not snooby in favour of the rich bypassing priority costs just by staking more. and instead works to penalise those who actually want to bloat every block. example of one here

oh and lets not forget have the blocksize adjustable at runtime so that its not a dev spoonfeed event once every 8 years but more of a community consensus where there are 2 settings:
upper (EG for now 8mb no go above zone)  utilised in maybe consensus.h
and a
lower ('preference' where majority halt it bock size, minority below move up to it)  utilised in maybe policy.h
where by if
3% had 1mb..
1% had 1.5mb
1% had 1.7mb and the other
95% were scattered at 2mb-8mb..
the policy/pref consensus would see 2mb was the preferred lower bound amount for now.. all of which are way below the harder to move 8mb limit of technical tested allowable amount, whereby the 5% minority were pushed up to the 95% acceptance..

hell.. even have a speedtest algo in a node that tests the propagation of seeing a new height, downloading, validating and then relaying out.
and get a 2016 block average to set as the upper limit (no go above limit) where by the preference is more free choice below this, that is affected by preference/policy dynamic consensus

.. rant over.. for now
5551  Bitcoin / Bitcoin Discussion / Re: The BUcoin chinese-funded trojan horse exposed on: March 22, 2017, 02:59:36 PM

In a PoW system, the hashpower majority controls the longest chain.  Supply and demand of the token determines its value.  (simple facts, right?)


nope

the hashpower majority just has more chance of having a block solution faster.. it doesnt mean that the block they produce seconds faster is any bettr or worse.

no one cares about hash power primarily. its about whats an acceptable block first. and then if there happen to be 2 acceptable blocks, the one which was produced using most chain work gets the edge, as a secondary thought.

EG
if you can make a cake because you have 4 arms and you forget to add the flour, thus making gooy soup.. and someone else makes a perfect cake but took longer. the perfect cake still wins. and the gooy 5 second soup gets orphaned even if it took 4 hands to make it instead of 2, even though it made it in 5 seconds.

bitcoin is not just 2 dimensional of needing pools to decide based purely on height, whereby the nodes are just database storage houses.

the nodes are part of the symbiotic relationship to keep pools inline.
bitcoin has atleast 10 different mechanisms.

for instance if nodes did not matter, core wouldnt have needed to go soft... obviously..
but nodes do matter, core just knew they may not get the community vote and so intentionally bypassed the node vote and intentionally handed the vote to pools.
now core is angry that the pools are not kissing core ass. so now core again want to avoid re evaluating and trying something more acceptable. and instead start blaming pools, start making out the pools bypassed node votes. and now threaten the community with UASF and also the pools with PoW algo changes. all to get CORES way, not the communities way

oh and if you think that nodes have no power at all (because you mis-understand core bypassing node power).. then how will core implement a PoW change if nodes have no power....
5552  Economy / Speculation / Re: SegWit losing Bitcoin Unlimited winning -> Moon soon on: March 22, 2017, 02:12:08 PM
I was arguing for continuity by sticking with Core (at least then we know Bitcoin won't likely fail due to a bug).

1. core have no bugs?  oh so segwit is not needed. because there is nothing buggy to fix? cant have one thing without debunking the other Cheesy
2. native keys still work after segwit, malicious tx's will still be a thing. only segwit keypair users(just voluntary key users) are disarmed not bitcoin network
3. by being diverse with different code bases. if a few nodes get exploited. network continues(no big deal). if everyone uses one codebase. boom(2013 all over again)

5553  Bitcoin / Bitcoin Discussion / Re: WIP Lightning Network wallet (video) on: March 22, 2017, 01:44:59 PM
lol

Quote
still working on it, but Iím just working on front-ends to LND which is open source.

much like making a "hello world" GUI and pretending its a live IP chatroom.
where as other groups have been using multisigs for years and doing private trades based on what is in their "escrow reserve"

as for "segwit is needed"
is zorton admitting that core have a exploit in multisigs? that only segwit can fix
is zorton admitting that core have issues and that multisigs are broke?
is zorton admitting that core have broken code?

wow

dont get me wrong, LN has a niche for certain usecases.. but should be treated as a voluntary side service. not the end solution to bitcoin
5554  Bitcoin / Bitcoin Discussion / Re: Article 2,Section 1, Articles of Federation of BU + Closed Source Patch!? on: March 22, 2017, 12:59:22 PM
Franky, please don't be so partisan you lose common sense. Core is not compelled to collaborate with and assist factions dedicated to destroying them and their work. That takes the notion of peer review and cooperation into the realm of absurdity.

There is no way to spin this for BU. It is another major screwup, and their approach to fixing it with a closed-source patch, even if they LATER release the code, destroys the trust that is vital to bitcoin's survival. One can criticize core/SW/LN etc. without being in cahoots with such insanity.

but if truly independent then there are no factions.
but by people saying bitcoin is
dependant on core devs - bitcoin weakness
core devs are not independent - bitcoin weakness
bitcoin should only function with one codebase - bitcoin weakness

my personal opinion is that there should be a dozen different implementations wrote in atleast half a dozen different languages. that way if one has an exploit.. only a few % go offline(like this month)... not 1-2 codebase where big orphan chains and lost transactions and double spends occur(like 2013)

where by consensus (real node and pool consensus) settles on features to improve the network. non of this go soft then blame pools. then blaack mail pools with bilateral splits bull crap


p.s
im not in cahoots with any brand. i kiss no asses. and i think thats what people do not like about me. i am frank about what i say, and i dont kiss asses.. devs can come and go. but thats why a diverse open decentralised network should remain higher priority than sucking up to Gmaxwell.

but i laugh when people confuse my desire for diversity and other options that are not just core.. by trying to pigeon hole in whatever latest REKT campaign cor try to do to keep them ontop.. because it just digs them people into bigger holes by admitting they want centralism

5555  Bitcoin / Bitcoin Discussion / Re: Article 2,Section 1, Articles of Federation of BU + Closed Source Patch!? on: March 22, 2017, 12:52:48 PM
I just say that they still follow/use their "Articles of Federation of BU", but with some loophole inside it Roll Eyes
Obviously, i know closed source software such as bitcoin is bad thing and i don't support BU.

how many people do you think actually read every line of cores code and then compile it themselves. or just rely on "trust" that the binary is ok because other people supposedly have read every line
5556  Bitcoin / Bitcoin Discussion / Re: Article 2,Section 1, Articles of Federation of BU + Closed Source Patch!? on: March 22, 2017, 12:43:49 PM
Bitcoin unlimited using hard fork in its code is having many troubles and will experience many bugs and that is why many are staying with the core developers.

so you admit the core developers are not independent.

because if they were independent they would not be "staying" with core. they would happily peer review other implementations.

bu problem is kind of like an infinity loop

implementation A not independently peer reviewed.
independent peers wont peer review A, because they are staying with central Tier group B
implementation A not peer reviewed.

do you see the problem of where the centralisation actually is

core refuse to get out of their cabin fever box and be diverse to be on the same level playing ground with other implementations
they don't want to be independent peers. they love the dependant Tier model much better
5557  Bitcoin / Bitcoin Discussion / Re: can someone point me to hard (objective) technical evidence AGAINST SegWit? on: March 22, 2017, 10:54:27 AM
When you say "block chain protocol hard fork", you likely mean "bitcoin consensus protocol changes". Which is exactly what happened in 2013, on an emergency basis. The errant code (due to levelDB vs. BerkeleyDB locking differences) validated malformed transactions and blocks, using 60% of the global hashpower. The 60% was overwhelming the correct blocks, and people noticed a large deviation in broadcasted blocks.
  As a fix, the blockchain was voluntarily rolled back in time by 12 hours, new blocks were built on top of it with a patched miner, and a ton of broken blocks were discarded and invalidated. (These blocks incidentally could be considered orphaned)

Also interesting as you point out, that the block size was limited to 512K during this bugfix.

My question is: was any aspect of the block chain itself modified ?  I have the impression (didn't look into the details) that this was an internal bug to core code not respecting the correct construction of BLOCKS and accepting them as valid *while in fact they weren't*.  So one just found out somewhat late that one had been building *an invalid chain*, but discarding (even late) an invalid chain is not the same thing as *modifying how a chain should be build* (THAT is a hard fork in protocol).


the block structure and chain was fine. non of the bitcoin consensus rules were broken.

the bug was how the blocks got saved to peoples hard drives in their local databases.
people using (at the time) leveldb could save the blockchain.. but if using berekly by not upgrading they were having issues saving the blockchain because it was using up all the locks of their berkelydb as the blocks grew beyond 500k (even when consensus had 1mb limit)..

so it was not about consensus rules. but bad database issues

devs didnt peer review what would happen in such cases because.

For instance, suppose that because of a bug in core software, the coinbase of a block jumps to 200 coins per block, and that this goes on for a month.  During this month, in fact, these blocks are simply *wrong* but are nevertheless, erroneously, accepted.  In fact, the error made a hard fork.  When the bug is *repaired*, suddenly, all these blocks are correctly seen as invalid, and the chain is seen as stalled a month ago.  So now, people can start building blocks upon the stalled, correct chain.   If that happens, I don't call it a hard fork, because the true protocol is still valid on the rebuilt chain. (while in fact it wasn't on the erroneous chain for more than a month).

coinbase jumping to 200 coins for a month??

well if everyone (your utopia) was running the exact same core software.. then it would go on for months.
but if nodes were diverse. then they would orphan off the block because it breaks the real consensus rule of 12.5btc right now. and so if the network was diverse enough to not have a majority running the buggy core. those blocks would get orphaned

and the pools running non core wont be making 200coin blocks. so the network wont be running for a month of 200 coins.

but in your utopia of everyone running core then yea expect more issues where after a month, those 4032 blocks of 200coins each block would eventually get orphaned and anyone making transactions during that month will see their transactions of that month disappear. causing merchants who accepted them 4032 blocks and thought they got paid, find out they no longer got paid because their customers transactions of the month no longer exist.

this is why diversity matters

5558  Bitcoin / Bitcoin Discussion / Re: BUg Unlimited - newb here on: March 22, 2017, 01:50:25 AM


Code:
franky1: "ill pretend the newest BUcoin bug is core's fault"

^ logic problem exposed (error code: BUcoin is dogshit)


BU was actually just a fork of core 0.12 (all core 0.12 bugs included)
bu just tweaked a few lines of code to allow dynamics and left it out there for the community of independent devs

it wasnt until fixes were done that people spotted some nodes hadnt upgraded post-fix. so exploited such.

funny part is assert(0) was actually a exploit that was able to harm core 0.12 too

also funny part is that BU devs didnt create it, and people didnt exploit it ntil it was patched.. which then made exploiters realsie that some users were not yet patched against it..

P.S
having BU screw up is actually a good promotion of why diverse brands SHOULD exist on bitcoins main net.

imagine however if EVERYONE was just running core and only core.
then imagine there was a issue with the db locks of the blockchain data..

oh wait.. no need to imagine it.. 2013's leveldb update which  didnt factor in something when moving forward .. causing several hour stall and orphan event.
...

but now imagine if bitcoin remained diverse with many different implementations . if one codebase goes down.. only a few nodes go offline and everything else continues as normal.

so all you crybabies that want core centralisation .. imagine future events like the 2013 leveldb event
anyone who wants diversity. imagine this months 'oh well a few nodes went offline' no big deal

diversity is good. not bad.
keep bitcoin diverse and decentralised and independent. dont advocate for centralised power house
5559  Bitcoin / Bitcoin Discussion / Re: Why not treat BU as Alt? on: March 22, 2017, 01:09:37 AM
Exchanges have already stated they'll list a contentious fork, no doubt they'll be delighted to list something that isn't the child of strife. If it really is superior to its daddy then the market will naturally migrate with no risks to anyone or anything.

emphasis contentious fork.

but what if BU has consensus..
.. remember BU has been around for 2 years and has set no agenda to split or do things contentiously. otherwise they would have.
also even when being offered by cores overlord and CTO gmaxwell to split officially, the community that want diverse opn dcentralsied onchain base block growth said no to him.

so although the core fanatics keep screaming about contentious forks, the only way it will happen is if core trigger it... which they seem to be planning on (UASF + PoW algo change)

which
if there was a CONTENTIOUS FORK (meaning controversial which then triggers core to open up their ban hammer) bu would be treated as the alt by not having majority..
but
if consensus occurs (the thing BU have in mind all along..) with BU having majority.. core actually becomes the altcoin.

bitfinex actually went into deeper detail
core having minority core = BCC
BU having minority bu=BCU

https://twitter.com/bitfinex/status/843226656940679170


devil is in the details of the announcement... "contentious"
5560  Bitcoin / Bitcoin Discussion / Re: Why not treat BU as Alt? on: March 22, 2017, 12:50:31 AM
BU is just a code implementation,

there are MANY
core, knots, fibre, bitcoinj, bitcoin ruby, BTCd, nbitcoin, statoshi, bitcoinxt, bitcoin classic, bitcoinunlimited... and so on.

bitcoin unlimited has set no deadlines, set no schedule of activation. has no zealous banscore tricks, no intention to cause a split.
bitcoin unlimiited wants consensus of many diverse nodes all on one PEER network. (bitcoin remaining diverse open and decentralisation)

however core feel its a threat to their segwit plans of a TIER network of core being the upstream filters, in control of validation and changes in future direction. so core are on the rampage fearing their loss of control..
(there should be no control anyway so anyone arguing core deserve control doesnt understand bitcoin. and is obviously involves in centralising bitcoin)

core first intentionally avoid hard(node+pool) consensus(vote) and went only for soft(pool) vote
then core uses bip9 that has some intentional banning pool/block features to turn their majority to 100% by killing off the opposition.soft(pool) contraversial

core next realised that pools were still unofficially(but a good reasoned safeguard) waited to see what node counts suggested before deciding.
so now core are going heavy. UASF and even as far as PoW algo changes hard(node+pool) bilateral split. to threaten the pools to vote for core or be struck off the network.

and now core see BU as a threat, because its giving the community another option. and risking cores dictatorship.

funny parts to remember.
1. core gave pools the vote so dont blame pools for saying no to core
2. core failed at bribing the community with fee discounts. while cunningly pushing fee's up to counter the discount
3. core will be the ones triggering the splitting of the network rather than accepting a no answer,
4. core are ignoring community views of wanting something else. because it doesnt follow the core corporate roadmap of centralised LN services to repay their $70m+ debt

meanwhile BU will keep on plodding along with no intention to do anything unless there is majority consent
Pages: « 1 ... 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 328 ... 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!