Ok, i took the plunge, panic mode ON and launched the command.... it worked!  thanks guys! guess it happens when you sync sometimes, right? always learn something new! It shouldn't usually happen. Did you modify your bitcoin.conf or anything? Is there anything about this hash in the earlier parts of your debug.log? |
|
|
|
Hmm. It most commonly occurs when you use an invalidate block command. Try running reconsiderblock 00000000000000000007b86426ffa671d5f52a0cf22eb1a03a73c114695983c8 . |
|
|
|
|
Try switching to an exchange that absorbs the fees (Gemini) or exchanges that charges lesser TX fees either with segwit or batch payments. It is an inevitable problem given that you're transferring Bitcoin/fiat back and forth regularly. Good news is, the network fees are getting lower right now.
|
|
|
|
|
Perhaps as well as a higher usage of LN? Admittedly, most people wouldn't use it so it's better to just concentrate on optimizing the onchain transactions.
You should also shift some attention to companies like Bitmex. They use multisig (with uncompressed keys) P2SH on their addresses and broadcast the transaction from it everyday, resulting in a huge unnecessary bloat on the mempool at certain points of the day.
|
|
|
|
RBF is does not seem to be available as there is no transaction for this request showing in History and when I double click the date section where it says Pending, nothing happens. The coins are still sitting in my Electrum wallet and there are 0 transactions recorded on Blockchain.info so my question is this: if the transaction never gets confirmed and drops out of the mempool, will Pending change to something else, i.e. unconfirmed or unsuccessful, thereby allowing me to resent the transactions with the appropriate fees?
Try right clicking and see if there are any options to bump fee. If it gets dropped from the mempool, the UTXO would be as if it was never spent. If it really does have no fee at all, its quite likely that the propagation was terrible. You could consider removing the transaction and sending another one. It could work without RBF too. Also, do all transactions have to have a signature? What happens if they don't?
Pretty much. There are special cases where it doesn't. An example is 3MaB7QVq3k4pQx3BhsvEADgzQonLSBwMdj. Its an example of anyone can spend. It is nonstandard as it doesn't require a signature. |
|
|
|
1 - Does ASIC machines get some sort of copy of Bitcoin Core to generate blocks, verify them, et, cetc?
The normal Bitcoin Core allows the user to solomine using their ASIC through getblocktemplate. It's not widely used by ASICs and mining pools as most of them utilise SPV mining, ASICBoost etc which means their backend is heavily customised and modified. 3 - If 1 is a "Yes", can I generate a block just for the fun of playing with it and learn about bitcoin core commands some more? Can I try to create a raw transcation put it in that block and try to add that block to the network, even knowing that obviously it will be rejected and probably I'm even thinking baout it the wrong way?  You can manually generate your own block (probably won't meet the target) and submit it. But the initial filtering by your client likely would see that your block doesn't meet the requirements and reject it in the first place. 4 - IF I can't do that on mainnet, can it be done in testnet or regtest for learning purposes?
Testnet has significantly lower difficulty so you can probably get away with a 1TH machine. |
|
|
|
|
RBF refers to replace-by-fee. Its an opt-in feature that allows the user to send a replacement transaction with a higher fee that would still be accepted by the nodes. Normally, subsequent transactions spending the same UTXOs are rejected by nodes, suffering from poor propagation.
You'll have to inspect the raw TX to see if its opt-in RBF. A sequence lower than MAX-1 marks the TX as an opt-in RBF. Some wallet UIs and block explorer displays this explicitly.
|
|
|
|
I seem to get it now that I looked up weight units in the Bitcoin wiki, apparently I can calculate the bytes tx fee from it and whatever blockchain.com showed me was the sats/vbytes. Since miners only look at the sat/vbytes value, how should I choose a suitable tx fee for segwit addresses? For this transaction I used https://jochen-hoenicke.de/queue/#0,1w to choose a suitable fee but that lists fees in sat/bytes and since vbytes is less than bytes I wonder if this means these transactions will be included slower than legacy addresses? Blockchain.com showed you sat/bytes. Your wallet was using sat/vbytes. Try to avoid blockchain.com and switch to a better block explorer. Jochen's estimator actually displays the fees in sat/vbytes when you look closely at the explanation at the bottom. |
|
|
|
|
Its just blockchain.com's UI error.
Segwit transactions are calculated differently from normal legacy transactions. The vbytes for segwit transaction is lesser. Blockchain.com took your sat/bytes instead of sat/vbytes. No worries though, miners looks at vbytes and not bytes.
WU is weight units.
|
|
|
|
In future I will check first and then bump up the fees if I see other people using higher fees than normal. I think this might be a little bit too much of a learning curve for average Bitcoin users to calculate fees, luckily for me I am a bit more advanced than normal Bitcoin users.. so it is not a big deal. (Imagine the first impression from a new Bitcoin user, if they have to wait 6 hours for 1 confirmation)  Which is why most wallets uses floating fee. Using static fee doesn't guarantee the most efficient fee possible for a transaction with the given network conditions. Most wallets should be able to provide a reasonable estimate for users to follow and it helps to simplify it for most users. In some cases, the volume might spike and result in an inaccurate fee. But those instances are not that common and are frankly quite unpredictable. |
|
|
|
|
SPV wallets do not download the entire block. They only download the block headers.
The block header contains the merkle root among other stuff. By downloading the block headers only, the SPV wallet saves a lot of bandwidth and space. With the block header, the SPV node can verify if the block has sufficient target and can also use the merkle root to verify if a transaction has indeed been included in that specific block.
Even if it isn't about SPV nodes, by constructing the merkle root, you're basically telling everyone all the transactions that has been included in the block. Only the block header is hashed, the individual transactions aren't. Merkle root is the way to include transactions in your block. Read up on how the bitcoin block is constructed to get a more in depth understanding.
|
|
|
|
And I think global hashrate is another reason why our transaction slows down.  Likely just the mempool that is causing this. The block intervals, from what I observed is still slightly faster than 10 minutes so that is likely a non-factor in the delay of confirmation of your transactions. You really shouldn't be looking at the overall size of the mempool from the start. Only the fee rates and the number of transactions within that fee range matters to you. Blockchain.com hasn't been a good source of data historically so you should really choose another data source. |
|
|
|
The announcement is nice and all but hmm, wouldn't some people take advantage of this and send spam mail? I mean, IF just if they were able to access a duplicate copy of the email and send them towards the affected, they could potentially dupe them into clicking their scam site or something. That is, providing they don't really read the email carefully and notice that the emailw as a fake ledger email. Though chances are small, there's still a chance.
That's specifically what the leaked information would be used for. Given the sensitive information being leaked, attackers could potentially use the information to craft a more personalised phishing emails for the victims. Even if it isn't, the sensitive information could also be used in SE attacks against companies. Fortunately, the data breach is not that severe, only impacting their merchant information. At the same time, I don't think its necessary for Ledger (or any other hardware wallet manufacturer) to keep sensitive information of their customers for long periods of times. I would have expected information to be scrubbed regularly. |
|
|
|
How did you obtain the wallets? Are the wallets yours? It seems suspicious how many new accounts have been trying to get help recovering wallet passwords. BTCRecover[1] is a good place to start. Its fruitless if you don't have the wallet files though. [1] https://github.com/gurnec/btcrecover |
|
|
|
the hardware wallet needs to send the actual coin addresses to ledgers servers so you can see the balance on that address. that info possibly getting out, the amount of coin someone has control of, is worrisome to say the least.
at the very least i would move everything to a new wallet (new seed etc) just so when someone looks up that addy all they will see if what it did have. of course its possible to trace the coins to the new addys.
sucks big time all around.
It says the Ledger Live isn't affected. You're right that Ledger Live does require the addresses being sent to the server and that is indeed quite worrying. I would have expected them to at the very least utilize bloom filters to try to protect their privacy. I don't have the time to review their code right now so I can't really see how the information is exchanged. Hopefully, people are using third party software like Electrum instead of their own Ledger Live. |
|
|
|
|
It's bad news for a company that is supposed to protect the user's funds.
However, being a hardware wallet, no addresses nor funds or any sort of sensitive information pertaining to the user's hardware wallet should be leaked. Hardware wallets shouldn't communicate such information with a centralised server for the sake of security. It's highly likely that what they're saying is true.
Anyhow, the main concern right now is the spear phishing attacks that could be initiated against the users with the information that was obtained from the data breach.
|
|
|
|
I have just seen another newbie who seems to having fallen for that old electrum phishing vulnerability. Shouldn't the team be doing more than just warning users not to download or use the older versions that are vulnerable to the attack? A DOS attack is being executed against the older wallet versions to try to prevent them from connecting to any servers. This won't be 100% effective and people can still seep through the cracks How about?
1. Making the older versions of electrum that are vulnerable to the attack obsolete or unusable for transactions until users are forced to get the more secure newer versions?
Not possible. DOS is the best that they can do. The design of Electrum doesn't introduce any way for outsiders to modify the older Electrum client. 2. Make the download links of the older vulnerable versions inaccessible. No one would download the older version when there is a new one available. I don't see why it would be dangerous to leave the older versions in a less accessible place. Still, that's a decent suggestion, maybe they can put a little readme to warn the users. Newbies are newbies. Most even probably don't know that there is such a vulnerability in the older versions of Electrum. I think they need a little more protection from the attack.
DOS is probably the best that they can do. People should always verify their downloads before doing anything with it. |
|
|
|
|
Connect to the internet, making sure you're connected to an Electrum server (green bubble at the bottom right).
Right click the transaction and select transaction details. Click the "Broadcast" button.
|
|
|
|
|
Show Posts
