1101
|
Other / Meta / Writing a welcome message
|
on: September 23, 2018, 08:58:25 PM
|
Here's a draft of a welcome message for new users. The user will see it on the screen confirming their registration, and it'll also be available in the help center at any time. Some text in the intro was obviously inspired by xtraelv's signature, which I really like. Please provide your suggested additions/changes. However: - I don't want to put in a lot of exact numbers such as all of the merit/activity thresholds, since then I need to remember to update them. - I don't believe in creating definitive rule lists. - There's no need for this to be a complete explanation of everything on the forum. It's just the basics.
Welcome to bitcointalk.org, the Bitcoin Forum! You can access this welcome message from the "help" link in the top menu bar at any time. As a member of the forum, you are surrounded by legends; phenomenal successes and catastrophic failures. The forum was created by Satoshi Nakamoto and saw the first exchange, the first altcoin, and the first ICO, but also catastrophic software flaws, massive thefts, and incredible scams. You too have an opportunity to become part of the forum's history: whether and in what way you do so is up to you. Table of contentsThe purpose of the forumThis forum exists to provide a platform for the free (but ordered) exchange of ideas. If you have an idea to express, then it is probably possible to do it here as long as you follow the rules. A lot of people come here primarily looking to make money. The forum administration is very happy that people are able to use the forum in order to better themselves; indeed, one of the reasons for Bitcoin's creation was to break the artificial barriers which prevent so many people around the world from attaining prosperity. However, if your attempts to make money conflict with the forum's primary goal of enabling discussion, then you are swimming upstream, and you will not be sucessful in the end. If you view the forum as some sort of "job" where you complete some basic tasks and get paid, then you will almost certainly be disappointed, and the forum administration will not be sympathetic. If you do make money using the forum, then it will be through innovation and entrepreneurship, not any sort of mindless busywork. Forum rankWhen you start out, you are a Newbie, and you will run into various annoying limits. These limits will be reduced to the point where you shouldn't usually notice them after you have participated in the forum for a few weeks. If you are on the forum to talk, then that's all you really need to know about rank. Don't worry about it too much, and you will eventually rank up. If you want to maximize your rank, then you need to increase two statistics which are listed on your profile: - Activity, which is maximized by posting once per day on average. Posting more than that is useless in raising your activity.
- Merit, which is gained by making good posts.
If you make ten thousand posts in a week, your activity will be capped and you will still be a Newbie. If you make ten thousand useless posts over any period of time, you will gain zero merit and you will still be a Newbie. You can rank up only by making good posts consistently. It's quality over quantity. When trying to write quality posts, a lot of people act as though they're writing a book report for school: putting facts that we already know into their own words. Nobody wants to read that, and you will not get merit for it. Moreover, the length of your post and the quality of your English are only minor factors. In trying to write a quality post worthy of merit, you should offer new ideas, personal experiences, or perspectives that other forum users will actually find new and interesting. Posting images and wearing signaturesUsers of Newbie rank cannot post images or wear signatures. If you want to do these things, then you can either rank up (explained above) or pay for a copper membership. Common rule violationsThese are the most common rule violations that newbies make. There are other rules than these. - Plagiarism: If you copy some text from somewhere, then you should have a good reason for it, and you must link to the source. Doing otherwise is plagiarism. Changing a few words around doesn't matter. If we find that you plagiarized, then you absolutely will be permanently banned, even if we find it years after you did it.
- Multi-posting: Do not post twice in a row in a topic. Instead, edit your old post.
- Low-content posts: Do not post low-content garbage like "agreed!", "nice project!", etc. You can be banned for this, and it's also pointless if you want to increase your rank, since you will never get merit for such posts.
LanguagesIf you are fluent in any language other than English, then it is highly encouraged for you to post in your local board. These boards often have tight-knit communities which will be able to help you, and in some ways you might be at an advantage compared to English-only posters. In the English sections, only English is allowed. It is not necessary to speak perfect English, though you should be understandable. Try your best. If you're unsure whether your English is good enough, ask in your local board or in the Beginners & Help section Here are the local boards: AUTOMATIC_LIST_OF_LOCAL_BOARDS Beware of scamsThis is a pseudonymous forum which emphasizes personal freedom and therefore also personal responsibility, so scammers are common. When trading, it's best to assume that everyone is trying to scam you, and act accordingly. Use an escrow, and take note of each user's trust ratings next to their posts and on their profiles. When you are more familiar with people around the forum, you should define your own trust list rather than using the default. Getting helpFirst, search for your problem to see if anyone has asked about it before. If you don't find anything on it, ask in the Meta section. If you don't speak English well, either ask in your local section or PM the moderators of your local section. If you think that a post is breaking the rules, use the "report to moderator" link on it. Do not PM moderators directly.
|
|
|
1103
|
Other / Meta / Re: Growing Blackmarket for Merit trading
|
on: September 22, 2018, 10:42:42 PM
|
As I've said before, I'm not really worried about it. Especially at those high prices (plus the risk of being red-tagged), it's enough of a barrier that it should still serve its intended function of creating a significant cost/barrier for garbage-posters.
BTW, if any merit source goes rogue and sells a ton of merit, then I will probably go through the transaction graph and undo all of the transactions touched by that sold source-merit. Merit ain't no immutable cryptocurrency!
|
|
|
1104
|
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.
|
|
|
1107
|
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 bitcoin.org or bitcoincore.org 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: https://bitcoincore.org/en/2018/09/20/notice/( *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.)
|
|
|
1108
|
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 bitcointalk.org 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.
|
|
|
1109
|
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.
|
|
|
1110
|
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.
|
|
|
1111
|
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.
|
|
|
1112
|
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.
|
|
|
1113
|
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.
|
|
|
1114
|
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.
|
|
|
1118
|
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.
|
|
|
1119
|
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...
|
|
|
1120
|
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.
|
|
|
|