Bitcoin Forum
July 22, 2024, 01:35:07 PM *
News: Help 1Dq create 15th anniversary forum artwork.
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 ... 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 [59] 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 ... 422 »
1161  Bitcoin / Development & Technical Discussion / The duplicate input vulnerability shouldn't be forgotten on: September 22, 2018, 07:47:55 AM
The bug fixed in Bitcoin Core 0.16.3 was really bad. IMO it was the worst bug since 2010. If it had been exploited in a 0-day fashion, significant & widespread losses (due to acceptance of counterfeit BTC) would've been likely, and Bitcoin's reputation would've long been tarnished. Furthermore, since a ton of altcoins are based on Bitcoin Core, this would've affected a huge swath of the crypto space all at once.

Everyone's human, and secure software engineering is largely an unsolved problem. The Bitcoin Core devs have done a remarkably good job over the years; in fact, in this case they were able to recognize that a bug report for a DoS attack was actually a critical consensus bug, and then they managed to roll out a fix in a way which ending up protecting Bitcoin. I am thankful for their work and diligence. However, the fact that this bug was introduced and then allowed to exist from 0.14.0 to 0.16.2 was undeniably a major failure, and if all of Bitcoin Core's policies/practices are kept the same, then it's inevitable that a similar failure will eventually happen again, and we might not be so lucky with how it turns out that time.

