There is a maximum: it's that value currently. Without the maximum, that much evil would result in a fee of 0.06491724 BTC at current rates.
I just wonder why the max value isn't similar with with costs of copper membership? At least they could get copper membership benefit and probably won't decide not to join this forum. Surely the simple solution is to avoid using Tor to sign up.
It's not simple for those who cares/have serious concern about privacy. If one is privacy-orientated, he/she doesn't have to use his own IP address. But using a VPN to register the first time or using a public WIFI is definitely an option. And after registering, you can freely connect via tor without having to pay any fee.
Using VPN probably will lead to same result (at least for free ones). Public WiFi is good option, but it reveal your geolocation.
|
|
|
That depends on the law on your country and whether malicious party only include link to illegal content or embed the illegal content on Bitcoin blockchain (which would be very expensive, without pool help & 0-fee transaction). If the malicious party only include link to illegal content, report the link to the authority (unless it's link of P2P-based protocol) should solve the problem since the link would be useless (after it's taken down/blocked by authority). Otherwise, you should hope there's law such as Section 230 of the Communications Act and Section 512 of the Digital Millennium Copyright which protect you. See Why Porn on the Blockchain Won't Doom Bitcoin for more info. Personally, it's worrying, but i doubt they'll go after individuals who run full node because there are many ways connect to bitcoin network or blockchain explorer.
|
|
|
Yeah I'm not sure this is a problem but it definitely has been there since I found the console table (probably at least a year ago). Deleting those lines just deallocates them, if someone is really after your data they might still be able to get it unless you defrag or fill the drive completely every time. If you'll notice you should be able to hit the up button to get your last command which is sometimes helpful but I don't think it should be encouraged either. They've probably done this because Linux does similar, you can normally access your previous commands on your next login.
I understand what you mean, but the real problem is they didn't trim secret information (xprv, seed and private key) and all attacker have to do is access config file which is far easier than recover deleted file or analyze raw hex format. On Electrum, there are only commands, so they could trim any information inside parenthesis for command such as importprivkey()
|
|
|
You could combine software which used to recover wallet with partial-loss password/seed such as btcrecover and bash script. But if you meant crack/recover multiple same wallet at same time (a.k.a parallel processing), then i don't know any software which could do it.
|
|
|
Bitcoin Core 0.18.1 just released few days ago, but both news and pinned thread on Bitcoin Discussion still show 0.18.0. So please update news about Bitcoin Core release to 0.18.1 achow101 already make the thread few days ago at Bitcoin Core 0.18.1 Released and it just need to be pinned.
|
|
|
The problem would be bitcoin blockchain that is not scalable and fast enough for multiple active projects with lots of contributions and commits. How do you think about a specialized blockchain with its own token? Obviously, it would need some incentive mechanism, but couldn't we define some sort of incentive for maintaining a permissionless decentralized git system?
You could built in on top of Bitcoin network by using side-chain with merged mining (just like RSK)
|
|
|
3. Increase the compression of the data within the block (will increase CPU overhead for Nodes.)
Have you heard about Compact Block? It significantly reduce block size (from 1MB to 9-20KB) which send to other node by only including these information - The 80-byte header of the new block
- Shortened transaction identifiers (txids), that are designed to prevent Denial-of-Service (DoS) attacks
- Some full transactions which the sending peer predicts the receiving peer doesn’t have yet
It won't work on IBD (initial block download) though.
|
|
|
Electrum is open-source and a free wallet which is why it can be manipulated more easily than Ledger that's hardware.
That's the disadvantage of open-source software, but would you rather use closed-source wallet and fully trust whoever create that wallet? Even if you can't verify the source code by yourself, popular open-source software will be reviewed/audited by someone else who usually would share the result if they found vulnerability or backdoor. Even the best of people can be fooled if they follow the pop-ups in the wallet and even Ledger has the same option of updating the version.
No, best of people would verify GPG signature of the downloaded installer/source code. They also could check the domain of Electrum website on the pop-up as well.
|
|
|
However, if you are solo-mining simply include the transaction into your block when calculating it.
And you need to find software which let you manually choose transaction, since i don't remember any up-to-date mining software for solo mining (unless you open-source pool server) coz i heard there's will be update to bitcoin network so i can manually approve by point my antminers s9 to thix tx !
If you meant support/decline a network update, your hashrate won't make any noticeable difference.
|
|
|
I did not notice these bugs, the script works normally. There were some errors in updating the source values but after refreshing the page everything works normally.
That's because the script get sMerit amount when you load the page & didn't check if you send sMerit on different page afterwards. The original script (before i modify it) works that way, so i don't change it. Generally, if you have some time, this update will be important for lazy people like me*: - Sending Merits quickly, instead of typing the number and then clicking Send, the numbers (1,2,5,10) are clickable. I'm also lazy people as well, so i'll do it when i have free time and not being lazy.
|
|
|
Thanks for sharing the podcast & i agree everyone should listen to the podcast/read the transcript, but which parts do you want to emphasize? 1. The fact hardware wallet is recommended for non-expert? Michael Flaxman: Yeah, yeah. Before we get into this whole episode bashing hardware wallets, which I enthusiastically stand behind, for most people, they are the best choice. If you’re owning Bitcoin, I strongly advocate holding your own keys, and unless you’re an expert, you should use a hardware wallet. If you are an expert, you should build your own hardware wallet with open-source software that’s free and equipment that you source yourself, but that’s way outside the scope of this. For most people, hardware wallets still are the best choice as far as usability and security, and they’re reasonably priced.
2. The importance of good RNG for both HW wallet & software to make paper wallet? Michael Flaxman: In terms of the things that you have to get right, because that was really your question, is this code doing what I think it’s doing, and am I running the code that I think I’m running? Both of those are incredibly hard things to verify. There are just so many famous examples of hacks and bugs, that it’s hard to point to all of them. There’s lots of other talks that’ll give examples of those, the idea is just that you should be cautious and paranoid, because it is really hard. One of my favorite examples is, there was a bug in 2013 in Android’s implementation of SecureRandom in Java. SecureRandom, as the name suggests, is a function that securely gets you some random bits of data. In a Bitcoin signature, you need a random component.
Michael Flaxman: It’s part of the proof in the ECDSA signature. If that bit is random, then it doesn’t matter. It’s not something that you ever would look at again. You can think of it as like nonce, a number used only once. It just is used to prove your ownership of that private key, but if that secure random data is actually not random, then somebody could intuit your private key instantly. This is not a difficult attack to do by any measure. There’s plenty of open source code that will do it from your signature. As soon as they see a signature broadcast, they know your private key, and that is terrifying. A lot of people lost money in wallets that were Android wallets in 2013. That’s the type of thing that nobody could possibly have been aware of.
Michael Flaxman: Yeah. That’s terrifying, because there’s a lot of copy-paste of code. Crypto is just really, really hard. If you have a library that does something in your language, you’re likely to borrow from it heavily. Unfortunately, almost all the hardware wallets are written in Python and MicroPython. That is not ideal, but I think that’s a more minor thing. Again, we’re talking like, you can chase the perfect secure system that was written in three different languages.
3. The risks of supply chain of HW wallet? Michael Flaxman: The supply chain risk is absolutely terrifying, because it’s completely outside your control. You could do things to minimize it. You say, “Well, I’m only going to buy my hardware wallet direct from the company at an event where they’re there.” If I get my device from a person who works at the company, then that’s probably better odds than, absolutely, do not buy it secondhand on eBay. That’s one way to minimize the supply chain risk, but you can’t know about upstream supply chain risk.
4. Difficulty of full transaction verification on HW wallet? Michael Flaxman: The point being that, hardware wallets, you want them to verify everything they can, and the screen helps you with some of that, but a lot of it’s buried in implementation details. It doesn’t matter how big your screen is, if you don’t verify what change address is yours versus an attacker’s, then you really don’t know what’s going on. If you don’t verify the inputs and the outputs, then you don’t know the fee. This is where there’s just so much devil in the details that, honestly, no one wallet does perfectly. Two wallets is your answer, because then you got to trick both of them. Even if one doesn’t do it perfectly, the other, hopefully, won’t have that exact same vulnerability.
On a side note, the idea of using testnet to test HW wallet and check whether your system is compromised is clever idea.
|
|
|
Recently i got my source sMerit filled & i found 2 minor bug : 1. I forgot to remove @downloadURL which causes the script update itself to grue's code which don't show personal/source sMerit amount 2. Amount of personal sMerit is deducted rather than source sMerit when source sMerit is available So i decide to fix it // ==UserScript== // @name bitcointalk merit // @namespace grue // @include https://bitcointalk.org/index.php?topic=* // @require https://ajax.aspnetcdn.com/ajax/jQuery/jquery-3.3.1.min.js // @version 1.1.2 // @grant none // ==/UserScript==
(() => { var sMerit, source_sMerit;
//get csrf token from the logout link let sc = $('td.maintab_back a[href*="index.php?action=logout;sesc="').attr("href"); sc = /;sesc=(.*)/.exec(sc)[1];
//Added by EcuaMobi: Get remaining sMerit $.post( "https://bitcointalk.org/index.php?action=merit;msg=29048068" ).then((data) => { sMerit = /You have <b>([0-9]+)<\/b> sendable/.exec(data)[1]; source_sMerit = /The next ([0-9]+) merit you spend will come from your source/.exec(data)[1]; }).catch(() => sMerit = null);
//selector for the "+Merit" link $('td.td_headerandpost div[id^=ignmsgbttns] a[href*="index.php?action=merit;msg="]') .each((i, e) => { const msgId = /msg=([0-9]+)/.exec(e.href)[1];
const $popup = $(['<div id="grue-merit-popup' + msgId +'" class="grue-merit-popup" style="position: absolute; right: 40px; background-color: #ddd; font-size: 13px; padding: 8px;border-width: 1px;border-color: black;border-style: solid;">', ' <form>', ' <div>', ' Merit points: <input size="6" name="merits" value="1" type="text"/>', ' </div>', // Modified by EcuaMobi ' <div style="margin-top: 6px; "><span id="em-smerit-count' + msgId +'" style="font-size:11px;" /> <input value="Send" type="submit"></div>', ' </form>', '</div>' ].join("\n")); $popup.find("form").submit( (e) => { e.preventDefault(); $popup.find('input[type="submit"]') .prop("disabled", true) .val("Sending..."); const merits = e.target.elements["merits"].value;
$.post( "https://bitcointalk.org/index.php?action=merit", {merits, msgID: msgId, sc} ).then((data) => { //Error pages usually have this (rough heuristic) if(data.includes("<title>An Error Has Occurred!</title")) { throw "error"; } //double check and see whether the post we merited was added to the list. Its msgId should be visible in the page source. if(data.includes("#msg" + msgId)) { alert("Merit added."); $("#grue-merit-popup" + msgId).toggle(false); // Added by EcuaMobi if(source_sMerit!=null && source_sMerit-merits>=0){ source_sMerit -= merits }else if(source_sMerit!=null && source_sMerit>0){ sMerit -= merits-source_sMerit source_sMerit = 0 }else if(sMerit!=null){ sMerit -= merits } return; } alert("Server response indeterminate."); }) .catch(() => alert("Failed to add merit.")) .always(() => { $popup.find('input[type="submit"]') .prop("disabled", false) .val("Send"); }); }); $popup.insertAfter(e);
$(e).click((e) => { e.preventDefault(); $("#grue-merit-popup" + msgId).toggle(); // Added by EcuaMobi if(sMerit!=null && source_sMerit==null) { $("#em-smerit-count" + msgId).html('<a href="https://bitcointalk.org/index.php?action=merit;msg='+msgId+'" target="_blank">Available:</a> <b>'+sMerit+'</b> ') } else if (sMerit!=null && source_sMerit!=null) { $("#em-smerit-count" + msgId).html('<a href="https://bitcointalk.org/index.php?action=merit;msg='+msgId+'" target="_blank">Available (yours | source):</a> <b>'+sMerit+' | '+source_sMerit+'</b> ') }; }); }); $(".grue-merit-popup").toggle(false); })();
|
|
|
There is a way to compress random data
As long as it's not truly random data, but there's upper limit and i doubt the ratio between uncompressed random data isn't that significant. But I can't fucking tell you about it because somebody wanted me to destroy my science paper.
But I can't fucking tell you about it even though it'll change everything for the better.
Then why bother talking about it if you keep it to yourself? You're wasting our time and potentially risking yourself
|
|
|
Prefix | Name | Format | SegWit? | bc1q… | native Segwit-Address | P2WPKH-bech32 (pay to witness public key hash) / P2WSH-bech32 (pay to witness script hash) | yes |
Actually Bech32/Native SegWit have bc1... prefix, not bc1q... q refers to witness version & in future (when other improvement such as Schnorr & Taproot added) we will be other prefix such as bc1p & bc1z See https://github.com/bitcoin/bips/blob/master/bip-0173.mediawiki#bech32 for detailed info
|
|
|
but concentrating just on segwit.. lets list what segwit promised and if it has/hasnt achieved it 1. better transaction capacity: no bytes per transaction has got worse since segwit. segwit is actually more bloaty. even with a 1.3x byte growth compared to ~2015 stats the tx count has not risen by 1.3x
But the reality says otherwise due to max. block size change from 1MB to 4.000.000 weight unit and SegWit have lower transaction weight size. dang you really are believing the propaganda. segwit does not have lower transaction BYTE hard drive storage size. it has UNCOUNTED size which they refer to as Virtual byte. these virtual bytes are used to make all the weight of a block appear as 1mb to not break the now outdated1mb rule but when it comes to WEIGHT which does account for actual bytes. segwit tx actually uses more bytes compared to a legacy tx of same input/output count maybe best to learn about segwit and how it mis-counts bytes I didn't say SegWit transaction have smaller size in byte and i know the fact SegWit transaction have bigger size in byte, what i said are : 1. SegWit transaction have far lower weight size2. SegWit indirectly allow higher TPS because max. block size changed from 1MB to 4 million weight unit 2. fee efficiency: no fee's in 2015 where pennies with a top price of 25cents before users complained. fees now are more by averaging 25c
And without SegWit and SegWit adaption, it'd be worse since less transaction would fit info a block which would increase avg transaction fees. Besides, using cents rather than satoshi makes your comparison useless because because Bitcoin price in 2019 is higher than 2015 same could be said about the other way, using satoshi's instead of cents. less people are transacting as often because the cost is so high Fair point, but the fact average transaction fees would be higher without SegWit remains true the grand debate of bitcoins purpose WAS about a open currency without borders. yet the tx fee of bitcoin has ruled out utility to many countries of unbanked people
I agree with your opinion, but few people also argue that's the cost of decentralization.
|
|
|
I thought Brave could be privacy-respecting browser for non-geek or technical illiterate, but looks like i was wrong. They should know they'll be forced to apply KYC on their browser, maybe they shouldn't push their BAT too hard. Anyway, it's unfortunate to see they prioritize BAT rather than their original goal which shown on their homepage. There is noting free in this world. They let us to use their free product but we pay them without our data. There are actually quite a lot of free services which will respect your privacy. Tails, Firefox, Tor, DDG. Have a look here for privacy respecting alternatives to most pieces of software: https://prism-break.org/Only because someone else "pay" for all of us in form of donation, source-code contributor, tester, host mirror server (such as mirror of linux software repository) and run node (such as Tor relay)
|
|
|
Honestly i worry about the security, functionality and ease-of-use of this crypto exchange. Their blockchain is buggy for years, the UI sometimes is confusing and their wallet had severe vulnerability few years ago. This is becoming a new trend now, because we also saw how https://localbitcoins.com/ changed their service to become 100% KYC/AML Compliant. Money and profit is more important than protecting people's financial privacy now. Because their only other option is to close their service due to regulation. The phrase "you either die a hero or live long enough to see yourself become the villain" applies on most bitcoin services which has been around for years and unfortunately most of them become "villain"
|
|
|
Fees: Bitcoin fees can become expensive especially when the network has been congested like in the past. This does not really happen on the lightening network as you are not paying miners to use their hashing rate exactly and instead you are paying for the use of payment channels which every payment channel that you go through will want a cut of the transaction. This is usually pretty low when compared to Bitcoin fees though.
But you need 2 on-chain transaction to open and close channel, which means you details with fees again. If user only need to make 1-2 transaction in some time, then create 1-2 on-chain transaction makes more sense. Centralization: Because of the nature of the Lightening Network it is at danger of becoming centralized. What I mean by centralized is there will be great benefit to those that send transactions on a daily basis to use the same node every time which in time people will see the need of creating what has become known as "super nodes".
The best example I have seen of this is if you were to go to a fast food restaurant and they have created a node for their store in the city. They would keep this node open so that customers could pay instantly without having to create a new channel every time.
I don't see how it's centralized, you always could route your transaction through another node, even though i won't deny most likely these "super node" will have big advantage, unless they decide to charge high fees for routing. IMO those "super node" doesn't mean centralization, but concentration and monopoly. This could eventually evolve into a nation wide and potentially worldwide payment channel rather than smaller ones being made all the time. America might decide that all american citizens can pay their taxes through the "United States Payment Channel" which would mean greater centralization in nodes.
Your example doesn't show centralization because "United States Payment Channel" is the destination & government don't force their citizens to route LN transaction through their channel, even though it could serve as big honeypot. Besides, if government could force their citizens to route all transaction through their channel, they also could force them to use wallet which created & managed by government.
|
|
|
1. All you need to do are import the private key from your paper wallet to your Bitcoin wallet. 2. It's possible to send Bitcoin to multiple address in a transaction. 3. While you can send remaining Bitcoin to same address on your paper wallet, it's strongly not recommended to do it due to privacy and security concern.
|
|
|
|