It is a necessary evil.
Sometimes the receiver has no other option when receiving bitcoin from for example some terrible service that pays very little fee and refuses to be helpful at all. Specially during the long mempool congestion times the receiver can't just leave the tx be unconfirmed and hope for the terrible service to not double spend the output when it drops from its mempool.
I know. I'm saying if there's an alternative, then it really shouldn't be used. There was this one time, I did CPFP (with a pretty hefty fee) and it didn't get confirmed for hours, RBF wasn't my first choice as I went to spend the unconfirmed UTXO already  . I got frustrated and just RBF-ed it and it got confirmed in the next block and the fees were lower than those that I spent in the combined TX. I'm not sure what's the composition of miners that accepts CPFP TXes too. I would simply just rebroadcast it continually till it confirms but if your service is using a 1sat/vbyte fees, then I think everyone should steer away from them. |
|
|
|
I kind of agree with you, only with the point of trust not being disclosed to a new user at all. What I mean is, there is no mention of something like a trust rating to a random new visitor for the forum. So if someone reads a post about something without logging in, the person most likely is never know that something like a trust system exists. To counter this, I suggest putting a text that says: "Trust Rating for this user can only be viewed when logged in. Please register or log in to view this user's trust rating", something like this:  Thoughts? For those who aren't logged in, if a trust flag is in place with sufficient support, they'll have a warning to warn the user. I don't like how the trust system has evolved into something more political and serves less of its original purpose. Trust flag would serve as a sufficient warning though they'll only appear in the relevant boards. DTs has improved from the past but is still far from perfect.
Having a forum wide trust system would be useful but I imagine the justification of it inhibiting discussion is understandable as well. |
|
|
|
I'll take 7. I'll send the payment in a bit, I'm outside right now.  Here: f0338e5931872c39edb1b0a24c4c693d48ab2a462c6393e1fab34bdbed1d7735 |
|
|
|
An unconfirmed transaction means that the coins are not really yours yet and the sender can reverse/cancel it.
To mitigate this risk, the receiver can create what's called a CPFP (Child Pays For Parent) transaction which spends the unconfirmed outputs and pays higher fees.
Paying higher fees will incentivize miners to include both transactions in the block they are working on. Think of it like bumping the received transaction fee.
I'm really not a fan of this. Yes, it's the only method that works if the sender doesn't want to pay a sufficient fee but it shouldn't fall on the receiver. CPFP does however, result in the transaction fees being way higher than required and introduce unnecessary spam by generating an additional transaction when the network is congested enough. It's possible that a small output could be generated and it would just result in you having to pay additional fees to spend that smaller output in the future. |
|
|
|
Could someone explain what exactly unconfirmed and subsequently 1 confirmation means, and if there are any actions you (the receiver) has to do?
It's when your transactions are not yet mined by a miner. At this point, the transactions are easily reversed since it hasn't been mined into a block yet and the efforts needed for it to be reversed is relatively little. The more confirmations you have, the more effort the attacker has to put to reverse that transaction. You don't have to do anything, in fact you can also spend unconfirmed transactions. Also what does the "amount" and "balance" numbers represent because they don't seem to be the btc nor fiat amount that was sent.
The amount is the amount of Bitcoins sent in the transactions to a recipient and the balance is the amount of Bitcoins left in your wallet at that point in time after that transaction. That's weird though, it is represented as such for me at least. |
|
|
|
|
I presume due to the storage concerns, you've decided to prune the blockchain to a certain size? Maybe you did this inadvertently.
You'll have to resynchronize the blockchain unfortunately, you can prune your Bitcoin Core but you cannot import wallet files as pruning discards the files that would otherwise be necessary for you to obtain the relevant transactions to your wallet.dat.
|
|
|
|
|
Ultrasonic cleaners vibrates at a certain frequency which helps to free up the dust and stuff AFAIK and they're much safer than using dishwasher because they wouldn't have any free ions or salts if you're using distilled water. I could see a problem with the components rusting if they're not dried properly.
I really wouldn't let mine touch water though, giving it a good compressed air does the job well enough. And I don't have to worry about anything shorting out.
|
|
|
|
So I have entered that, which seemed to work. However my wallet still shows, 0.01213365 BTC [-0.0117706 unconfirmed], and when I try to send the exact amount I initially sent, I get an insufficent funds notification.
It's not exactly instantaneous, took me a few minutes when I tried doing it last time. Give it a few minutes and it should disappear but do not restart your Electrum. Im not sure how there are 2 outputs, literally all ive done is broadcast a transaction, increased the fee once, and then cancelled it. I'm so confused
It's a change address. The remaining Bitcoins that aren't sent to the recipient are sent to your own address. |
|
|
|
I don't think looking at the current state of the mempool is sufficient. What if for example, 4 or 5 blocks were recent found in a span of 3 minutes? A fee consistent with transactions 1 MB 'deep' in the mempool might not confirm for hours/days. On the other hand, if there have been 2 blocks found in the last 3 hours, a transaction 1 MB 'deep' might confirm in just a few blocks. In all cases, a transaction 1 MB 'deep' is unlikely to be confirmed in the next block.
IMO, any fee estimator needs to have an adjustable parameter that assumes the average block time for the next n blocks. Over the long term, blocks will be found on average, once every approximately every 10 minutes, but at 2:00 on a Saturday afternoon, the time until the next 6 blocks are found could be a wider range of times.
edit:
maybe a better analogy would be the last block was found 10 seconds ago versus the last block was found 90 minutes ago.
Definitely isn't. There isn't a reliable way to predict all the factors and what they can do is to give the best estimation. If you want to assume such scenarios, then there lies the risk of overcompensating which is what some fees prediction formulas accounts for and could grossly over-estimate the fees. I don't think there would ever be a way to accurately predict the fees given the huge uncertainty of the various factors and giving the users a choice to see which of the fee mechanism they want to follow would be the best. Anyways, I don't think having such excessive fluctuations are common, the varience wouldn't be that big without a huge cut in the hashrate. |
|
|
|
But its like we want to crack 24 digit password with 24 characters , its easy for computer to test all of this possibilities
Yes, but your computer needs to run for 25k years (and remember that an average human life span is around 80 years), that isn't easy. 12 words is okay, 24 is not. I don't know of any script that could recover 24 word seeds because its so infeasible. BTCRecover is your only chance, unless you pay someone to write a script for you. Even if you factor in the birthday paradox, you need 17.5k years. |
|
|
|
I don't understand why would you not know the sequence when you're writing down... But that aside, yes as jackg said, its a pretty huge keyspace to search for. BTCRecover could work but 24 words is really a lot, can you at least have a rough idea of the sequence? If you have a vague idea of it (at least 12 words), go try https://github.com/3rdIteration/btcrecover/blob/master/docs/BIP39_descrambling_seedlists.md. Or else, sorry you're out of luck. Resources needed for 24 words is really astronomical. |
|
|
|
Okay... But I've scrolled through 9 whole pages of your account and all that I can find is short sentences that doesn't really make sense or just you claiming your bounty. You can appeal if you've contributed substantially to the community and get a lighter ban but I doubt thats happening, judging by your post quality. |
|
|
|
Hmm... You copied the posts from the internet to earn from your bounty  Post your profile link so we can tell you how bad your spamming was. Don't think you would get unbanned though. Plagiarism is not tolerated here. |
|
|
|
With the big tech companies taking in too much Bitcoin, the price will only go up - but will it make the cryptocurrency less accessible for everyday people who don't have millions of dollars to plug into electricity money death?
There's no shortage of Bitcoin, it's just scarcity that pushes up the prices. You do realise you can buy fractions of a Bitcoin right? If hypothetically, Bitcoin rises to 1 million dollars, then we'll transact in smaller denominations. Obviously having more demand than supply is beneficial to those holding cryptos, it's literally the most fundamental economics principle of supply and demand. |
|
|
|
|
Yes. The seed imports all the addresses in the first wallet to the second.
You'll be able to spend the funds from both wallet, as long as you do not create conflicting transactions. Ie, spending the same inputs from both wallet at the same time.
I won't really advise you to do so though. The more places you import your wallet, the larger your attack vector (if one is compromised, then all your funds will be at risk). Instead, I'll decide which is the more unsafe (in terms of portability, operating system, things I would do with the computer) and create a new wallet and send a small portion of my funds there.
|
|
|
|
|
You cannot change the additional fees because its charged by Electrum/TrustedCoin, it's different from a miners fee. If you pay that, you'll also pay for the subsequent transactions.
If you want to stop their 2FA, go ahead and create a new wallet and restore using the seeds and send normally. You have to pay the fees to use 2FA.
|
|
|
|
Limitations:
Sudden spikes in the mempool will make your transaction get delayed. Fee is underestimated in those cases.
But i think this is better than suggesting 200 vbytes while you could use less than 10.
Pros and Cons to both approach I guess. I don't think your code would compensate for the sudden drop in fees right after a block is mined right? Fees after a block is mined tend to be lower (of varying degrees depending on the fee structure). Giving users the visualisation of the fees is great but I think users tends to complain more when their transactions get stuck than when they over pay for the fees, from what I've observed anyways. I actually stumbled on your site a few days ago and I liked the graph on the right a lot. Please do keep it  |
|
|
|
the difficulty will drop to 1 for 2016 blocks and I suppose that happens quite too often because miners could be mining blocks in the future by adding 20 mins to their node timestamp just to cause a difficulty drop, but there are only 2016 blocks to be mined and some people abuse the testnet with S9s, so there is no guarantee that you will manage to hit a block before the difficulty gets adjusted again, but if your hashrate is good enough to solve a block with 1 diff in a few mins, then I can't see why not!
Nope. The difficulty reset doesn't last for 2016 blocks. It only happens when the time elapsed since the previous block has exceeded 20 minutes and the client will accept any blocks with a difficulty of 1. Right after it gets mined, the difficulty will jump back to it's previous difficulty. The trick that loads of people use is to just mine a block with a difficulty of 1 and right at the moment when it hits 20 minutes, they will broadcast the block. |
|
|
|
So, I would like to know what is the default timeout for inbound connections and outbound connections before the other peer closes the connection. In other words, how much time I have to fix network connectivity issues before I begin to lose most of my peers. I assume these two can have different values?
Bitcoin Core has two flags, -peertimeout[1] and -timeout[2]. Both of which are configurable by the user. The latter meaning the timeout when connecting to peers while the former means the time for which it waits when a peer is unresponsive before disconnecting. I don't think Bitcoin Core removes the nodes from peers.dat unless they misbehave right? If so, then your peers will reconnect when they restart anyways so no worries there. You can find the relevant codes here: [1] https://github.com/bitcoin/bitcoin/blob/1b75f2542d154ba6f9f75bc2c9d7a0ca54de784c/src/net.h#L85[2] https://github.com/bitcoin/bitcoin/blob/1ae46dce60a187740ec78b5a3cee8baad0fa539d/src/netbase.h#L23 |
|
|
|
I made a very simple script which will just look at the mempool and suggest the lower fee within the 1 MB blocksize. The transaction may not be confirmed within the next block. What do you guys think? Is it useless, or should I publish in my mempool page? I thought about creating an alert like this "Optimum fee: X sat/vbyte. Warning: Your transaction may not be confirmed within 30 minutes, but probably will." (or soemthing like that) I don't think any of those fee estimators do any good. Few days ago the mempool was cleared (1 sat byte would get a confirmation) and electrum was suggesting 200 sat/byte . Hmm, how different is it from pre-existing ones? There's no harm sharing with us. I think the main aspect that most estimators are missing is likely the issue that the fees are sticky downwards and tend to be less responsive to the smaller mempool. I find it hard to estimate fee given the variables and uncertainty. It'll be great if it could display the fee stats of a few hours prior and a visualisation of the current mempool. Anyways, when I feel that Electrum is overpaying with their ETA fee estimation, I'll just switch to mempool and hope for the best. Don't find anything wrong with it, their ETA has to be more cautious since mempool could be smaller due to a bunch of blocks being mined in succession and resulting in a perceived smaller mempool size. |
|
|
|
|
Show Posts
