..... anyway. now that comedy sidetrack is now pushed aside..

bitcoin mining does cost money. yes. and thats what backs up a baseline value.(im not talking about speculative volitile ATH price.. im talking baseling (bottomline) value)
EG if gold mining was free gold purchasing would be cheap

at the moment bitcoin mining does not eat into needed demand of residents. it actually buys the EXCESS (above demand) that power stations produced that just goes to waste if not bought.

power stations love it.

as for asics

in late november the math of cost of mining was exa * 277
in mrch-june. it came down to exa*135
and as of october-november it will be exa *65

thats because the cost of the rig and the electric. and the hashrate of the rig change per batch and generation

in october new asics are coming out which have twice the hashrate. the rigs will cost a bit more but thats offset by the reduction in electric used. thus balancing out. .. but effectively being 2x more efficient

again your mentioning the need for elevators.. meaning water has to go up........ (facepalm)
no, no and no. ill say it one more time
it goes downstream. collect in a second area DOWNSTREAM  and goes down again... there is no up

yea you brought up a river thats a crap example and one we both agree is not supportive of such due to cost.
you said it above and you quoted me as i show below. that its about politics and costs and that it would affect the population.. which the electricity demand for the area is not high enough to sway the argument to change that... so why mention the danube.. it has nothing to do with bitcoin mining or hydropower to power bitcoin mining.
no one would be foolish to set up a mining farm in that area..

i am familiar..
im in the UK we have hundreds of canals and thousands of canal locks.. the stupid thing you dont see is you cant use a dam as a 'lock'
a dam is a dam and a lock is a lock. if your going to dam a river you dam a river. boats cant go up
so the only time you dam a river is if the demand for electric outweight the public need for an open river


nope. it does not play out as short term minded as you think
i know your thinking when the price jumped to $20k from novembers lower rate.. that the hashrate must have jumped 3-4fold
no
here ill show you. no spike in december 2017 from
btc.com https://data.bitcoinity.org/bitcoin/hashrate/2y?mining_pool=BTC.com&t=a
btc.top https://data.bitcoinity.org/bitcoin/hashrate/2y?mining_pool=BTC.TOP&t=a
antpool https://data.bitcoinity.org/bitcoin/hashrate/2y?mining_pool=AntPool&t=a

now. here is the thing. the pools above are the main pools that think long term and progress at a periodic growth and when prices go up they dont ramp up more machines 4x and then ramp down just as fast.
Eg the dont ramp up 4x december and ramp down 4x in spring 2018

they make profit and spread it across the year and then progress over the year.
..

now look at these short term pools. you know the ones that now laughingly only have 1% of network hash who are small minded and dont play "the game"
https://data.bitcoinity.org/bitcoin/hashrate/2y?mining_pool=BTCC+Pool&t=a
as you can see they did foolishly sheep follow the price. ..
and if you were to rmeember last year btcc was one of the big names. now its only 1% of network hashpower.
they switched off too many rigs. sold of too many coins in january and then bought too many rigs in january. tried t run them too soon. and by march they had to drop down their rigs again by march
(facepalm) thus now they are stuck with rigs left to gather dust. and no spare cashflow to play any games with..

yea the recent news that bitmain is in trouble is actually that btcc are in trouble.
bitmain are happy spending money in investing in other companies while btcc is closing down business.. as i said btcc is now in the 1% bracket.


lol im laughing
you should be a comedian

you do know bitmain make them right.

i explained above bitmain and the smart pools play the long game.. its actually BTCC that played the short game buying up rigs and then getting face slapped because they ramped up mining too fast due to december.
- hashrate charts dont lie.-

as i said. its stupid that when you make profit. to spend all your profit just to work harder.. btcc learned that the hard way

where as bitmain that have no ASIC shortage and COULD HAVE ramped up their hashrate in december. but they didnt. they played the long game.

anyway.. the bigger point is not about the ATH but sustaining the LOW which sits above $5800

anyway nice talking to you, enjoyed your diverted comments about rivrs unrelated to mining and the comedy of you thinking water has to go uphill via lifting cups of pee or using elevator analogies.. was real funny you cant grasp the concept of down stream...

