Bitcoin Forum
December 16, 2019, 04:38:49 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 214 215 216 217 218 219 220 221 222 223 224 225 226 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 ... 861 »
5261  Bitcoin / Bitcoin Discussion / Re: Peter R's talk at Coinbase -- yes they will 51% attack the minority chain! on: March 24, 2017, 10:16:21 AM
(If nothing else we'll learn a lot from the experience, a $20Billion lesson.. better be good)

there is no $16B-$20B dollars!

thats the speculative bubble number based on a few thousand coins being stired around in exchanges to have a $1000 'price' and the multiplying it by 16m

there are not 16-20 billion actual dollars sitting in bank accounts.
i can make an altcoin tomorrow with 5,000,000,000,000 premined coins. get just 1 coin onto an exchange and sell it to myself for $1.. and instantly have a $5trillion market cap.

so stop talking about the speculative bubble number.. its meaningless. all the holders of the 16m coins of bitcoin are not promised or guaranteed $1000 if they all cashed out today. its not a 'valuation' .. its a bubble number of multiplication
5262  Bitcoin / Bitcoin Discussion / Re: Bitcoin’s Final Obituary? on: March 24, 2017, 09:50:02 AM
guys.
you have been fed a script of hidden meaning. where by soft vs hard has been pushed out as softs best case scenario and hard's worse case scenario. and treated as if thats the only 2 options.

what you dont realise is soft can also cause splits. and hard can also keep the chain united.

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



core do have network splitting code in thir bip9 soft activation
here is their lord speak of such
BIP9 changed to a new quorum sensing approach that is MUCH less vulnerable to false triggering, so 95% under it is more like 99.9% [A] under the old approach.  basically when it activates, the 95% will have to be willing to potentially orphan the blocks of the 5% that remain
If there is some reason when the users of Bitcoin would rather have it activate at 90%  ... then even with the 95% rule the network could choose to activate it at 90% just by orphaning the blocks of the non-supporters until 95%+ of the remaining blocks signaled activation.

[A] basically leading to core centralism of 100% control by core


P.S
those thinking "china control bitcoin".
1. it was cor that gave pools the vote. bypassing user voting privilege. so dont blame the pools.
2. also not as many pools as you may think or as much hashpower as you may think is in control of china
3. if your still wanting to blame china. please stop watching fox news to lower your racial tendencies hypnotised into you. and stop reading reddit to not be fooled into the misdirects of core blaming everyone else, bar themselves
5263  Bitcoin / Bitcoin Discussion / Re: When will SegWit activated, considering BU nodes is a very small number now? on: March 24, 2017, 09:28:51 AM
dynamic implementations know 51% is the out right minimum hashrate. but they know the node count more is crucial. thats why they are waiting for consensus and not rocking the boat with deadlines/threats. only core have mentioned the ban hammer tools of blackmail. (lowered bip9 bans threashold, UASF and mining algo changes) no one else.

dynamic implementations have just plodded along waiting to let the community naturally decide. no harm no foul no desire to split away from the peer network, or they would have done so over the last 2 years.

segwit bypassed the peer node count (for many centralist TIER reasons) intentionally giving the pools the only vote, st deadlines, made threats.

segwit should be asking the 74% no/abstainers why they are saying no/abstaining and tweak segwit to accommodate the wishes of the majority. not get all emotional with blaming pools for not kissing ass or segwit threaten the pools.


it is funny how segwit said they went soft to avoid a 5% node splitting risk as their excuse for not giving nodes a vote in their TIER network concept.

but now willing to throw the blackmailing ban hammers and mining change algos guaranteeing a worse split if the pools dont kiss segwit ass..

for entertainment purposes only: (enjoy the chuckle)
with all the ban hammer talk, the lightning and thunder talk, the wanting to be bitcoin gods. they should rename themselves THOR and call their sidechains, the 'byfrost' because they seem to be playing by some script.. so they might aswell use a script that already exists
5264  Bitcoin / Bitcoin Discussion / Re: Satoshi Economic Missteps? on: March 23, 2017, 10:21:30 PM
within the first few paragraphs... the author lost the plot

"Bitcoin is the top cryptocurrency valued at $16 Billion"
 i laughed
a. there are no $16billion sitting in bank accounts backing up bitcoin
b. bitcoins individual price is not based on 16 mill coins being sold either.
c. the exchange rate is based on only a few thousands coins loaded on an exchange and re-circulated by day traders

in short the author thinking bitcoin is valued at $16B.. is an economics failure.. thats a speculative bubble valuation based on multiplying an average of a small subset of the market..

so i didnt bother reading after that.

edit: screw it i thought id read a little more.. dang the very next line.. and he lost the plot again

"Bitcoin’s percentage value relative to other cryptocurrencies is gradually falling over time"

a. i can make an altcoin right now that has 5,000,000,000,000 coins.. and i can sell just 1 coin for $1. and instantly have it valued at $5 TRILLION, due to how the author believes bitcoin is "valued".. thus i could tank the markets just spending $1 on my alt... lol
5265  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 09:37:04 PM
already have. Those lines of codes are to fix Transaction malleability. Do you agree that needs to fixed? IF so, what is BU doing about it?

segwit fixes tx malleability..?..?.  im laughing

p.s.
people need to voluntarily move funds to new keypairs to disarm their own funds and own signatures from being used in a malleated tx.

malicious users will stick to native tx's and continue doing malleated tx's = problem not solved or fixed

even funnier.. LN doesnt need it..
the simple fact that in a LN. its a 2 co-signer multisig.

each co signer sees the stripped tx and signs it. they can check and double check the tx and see if its malleated.
and if it happens to slip through..

the innocent party is not then going to agree to sign a second non malleated tx just so the malicious person can double spend.
thus LN, just by being a co-signer, double check concept.. mitigates malleability.
5266  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 09:30:27 PM
But it DOES mean to expect 1109 blocks for A and 907 block for B, it is just that
since luck is involved it will be close to those numbers. Could be 1078/938, or 1176/840
or whatever, but it will always tend down to "1109/907" though.
nope its not that predictable

ok


antpool has 565peta 20
slushpool 207peta 12
bitfury has 350peta 12
btc.top has 232peta11
f2pool has 428peta 11

as you can see based on hash power you would expect f2pool to be nearer to 17 not 11
and slush should be nearer 10 not 12

I think the issue is that on the AVERAGE it IS linear. But in real time at any given moment,
it could be anything, even 2015/1. Your comments ignore mining through time, right?
And that is why we have a misunderstanding?

But, the addition of B,C,D will effect Pool A's work after the next difficultly adjustment.
The newly adjustment difficultly will make Pool A's 500petas weaker than the prior difficulty.
difficulty is not adjust by hashrate... just time it took for 2016 blocks..
EG i could make 1 million pools all with say 20peta each... knowing over 2 weeks they have not solved a block.

and have no actual bearing on the speed the other pools make blocks
the difficult wont change differently if im just running them pools or not.. they have no impact on other pools. even if there is now an extra 20mill pta "network hash"

.
how the difficulty is measured,
imagine its measured over 4 blocks(simple maths)
if block A was made in 9:30
if block B was made in 9:30
if block C was made in 9:30
if block D was made in 9:30

then the difficulty would say that they were made ~5% too fast. so adjust 5% more harder difficulty is implied (technically 10% to counter the 5% gain already made vs the 4 blocks yet to come that need to be 10:30.. to hopefully average the 8 blocks 10:00

remember block A solution was from ONE pools work using only that pools hash, no other pool helped.
remember block B solution was from ONE pools work using only that pools hash, no other pool helped.
remember block C solution was from ONE pools work using only that pools hash, no other pool helped.
remember block D solution was from ONE pools work using only that pools hash, no other pool helped.

I understand that. I just don't undesatnd why you would say that Pool A could still get
2016 when more pools enter that are close to their hash power. In thoery, over time
and averaged Pool A should not be able to get close to 2016 blocks, and should lose
more so tend down to an average around 504 block. It might be 623/539/445/409.
But, 623/539/445/409 should average to 504 for Pool A. Anything over 504 is luck
(ignoring that Pool A has a few petas more than B,C,D, I state this in general).
So am I correct here or am I still misunderstanding what you are intending to mean?

in theory maybe. but other things are in play too.
more blocks could have been solved by antpool more often or even by any pool more often but it gets orphaned off and seconds later something else is there taking the glory.
pools cold take advantage of spv/empty block mining to get a few seconds advantage (this actually helps more than pure hashrate)
also by rlaying the block out faster can shave off time compared to trying to hash a few seconds to take the glory

oh and umm.. right now there are way MORE than 20 pools.. but you dont see them as they dont get to be seconds faster then some pools.
thus the actual "network hashrate" is bigger then you think
5267  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 08:30:49 PM
Oh!. Thank you Mr. Jonald for clearing that out. My friends are also getting worried when we are talking about this.
 I think there will be a big dump if this questions like this will not be answered correctly or simply to where some investors could understand it. Even small holders should know this.

just to add.
dont hold your coins in an exchange/third party service.

use a wallet where you own the private key.
coins are in laymans terms attached to the private key soif you import that key into whatever client there is. you have the coins.

if you just have them on an exchange. that exchange may decide not to give you the other split side because you only deposited on one side.(even before an activation)

so keep them off an exchange and you can then have freedom of choice no matter what happens
5268  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 08:24:27 PM
So if BU wins will our bitcoin now will have no value anymore? So should we sell to buy BU?
Trying to understand from an average person's point of view and a level of mind. Please understand I am not into mining.

infact the exchange announcement of naming BU an alt if core pull a contentious trigger. is meaningless in regards to the naming...
by admitting they will accept the coin (no matter what exchanges name it) means the coins have utility.(they are spendable)

what would have been different is if the announcement would of said.. no matter what they would only accept core. then the dynamic implementations wont have much utility.



i know your looking for a economics answer of BUY X sell Y.. but no one can predict future speculation without a time machine
5269  Bitcoin / Bitcoin Discussion / Re: Why not treat Core/Blockstream Lightning/Segwit like an Alt? on: March 23, 2017, 07:42:34 PM
I understand this, but did I contradict this in a prior statement?

But, you do agree that there are "different pools doing their OWN work. competing
against each other" but their independent correct answers is based on the prior 2016
block collective, that is used for difficultly to scale back to a 10 minute average, right?

So for example, if a pool 1 has 99% hash and pool 2 has 1% hash of the total network
hash, and Pool 1 (99%) "drops off" the network, Pool 2 (1%) is still trying to find the
10 minute average block based on a nonce/difficultly that accounts for the total
network hash prior to the Pool1 (99%) "drop off". So Pool 2 has no competition
and they will "always find the blocks first now", but it will take them much longer
on average to find the blocks in general.

In the above para, if Pool 1 (99%) dropped off, then it will take Pool 2 (1%) about
144 days in order to make 144 blocks (1 block per 24h). To get to the difficultly
adjustment, it would take at maximum 2016 days, which is 5.5 years.

Are we in agreement, or am I still missing your point?

the 2016 blocks has nothing much to do with hashrate.

for instance.
pool A could have 500petahash and pool B has 480peta - not that important to state this and you will see why

this would give A a few second advantage..
however. this does NOT mean expect 1109 blocks for A...... 907 for pool B
infact
pool A could be lucky enough that EVERY block which A makes is just 2 seconds faster than pool B
meaning

A gets ALL 2016 blocks.

then if there was a split.
they are both making blocks at nearly the same times on 2 chains. yet the activation 2016 blockcount says that A has 100% power..

it does not mean that because A has 100% block winning that B will take hours to make blocks.


as for the network hash rate

now imagine there was pool C with 480peta
and imagine there was pool D with 480peta

this changes nothing for pool A. pool A still does the same work at the same time with the same 500peta.

but B,C,D are all just unlucky.

the network hashrate going from 980peta to 1,940peta again does not affect pool A's work in the slightest.

all it means is now there are 3 competitors agains A so A may not always get so lucky.
but again this does not mean suddenly A is only making ~500 blocks.. A could still get all 2016.

this is what has been known since 2012 as the risks of a 51% attack. where one pool just has the little edge against the rest to be able to potentially control all the blocks produced.
5270  Bitcoin / Bitcoin Discussion / Re: [POLL] Possible scaling compromise: BIP 141 + BIP 102 (Segwit + 2MB) on: March 23, 2017, 07:30:48 PM
Could some joker jump the gun and start producing/mining SegWit blocks before Flag Day?  Would they be rejected?

Again, my apologies for asking dumb questions.

the funny thing is that segwit meant to be soooo backward compatible that it would be accepted.
yet they need deadlines.
makes me wonder why...

i also said to gmaxwell to instill some confidence by asking their partner BTCC to go make a segwit block and include a segwit tx within that block and see if it is acceptable.. worse case is its rejected and even worse case they could use part of thier $70m to pay BTCC $12.5k to say sorry for wasting their time for making a orphan

if it doesnt orphan. then it would give confidence.... strange thing is they are not explaining why such a backward compatible block actually needs a deadline before being made.

but very funny non the last seeing all the promise become empty
5271  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....
5272  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.

5273  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.
5274  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
5275  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
5276  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
5277  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.
5278  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
5279  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
5280  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.
Pages: « 1 ... 214 215 216 217 218 219 220 221 222 223 224 225 226 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 ... 861 »
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!