Bitcoin Forum
January 20, 2020, 09:40:40 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 329 330 331 332 333 334 335 ... 873 »
5681  Bitcoin / Bitcoin Discussion / Re: What is Bitcoin Unlimited ? Is it different from Bitcoin ? on: March 16, 2017, 07:08:51 AM
it's another chain(or altcoin if you prefer) with no limit on the block size, which is currently set to 1MB, it seems that for now this hardfork will not happen thanks to a bug that was discovered in BU

anyway https://www.bitcoinunlimited.info/

^ to correct this guy ^

BU is another bitcoin implementation that has been running for 2 years on the bitcoin network.
bitcoin has many implementations that all run on the bitcoin network

btcd - implementation wrote in Go
nbitcoin - implementation wrote in C#
bitcoin ruby
bitcoinj
Bitcoin unlimited
bitcoin classic
bitcoin xt
bitcoin knots
bitcoin core
bitcoin statoshi
bitcoin btcc

the list goes on.

bitcoin unlimited want the community to vote by using their software if the community want dynamic blocks. where by the blocksize changes and grows at a safe node capable and node accepting rate without needing endless debate with devs and without devs being needed as much to run the network. allowing the nodes to self regulate.

yes its a tweak of core code, but so is many others. simple solutions dont need complete rewrites.

also bitcoin unlimited are not wishing to act like dev-kings owning the network.


which is why over the last 2 years of having bitcoinunlimited running on the network they have not shown any desire to split the network or take control. infact they have done the opposite, and refused to split the network up.

if "other devs" were actually independent they would happily bounce around all the implementations and help the community and peer review all the implementations.. but instead the core devs while wearing a independent shirt are wearing the blockstream name badge and refusing to help out independently. and the scream that other implementations are not independently reviewed (self fulfilling hypocrisy at its best)

instead they just exist as a free and option choice. take them or leave them.
the blocksize will only move forward if the majority of nodes allow it (this means if you run classic, xt or a dozen other nodes that allow for adjustable block sizes, then your still part of the community). an its only a few lines of code to tweak if core want to prepare themselves if the majority decide on it.

if the majority dont decide on it. so be it
the community have voted.
and another implementation proposal offering something the community do want or need may come about.

the whole debate is about fake politics of BU taking over the network.
where the reality is that its core holding back the network with false hope half measure features and bypassing community voting (consensus).

th multiple implementations believe in the real bitcoin of one network of diverse distributed decentralised nodes forming consensus to strengthen bitcoin and kep it robust with no single point of failure.
EG if a few nodes go offline, the network continues.

but if everything became "core only" .. if core had a bug taking core nodes offline. then that would be all node (emphasis in a core only network)
5682  Bitcoin / Bitcoin Discussion / Re: "Super UASF" on: March 16, 2017, 06:48:45 AM
how about get core to offer actual features that do the job they promise.
even you have admitted that cores features only work if users adopt the new keytypes and move funds across
you even admit it would require 100% adoption to get 100% expectation.
Segwit is amazing even without any capacity increase.

lol ? amazing?
you have not even ran any tests or read the code yourself.
stop reading the scripts. your getting obvious

-snip-
this is why people are not running full steam into adopting it. because its not an actual fix. its a complete rewrite of code only offering half measures.
please take off your blockstream defender hat. and put on an unbiased logical hat.
Bullshit. If you truly think that mr. Jihan and his subpools give a damn whether it fixes something or nothing, you have no idea what is going on here. You still keep living in your delusions.

jihan has far less than 15%.(not all of antpool is in the BU camp) chck your stats

can you explain the rest of the network that are undecided and/or against segwit
5683  Bitcoin / Bitcoin Discussion / Re: "Super UASF" on: March 16, 2017, 06:43:46 AM
UASF seems like the only way forward, which should teach these miners a lesson. Initially I was against it, but after reading though it a few times I'm also in support of. BU BTU could simply avoid this by adding SWSF and then advocating their 'emergent' whatever after it activates.