but great comedy any.. have a nice day

ICO PRIORITY JOB NUMBER 1
actually make something

ICO PRIORITY JOB NUMBER 2
make something that needs to be made.

ICO PRIORITY JOB NUMBER 3
dont use the main bitcoin categories, keep it in altcoin section

ICO PRIORITY JOB NUMBER 4
care less about spamming for adoption
if its any good people will flock to it naturally

ICO PRIORITY JOB NUMBER 5
stop using such big writing

lol seems me and powell and now someone else found the inconsistency in the story..

lol

hmm
bought 20btc at $8k ($160k) and 50 at $11k($550k)

if you have $710k spare to hand... then in other assets and stuff you probably already would have been a millionaire before you begun. so i dont see how you would comment of a dream to be a millionaire.

im guessing this story is more like you bought 2btc then 5btc and decided to add a zero to both to sound impressive.

anyways
you never lose unless you actually sell at a loss. prices move up and down.

although there is a chance that the price could nip below the $5800-$6k support line held since november 2017 this  would not be due to trading Hodlers. but due to at worse some new mining asic releasing in october which if the hashrate does not increase equal a mining cost decrease for those running the more effienct(cheaper cost) asics which could prompt them to sell for less.

but the percentage of coins mined in such case vs the coins that circulated/traded above the $6k line wont present much of a threat to turn the price downward by much.

it would have to be a world collapsing tragedy to do that.. which the recent network effecting bug this week seemed to have not caused such negative impact.. just a temporary slip to 6100 and then suddenly up to 6700 so.. chances of a $5000 are very very slim

the $5800+ supports of the last 10 months have been tested alot and it seems no one is foolish to break it.

as they say never sell at a loss and the UTXO movements and current mining costs show the majority over 65% wont sell for less than $5800(i would say more but its not been that long since the most reason Low test)

question translated:
Is Bitcoin stored in the Core wallet?
I mean how is the upgrade as urgent, no one can access my private key properly?

answer:
Bitcoin is stored on the blockchain. Your wallet is for your private key.
bitcoin-core is software that connects two parts

This error does not affect your wallet.

If people need to upgrade but not upgrade then. If a mining exploit block occurs, they will get it and send it to someone causing the problem to some people.

If no one is vulnerable to software attacks. Then an exploited block is ignored by everyone


If a block uses malicious exploits:
This error can cause any new transaction to appear as confirmation and then not confirmed.
As well as the ability to create more fake btc appear,
but only if someone can exploit a block and only lasts until the exploited blocks are deleted.

answer translated:
Bitcoin được lưu trữ trên blockchain. Ví của bạn là dành cho khóa riêng của bạn.
bitcoin-core là phần mềm kết nối hai phần

Lỗi này không ảnh hưởng đến ví của bạn.


Nếu mọi người cần nâng cấp nhưng không nâng cấp thì. Nếu một khối khai thác khai thác xảy ra, họ sẽ nhận được nó và gửi nó cho ai đó gây ra vấn đề cho một số người.

Nếu không ai dễ bị tấn công phần mềm. Sau đó, một khối bị khai thác bị bỏ qua bởi tất cả mọi người

Nếu một khối sử dụng khai thác độc hại:
Lỗi này có thể khiến bất kỳ giao dịch mới nào xuất hiện dưới dạng xác nhận và sau đó không được xác nhận.
Cũng như khả năng tạo thêm btc giả mạo xuất hiện,
nhưng chỉ khi ai đó có thể khai thác một khối và chỉ cho đến khi các khối bị khai thác bị xóa.

(excuse any broken vietnamese i speak english and used google translate to vietnamese)

lightning is a separate network.
many coins will use it.

lightnings concept is similar to the 19th century bankers gold concept

"using gold for coffee is cumbersome.. here lock your gold into these vaults (LN factories) and ill sign you a transaction promissory note that you can then play around with. and if i like the recipient and see my signature i will authorise my payment to them. because its faster easier and cheaper than handling confirmed gold"