Finger-pointing would not be constructive, but neither would it be sufficient to say "we just need more eyes on the code" and move on. This bug was very subtle, and I doubt that anyone would've ever found it by actually looking at the code. Indeed, the person who found it did so when they were doing something else and ended up tripping the assertion. Furthermore, this bug probably wouldn't have been found through standard unit testing, since this was a higher-level logic error. (By my count, something like 18% of the entire Bitcoin Core repository is tests, but that still didn't catch it.)

Perhaps all large Bitcoin companies should be expected by the community to assign skilled testing specialists to Core. This vulnerability could've been detected through more sophisticated testing methods, and currently a lot of companies don't contribute anything to Core development.

Perhaps the Core release schedule is too fast. Even though it sometimes already feels painfully slow, there's no particular "need to ship", so it could be slowed down arbitrarily in order to quadruple the amount of testing code or whatever.

Perhaps there should be more support and acceptance for running older versions, or a LTS branch, or a software fork focused on stability. The official maintenance policy says that the current and previous major release is supported, but that doesn't seem to be closely followed. In this bug, backports were written for 0.14.x and 0.15.x, but as of this writing no binaries have been released for those, even days after 0.16.3's release. SegWit didn't have any backports when it was released, even though users would've needed to enforce SegWit in order to achieve full security if SegWit had activated as quickly as originally hoped. Sometimes fixes are backported to an old version's git branch but no release is actually made. If 0.13.x is not currently supported, then there was no supported version without the vulnerability. This might indicate that the maintenance period isn't long enough; there are a few hundred people still using 0.13.2, and they were the only Bitcoin users completely safe from this vulnerability.

I do not think that it would be constructive to turn to any of the full node total-reimplementations like btcd, which are very amateur in comparison to Bitcoin Core.

I don't know exactly how this can be prevented from happening again, but I do know that it would be a mistake for the community to brush off this bug just because it ended up being mostly harmless this time.
1162  Economy / Speculation / Re: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion on: September 21, 2018, 06:20:56 AM
Seriously considering running a Bitcoin Knots node or similar for resilience.  A wake up call for many.

Knots actually focuses on being less stable / more experimental than Core. Maybe a more stable software fork is needed.
1163  Economy / Speculation / Re: Wall Observer BTC/USD - Bitcoin price movement tracking & discussion on: September 21, 2018, 01:41:03 AM
I wonder if the recent Core bug will move the market. It might be the worst bug since 2010, though luckily it wasn't actually exploited and is unlikely to cause future trouble.
1164  Bitcoin / Important Announcements / New info escalates importance: upgrading to 0.16.3 is REQUIRED on: September 21, 2018, 12:39:50 AM
0.16.3 was announced a few days ago, but if you're running a node and haven't already updated, then you really must do so as soon as possible. The bug fixed in 0.16.3 is more severe than was previously made public. You can download 0.16.3 from or or via BitTorrent, and as always, make sure that you verify the download.

If you only occasionally run Bitcoin Core, then it's not necessary to run out and upgrade it right this second. However, you should upgrade it before you next run it.

Stored funds are not at risk, and never were at risk. Even if the bug had been exploited to its full extent, the theoretical damage to stored funds would have been rolled back, exactly as it was in the value overflow incident. However, there is currently a small risk of a chainsplit. In a chainsplit, transactions could be reversed long after they are fully confirmed. Therefore, for the next week or so you should consider there to be a small possibility of any transaction with less than 200 confirmations being reversed.

Summary of action items:
 - You should not run any version of Bitcoin Core other than 0.16.3*. Older versions should not exist on the network. If you know anyone who is running an older version, tell them to upgrade it ASAP.
 - That said, it's not necessary to immediately upgrade older versions if they are currently shut down. Cold-storage wallets are safe.
 - For the next week, consider transactions with fewer than 200 confirmations to have a low probability of being reversed (whereas usually there would be essentially zero probability of eg. 6-conf transactions being reversed).
 - Watch for further news. If a chainsplit happens, action may be required.

More info:

(*Almost everyone will use 0.16.3, but source-only backports have also been released as 0.14.3 and 0.15.2, it's also OK to use Knots 0.16.3, etc.)
1165  Bitcoin / Development & Technical Discussion / Re: Flaws in LN (Lightning Network). on: September 20, 2018, 04:15:52 AM
I think that LN will eventually be an important part of the overall ecosystem, but there are some downsides:

First, the biggest downside of LN is that the recipient has to have their LN node online and listening at the time of the transaction in order for the transaction to occur. This is fine for payments to web stores etc., but I think that it will largely preclude usage of LN for more peer-to-peer transactions (eg. forum trades). It would not be good if people were expected to use only LN, since that would result in almost all individuals using trusted-third-party wallets in order to accept payments.

Second, LN often does not integrate easily with existing BTC payment systems. For example, I would have to almost completely rewrite the payments system in order to make it work with LN. (Someday I'll do it, but not soon.)

Third, it's possible that the network will end up excessively centralized. If 90% of LN channel-value goes through a small handful of nodes, then that would be a real problem. That sort of centralization could lead to: 1) a lot of people getting their funds locked up for a long time; 2) possibly a slippery-slope to further centralization, eg. "gatekeepers"; and 3) possibly even losses if too many unilateral channel-closes are necessary at one time network-wide. However, the degree of centralization in your channels is completely controllable at your end. If you want to avoid channels which go through a certain highly-popular node, you can do so (possibly at higher cost), and then you will be immune to problems related to that node. You can never be forced to accept centralization with LN. So ultimately this ends up being a software problem of properly informing end-users of centralization and risk. Depending on how the network ends up looking, this might or might not be a difficult problem to solve.

In a few years, the majority of transactions will probably go through LN, but I think that it's currently a bit over-hyped. LN can only be part of the overall picture, and it'll take quite some time to figure out how to get it to fit smoothly and safely into everyone's lives.
1166  Bitcoin / Development & Technical Discussion / Re: When Schnorr will be added? on: September 20, 2018, 03:40:38 AM
So in order to add schnorr signatures, we will not go through another dramafest of mining wars fighting each other with hashrate signaling different things?

If I remember correctly satoshi used in the past softforks that didn't need mining signaling (basically a UASF? but there wasn't a name for it back then). Im not sure why segwit took that route. Was it simply to allow miners to have their say with their hashrate or was it because of technical reasons that needed it to be implemented that way?

Yes, Satoshi always did UASF-style softforks. AFAIK future softforks, including Schnorr, are likely to use BIP 8, which is basically a UASF with an optional miner-enabled fast-track. So miners will be able to speed things up, but not block anything.

It was thought that BIP9 would be a faster and safer way of doing softforks than the Satoshi-style method, but boy did that turn out to be wrong. It was definitely not intended to be a way of letting miners "vote"; miners are not and should not be a decision-making body for Bitcoin.

That's because SegWit developer use "anyone-can-spend" and remove signature part of transaction as method for backward compability where it can be used to steal Bitcoin if majority nodes/miners don't support/use client that support SegWit.

Those were arguments that the anti-SegWit people used, but they're not true:
 - SegWit's security doesn't depend on miners, but rather on the economy. (Otherwise the UASF attempt wouldn't have made any sense...)
 - SegWit outputs are interpreted by pre-SegWit nodes as being spendable by anyone, but that doesn't really mean anything. P2SH outputs were also interpreted as more-or-less spendable by anyone by pre-P2SH nodes.
 - The signature is not removed. Between SegWit nodes, every transaction must be accompanied by its signatures or it's invalid.
1167  Other / Politics & Society / Re: Supreme Court pick Brett Kavanaugh on: September 20, 2018, 03:15:01 AM
Check the timelines on nom's getting in, even if someone is rammed through starting today there isn't enough time before the MT's.

The schedule is defined by the Senate majority. If McConnell wants, he can bring a final nomination vote to the floor on the same day as the President makes the nomination. It would be highly unusual, but so was ignoring the Garland nomination or invoking the nuclear option on Gorsuch; McConnell doesn't care. If Kavanaugh loses the vote and the GOP loses the Senate, I suspect that he will force someone else through in this way during the Senate's lame duck period.
1168  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 20, 2018, 02:00:59 AM
Just a suggestion for safety safe, don't put the sha256 sigs on the same ftp/host as the files. That way if the files do get hacked the hacker cant alter the sha256 sigs too.

This is well-addressed by the verification procedures you should follow.

So we don't need to delete the chainstate folder before opening the new update?

No, deleting old stuff is never necessary. If any adjustments are necessary, the new version will do it for you.
1169  Other / Politics & Society / Re: Supreme Court pick Brett Kavanaugh on: September 20, 2018, 01:52:51 AM
If it becomes clear that the allegations are true, then this should disqualify Kavanaugh simply because that would mean that he's currently blatantly lying about it. All of the other arguments regarding the particulars of the case are irrelevant in the face of that fact, assuming he's guilty.

If the government was full of a bunch of honest philosophers who really cared about doing things the right way, then IMO there's enough evidence to halt the process and look into it carefully. But we all know that both sides are acting 100% in bad faith at all times, and are only looking to win as much as they can. With that reality in mind, and even though I don't like Kavanaugh, I feel that if the Republicans back down now in any way, it'd set a bad precedent for completely derailing things based on fairly weak accusations, since a complete derailment is a possible result of any delay.

The best-case scenario IMO is that we quickly get solid evidence that Kavanaugh is guilty, and then he's replaced by someone better who is then confirmed before the Democrats have any possibility of taking back the Senate. The worst-case scenario is that this drags on for a long time, the Democrats end up getting a more anti-constitution justice, Kavanaugh is proven innocent after the fact, and a strong precedent is set for winning by throwing weak allegations around.
1170  Bitcoin / Development & Technical Discussion / Re: When Schnorr will be added? on: September 20, 2018, 01:26:28 AM
There's certainly a proposal.  You can read the BIP here and the relevant part of the roadmap here.  Even small changes take time to go through the peer-review process and this one is actually a fairly big change, so I don't believe there is a fixed date for release or anything like that.  

That draft BIP is only for the details of the signature algorithm itself, since there is no standardized way to do Schnorr signatures. It's the equivalent of the SEC 1&2 standards which specify how to perform the ECDSA signing currently used in Bitcoin. That BIP needs more time for review before it is finalized, and then a separate BIP will be needed for actually integrating it into Bitcoin. I'm not following its progress too closely, but I wouldn't expect it this year.

What DooMAD said, Schnorr is at least as big of a change as SegWit, and we all know how easy and smooth of an upgrade that was...

It's far simpler than SegWit, there's even less reason for controversy around it, and it won't be done using the BIP9 process which caused SegWit's unnecessary delays. I could see the Schnorr softfork completing next year.
1171  Other / Meta / Re: Theymos: Can we block PMs from Copper-Newbie members? on: September 20, 2018, 12:00:43 AM
How the code is currently written makes copper members equal to either whitelisted newbies or Members, both of which bypass ignore-newbie-pms IIRC. If it becomes a problem, I could change it, but for now: if it's spam, just report it and know that they wasted $10 spamming you.
1172  Local / Бизнес / MOVED: Идентификация и продажа QIWI, ЯД, W1,Яндекс карт&# on: September 19, 2018, 11:35:11 PM
This topic has been moved to Trashcan. Trademark complaint.
1173  Local / Бизнес / MOVED: Магазин по продаже идентифицированных Qiwi on: September 19, 2018, 11:34:16 PM
This topic has been moved to Trashcan. Trademark complaint.
1174  Local / Бизнес / MOVED: Магазин по продаже идентифицированных Qiwi on: September 19, 2018, 11:33:53 PM
This topic has been moved to Trashcan. Trademark complaint.
1175  Other / Meta / Re: The new rule (1 Merit for Jr. Member) is already reducing spam on: September 19, 2018, 07:41:52 PM
All posts:
| Days ago | posts |
|        0 | 26510 |
|        1 | 42433 |
|        2 | 46736 |
|        3 | 54921 |
|        4 | 45271 |
|        5 | 48072 |
|        6 | 48926 |
|        7 | 46559 |
|        8 | 45886 |
|        9 | 49366 |
|       10 | 55894 |
|       11 | 47335 |
|       12 | 50829 |
|       13 | 53678 |
|       14 | 48648 |
|       15 | 49082 |
|       16 | 50333 |
|       17 | 57172 |
|       18 | 48595 |
|       19 | 52579 |
|       20 | 57679 |
|       21 | 40384 |
|       22 | 54342 |
|       23 | 56030 |
|       24 | 61043 |
|       25 | 48891 |
|       26 | 48744 |
|       27 | 50118 |
|       28 | 47206 |
|       29 | 51689 |

Deleted posts (not necessarily by a moderator):
| Days ago | posts |
|        0 |   749 |
|        1 |  3004 |
|        2 |  2430 |
|        3 |  1950 |
|        4 |  2275 |
|        5 |  2395 |
|        6 |  2836 |
|        7 |  3439 |
|        8 |  2743 |
|        9 |  3244 |
|       10 |  3793 |
|       11 |  5510 |
|       12 |  5153 |
|       13 |  5681 |
|       14 |  4870 |
|       15 |  5974 |
|       16 |  4685 |
|       17 |  5909 |
|       18 |  7518 |
|       19 |  7709 |
|       20 |  6472 |
|       21 |  5671 |
|       22 |  8891 |
|       23 |  7594 |
|       24 |  6634 |
|       25 |  6694 |
|       26 |  6433 |
|       27 |  5401 |
|       28 |  6260 |
|       29 |  5504 |

That's "24-hour periods from now", not calendar days.

There was a bug for the last ~7 hours which prevented all newbie posts, so that's going to make a big dent in the stats.
1176  Other / Meta / Re: Newbies can't make posts? on: September 19, 2018, 07:02:47 PM
Strange thing. Was this an attack on the forum?

Nah, I apparently fat-fingered a configuration file just before going to sleep...
1177  Other / Meta / Re: A Copper membership needs signature reductions on: September 19, 2018, 07:00:29 PM
I suspect that it won't be a major issue because they'll be losing their ~10 dollars every time they get banned. It won't be profitable, hopefully. If it seems to be a major source of spam in a few months, I'd reconsider.
1178  Other / Meta / Re: Newbies can't make posts? on: September 19, 2018, 06:49:38 PM
Damn it...

It's fixed now.
1179  Bitcoin / Bitcoin Discussion / Re: Bitcoin Core 0.16.3 Released on: September 19, 2018, 03:28:59 AM
how can a transaction have a duplicate input? can you give an example also point us to its PR on github?

Such a transaction is invalid, so you won't find any examples in the block chain. But Bitcoin Core crashes upon detecting its invalidness in a valid-PoW block (not when the transaction is free-floating). The crash is caused by an optimization which had incorrect assumptions; the fix simply disables the optimization, changing a false to a true.
1180  Other / Politics & Society / Re: Supreme Court pick Brett Kavanaugh on: September 19, 2018, 02:29:53 AM
The "#MeToo" stuff is often guilty-until-proven-innocent, which I absolutely hate, but the accuser in this case apparently has some years-old records of the accusation. It may be a stronger case than usual, though it still has plenty of the guilty-until-proven-innocent smell, and CoinCube brings up a lot of interesting points that I hadn't heard in the media coverage of this.

Whether it's true or not, I wouldn't be surprised. Kavanaugh has been groomed by the Federalist Society for decades, so the Democrats could've easily set up the accuser's corroborating records long in advance. I really wouldn't put it past them. But I also wouldn't put it past Kavanaugh to sexually assault someone; it sounds like he was part of a disgusting rich-kids culture where that kind of thing could easily happen.

It was politically a smart move by the democrats to delay the announcement until now. If the Republicans force through the nomination, then the Democrats can use that as "Republicans hate women!" in the election. If they stop it, then that's a win for the democrats in itself.

Personally, I hope that Kavanaugh gets replaced by Amy Coney Barrett, though that's probably unlikely.
Pages: « 1 ... 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 [59] 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 ... 422 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!