Hi all! Thinking of selling my BTC, I don't have much, but personally I think it's value has topped so it could be a good moment to jump off (of course, this means you are all in luck because just 3 seconds after I sell, the value of BTC will increase 10 fold). I thought it would have changed to a much more user friendly environment by now, however, the crypto world is still an incredibly hostile place for people like me who aren't too digitally inclined, so it's probably time for me to get out. There is something I'd like to ask though, relative to this thing called a "fork", I posted about it a few years back but I guess things would have changed by then. Are there any worthwhile forks that I should be chasing up after I sell my BTC ? Thanks.
If you have your funds in a single address, here's a nifty website to help you check it: http://www.findmycoins.ninja/Short answer is probably not, but it could be better than nothing. |
|
|
|
|
How many transactions did you make after your backup? Bitcoin Core used to maintain a keypool of 100 addresses that are pregenerated for you in the wallet.dat. This also means that you should have made a backup every 100 transactions. If you didn't make a backup 100 transactions before that address, then the address will not be in that wallet.dat.
|
|
|
|
1) How long does it take until my deposit moves?
Instantly. It does take sometime before it gets confirmed though. Miners usually prioritize the highest fee/size first and the top 1MB (ie. next block) is around 100 satoshi/byte and if you've paid the minimum, it would probably not confirm so soon. You can check how much fee you've paid when you right click on the transaction and press View Transaction, should say something about satoshi/byte next to your fees. You can go to https://jochen-hoenicke.de/queue/#0,24h to see roughly how many transactions there are before you. Miners almost always takes the top 1MB of the transactions that you see on the site. 2) What's the difference in those three options it gives you when paying the fee?
I don't remember what those three options were, "Static" probably was one of them? Anyway, what's the difference in those? You need to choose one when you pay the fee.
Static does not take into consideration of the network conditions and you'll probably pay a less than optimal fee if you were to use that. There's mempool which reflects on the actual network conditions, 1MB from the tip means roughly within the next 2 blocks if no one else sends anymore transaction, etc. ETA refers to the number of blocks which you're estimated to get a confirmation, choosing that will give you a relatively more conservative estimate. If your transaction pays something like 1-3satoshi/byte and you don't want to wait anymore, you can right click it and select Bump Fee or ChildPayForParent, the former allows you to create a replacement transaction with a higher fee and the latter spends the outputs with a higher fee so that your transaction will get confirmed. Do note that either of the options will incur a larger fee and if your fee is still reasonable, then you can consider waiting. |
|
|
|
A single UTXO double spend on two chains is possible.
Is this the case?
Correct. What is the difference in the two transactions?
I linked it with my post. The fees? (after an initial claim of an RBF transaction being bumped up, it appears the was not the case)
One of the transaction actually do have a higher fee and that makes me think that the transaction that was on the losing block was actually the RBF'ed transaction, since the lower fee transaction actually signals optin RBF. The recipient address? Well, this would technically be a double-spend. But is this what happened?
The transaction had an additional output that was spent to a P2SH address and a few different UTXOs being spent as well. I guess this was intentional.
No. Both pools mined the transactions within seconds apart, and it's likely that SlushPool didn't manage to replace the existing transaction with the RBF transaction that spends a higher fee. Unless the attacker owns either of the pool, it's highly unlikely that it was planned at all. |
|
|
|
There's a discussion here: https://bitcointalk.org/index.php?topic=5311173.0Let's get some facts right. Here's the replaced transaction: https://www.blockchain.com/btc/tx/a13c2bdefcd51ef2a162f232179676c848b853b11596ac3381b70726758cfd41 and the original transaction, which was confirmed in the longest chain: https://www.blockchain.com/btc/tx/9e19bc72f3b9bb23351311f88dc6f5c2e7a209a4fb0ad80b35d50f765e343e29. In this case, both of the transactions were mined at the same height in different blocks and one of the blocks eventually prevailed to be the longest chain. Unlike what usually happens in normal circumstances, it appears to be the one with a much lower fee. This is something that is already known and is not a network weakness. To prevent this from happening, the merchants should operate a well connected node to monitor for any possible forks and/or competing transactions on the blockchain and delay the provision of goods and/or services if that transaction is not included in both blocks. If it isn't, then the merchant has to wait for another confirmation for the transaction to be confirmed in the longest chain. Note that lengthy block reorgs are not common and I would expect 3 confirmations to be more than sufficient for larger amounts and 1 confirmation to still be safe in day to day use for smaller transactions provided that the above has been met. |
|
|
|
Assuming that more future blocks are refer to A as a predecessor, A will be part of the longest chain, while B is referred to as an orphan block. I was trying to figure out how often such a scenario takes place. I found this graph on blockchain.com: https://www.blockchain.com/charts/n-orphaned-blocks (select All Time and Raw Values) It's a stale block. They are not orphaned blocks as the preceding block is known. Stale blocks are often referred to as orphan blocks but that'll be the wrong term to use. Can someone verify the correctness of this chart?
You can't. Stale blocks are often poorly propagated as nodes do not propagate competing blocks at the same height once they have seen either of them. To answer your question; it's not accurate, BitMex just recorded a stale block yesterday and it isn't reflected on the chart. If it is correct, why do such micro forks only occur between 2014-2018?
I thought such a scenario would happen way more often.. Why not?
The spike that you see in 2015 is mainly due to the SPV mining fiasco that happened around that time, where an invalid block was mined and miners continued to build on that chain due to the fact that they didn't validate the block before mining on it and thus accounting for that spike in stale blocks. The reason why the stale blocks happens much less often, but still happens occasionally is due to the implementation of compact block[1] which relays the blocks way faster than before and it was introduced a Core version in late 2016, IIRC[2]. If the mining pools are well connected to each other, as they should, they could avoid mining on the wrong chain and losing their block rewards. Selfish mining could contribute to stale blocks but I'm not sure if that has happened yet. I'm operating a full node. Can I verify the numer of orphan blocks by myself? (Are they stored by my node)?
You have to be running a node for the entire duration to record down any stale blocks that has been relayed to you. You'll find it hard to record the accurate number of stales without quite a few nodes and/or a well connected node. You can probably run quite a few nodes and just issue getchaintip to each of them from a central server and note any discrepancy between the responses. That's probably how forkmonitor.info is doing it as well, but at a more refined level probably. [1] https://github.com/bitcoin/bips/blob/master/bip-0152.mediawiki[2] https://github.com/bitcoin/bitcoin/blob/c7ad94428ab6f54661d7a5441e1fdd0ebf034903/doc/release-notes/release-notes-0.13.0.md |
|
|
|
That's true, but not if you double-spend the same inputs on the new "longest chain", which is what happened with the transaction in the Bitmex study, it all depends on the node that you connect to if the node tells you the transaction is confirmed and you release the goods/services based on that confirmation, only to find out later that not only the transaction has gone missing, it actually never existed.
I think the main mitigation to one-conf transactions would be to try to connect to a diverse number of nodes in hopes that somehow you'll also be aware of the other competing block on the same height, ensuring that the transaction is well propagated and with a sufficient fee would do. That's the general advice that I would give when 0-conf transaction was a thing but it would apply here as well. It's quite normal to see a double spend on a 0 confirmation transaction, some wallets made that pretty easy to do anyway, but to see that 1 confirmation and then the transaction disappears isn't something that happens every day, not even every year if I am not mistaken.
Theoretically, the occurrence of stale blocks with competing chain should've decreased substantially. I'm not sure about the exact propagation timings but if I had to make an educated guess, I'll say that it's relatively fast. Stale blocks are unfortunately very difficult to track since either one of the competing blocks would probably suffer from poor propagation and most nodes would only see one of them. It's probably trackable with a very well connected node or monitoring the mining pools to have a general sensing. On the forkmonitor.info it says: No (RBF) fee bumps have been detected
Not sure why that's the case. |
|
|
|
This is what they would like you and everybody else to believe.
But if you dive a little bit deeper then you will come up with a different conclusion.
Tails is designed and maintained by the NSA, and is funded by the government.
Follow the money.
To delve deeper, here's the source code: https://gitlab.tails.boum.org/tails/tails. Snowden seems to favour tails quite a bit. Unless he's currently working for the NSA, I wouldn't think he would want anything to do with Tails if what you said is true. |
|
|
|
Such incidents are unlikely to happen, but they can happen, which also makes question the ability of blockchain to be used for day by day payments without a second layer of some sort, even with an unlimited blocksize, imagine Starbucks telling you that the coffee you paid for was "orphaned" and you need to make a new transaction or return the coffee.
You probably don't have to make a new transaction, the transactions in the orphaned blocks would just be pushed back into the mempool. The instance as described seems to be corrected as a RBF instead of an actual double spend but I can't find the other competing transaction to verify if this was exactly the case. I do think 1 confirmation is sufficient to accept a small transaction with a fair amount of precautions, being well connected, having diverse nodes to detect competing blocks, etc. You don't have to obtain 51% of the hashrate unless you want to doublespend transactions that are 6 confirmations deep. In fact, with selfish mining, you would have a higher chance to outpace the network for a limited number of blocks. For most exchanges that I've seen, they require 3 confirmations at the least for deposits or if they don't, there'll be some sort of limitations on the withdrawal (binance has 2 confirmations on their withdrawal IIRC). I would think that "stale blocks", which btw is a terminology that I've gotten used to, I think orphan blocks would refer to more like a block without it's preceding block known, are not that common nowadays. Blocks are often relayed fairly quickly through the network with compact block and pools often try to have a lower latency connection to other pools, like SPV mining previously. I assume that regular transactions would be way smaller than those being sent to an exchange so that'll probably be a risk that merchants have to decide on.
Also, these kinds of double spending wouldn't necessarily be successful as well. It can only be done if the transaction is included in one of the block and not the other. If the transaction is propagated fairly well and has a decent fee, there's a good amount of chance that it was actually included in both blocks since they were both competing at the same height. |
|
|
|
|
Your wallet is probably talking about the minimum relay fee as opposed to the dust limit.
The dust limit is usually defined on a node policy as opposed to a network policy. The reason why a transaction that spends dust could be rejected is because the node considers it as a dust and thus non-standard. Otherwise, it could be mined if a miner is willing to mine it, just that you're likely to be experiencing poor propagation due to it hitting the node's dust limit. The dust limit used to be defined in terms of the minimum relay fee but it's currently defined in terms of the dustrelayfee.
The default limit for dustrelayfee (for reference nodes) is actually 3satoshi/vbyte, thus for a transaction that sends to a P2PKH address (ie it's output), this sets it at 546satoshis or 294satoshis for P2PWKH. This makes it such that it will not cost more to spend the dust than it's actual value.
|
|
|
|
centralized organizations---military, corporations, banks---can harden their systems extremely quickly if necessary. bitcoin cannot. millions of coins will remain vulnerable.
Judging by how most organizations outright refuse to upgrade their systems in a cost saving measure, it's debatable how quick that'll be. I'm not sure if there'll be a standards defined by then and whether consumers can roll out the update quickly. how about in 10 years? how about when bitcoin is bigger than gold's market?
i just don't understand the blind optimism. everything boils down to "even if it happens, nobody cares enough about bitcoin to attack it" or "everyone on the network---including the former owners of lost coins?---will magically move their coins the second before QC is a real threat". neither of those are believable to me.
That'll be a speculation, just like what most of the thread is about. What if in 10 years, Bitcoin drops to $10 per coin? There's both ways this can go of course. My take on this is that governments are not primarily very interested in monetary incentives**, if you consider that most of the country's GDP is way more than Bitcoin's market cap and you have to include the cost for running one as well and AFAIK, current technology is nowhere near the efficiency that we need and the difficulties of running one for long periods of time, I think it's close to 0K? I don't think that there is any viable solution to stop potential attackers to benefit from the older coins and most of the current proposals are merely based on the economics of doing it. If you can propose a way to stop attackers from siphoning those funds without forcibly taking it away, I'll totally be behind that of course. Otherwise, the funds will eventually be stolen, when quantum technology gets cheap enough. I don't believe that either of the statement will be true but I do however believe Bitcoin will not be the first to be exploited. ** Again, this is another speculation. The cost of running one will be clearer once we get closer to the required qubit and frequency. |
|
|
|
|
Tails is designed for privacy primarily but you'll be better off using Tails than most of the other Linux distribution since it comes with Electrum preinstalled and you wouldn't need an internet connection in that case.
I find it insecure to do something this sensitive on a public computer. There is a possibility of a rootkit infecting the firmware of the components within the computer and/or it's BIOS so I wouldn't recommend anyone doing anything on insecure computers regardless. Most public computers locks their boot priority so I'm not sure if you would be able to boot from your USB in the first place. If possible, this should be done in a private place and on a computer that you can trust.
|
|
|
|
|
I synchronized my Bitcoin Core the other day and it took roughly about 16 hours or so to complete. The main bottleneck in my case was with my HDD, the ram was saturated at about 3GB with the larger dbcache configuration. It will appear to stagnant after awhile before the dbcache gets flushed and it was quite a sporadic progress in general. If you have an SSD and with sufficient space, you can synchronize it there first and move it to a HDD with a symlink or something similar.
You'll know what your main bottleneck is. If you increase the dbcache, you'll see that the ram usage will steadily climb and you can check whether the internet connection, ram or disk drive is heavily utilized. I would assume that Core can slow down even more after you get pass the assumevalid threshold.
|
|
|
|
I meant...to a new seed, unless I there is an option to change the seed, which would provide the them result as moving the coins to a new one.
You'll have to create a new seed before sending your funds then. There would be nothing wrong with the steps in this case. Send it as you would to any other addresses. |
|
|
|
|
Read their terms of service. Will you violate any of their terms when making transactions?
The most common reason why they would freeze accounts is to comply with regulatory requirements. They may occasionally suspend account on the basis that you're engaging in activities such as gambling if the source of your transaction is linked to a gambling website. So yes, they do track your transactions.
|
|
|
|
|
It wasn't encrypted. If you can see the message on the block explorer, then it isn't encrypted. It's encoded with Op_return as a flag so it'll be valid.
As to the transaction in question, you might want to see what the number on the block that it was included in is and how it relates to that bible passage. It was done intentionally so that it has a high chance of being in that specific block.
|
|
|
|
|
You have to understand firstly that Bitcoins are not transferred within wallets. Bitcoin is a ledger which keeps track of where the funds are transferred (at a very simplified level) but the correct answer would be UTXOs being spent and created.
Your watch only wallet is created with the master public key of the cold storage. This means that your watchonly wallet is essentially a mirror of your cold storage but it only has all of your public keys or rather your addresses. You can generate as many addresses as you'd like as there will be no deviation from your cold storage. You can test it out if you want and see that the addresses from your cold storage matches those from your online computer.
Funds are never transferred within wallets. The addresses that is shown in your watchonly wallet should correspond to those on your cold storage and your cold storage should also have the corresponding private keys needed.
Yes. You can use a QR code as a medium to transfer the data between the machines.
|
|
|
|
|
Blockchain is a ledger. Nodes are decentralized mechanism to distribute it.
Nodes doesn't technically secure the entire system but rather it acts as a decentralized storage for the blockchain where every nodes saves their own copy. It doesn't necessarily mean that they would provide security for the blockchain though. Verifying the entire blockchain primarily benefits the user of that node and the people retrieving data from that node. Having more nodes does however means that sybil attacks are harder due to the larger number of nodes to choose from.
|
|
|
|
|
When you're creating an airgapped wallet, the online desktop wallet should have your master public key imported and it should be able to allow you to see all the addresses related to that airgapped wallet. There is no need to pick specific addresses, unless you want to use CoinControl and you can right click the specific address and press "Send From" to select specific transaction outputs to spend. After generating the raw transaction, you can either export it as a QR code or a file for it to be signed on the offline computer.
I'm not exactly sure what's the context of this. You created a new topic previously and I'm wondering if that's related.
|
|
|
|
for example the DNS seeds which are ONLY used when the nodes run for the very first time are created and hosted by those altcoin creators and their network is completely separate from bitcoin's network.
The node will always query DNS seeds when they are unable to get any peers. A common scenario is if the peers.dat is not backwards compatible or if the user deletes the peers.dat and anchor.dat completely.
Depending on the difference in protocol rules, the transactions that is made on Bitcoin could very well also be valid on a fork of Bitcoin and thus exposing the user to the risk of replay attacks and that is also one of the main concerns when dealing with Bitcoin forks. |
|
|
|
|
Show Posts