and now..
"if you dont want the promissory notes. here have a bag of copper, brass, tin and nickel coins"

think about it...

history has shown that gold is no longer a payment method. a medium of exchange or a common currency. but something held and owned by the vaults(ln factories)

i did try to keep this topic away from certain people replying. but that certain kitty in sunglasses must not have read the grey writing

anyway, moving on


i do read and review their code. but my interest is more in looking for issues that change the bitcoin networks purpose. not to debug a codebase i do not use

i have though informed them of bugs before. i can even remember achowe and myself arguing for months about the 'anyone can spend' issue pre segwit if using segwit transactions before activation
and eventually and funnily enough. core eventually without admission succumbed to the realisation and they done a work around by not letting people actually make a segwit formatted tx until weeks after it was activated. to ensure the issue i addressed would not occur. (though he will not admit remembering such conversations nor my input had any impact on that workaround yet forum post dates and quotes can be found)
its also why segwit would have only worked with 100% segwit compliance instead of their weak 35% flag.. but thats been discussed endlessly in other topics about their methods of getting 100% compliance

so moving on

 i personally do run my own node and it has not crashed and does not have that bug and it's my own code. because i did not use c++, thus i did not just copy and paste it from core.
it was wrote from scratch and does validate transactions and does validate blocks and relays transactions and blocks but i say this
(pre-empting  standard core defence replies)
 it is not xt,classic,bu, abc based either. nor am i part of the cash group.
i am independent and believe in a diverse network of multiple teams that use consensus as it should be used
certain some who again are defending core by thinking diverse codebases being on the same network are the enemy. will not tolerate such sacrilegious code. so i just use it for myself, happily

again lets keep this about the network diversity and not the picking of names and insulting (i know, they poked the bear and i bit. but lets get back to concentrating on the matter at hand)

---

edit to avoid spam but address the comment below ill repeat whats already been said:
certain some who again are defending core by thinking diverse codebases being on the same network are the enemy. will not tolerate such sacrilegious code. so i just use it for myself, happily

that has been tried for years by other teams that wanted a united network of multiple implementations (not altcoins)
all using real consensus to activate their proposals or just plodding along.. using current consensus rules if no majority preference is seen... not using mandatory bilateral split bips

end result were endless REKT campaigns and 'go F**k off, and "your not wanted here" statements
(ill let you decide if ** = UC or OR)

having the mindset that xt, classic, bu and (as theymos shows in other topic) btcd and other implementations should not run on the network.. shows how defensive and core cuddling some people are.

that has been tried for years by other teams that wanted a united network of multiple implementations (not altcoins)
all using real consensus to activate their proposals or just plodding along.. using current consensus rules if no majority preference is seen... not using mandatory bilateral split bips

end result were endless REKT campaigns and 'go F**k off, and "your not wanted here" statements
(ill let you decide if ** = UC or OR)

having the mindset that xt, classic, bu and (as theymos shows in other topic) btcd and other implementations should not run on the network.. shows how defensive and core cuddling some people are.

i did find it funny that theymos in the midst or a core bug was still saying other nodes that did not have the bug, were buggy..

same with the palm oil example in the OP

you do not need a single blockchain that needs to last for eternity to hold every movement of palm oil barrels from 2018 to 21xx
instead it just needs a chain of blocks to represent each 'season'

it can have advantages
before military treasuries had to trust that when a procurement department ask for $5m.. that the $5m actually went to buying 2 engines of $2.5m as oppose to 2 engines of $2.4m and $200k in someones back pocket.

this way. the engine manufacturer can price the engine at $2.4m.. and add a identity for the engines. and send an invoice to the army base who then hand it to the pentagon who then hand it to the treasury. knowing no one can falsify the invoice while all departments agree that the items are needed

the pentagon, armybase and the temp working in the warehouse are then not handing funds. but instead the payment is locked to the engine manufacturer company and is only released when the engines are received by the armybase.

the downside of blockchain WAS. is that not every transaction needs to be kept forever. but because the blockchain in this example is not about a fixed supply currency where the origins of the funds need to be tracked back to its creation years prior the blocks can be prunned away after every 6 monthly treasury budget review

