|
The forum is missing a lot of things, but selective ban-censorship is not one of them.
|
|
|
|
The results from the 'Other media campaign' (bounty part 1) can now be seen here: https://docs.google.com/spreadsheets/d/14HdYbHd4j4IuYT9XBGAA7DP592jlkZA_0Ufh65GtYOQ/edit#gid=90749849. Users are again required to provide an address to swap these out before they can receive any coins. They will also be gradually contacted over time. Facebook/Twitter from the first bounty is still TBD. Once these are provided and merged with the entries from this part of the bounty, the payout can be started. That would conclude both bounties (part 1 and 2). |
|
|
|
1) There is no guarantee that you have earned any coins. 2) You can't receive anything until you have provided a Vivid address (which is not an ETH address anymore). I have received the sheet from the 'Other Media' Campaign (FB/Twitter is being worked on); the others don't have sufficient valid entries. Users are required to provide a valid address on time and will be contacted if they have earned any stakes. The sheet can be found along with all the other ones in the new bounty thread. Is this dead?
Obviously not. |
|
|
|
As per: Most giveaway threads are no longer allowed in the Alternate cryptocurrencies sections. From now on, posting or replying to such threads could result in being banned. Existing threads will be locked.
Specifically, you are not allowed to give people any incentive to post insubstantial posts in your threads. You can't offer to pay people who post their addresses, usernames, etc. You can do giveaways off-site and link to the giveaway page in a thread, but you can't give people any bonus for replying to your thread.
Similar threads are already restricted to Games and Rounds in the non-altcoin sections, but the giveaway-related post volume is so high in the altcoin sections that I've decided to just ban them entirely here.
It isn't allowed. Just report the thread. |
|
|
|
|
The above is not true, is posted by a known troll, and should be generally ignored. Especially not the part regarding why the developers do not currently recommend the use of LN with a lot of funds (which has to do with software maturity, not any made-up flaws).
|
|
|
|
|
Quite a number of these rules are overly complicated or just outright nonsensical; they would lead to to severe worsening of the situation. You really need to think this through. There aren't even explicit rules against spamming by theymos (e.g. posting from several accounts just to get paid).
|
|
|
|
(...)
I maintain my arguments up-thread regarding software bloat as the most distinguished source of bugs. I understand it is the hard way and needs a lot of efforts but once you are concerned about bugs, best practice is to take care of code volume.
A complete separation of node and wallet code (i.e. the possibility of just building and running the node base) would help IMO. It does come with drawbacks though. At least for alternative implementations for monitoring it is the way to go. Could you elaborate on the drawbacks? ryanofsky is working on process separation as seen here: https://github.com/bitcoin/bitcoin/pull/10973. Here are his slides regarding process separation: https://docs.google.com/presentation/d/1AeJ-7gD-dItUgs5yH-HoEzLvXaEWe_2ZiGUUxYIXcws/edit#slide=id.p. Look at page 6. Reviewing the node code would be easier if it was completely separated from the GUI and wallet code (there would be noticeably a lot less lines of code to go through). I'm not sure if the end goal is complete separation though. |
|
|
|
Isn't it more about prevention rather than cure?
And for the cure, I don't get it how an alarming system would help? Actually it seems to me as a source of even further risks. I maintain my arguments up-thread regarding software bloat as the most distinguished source of bugs. I understand it is the hard way and needs a lot of efforts but once you are concerned about bugs, best practice is to take care of code volume.
A complete separation of node and wallet code (i.e. the possibility of just building and running the node base) would help IMO. It does come with drawbacks though. |
|
|
|
Why is a random newbie account interested in my account? Government employee or just an alt of someone who got busted (and is out to get me)?  You have been very bad kitty. FBI is interested why you have changed email on forum. How dare I change my email on my account?  Lauda blackmail people and steal money
Did Lauda ask for money to remove the trust? That accusation has been overused. |
|
|
|
Why is a random newbie account interested in my account? Government employee or just an alt of someone who got busted (and is out to get me)?  |
|
|
|
For starters, update to 0.16.3 and make sure you are fully synced.
Agree with Lauda, first of all update your core to 0.16.3 Now talking about the transaction i try to push it on blockchain.com and it say: Missing parents for 0420e1fadbdecb7949aeb3351e8ce6ff5c0b8e1fced08ffbde6d67524bd3a65e while inserting: [1cb8c4ad8e01812df83a371d1654823b610c695e6149c7e0dee9cbf702e020d7, 6afb6f83f034a1d66d9a6ea4cd801cc5b745df3965f86d3f04fd670b3a26b60d] So, this makes me think you have a problem with one input. Use listunspent to select the inputs you want to use for the transaction, that way you can verify they are valid inputs. Thanks. I will upgrade tomorrow. And the data is in testnet, I am not sure if it can be pushed on blockchain.com There is this: https://testnet.blockchain.info/pushtx. Therefore, I don't see why not. I have never used it though. |
|
|
|
|
For starters, update to 0.16.3 and make sure you are fully synced.
|
|
|
|
Where can I download the latest version?
https://github.com/GuntharDeNiro/BTCT/releasesWill it still be registered/verified on the exchanges purchased?
It should. If it isn't, contact support staff. How can I convert the original setup (old version of config files) to the latest please?
There's no automated tool for that I believe. |
|
|
|
|
I've checked some of their work and can confirm this wasn't done manually without a doubt.
|
|
|
|
This is without a doubt absolutely tag-worthy even if your intentions are harmless (but they aren't). You are providing tools/guidelines for people to scam others. |
|
|
|
2) Updates can never be automatic for a decentralized system as such. Even adding something like a 'update available' notification system can open up more attack vectors and is (as always) prone to abuse.
I agree with the first part, but as far as 'update available' notifications, is it any worse than relying on GPG verification of binaries in the first place? Update notifications could also automate the GPG verification which few people aside from very serious users probably do. Of course that means relying on the key baked into the software, but it is always possible to compromise something somewhere. Having to read the news to find out there is a critical vulnerability in the software you are using does not seem to be ideal, imo. This also comes back to the 'control issue' that I believe. The alert key system was able to do exactly that, but it was ultimately removed. I believe that there are no plans to implement something similar at this time. |
|
|
|
It's actually quite clever game theory, you don't need to be honest, but if you try to cheat you will lose money.
So it's in your best interest to be honest. So come again: who/what decide (i.e. judge), is cheating A who claims his last transaction to B is N+1, or B who claims the last transaction he received from A is N? Cryptography. Use Google: "In Lightning, a single bi-directional channel is constructed using a breach remedy transactions (BRT), the idea being: before updating the channel state, both parties commit that if they broadcast an earlier state, the counterparty will be able to claim all funds. This is achieved with relative timelocks."
https://bitcoin.stackexchange.com/questions/63073/lightning-network-are-decrementing-timelocks-used-in-bi-directional-channels |
|
|
|
Where do you draw the line between an "opinion" and something that is objectively a lie?
Note: Picture may not be completely accurate, but you get the general idea. |
|
|
|
whenever I hear from anyone saying "USE LN"
Whoever tells you to just use LN without warning you that LN is in testing mode, that it's risky to use LN and that you should really use LN for now only on testnet is incorrect (to say it nice). That is no longer true. It is sufficiently safe to play around it with the suggested amounts (up to $40) on mainnet. Heck, some people almost insist that you pay them only via LN for any smaller purchases now (even though on-chain fees play no role currently). 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.
Aren't we already there though? Given how many people use: a) SPV wallets (which are not connected to their own node). b) Online wallets. c) Exchanges and other services as their wallets; I don't see this as a real argument here. However, it is indeed quite inconvenient that you can't use LN without an active node. Watchtowers should help. |
|
|
|
Plus most Linux users have always used or are always using the command line. I believe a simple step by step "howto" guide should be easy to follow for anyone who uses Linux.
I believe that the majority of people running Linux nodes are split into two groups: 1) Those less familiar with it and/or running GUI - use PPA. 2) Those that are quite familiar with it, and manually download binaries (and/or build them). In either case, I don't see OP's statement to be in line with reality. This is especially the case with PPA where you basically only need to run 'apt-get update && apt-get upgrade' and everything is done. I was about to ask about that. Would it have been better, in this instance, if the alert system was still at the developers' disposal?
Actually it wouldn't. AFAIK the way that the alert system was implemented was also problematic; there was no sure way to tell how many people have access to the key(s). So for example, if an agency compromised a single developer and took the key we couldn't really know (heck, he might not know himself if they did it secretly while they question him on some false grounds). Additionally, it is an issue of centralization vs. decentralization again which is also why it eventually got thrown out. But is that enough? There is about 80% of nodes that have'nt done the upgrade.
~70%. Use this: https://bitnodes.earn.com/nodes/ for a sufficient estimate. The thread isn't as serious as it was assuming miners and major economic players have updated, and given that a large portion of the network already did upgrade. I'm certain that the release of 0.17.0 will speed this up as well. |
|
|
|
|
Show Posts