oh lauda..
CORE gave pools the vote
CORE now want to split the network if pools dont give core what core demands.
rather than core just acceting the vote and re  thinking if the promises/feature were actually good enough

and you want to blame pools and non-core..

how about get core to offer actual features that do the job they promise.
even you have admitted that cores features only work if users adopt the new keytypes and move funds across
you even admit it would require 100% key adoption to get 100% expectation.
even you admit that the activation event itself offers no instant feature ability.

this is why people are not running full steam into adopting it. because its not an actual fix. its a complete rewrite of code only offering half measures.
please take off your blockstream defender hat. and put on an unbiased logical hat.
5684  Bitcoin / Bitcoin Discussion / Re: "Super UASF" on: March 16, 2017, 05:55:59 AM
soft for was a pool only vote.. and CORE decided to make their proposal soft. so core have only got themselves to blame of pools say no..
core should take the vote serious and just realise pools say no..

they could have gone hard consensus (node consent THEN pool consent).(whole community vote which would have given pools more confidence if they seen the nodes wanted it)

but guess what.. now core want to avoid hard consensus(node then pool) and go straight for HARD bilateral split..
just splitting the network no matter whats decided with their UASF- (facepalm)

also sheep stroke their flock to sleep with the false buzzwording by calling it USAF.. when reality is UASF is not even soft...

if only people look passed the buzzword games of the reddit scripters and party games of gmaxwell and actually run real scenarios and read real code, people will learn whats really happening.
5685  Bitcoin / Bitcoin Discussion / Re: "Super UASF" on: March 16, 2017, 05:50:22 AM
6000 nodes with this bug, suddenly goes down at the same time and then get patched and brought up almost immediately.

6000 nodes went offline?
LOL
im laughing

it was only a couple hundred and those couple hundred didnt all exactly go offline at same time.. some script kiddy made some code after reading peter todds twitter. that grabbed BU node ip list from bitnodes.io. and ran the code.

some nodes upgraded immediately, some not so immediately and some still havnt yet.

maybe worth you checking the many different node checking websites.

sorry gotta say it again.. you think 6000 nodes went off line.. LOL yo crack me up Cheesy cheers for the laughs
5686  Bitcoin / Bitcoin Discussion / Re: A call to arms: Everyone to run a Core node! on: March 16, 2017, 05:39:10 AM
BU nodes go offline. but the diversity of other nodes kept going..

however if everything was just core.. expect another 2013 event.
diversity and more then one codebase is GOOD for the network
It's good for Bitcoin that it splits in to several different mutually incompatible coins? The combined price of the coins would plummet for sure. Noone wants to use multiple currencies that are hardly different, yet still unfungible.

bu, xt classic, and even some independant core nodes have tweaks to all work together using the same native keys and will not throw out the ban hammer...

there wont be "multiple coins" if dynamics went forward.
core on the other hand are ban hammer heavy and will be the ones causing a split by banning nodes/pools/blocks they dont like.
even bip9 and UASF and even gmaxwell himself have admitted such

where as the other implementations have said they want consensus and wont throw the ban hammer.

wake up and research beyond the reddit scripts.

relying on one team that has one king is no better than fiat. and that is bad.
To be fair, it's BU that wants a "president" and a "secretary" of Bitcoin. No joke. https://www.bitcoinunlimited.info/articles
but bu want consensus (all differing node brands working together on the same network.)
also core that already has the CEO adam back, CTO gmaxwell etc.
but to add to that they dont want diverse distributed decentralisation. the want just distributed centralisation.

if there was a bug in sgwit requiring a downgrade. anyone with funds on segwit keys cant spend them.. locked
Not true. SegWit requires only a soft fork, meaning that it has stricter rules, not incompatible rules, to the original protocol. That way SegWit transactions are compatible with non-SegWit nodes.

lol. learn segwit atleast realise the soft fork is just the activation... but to actually see any segwit features, users need to move funds to segwit keys.
EG if no one moves funds out of native keys to segwit keys.. no tx count boost, no malleation of sigop disarming.
atleast learn segwit.. or are you only on this forum to defend blockstream CEO and not so much any code that could run..