EG the treasury has $200b to hand to DoD. so the treasury creates 200b treasury credits.
they get transacted around the different departments. and within 6 months the engine manufacturer  and can show the path back to the DOD, pentagon, army base so gets the 4.8m treasury credits. and then sells the credits for $4.8m

after 6 months a new chain of 200billion treasury credits is made

there doesnt need to be an eternity existing single chain that keeps hold of decades of data on one chain forever growing

too many ICO's think that it has to be 1 chain and having to predict a token supply that will last a lifetime
EG a DoD chain of 40trillion credits to cover 100 years.
instead it can be 200 chains of 6 month budget worth of tokens per chain(created at each 6 month budget meeting). thus the system is covered for 100 years. where not all 200 chains need to exist for 100 years but can be deleted after 6months-10 years(whatever is practical)

finally some great thought from wind_fury
you have definitely earned 10 merit for this

i may add some points to the 'consequences' and explain the 'simply works'
some privacy concepts being discussed by devs are to hide the VALUE being moved.
this alone can make bitcoin UNauditable and thus challenge the point of a transparent trustable chain where people can see that coins at Z are real because they can be seen right back through the chain back to their original mined block A
many dont care about WHO.. but they still want to clearly and simply know the coins have a clear visible path from A-Z

these privacy codes actually add bytes of data to a transaction and only work when multiple parties mix funds. meaning its not only a bloated multisg transaction. but a multisig with extra bloat for the value privacy.
which means less transactions per hard drive space. which is not an optimisation of transactions vs space. but a de-optimisation

then theres the fact of adding too many features to something that should just be about send A to B. that it opens up risks of bugs where certain checks are not instantly done because theres just so many checks to do. thus causing risks by skipping a check initially to attempt to optimise relay speed, and do checks after. that then cause bugs of their own

as windfury said. if you want privacy that your name wont get attached to a transaction on the chain that you do not want seen. use other services/networks that do not publish details that need to be checked.

bitcoin is about checking and validating data. if we stop checking and validating data. then blockchains become pointless

putting aside the social /community attitudes.

if you concentrate on the code/network affect of what developers are doing to the actual network. that too is actually deviating away from the original ethos of what bitcoin was about

decentralised
 is becoming a monarchy codebase (core reference client) that is distributed.
we have lost the diverse code bases of multiple teams separately making full nodes. hense why this months 'bug' has proven to be a risk. decentralised and distributed are 2 different things

borderless
 is becomeing walled up and bordered. we seen the fee mechanism ripped out. causing a fee war, which has caused a barrier of entry to 3rd world countries where the fee of even just 5cents+ is more than a hours labour for some countries. thus they have been chucked to the side.
the monarchy/hierarchy mindset of trusting core has made a barrier of consensual unity of different idea's. instead theres now a singular roadmap that the community fight over and created a barrier where if people dont like the monarchy's roadmap they are told to cross the border and use something else "F**k off" basically (ill let you decide if **= UC or OR)

permissionless
with developers themselves saying bitcoin is broke and cant scale but commercial side services are the future, requiring smart contracts of co-signing parters, is eroding the permissionless part of handling funds. also the reliance people have of preferring to have funds held by custodians. and ofcourse where new developers and interested parties now have to leap through a 3 hop process of moderated venues just to get a code proposal listed before it even reaches the 'reference' client

..
we need to get things back to the simpler more diverse times of 2009-2013 where things were not so manipulated/influenced by certain entities. as bitcoin was never supposed to put anyone into a referential, preferential higher pedestal as anyone else

look into orphans/rejects

transactions are deemed as 'confirmed' but not 100% immutible..as that takes time..
it just means it passed the first quality assurance checks, but thats not all of the checks/risks covered/ruled out

bugs can make blocks get rejected, thrown away and thus the transactions of that block are not part of the chain anymore. thus no confirms no existance. and not immutible.

once all the FULL checks are done
once enough good blocks are added to good blocks the chances of a transaction in the past being of issues becomes nothing.
(more blocks=more confirms=more confidence= eventually milestoned as immutable.. eventually(not instantly at 1 confirm))

