Topic: Bitcoin Core 0.16.3 Released (Read 2363 times)

Bitcoin Core 0.17.0 has been released

The PR for that change was too close to the 0.17 branch off date and it did not have sufficient review to be merged.

Developers of every single fork will have to take care of that issue on their own. Litecoin, which is a fork of Bitcoin, has already got its client patched. I wouldn't expect any reaction from the developers of, for example, Bitcoin Diamond, Emerald and any other Bitcoin clone which nobody uses.

@achow101 Do you happen to know why the minimum transaction fee is going to be lowered in the 0.18 release and not in the 0.17 one?

What about Bitcoin having like 11 forks?

It has been tagged and will be released in the next few days. The releases occur a few days after the tag is made so that the deterministic builds are done.

Am I reading this right... 0.17.0 has just been released?

https://github.com/bitcoin/bitcoin/releases/tag/v0.17.0

I would recommend against using USB drives for the blockchain. You are more likely to run into database corruption errors and accidentally corrupt the database by prematurely unplugging the drive (as you have done).

If you are able to start Bitcoin Core with those wallets, then the wallets should be fine. Of course, you should double check that the private keys are correct by signing and verifying a few messages with your addresses.

A wallet does not need to be online in order to receive Bitcoin.

Bitcoin Core requires downloading and verifying the blockchain to work. The blockchain can be pruned, in which case blocks are discarded after they have been verified and area few hundred blocks deep into the blockchain. If you do not have a copy of the blockchain, it will need to be redownloaded.

I downloaded the BTC blockchain and created a couple of wallets with the new version on a USB hard drive. I ran a few mined coins through the wallets and into CoinBase with no problems.

The trouble began when I inadvertently unplugged the hard drive. This is my second day attempting to recover the blockchain. Actually the first attempt resulted in a disk error and scan which was pretty fast but now it seems that I'm having to download the whole blockchain again which of course takes a day or so.

I'm hoping that my wallets are still intact after recovery. I have two workers pointed at those wallets so I am curious to see if the coins mined during the down time will be there.

I also wonder what happens if I ever shut down the node on purpose. I am assuming the wallets will be there but will I have to download the whole damn chain when I restart Core?

Bitcore is completely unrelated to Bitcoin Core. Questions about bitcore are off topic for this thread.

If you have used the bitcoin code for your altcoin then you gotta upgrade as well

The bug is very serious. I suggest that for at least one month we all put a signature message to remind that everyone should upgrade. I already did it 

these two are completely different arguments though.
implementations such as XT, classic,... were planning on enforcing (eventually) different consensus rules and they were created because certain people didn't want SegWit and wanted bigger blocks. if there were no SegWit or bigger blocks then these implementations wouldn't have existed at all. that is one thing. not to mention that they were forks (copies) of bitcoin core so that is not even related to this discussion because technically since they copied the code they would have had the same bugs.

another thing which is what @ETFbitcoin is talking about is having other clients that do enforce and continue to enforce the same consensus rules. there currently are other implementations. it is not like they don't exist at all but not many use them.

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)

If it was based on any newer Core version it would have the bug. Sounds like you are clearly lying. Where is this magical implementation? If you were pro-diversity, you'd publish the code. Hint: You aren't; you are just a pathetic troll.

---

Wind_FURY please stop indulging the idiot.

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..

Then why don't you start developing your own implementation or start running one of the other implementations available? I heard Mircea Popescu's "The Real Bitcoin" is the closest to "Satoshi's Bitcoin".

Plus we care enough for the network to support the best developers. But they are human, and maybe they also deserve some criticism for leaving a bug unseen for that long. It should also be taken as a sign that smart developers like you, franky1, should keep an eye on the code.

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

No, because code is law on cryptocurrencies.

And it is already being used by this idiot to spread propaganda:


We should thank him for not breaking the law?

---

He can't face the fact that he is significantly less competent than even the least competent Core developers. That's his problem. He's a sad, bitter and definitely pathetic, developer (based off of this article) who got a little lucky.