BU nodes go offline. but the diversity of other nodes kept going..

however if everything was just core.. expect another 2013 event.
diversity and more then one codebase is GOOD for the network

relying on one team that has one king is no better than fiat. and that is bad.

BU, xt, classic, and many others (including some core tweaked version, will all run happily together.
but blockstream(core) only want blockstream approved code running which if one goes down. they all go down.



oh and if there was a bug in dynamics requiring a downgrade. blocks just have to drop to below 1mb again and everything is back to as it is now.

if there was a bug in sgwit requiring a downgrade. anyone with funds on segwit keys cant spend them.. locked

Thats a lie, that rebound from BU nodes comming online again happend in a very short time, thats not diversity  Shocked those nodes are in control by a few people! Claiming Core nodes comming down when 1 goes bust is another major lie.

Core nodes are more wide-spread over the globe.

why are you even mentioning geolocation (wide spread over the globe)

im talking about.. implementation diversity .. not distribution
imagine core had the assert(0) bug.. if everyone was all running the same exact codebase. all nodes go offline due to exploit.
no protection from classic. no protection from xt. no protection from knots no protection from a dozen differing implementations that would run while core sort out a release without the assert(0) bug..
5687  Bitcoin / Bitcoin Discussion / Re: BTU Coin Questions on: March 16, 2017, 05:00:06 AM
non-core implementations have been running on bitcoins main net for a couple years and NOT signalled splitting, not signalled banning. they have only shown desire to stick to bitcoins main rule of consensus.

they will only grow when there is clear majority consensus of NODES AND POOLS.
and then even with majority the pools wont push the boat out unless the pools know the orphan risk is low and that the merchants and services that they can spend their rewards with are supporting what they produce.

so dont expect BU to cause a split intentionally.

thy have even laughed in gmaxwells face when he begged them to split.



all the dynamic and base block increase proposals are adaptable to each other and many diverse nodes can function together uniting the community. however blockstream(core) refuse to release an adapted codebase and instead have banscore and autoban stuff to orphan a block, a pool or node that dont meet blockstream(cores) biased rules.

meaning if a majority event happened where the nodes, pools and merchants were ready to go with dynamics. it would be blockstream(core) thats a minority, who will ban their opposition. causing blockstream(core) to self inflict themself into being a minority split by not preparing to join the majority and instead being the banners.

so knowing the majority of merchants nodes and pools are moving forward with dynamic blocks. people on the majority side can just use their native keys as normal and need to do nothing.

but if your on blockstream(core) minority, their ban-hammer event causes them to activate segwit on a minority whereby they are only seeing other segwit nodes/blocks. and as such.. to achieve any noticeable segwit features users will need to start moving funds to segwit keys.

with less hashpower meaning delayed block creation times and people moving funds to new keys causing mempool bloat. and possible 51% attacking the minority pools. extra bloat from replay attacks.. dont expect a smooth transition for the minority SWcoin.



also you can use your pre activation(native keys) on both chains but expect people to be either manually or scripting transactions on one network to be copied and pasted to the other side(replay attack).



now imagine you did safely move your coins on both side to protect yourself from cross network replay attack.
because the events of a dynamic chain having majority, hashpower and node/merchant count.. the SWcoin will be worth alot less.



also note if there was a segwit bug that required downgrading back to old software. the segwit keys become deactivated and any funds on segwit keys are locked.

also note if there was a dynamic bug. blocks are just made at under 1mb again and because dynamic implementations stick with using native keys, users just use their private keys as standard(no fuss).

5688  Bitcoin / Bitcoin Discussion / Re: BU Hard Fork or Segwit Soft Fork newbie questions on: March 16, 2017, 12:27:18 AM
BU, xt, bitcoinj, classic are not demanding a split. not going to ban nodes to split.
meaning that things like BU, XT, classic and other nodes that are compatible to a change in the blocksize will not hurt each other and will grow together...

however it will cause cores over weight ban hammer to trigger and core nodes will start orphaning and banning what it doesnt like.
this was seen by the simple 3 second orphan event of BU making a block that was 1.000250.
xt, classic and other nodes just seen that because the dynamics were not activated to treat it as a rule breaker and reject it. nothing more. things went on just like all other orphans that happen a few times a week. no drama no fuss.. 3 seconds and forgotten

but core went ban hammer heavy and banned nodes that relayed such a block.

all core needs to do is add a few lines of code to allow the 1mb base limit to grow if a certain activity occurs. and core too can continue running on the same playing field as the rest of the community.

but no. core will ban it and be the cause of their own altcoin if an event happened.

the only people wanting an altcoin are the greedy ones. the ones that think they can "double their money".
the issue with this is "what then".... 10 minutes of having double coins.. you spend one half... and then.. all that excitement and greed is over..

then ...... yep stupidity.

to keep bitcoin strong the community need to be working on the same playing field. not looking to have kings and networks of just one code base. and a 10 minute double coin event that ends up in a cauldron of mixed services that are biased against one chain and adoring the other causing user confusion about which coin merchants accept and not accept

diversity, decentralisation is good on one network.
but centralising 2 networks is not good
distribution of a centralised codebase on a network does not mean decentralised
5689  Bitcoin / Bitcoin Discussion / Re: A call to arms: Everyone to run a Core node! on: March 15, 2017, 11:13:27 PM
Did you read about the recent sudden sharp drop in BU nodes? If not, do that. It is all you really need to know to be sure you don't want to hand responsibility over a $20 Billion network to reckless amateurs that don't review the code they crappy code they write. We can just be glad that this bug was exposed before a hard fork, not after.

BU nodes go offline. but the diversity of other nodes kept going..

however if everything was just core.. expect another 2013 event.
diversity and more then one codebase is GOOD for the network

relying on one team that has one king is no better than fiat. and that is bad.

BU, xt, classic, and many others (including some core tweaked version, will all run happily together if a dynamic event occured.
but blockstream(core) only want blockstream approved code running which if one goes down. they all go down.



oh and if there was a bug in dynamics requiring a downgrade. blocks just have to drop to below 1mb again and everything is back to as it is now.

if there was a bug in sgwit requiring a downgrade. anyone with funds on segwit keys cant spend them.. locked
5690  Bitcoin / Bitcoin Discussion / Re: A consensus algorithm that employs neural nets instead of raw computation? on: March 15, 2017, 10:37:07 PM
if it requires a binary answer (even if that binary answer is converted to ascii or other readable thing) the end result is within 6 months there will exist pools of either node sybil syndicates or mining farms doing it more efficiently than solo.

 
5691  Bitcoin / Bitcoin Discussion / Re: A call to arms: Everyone to run a Core node! on: March 15, 2017, 10:01:06 PM
everyone should do what they feel is best for the network, and there is no better way of participating in the debate , then what you describe.

altho i would call on all the BU supporters to run BU nodes.

and all the other node users to support other nodes
but in short dont read the reddit sales pitches. scrutinise things independently. and dont think about short term gains of going for X because it will cause double coins. as thats just temporary drama that ends 10 minutes after you spent them coins.

think about the long term ACTUAL real benefit that can actually be achieved. without reliance on dev handouts every few months
5692  Bitcoin / Bitcoin Discussion / Re: A call to arms: Everyone to run a Core node! on: March 15, 2017, 09:30:54 PM
lol "call to arms"
against.. oh wait
against diversity, decentralisation. freedom and choice.

i see.
so only having core is..
giving power to a higher order of dominance. reducing diversity, choice, freedom. and decentralisation.. but selling the only thing left distribution as the fake meaning of the other features lost.

you do know other implementations have been running for years and set no deadline because they have no intention to just pull a trigger without majority consent. and even then the other implementations are ready for it...... apart from core.. which is adement about blocking any changes that are not king blockstream approved..

but hey consensus is what non core will use and they will not rage with a ban hammer either.
thats the beauty of bitcoins build in features. not needing to ban hammer anything.

however look at all the core dialog
"treat non core as altcoin"
"shout that they will kill bitcoin by forking to become an altcoin"
"beg them to fork to become an altcoin"
"core bip9 to ban opposition pools blocks.. and ban non core nodes from being upstream"
"core: we gave pools the vote intentionally so blame the pools"
"core: if pools dont follow our dictation we will ban them all so our nodes only see what we want"
"core: blockstream have to rule supreme"

it gets hilarious.

especially when you start reading the code
segwit blocks dont look like native blocks
segwit transactions dont look like native transactions
segwit features ar not promed
segwit fixes are not promised
segwit discounts wont get usrs back to a few cents a tx

core is losing grip of its old sales pitches because each 'selling point' has been scrutinised and seen as empty, exaggerated, temporary gesture or just a bait and switch.

kind of makes me laugh that segwit went soft to avoid a real community vote.. and then skipping straight to the altcoin making hard option again skipping a community consensus.

but hey. they have to pay the 70mill back somehow. shame they have to screw with bitcoin to do it
5693  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen now plotting to attack and destroy bitcoin on: March 15, 2017, 08:20:47 PM
oblivious Chinese centralized takeover is sheer lunacy.

lol

think you need to check your fact sheet on that one.

EG antpool distributed into mongolia too
btcc has stuff st up in georgia and iceland
shush managed in thailand.
bitfury also world wide..

even though those 4 are dumbly classed as "china"
lastly.. remember which team went "soft" (bypassing nodes and only allowing pools the vote)
5694  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen now plotting to attack and destroy bitcoin on: March 15, 2017, 07:20:28 PM
jonald_fyookball, franky1, Hyena, how much does Roger and Julian pay you guys to support their shitcoin attempt BTU?

sorry to tell you but im an advocate for:
dynamic diverse nodes using consensus without any dev-kings.
and not any particular 'brand name' of implementation

this is why all the REKT campaigns couldnt categorise and get me with their 2015 'xt shill' 2016 'classic shill' and 2017 'BU shill'

if core (cough not cough) independent devs got rid of the blockstreams oversight and management and censorship you would see totally different debates going on in the community.

but hey if anyone hates blockstreams agenda then blockstream just throw them in the current non-core brand to be rekt category.

kind of boring really,
well not as boring as the same scripts the blockstream defenders keep spewing out since 2014 of how bitcoin needs to centralise, but then needs everyone else to f*rk off so they can command bitcoin.. while playing the victim card of "they f*rked off* while simultaneously begging non-core implementations to "f*ork off"

also boring but stupid how ignorant blockstream defenders are.. (not sure if actual stupidly or actual informed/intentional script plans willingfully spread)
blockstream gave only pools the vote intentionally.
blockstream defenders - "spew out nonsense hating miners voting and non-core nodes being on the network"

5695  Bitcoin / Bitcoin Discussion / Re: Adam Back supports peer-to-peer electronic cash, he just prefers it on altcoins on: March 15, 2017, 06:52:47 PM
hmmm ... zcash... (ill emphasise this more in a minute)

if a zcash chain can handle it then
chain for chain means bitcoin CAN too.
but blockstream says no.. (for reasons of neding commercial srevices to grab fees to repay the 70m+debt hannging over them from VC's

now follow the money
zcash<->digitalcurrencygroup->blockstream

zcash<->http://dcg.co/portfolio/#z -> http://dcg.co/portfolio/#b -> blockstream
5696  Bitcoin / Bitcoin Discussion / Re: Mining with Software not based on Satoshi's Original Code on: March 15, 2017, 06:43:59 PM
im sure SPV mining isnt using the real full node
im sure you can use others too, such as an implementation wrote in Go. (btcd)
im sure the firmware in an asic is not using satoshi code

infact i remember a video of someone using pen and paper to "hash" data

all i see is just an advert for a dev that made a node.js implementation
ok he had his 15 minutes of fame, moving on

as long as the block result hash met the difficulty rules and the origin blockdata match and validate to the consensus rules, no big deal.
5697  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen now plotting to attack and destroy bitcoin on: March 15, 2017, 06:28:32 PM
When does this myth start?

though increasing blocksize has been in conversations as far back as 2010..

after 2014 [blockstream setupshop] things started heating up with the myths of
"gigabytes by midnight" <-illogical myth. it wont get to that so soon. relax think growth over years-decades
"billion users by midnight" <-illogical myth it wont get to that so soon. relax think growth over years-decades
"tech cant advance by midnight" <-illogical. relax think growth over years-decades
5698  Bitcoin / Bitcoin Discussion / Re: Gavin Andresen now plotting to attack and destroy bitcoin on: March 15, 2017, 05:43:55 PM
Then go ahead and activate, since you are so convinced. We'll find out who is living in la-la land.

lol
not verbatim but generalising the silly mindset

blockstreamer: "everyone be afraid, non core will split
community: "nah they wont, they as a community want consensus of everyone playing on an even playing field"
blockstreamer: "you wont get consensus, so you should split and see what happens"

lol
create fear of a non planned event that wont happen. then demand it happen.... lol

so lame
5699  Bitcoin / Bitcoin Discussion / Re: Mining with Software not based on Satoshi's Original Code on: March 15, 2017, 05:27:29 PM
Last March 13, the first block was mined using a different codebase which is not based on the original code of Satoshi.
What is your opinion about it? Is this a good thing or not? Considering that it's not based on Satoshi's C++ Framework.  Huh

pools dont use satoshi's frame work.

satoshi has not been around since 2010. and mining has changed ALOT since then.
satoshi was CPU mining afterall

asics, stratums, more efficient ways of commanding which asic gets which nonce range to not all be hashing the same exact nonce from 0 to X.

as long as the hash RESULT matches the required hash difficulty the network difficulty is looking for.. and the data the hash originates from validates, mining can be done in many ways


funnily enough you can mine with a nintendo NES (but yea forget ever getting a reward due to the inefficiency)
https://motherboard.vice.com/en_us/article/this-nes-mines-bitcoin

as long as the RESULT meets consensus rules. it doesnt matter HOW they got the result. just that the result and actions are understandable to the network
5700  Bitcoin / Bitcoin Discussion / Re: Bitcoin core developers attack BU? on: March 15, 2017, 05:13:23 PM

Indeed.

https://blockchain.info/address/14PUebVa1CpYuFVEvdyCB1vG37SpmBtWQL?offset=0&filter=6

751 inputs, balance 0.26644724 BTC

751 inputs at 148 bytes per input = 111148 bytes
111148 bytes at prompt 200sats/byte fee = 22229600 sats fee = 0.222296 BTC fee

Effective spendable balance (assuming a fairly prompt confirmation)  0.26644724 - 0.222296 = 0.04415124 BTC.

Do you see why some people want to solve this issue?


Good case. Try to SW-sent this (in case SW gets enough hashpower) . Does this get cheaper ?

nope.
because although lets say average fee today was 200sat/byte

with the grace period of activation. followed by the few weeks to wait for a SW wallet active release. and then people sync to it.
(atleast a month)
the fee might be 400sat/byte.

then spending all them outputs(native keys) cost 400sat/byte.. to put into a SW key.. to then and only then only cost 100sat/byte to respend that day...

whereby then your playing the fee war game again because not everyone is on SW keys(thus not getting a real 2mb block) and mempools are still bloated. and that 100sat/byte SWfee wars into 200 sat/byte SWfee and 800sat/byte nativefee

thus no end benefit, because the fee war will catch up with the possible discount.

forget ever going back to 1c/tx average. all your doing is TEMPORARILY back dating fee's by a couple months.
Pages: « 1 ... 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 329 330 331 332 333 334 335 ... 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!