Bitcoin Forum
January 24, 2020, 08:32:42 PM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 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 336 ... 873 »
5701  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.

 
5702  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
5703  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
5704  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)
5705  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"

5706  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
5707  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.
5708  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
5709  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
5710  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
5711  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.
5712  Bitcoin / Bitcoin Discussion / Re: Adam Back supports peer-to-peer electronic cash, he just prefers it on altcoins on: March 15, 2017, 04:59:39 PM
You want huge block sizes that would centralize the network while wanting to call that cash, it doesn't work like that, so get your priorities straight.

nodes set the limits.
so nodes wont throw out "gigabytes by midnight" flags. and will ofcourse reject pools that try

nodes will flag maybe 8mb right now as what they are capable of. then pools will incrementally go from 1mb, to 1.002mb to test orphan rate and bugs and then grow from there, OVER TIME to get to limits.

much like
nodes flagged 1mb years ago as what they are capable of. then pools will incrementally go from 0mb, 0.x in 2010, to 0.5mb in 2013, and 0.75 in 2015 and test orphan rate and bugs and then grow from there,

wake up to reality.

we wont have
billions of users by midnight
gigabytes per block by midnight

think rationally over NATURAL growth timescales of the next few years-decades.

otherwise you might aswell be shouting at activision back at 1996 shouting 1mb internet required and 60gb hard drive required. dont make Call of Duty, EVER because dialup and 4gb hard drive limit of 1996.

arguing to not scale naturally OVER TIME with failed logic rhetoric of "it cant cope with huge numbers today" is just (facepalm)
5713  Bitcoin / Bitcoin Discussion / Re: Why bitcoindev prefer to SegWit, we should represent block time to 2 min on: March 15, 2017, 04:33:07 PM
10 minutes or 2 minutes, your still playing the real life argument of

"but i cannot just stand in a grocery line or the line at the rent office for 2-10 minutes waiting for a confirm"

even 2 minutes is still too long for the majority of arguments that are being poked at the 10minute average
hence the LN service as a NICHE and VOLUNTARY side service for those wanting quick 'service' (emphasis voluntary not compulsory)



also. you have to think of the relay network (propagation risks)
if nodes have 8 connections(as an example), it means to get data to all the nodes requires atleast 4 hops if everyone had the 8 connections each (degrees of separation/web peer connectivity)

imagine you download a block in 1second
imagine you verify a block in 2second
but then need to push it out to 8 nodes(8seconds)

3second receive-verify 8seconds(send 8 times) relay nodes receive = 11seconds per hop
44-55 seconds for whole network to receive it

knowing that the 10 minute rule was not a exact science but an average of many blocks over a timescale.

there would be many issues of higher orphans and fighting over blockheight compared to today. where by more blocks are found within seconds of each other before the whole network has received and settled on an fully agreeable new blockheight.

we already even with the 10 minute rule have blocks being found with 20 seconds of each other but then find one of them is dismissed and thrown aside because the network believes another block deserves precedence to be added to the blockheight.



thirdly messing with the reward halving and the timing may seem mathematically possible and only cause mining for reward to stop 8 years earlier affecting just 0.00733~btc of total cap
the sentiment of being able to change the amounts(although end result is so far away and so small deviation) opens up the floodgate of loss of trust that it will/wont be changed again but with a bigger impact sometime in the future



knowing that bandwidth and storage of 1mb/2min is the same as, say 5mb/10min
is not helping bandwidth or storage. so those debates will still continue aswell as adding the debate about propagation risks (as mentioned above)