its why some say dont trust a 1 confirm transaction as solid/definite as there is a 0.5% chance the block containing it can be rejected
its why some say dont trust a 2 confirm transaction as there is a 0.0025% chance the block containing it can be rejected
and so on

so only risk instantly accepting  (during a no known bug period)
a value of ~chewing gum for 0 confirms
a value of ~ a meal for 1confirm
a value of ~ a weeks salary for 2 confirms
a value of ~ a second hand car for 3 confirms
a value of ~ a lambo for 4 confirms
a value of ~ a house for 5 confirms
a value of anything for 6 confirms

but because of the bug. treat 200 confirms as the milestone as orphans/rejects can keep happening. for upto a day until the network cannot tolerate/allow constant interruptions of orphans/rejects

the  "<- important point" in my last post

the optimisation bug. was that it does not check for duplicate inputs in the initial 'optimised check' of a block. but does check when the node thinks its download new block sequence is done and can rest for a few moments.

so there is a gap in time where a transaction can reuse a input of funds of say xbtc hundreds of times in a block and it show as confirmed at the first important point. but rejected at the second important point

usually all of this happens in a few seconds. but some people may have systems inplace that if they see something have a confirm. that instant they authorise some goods to be delivered or a service to be honours.

 

the exploit has existed since the blockstream devs re-wrote the bitcoin codebase to be including certain features and what they believed were certain optimisations (from 0.14.x)
bitcoin nodes that did not include those certain features are immune automatically from having themselves become victim of becoming DDosed.

but while nodes that are immune wont get DDoSed by a malicious block. the network, while it continues to have a mix of vulnerable nodes could see a chain of blocks broadcast to it containing the malicious block and see it get rejected and cause havok with transaction confirmations

EG
imagine a chain of 5 blocks
block height X12347
block height X12346
block height X12345
block height X12344
block height X12343

imagine x12343 was a malicious block exploiting the bug
the network of immune nodes reject it. and accept a different pools y12343
there are now 2 block height of 12343  (x and y)

the immune nodes add a clean y12344 to their clean y12343 and life goes on. y..5 y..6
but behind the scenes the malicious pool adds on a x..4 of their own to their bad x..3.. and then a x..5 and then a x..6

now imagine that the malicious pool gets to add on a x..7 before the clean pools win the block creation race
the malicious node announces they are the winner. broadcasts its CLEAN x...7 and all nodes see its good.

the immune nodes then because this winner has differing y..6 y..5 y..4 y..3 request the 4 differeing blocks the immune nodes dont have.
and optimised check x..3 is good. keep it and delete their y..3 <- important point. ill explain in next post
and optimised check x..4 is good. keep it and delete their y..4
and optimised check x..5 is good. keep it and delete their y..5
and optimised check x..6 is good. keep it and delete their y..6
and optimised check x..7 is good. keep it.. now all caught up

so now they have seen transactions in Y that had upto 7 confirms that are now gone
and now can see transactions in X that have upto 7 confirmations suddenly show as confirmed

now the immune node thinks it has caught up, it can regenerate a new set of the confirmed transactions which requires a full check of the blocks (unoptimised)
and bam.. x..3 is show to be bad.     <- important point. ill explain in next post
meaning x..4 5 6 7 are also bad.
suddenly the x blocks are rejected and the transactions are unconfirmed.

and the immune nodes ban any conversation with nodes broadcasting a x chain.
the immune nodes then rebuild the y chain. and suddenly the transactions in the y chain re appear as confirmed again.

...
this game can continue every new block the x pool wins the fastest block race. of making confirms disappear and reappear. until the entire network either
a. outpaces the x pool to never win a block again
b. the entire network bans communication with vulnerable nodes broadcasting x (causing a altcoin fork)
c. there are no more nodes or pools that accept/create/rebroadcast x blocks

which is a case where a solution is usually found and implemented within 200confirms, as having x continually disrupt and causing a headache of rejections wont get tolerated

