|
1841
|
Other / Beginners & Help / Re: Selecting a proper way to store my Bitcoins
|
on: March 07, 2021, 05:38:37 AM
|
Don't use Web wallets. They don't provide any tangible benefits whatsoever, Desktop wallets like Electrum, Wasabi Wallet and Bitcoin Core are fine for normal use but they're not as safe as it's far more susceptible to malware attacks since you're using it all the time. They act more like a hot wallet to store small amounts of Bitcoin for easy and quick access. It's safe enough provided that you are able to manage your own security well. Hardware wallets (Trezor, ColdCard) are much safer than those but comes at a price. I would recommend you to consider it if you want the convenience and have an idiot proof method to store Bitcoins. If possible, try to ship them to your PO boxes or a reshipper so you won't reveal your actual address. Do your own research before any purchase. I can't really recommend people to use paper wallets. If you want, you can create a an air-gapped storage using two Electrum instances[1]. It provides similar security to an airgapped wallet if done correctly as it practically eliminates the possibility of a malware attack. [1] https://electrum.readthedocs.io/en/latest/coldstorage.html |
|
|
|
|
1842
|
Bitcoin / Bitcoin Discussion / Re: Question about current capacity
|
on: March 07, 2021, 04:14:10 AM
|
|
The capacity will vary wildly depending on the types of transactions that you're looking at, P2SH transactions can often be bigger than Segwit and Legacy or the number of inputs/outputs per transaction. Currently Segwit adoption is still below 50% which means that the blocks can't be at its theoretical maximum of 2.3MB. While the solution is not for everyone to switch to Segwit, it would definitely help greatly.
Taproot will make certain transactions smaller as they can be aggregated into a single signature for multisig. There probably isn't anything that will increase the on-chain capacity exponentially barring any block size increase or whatnot. I'll think Lightning network is more useful for smaller transaction. Of course, if there's any better proposals, do let me know might've missed something during my hiatus.
|
|
|
|
|
1843
|
Bitcoin / Bitcoin Technical Support / Re: Stuck transaction with descendants - help!
|
on: March 06, 2021, 04:19:57 PM
|
I would have to wait first for this transaction to get confirmed before I can do any other transactions?
You made a small mistake in here. Burning dust entails that the transaction should only contain the dust as the inputs and nothing else. The purpose of certain dust attack is to de-anonymize users by making them spend the dust inputs together with their other inputs and thus resulting in a link between those addresses in the same transaction. By spending the dust with your other UTXOs (inputs), you are doing exactly as they intended. In some cases, the inclusion of that dust input would actually increase your transaction fees disproportionately, making it more expensive to spend the dust. As long as you take care not to include any of your own inputs in a transaction intended to burn the dust, none of your other transactions will be dependent on that transaction as none of them will be spending the output from the burning transaction.
You can lock specific UTXOs to avoid spending them at all and save the hassle. See the documentation: https://chainquery.com/bitcoin-cli/lockunspent |
|
|
|
|
1844
|
Bitcoin / Development & Technical Discussion / Re: How to verify btc transactio signature with site like https://tools.qz.sg ?
|
on: March 06, 2021, 03:22:30 PM
|
I was try empty messages, paste publick key without header(04,02 etc)but not successful.
You cannot verify signatures with Bitcoin transactions from these sites as they are made to verify signed messages instead. Signed messages has a different format as compared to transaction signatures; having "Bitcoin Signed Message:" added before the actual message, etc. I'm not sure what you're trying to achieve here. Are you trying to verify if a transaction has been signed correctly? |
|
|
|
|
1846
|
Bitcoin / Bitcoin Technical Support / Re: Stuck transaction with descendants - help!
|
on: March 06, 2021, 02:15:30 PM
|
That sounds promising. I have never scripted a raw transaction before and am a bit puzzled what exactly to put into the the fields at https://coinb.in/. Would you (or anyone) be able to assist me with this as I do not want to make any errors. Feeling bad enough already that I created this mess in the first place. Before that, you can try abandontransaction to see if it'll remove the transactions as well as the descendant transactions to see if it'll remove them and mark them as spendable. bitcoin-cli abandontransaction de188ec7d50032773a43af8703b2f17d6bde2ae701b64934bce3e8850cd6a904
If you're running anything older than 0.21.0, can you try restarting your full node and running it with -zapwallettxes as a flag at startup?
If neither of them works, then you'll have to try to create a raw transaction manually and it can be slightly tedious. I was trying it out for myself and their own server doesn't seem to be working so you'll have to select a different source at https://coinb.in/#settings. Select Blockchair (Bitcoin Mainnet) under Unspent Outputs. At https://coinb.in/#newTransaction, you can enter the address that contains the inputs from (de188ec7...). After which, you should see that the inputs tab is populated with the unspent inputs associated with that address like so:  After which, you have to paste the desired address in the Address column as well as the output amount. Take note that any Bitcoins that is not spent will be used as a transaction fees so you have to spend all of it less the transaction fee or just add another output to use as a change address. If you're unsure as to how much transaction fees to include, here's a nifty website that gives you the fees to include ( https://bitcoindata.science/plot-your-transaction-in-mempool.html). After which, you can click on submit and there should be a box with a long string. Copy that down. bitcoin-cli decoderawtransaction "COPIED STRING"
Check if the transaction details are correct. You should be able to see the virtual size as well. Divide your fees in satoshi by that to get your fee rate which should be what you have entered in the site above. If it is, you can sign it/ bitcoin-cli signrawtransactionwithwallet "COPIED STRING"
You should be given a signed raw transaction. Decode it at https://coinb.in/#verify to check it again and you can broadcast it using https://coinb.in/#Broadcast.
Given that OP says that none of the transaction have been broadcast, and I can certainly not find any of them in a handful of mempools I have just checked, would it not be easier for him to just use abandontransaction on the first one, which will abandon all three transactions and allow the inputs to respent directly from Core. He can then just create and broadcast new transactions the usual way without having to manually script anything. OP, see here for more information: https://bitcoincore.org/en/doc/0.21.0/rpc/wallet/abandontransaction/I forgot about that at first. Should work if it's not in the local mempool. |
|
|
|
|
1847
|
Bitcoin / Bitcoin Technical Support / Re: Stuck transaction with descendants - help!
|
on: March 06, 2021, 01:06:21 PM
|
Is it true that these two descendant transactions will only be broadcasted and picked up by the miners when the ancestor is confirmed?
They will only be confirmed when the parent transaction is confirmed, either in the same block or in a preceding block. As the parent transaction isn't relayed, your subsequent orphan transactions can't be confirmed as well. I tried to bump the fee for the first low-fee transaction by using bumpfee "tx-id", but that does not work as the transaction has descendants.
I do not have the luxury to just wait until they are removed from the mempool because the other two transactions should already have gone through yesterday.
None of your transactions are replaceable so bumpfee will not work regardless. It is not in the mempool in the first place, or at least it is very poorly propagated. You can try scripting a raw transaction instead with the inputs used in that transaction. It'll go through just fine. How to fix this? Is it still possible that I ask a miner or - as what was suggested in the "Stuck transaction topic" - to ask someone who has access to F2Pool's transaction selector?
I am willing to pay for the fees of course.
Below are is the output of the mempool entries of the three involved transactions
Possible. I'm not aware of anyone who has access to that though. Be wary of anyone claiming they do and attempting to collect payment upfront.
You might want to use https://coinb.in/ to script your raw transaction. If you were to include any of the inputs from the first transaction (de188ec7...) in your new transaction, then that transaction and its descendants will also be invalidated when it gets confirmed and you should be able to make the other transactions as well. |
|
|
|
|
1848
|
Bitcoin / Bitcoin Technical Support / Re: Double Spend VS Transaction Accelerators.
|
on: March 06, 2021, 11:12:45 AM
|
-snip-
I tried replicating the scenario that you described. This isn't anything scientific but should provide a clue into the behavior of reference client. Miners should have a different behavior given that they are probably not running the reference implementation. Here's my first transaction: Output A to Address B. 91ed8bad00c62dfdde7068da6c3216fa2af51e0d3c994ac683cf03069ceea1b6 {
"fees": {
"base": 0.00000550,
"modified": 0.00000550,
"ancestor": 0.00000550,
"descendant": 0.00000550
},
"vsize": 110,
"weight": 437,
"fee": 0.00000550,
"modifiedfee": 0.00000550,
"time": 1615027325,
"height": 673402,
"descendantcount": 1,
"descendantsize": 110,
"descendantfees": 550,
"ancestorcount": 1,
"ancestorsize": 110,
"ancestorfees": 550,
"wtxid": "5ea4da4c370d67bfcaf0d7a3591b56cb7b4240a4cbfd72a404c5078d606d443e",
"depends": [
],
"spentby": [
],
"bip125-replaceable": true,
"unbroadcast": false
}
My node sees it in the mempool. After which, I replaced it with another transaction. Output A + Output C to Address B. The first transaction is purged from my node's mempool. The second transaction is now available. { "fees": {
"base": 0.00001246,
"modified": 0.00001246,
"ancestor": 0.00001246,
"descendant": 0.00001246
},
"vsize": 177,
"weight": 708,
"fee": 0.00001246,
"modifiedfee": 0.00001246,
"time": 1615028442,
"height": 673405,
"descendantcount": 1,
"descendantsize": 177,
"descendantfees": 1246,
"ancestorcount": 1,
"ancestorsize": 177,
"ancestorfees": 1246,
"wtxid": "cd4f4135cd73e4ac9a8059feef951dd8948544c826f933ee5423b1453c5559c4",
"depends": [
],
"spentby": [
],
"bip125-replaceable": true,
"unbroadcast": false
}
Afterwhich, I broadcasted the third transaction. With output C only to Address B. 8724f830d928064a095107c99dc84f57ec5df22477d075d4d1539f7e028212ad
{
"fees": {
"base": 0.00001430,
"modified": 0.00001430,
"ancestor": 0.00001430,
"descendant": 0.00001430
},
"vsize": 110,
"weight": 437,
"fee": 0.00001430,
"modifiedfee": 0.00001430,
"time": 1615028761,
"height": 673405,
"descendantcount": 1,
"descendantsize": 110,
"descendantfees": 1430,
"ancestorcount": 1,
"ancestorsize": 110,
"ancestorfees": 1430,
"wtxid": "22ba16de06447cc25b8211a99c39c1b247cb17410378c3814578f300beada316",
"depends": [
],
"spentby": [
],
"bip125-replaceable": true,
"unbroadcast": false
}
The previous two transactions were both evicted from the mempool. Results appears to be consistent across both of my nodes.
Transactions that are evicted from the mempool but are still otherwise valid appears to be excluded from a reference node's mempool after it gets replaced. |
|
|
|
|
1849
|
Bitcoin / Electrum / Re: Should I Upgrade?
|
on: March 06, 2021, 08:51:29 AM
|
If you go in to both your wallets, open the console (you might need to click on View -> Show Console first), and then enter the following command: wallet.gap_limit_for_change There is no easy command to increase the gap limit for change address like there is for receiving addresses as far as I am aware You actually mentioned the command needed to do so yourself  wallet.gap_limit_for_change = X . Just replace X with the gap limit. |
|
|
|
|
1850
|
Bitcoin / Bitcoin Technical Support / Re: public address in my wallet?
|
on: March 06, 2021, 05:52:33 AM
|
Correct, don't want to override it..probably don't need it at all.. however, just was curious whether that would be something possible or not. Yes, once I received the back the difference to the system generated address, I could send back the difference to my desired address again, in this case ABC. However, another transaction means another fees as well. So I just was thinking that if we could specify the public address where we r supposed to receive back to, at the time of when we send it somehow, we could avoid another fees possibly...
Yes. The UI provides a fairly easy way to do so as well. Ensure that you have Coin Control turned on in the settings.  After which, you should be able to see a box labelled Coin Control features. There's a checkbox to specify a custom change address and after which, you can specify your own change address.  |
|
|
|
|
1851
|
Bitcoin / Development & Technical Discussion / Re: Are you running Bitcoin Core through Tor? Should it be a requirement?
|
on: March 06, 2021, 05:23:03 AM
|
Even IF a peer starts analysing the packages exchanged between him and you, he still doesn't know wether you created a transaction or merely broadcasted a transaction from somebody else. If you don't re-use addresses and mix coins before moving them to cold storage (or a hardware wallet), your privacy is reasonably safe... Safe enough for me atleast
The ISP or anyone that can see the traffic between your computer and the clearnet can probably tell if the transaction originated from you or someone else. This probably would be the main reason why people are using Tor.
I second with the above sentiment. I don't think forcing everyone to be communicating through Tor is necessary. Bitcoin is after all not that privacy-centric by nature and trying to force it to be Tor only would just create a false impression that it helps to improve privacy in the first place. I've tried running through Tor using my main computer and it just doesn't work which could probably be something wrong with the configuration and it's just way too troublesome to debug and fix. It's kind of tough running Tor in certain countries without bridges and provided that you're able to download Tor in the first place. |
|
|
|
|
1852
|
Bitcoin / Electrum / Re: Should I Upgrade?
|
on: March 06, 2021, 04:22:09 AM
|
Why the extra 4?
The gap limit for the change address was changed from 6 to 10, between 3.3.8 and 4.0.1. It wasn't reflected in the Release Notes but I compared the changes in the codes previously. Forgive me lack of understanding, but if in V 3.3.8 I generate several new addresses, after the original 26, would new private keys result?
No. Your seed phrase provides you with a master key pair, both master public key and master private key. The subsequent addresses or private keys that are generated from the corresponding keypair should not deviate no matter how many keys you generate. If so, and if I used the seed phrase to restore a wallet, how would it know that new private keys had been created?
When you restore a wallet, Electrum will start to generate addresses until it hits a gap limit, that is if it finds at least 20 "receiving" addresses that has never been used and 10 "change" addresses that has never been used. If you were to change the gap limit and use the addresses out of sequence, you'll have to modify the gap limit to ensure that Electrum manages to generate that many addresses. Finally, can I assume that because v 4.0.9 generates 4 new private keys, then restoring a seed phrase from a V 4.0.9 wallet to recreate in V 3.3.8, then effectively, 4 private keys, and their associated addresses and bitcoins, would be lost?
No, the software should never generate addresses which doesn't belong to the seed phrase or the master public key that you have imported. Both wallets will generate the addresses similarly as Electrum seeds has a version byte which tells the software the types of keys to generate so that it won't generate a legacy address (1) if you have used a Segwit address(bc1) before and vice-versa. |
|
|
|
|
1853
|
Bitcoin / Wallet software / Re: Iphone attack/hack? I was asked for name, number and IMEI
|
on: March 05, 2021, 02:09:36 PM
|
With a name and phone number, they cannot replicate your Google Authenticator, but they might be able to replicate your Authy if that's what you use. Authy store all their codes on their servers, and so if someone can convince Authy they are you (perhaps by spoofing your phone number or executing a SIM swap attack) then they could access all your 2FA codes and therefore attempt to hack your exchange accounts. This is the main reason you should not use Authy.
Authy does encrypt their backups and switching device will require the user to decrypt their accounts again. -> That is if my memory serves me right but I felt that it wasn't easy to get compromised through a sim swap. If you ever hand your phone over to anyone else for repair or anything else, then you should export all your data to a back up and then wipe it before you hand it over.
Exactly. Most devices can have their encryption bypassed, given enough time or a zero-day exploit. |
|
|
|
|
1854
|
Bitcoin / Wallet software / Re: Iphone attack/hack? I was asked for name, number and IMEI
|
on: March 05, 2021, 11:37:24 AM
|
Is it possible with a Name and Phone number and IMEI to fake your iPhone download google authenticator, or authy, and get into your Binance wallet accounts?
Not that I know of. Google Auth, Authy operates independent of your IMEI and it should be impossible for anyone to social engineer their way using it as well. Can they get all the apps downloaded that you have on their faked phone?
No. Does this seem really sus? for what reason does she need that info.
Will I be safe having given a fake IMEI?
Most countries usually use IMEI as a way to track and identify any possible stolen phones. It is perfectly reasonable and possibly within the guidelines for them to ask for your IMEI. IMEI number has a checksum so they should know if it's invalid if they try to check. |
|
|
|
|
1855
|
Bitcoin / Wallet software / Re: What is the story of old addresses not safe and the need for new addresses?
|
on: March 05, 2021, 06:34:33 AM
|
This sounds like something that each wallet software or possibly a shared library that they each use has to fix on their own. This RFC6979 patch would have to be applied by them all in order for them to be considered safe, right?
Not exactly. RFC 6979 only ensures that the r values are not reused by implementing a deterministic signature, it doesn't necessarily mean that non-RFC6979 signatures are vulnerable. What is the guarantee that some lesser-known wallets (not common wallets like Core and Electrum) aren't using this RFC and aren't reusing r values?
If you're reusing r values, then your funds would probably have already been stolen. The risk really only exist in the poorly designed wallet (either included intentionally or accidentally), mitigation is to use more well known and audited wallets. I don't see it as a big issue if wallets don't implement it as long as they don't reuse the r values. It should probably be one of the few basic checks on the transactions/signature before any release. |
|
|
|
|
1856
|
Other / Beginners & Help / Re: P2P Network discovery question.
|
on: March 05, 2021, 04:34:44 AM
|
2. So once the IDB is done, then sync is pretty much instantly is done. Depending on the network latency, I could see the new block right away or probably next day then...
Depending on the peers. Unless you have intentionally connected to some very bad peers, you will still see the headers pretty quickly as the block is propagated. 3. So in this case, say Block B has a transaction saying PA sent 10 bitcoin to PB. Then this will be invalid transaction..so PA will receive back that 10 bitcoin...then this PA user will eventually find out the bitcoin hasn't been sent..or PB found out he/she hasn't received it..then PA will need to send 10 bitcoins again eventually?
That depends. In this case, a transaction would only be invalid if a different transaction which spends any of the same inputs (UTXOs) are included in the longest chain. If there are no competing transactions, the transactions in block B which are otherwise not included in any of the blocks that are in the longest chain (Block A or C) would just be returned back into the mempool, awaiting for another miner to mine a block that includes the transaction. |
|
|
|
|
1857
|
Other / Beginners & Help / Re: P2P Network discovery question.
|
on: March 05, 2021, 04:00:03 AM
|
1. When bitcoin-qt started, full sync will be performed. Say I started my bitcoin-qt, then once the full sync is done, my blockchain is up-to-date, which means, my latest block height is highest number. Correct?
Bitcoin Core will determine if it's the latest block by comparing the block header with your peers. 2. Each node has their own copy of the blockchain. Whenever sync is done, the blockchain in each node will be updated acoordingly. So when the sync is actually performing? Only at the startup? Whenever new block is submitted from a miner? Periodically?
Initial Block Download (IDB) is the process to download the blockchain from the genesis block initially. After it gets to the chain tip, it will verify and process blocks when it gets relayed from any of its peers that it is currently connected to. 3.I am not sure I fully understand here...so how the block height will be synced across nodes correctly? I mean...say..in A node, there r 5 blocks...and new block submitted to this node, and added in that chain, say the block height of this new block is 6...say in B node, there are 5 blocks as well...say new block submitted to this node, and added...then this block height is also 6... So..basically same block height number, but different blocks... wouldn't that be necessary to resolve this somehow?
Nodes will always follow the chain with the highest cumulative POW(POW). If two blocks happens to be found at the same time, a fork is formed. In a perfect scenario, half of the network's nodes will see Block A and half of the network's node will see Block B. Miners will build their blocks on top of the block that they see first. Whichever miner that finds the block on either chain will lengthen the chain and thus increase it's cumulative POW. After which, the new block, Block C which is built ontop of Block A will be relayed through the network. Those nodes which sees Block A will include Block C in their Blockchain and those nodes which sees Block B will discard Block B and include both Block A and Block C in their blockchain. As such, Block B is out of the equation and the network continues to build on Block C. |
|
|
|
|
1858
|
Other / Beginners & Help / Re: What are full nodes
|
on: March 05, 2021, 03:49:31 AM
|
But, I have a question, normally in a pool mining, no nodes for verification, miners in this case depends on pool server, in this process if one of the miners in the pool mine a block, the miner will not be able to verify? I believe after it mine a block, it will still have to depend on the pool server that has the blockchain for verification? Or, after a block is mined, the mining is the first verification?
Your phrasing is a bit confusing so I'll just answer this based on how I interpret your question. It is correct that every miner should be a node, or at least have the capabilities to validate all the transactions and preferably also be able to validate the blocks that it receives.* The miners in a pool will at no point receive sufficient data or have sufficient data to validate anything; they don't have UTXO, they don't receive the entire block from the pool. When a pool receives a new block, the pool validates the block and if it passes validation, they will send the block header together with the hashes to the miners and they will start compiling the block headers to hash it. A pool has to be able to validate transactions. If they are unable to do so, they cannot determine the valid transactions to be passed onto the miners mining in that pool. Miners within a pool doesn't need this, they trust that the mining pool is able to discern valid blocks and valid transactions. * As for this, I imagine if you were able to SPV mine and just trust a reliable source (some block explorers) for the hash of the tip, target, etc , you can probably just mine empty blocks and you wouldn't need to validate anything. Of course, no one does this. |
|
|
|
|
1859
|
Bitcoin / Bitcoin Discussion / Re: Vanity address scam rising
|
on: March 05, 2021, 03:37:37 AM
|
LOL. Those scams generally don't ask for donations. They advertise themselves with something like "Elon Musk decides to giveaway bitcoin in celebration of SN10 landing". Then they'll have some explanation about how the most tech-savvy man wants you to "learn" bitcoin. So, as a proof, you need to send some BTC and Musk will send you double of that.
There generally are lot of supporting replies saying, "OMG, My life has changed. Thank you so much @elon"..
It is indeed funny that people still fall for these scams.
Oh, those are quite prevalent on Twitter then. They're always on Elon Musk's tweets with a photoshopped image. The fault is thus on Twitter for not actively policing the feeds to remove then. It would be incredibly easy to at least tag them with the current OCR they're using on images to detect certain phrases. |
|
|
|
|
1860
|
Bitcoin / Bitcoin Discussion / Re: How will Quantum computing affect Bitcoin?
|
on: March 04, 2021, 05:22:21 PM
|
I understand that reusing the same wallet address is not advisable when security is the top priority, the last time I read public can be share online but what you just said now makes me surprise and curious what you really mean. The question is why would people with exposed public keys be vulnerable?
On the similar vein, reusing address results in exposed public keys as transaction will contain the ECDSA public key of the address. The private key can be derived from the public key using Shor's algorithm given a sufficiently powerful quantum computers. Addresses are not public keys, they are the hash of the public keys. |
|
|
|
|
Show Posts