all for a 2 minute AVERAGE waiting period which some people believe is still too long for real world use anyway
..
where as
a 5mb block (based on OP's DATA of scenario used over the standard 10minutes)
the relay propagation risk has more breathing room to get the blocks around the network before worrying about the other competition as much and also without worrying about the next block height after that being solved before all nodes get the first block.
plus it doesnt mess with the reward halving timing. rewards per block, difficulty retarget or the predicted 2140~ end day of reward mining
5714  Bitcoin / Bitcoin Discussion / Re: Bitcoin core developers attack BU? on: March 15, 2017, 11:20:00 AM
xt, classic, btcd, btcc, statoshi, core, knots, BU etc should all be on the same level playing field in regards to a open community of PEER REVIEW
Who is playing the Utopian dream scenario now? Cheesy You can't really have that if some* players attempt to diverge from the protocol without attaining prior consensus from the whole network.

xt, classic, btcd, btcc, statoshi, core, knots, BU

the ones not crossed out want consensus and happily not put in deadlines. and nodes have not decided to split off in the 2+ years of their implementations being running on mainnet.

however core 0.13.1+ and knots.. bypassed consensus by going soft
willing to split the minority off once reaching 95% (bip9 allows this)
and at worse split at a lower threshold UASF

so im guessing your 'if some* players' has the * referring to core and knots.

after all (which you know because i quoted it to you many times) gmaxwell actually invited the non core implementations to split off ages ago and they all laughed in his face.

non core implementations want to use bitcoins consensus to keep to a single network.
its only core that is shouting opposite to point the blame in the other direction when they themselves pull the ban hammer trigger

Careful what you wish for, unless you have a warehouse full of asics at the ready.
Two words: PoW change.

so logically
blockstream proposals:
removing PoW
removing changing native keys to segwit keys
removing changing peer-to-peer to peer-to-LN
removing node consensus for pool only consensus
bypassing pool only consensus by having upstream filter FIBRE activated UASF

can you not see the big picture?

all thats then left is for them to stroke their sheep into agreeing to a nice licence..
(sarcasm) Hmmm.. i wonder have they hinted they are going to swap to a new licence(we know they have)
oh look so they have
Defensive Patent License
5715  Bitcoin / Bitcoin Discussion / Re: How much BTC do you really have? - the unspendable UTXO on: March 15, 2017, 10:33:37 AM
with a UTXO becoming an input when spending. and the byte count per input being roughly 148bytes.
and bitcoinfee site showing it costs 180+ sats per byte.

any UTXO at or below 0.00026640 just becomes the miners fee just to spend itself (without factoring in the extra cost for the output)

30cents, loose and on its own is now expected as to be worthless and just handed to a miningpool no matter how you arrange it.

id say keep it.

one day devs might start only handling sats per kilobyte and then as the bitcoin valuation goes up. they reduce it down to 10sat per kb

to then be a cost of 1sat per 100byte (thus costing only 2sat(mathematically under 2) to spend a UTXO)
5716  Bitcoin / Bitcoin Discussion / Re: Bitcoin core developers attack BU? on: March 15, 2017, 09:39:34 AM
Franky1, you do understand that BU themselves were the first to publicly release this info, right?

i was actually putting a critical/unbiased hat on and playing with the blockstreamers mindset that:
"BU couldnt fix their own problems and found out after things went public."
(their rhetoric)

and putting shoe on the other foot and switching it, to ask
if those events were involving blockstream(core) code where the community exploited first. rather than secretly inform first(peer review) what would they do

point being.
if core are "independent" then they should help each other out. not kiss ass of one team and only one team. as thats just centralist mindset
EG if core prefer to dominate and stick to a higher TIER, then they have no PEER.

bitcoin should be about PEER review not TIER review

xt, classic, btcd, btcc, statoshi, core, knots, BU etc should all be on the same level playing field in regards to a open community of PEER REVIEW
and not the cat and mouse game of
'im not gonna peer review their code'
then same person
'its not peer reviewed so cant be good'
meaning if your not going to review it. then dont complain about it not being reviewed

EG like a book critic not reading a book. then crying it must be bad because its not been critiqued
5717  Bitcoin / Bitcoin Discussion / Re: BUcoin is officially dead on: March 15, 2017, 08:44:35 AM
diversity is good.

imagine(shoe on other foot) if the network was just core only and they had a bug..
...
(2013: AKA Sipa's big leveldb boo boo) caused more real damage than just a few nodes going offline

however by having many different implementations and being diverse. means people can just run a different node until a bug is fixed.

devs need to start acting independent and helping eachother out.
but if core want to kill(rekt) the network to become kings. then users wont have diversity to protect them, expect another 2013 Sipa boo boo

You know franky1, leveldb was rnike heam's brainchild, right?


you know the issue was about something not fixed between berkely and leveldb, where by it was not (prior to bug) seen that going for the more efficient LevelDB(which we use today) would cause issues for the berkely locks. and wuille did not see this when he helped migrate to leveldb that the locks would cause issues in his many 'efficiency additions' to 0.8.0


separately why did you intentionally write mike hearns name using RNike heaM (lower case looks like.. rnike heam)
i have noticed a few people play with this. you and it seems icebreaker likes to spell it heaM too many times to just be a typo

i have also noticed that certain people use certain buzzwords repeatedly that it became obvious there must be a reason.
BTUcoin, conservative. ad-hom

im guessing there must be a REKT competition going on where certain words/spellings need to be used to be picked up by search

5718  Bitcoin / Bitcoin Discussion / Re: Bitcoin Unlimited Remote Exploit Crash on: March 15, 2017, 07:38:13 AM
Does *anyone* reasonable still want the client of these guys to be the main one on the network? Cheesy

dynamics is compatible with many implementation. even some other "core" nodes that have been tweaked in their own repo's
and yep that includes pools who have set consensus.h & policy.h to be adjustable at runtime.

blockstreams(core) can be dynamic with only a few extra lines of code.

but blockstreams(core) want dominance and want to be the sole codebase.
imagine if blockstreams(core) achieved it withno diverse codebase of differing nodes existing.. and blockstreams(core) had a bug.
it wont be a simple copy and paste keys into an alternative while you wait to fix.. your instead stuck

diversity is good(Sipa's 2013 leveldb bug taught us that atleast)

but todays event atleast shows that core are NOT independent by not wanting to help keep things diverse.

but i do laugh that you think running BU or anything not blockstream is a "power grab".. where the truth is its actually a dilution of power and an increase of diversity by having different 'brands' on the network


which would you prefer:
diversity: a few nodes of one brand go offline due to a bug/exploit
centralist: all nodes of one brand go offline due to a bug/exploit
5719  Bitcoin / Bitcoin Discussion / Re: BUcoin is officially dead on: March 15, 2017, 07:31:31 AM
diversity is good.

imagine(shoe on other foot) if the network was just core only and they had a bug..
...
(2013: AKA Sipa's big leveldb boo boo) caused more real damage than just a few nodes going offline

however by having many different implementations and being diverse. means the network continues and people can just run a different node until a bug is fixed.

devs need to start acting independent and helping eachother out.
but if core want to kill(rekt) the network to become sole dominant kings. then users wont have diversity to protect them, expect another 2013 Sipa boo boo
5720  Bitcoin / Bitcoin Discussion / Re: Bitcoin Unlimited Remote Exploit Crash on: March 15, 2017, 07:18:54 AM
All their btc would be worthless now.

Can you explain the logical link between software crashing, and coins being worthless ?
If they had an exploit that could send unwarranted transactions, THAT would be fun.  But just crashing the node, what does that do ?  If the operating system on which the node runs, crashes, or the computer has a power failure, are coins worthless too ?

nope just copy and paste your private key/seed into an updated client that does not have the bug.
diversity is good.

but imagine if the network was running only core nodes. nothing else was allowed. then your stuck(not destroyed) just stuck waiting
Pages: « 1 ... 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 336 ... 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!