in simple terms
if some people keep gifting you the same crappy (10min)birthday present, within 200 birthdays you will stop inviting them to your party(option b)

some nodes have a checkpoint of 200 confirms that lock a chains state as immutible. meaning anything less than 200 confirms if something was off about that block is able to be rejected and its subsequent blocks of that 'iffy' chain can be rejected.

many people state this bug is 'fixed' for the network. however. the real wording is that a vaccine has been provided for the vulnerable (nodes based on core 0.14.x-0.16.2 code) and it still requires everyone who is not already immune via having a diversified codebase (not core 0.14.x-0.16.2) to upgrade, so that there are no more (core 0.14.x-0.16.2) vulnerable nodes left on the network

until the point of which the network has removed the vulnerable nodes, there is still some risk. especially for those running such

many people also think that the mining reward is a defense in itself to not try it. however trying to assume that miners wont do something because of a 12.5 reward is flawed.

there are over 20 pools and only 1 pool gets the 12.5btc every ~10 minutes.
the other pools still mine blocks knowing that its not a guaranteed outcome of every pool wins. but a fight.
they still mine anyway.

knowing on average across the network its a 95% chance they can make a block, work on it and not get 12.5 anyway. every 10 minutes they continue working anyway. so a malicious pool could take the risk... because they are used to not always getting 12.5btc every 10 minutes anyway.. thus its not really a loss if they dont get it. they will just try it, and worry about getting income in later blocks

and all you have done is predict the PRICE waves will go up and down.. not much of a prediction...

but ignored my content completely at looking at the bottom line growth of a sustainable rise of value.
each day i can easily write ' i predict this week the price will go up and down due to.." and i would be right, but who cares

the ups and downs are meaningless prediction goals. whats important is the bottomline value that the community refuse to go below. as thats the line we all can stand above and take advantage of.

as for the ups. only less than 1% are online/fast enough to take advantage of the tips of the mountain(ATH). so why even concentrate on the ATH tip that we all will not gain from. but all can gain from standing at the bottom and riding the waves and let the bottom grow taking us along with it constantly.

yes enjoy the waves and profit from the waves. but just dont concentrate on waiting for the next tsunami, because when it hits, 99%+ would have missed the chance to ride it, or fellioff due to a wrong move

firstly some do not wish to protect and defend the network, some only wishes to protect a team of developers
i find it funny in that regard as the proof is clear when you look at some attitudes about the assert ddos bug of yesteryear compared to the block ddos assert bug this year.

neither of which did some sound like network defending arguments.. but sounded like arguments to why some want to hug a core dev and smother them with affection

one day, its been 3 years so far some will learn about the the network concepts of consensus and decentralisation that have become lost, and hopefully learn that when devs retire the network should live on and that caring about a certain dev is a meaningless pursuit as it does not help the network

if people cared for the network more than a certain dev. they too would actually want
diversified codebases in consensus and decentralised
instead of a
monarchy 'reference' codebase and distribution.
as the two concepts are vastly different


but hey. some has a long way to go yet. and many have tried reminding them to learn about the network and code protocols but stil see some only reply protecting developers


*i removed names in replacement for 'some' to avoid the auto reply of the ad-hom buzzword, of which has been a over utilised defensive argument to avoid addressing the content about caring for the network more than a developer point of my post. if anyone feels that 'some' equals them. than do not reply just realise that they have just confirmed to themselves that they care more about a developer than the network and thus no point trying to reply to sway that argument. as replying is just confirming it more. i also greyed out this statement to ensure some really concentrate on the care of the network content of which we should all want diverse codebases instead of a monarchy codebase. rather than have some reply only to rply with persona attack defense posts that distract the point about the network

if the poster is just
plagiarising someone else, no
just repeating something thats been common knowledge for years, no
just saying something they have an opinion on, no

but if its something notable. like something that makes people feel like they just been hit by a wisdom stick.. then yea it can be worth a merit.

but then.. its like youtube. number of views does not always equal number of likes/ subs/ shares.
and you will find begging for merits actually counter acts getting them. so dont expect a merit per view even with a well wrote wisdom giving post