text:
How would one extract the list of public keys from Electrum wallet?
I am looking for a way to extract all of the public keys associated with my electrum wallet. I am aware that listaddresses() does this for public addresses, such as 1CWX7o1Ppe4JpEpSLmuovU4HFY3D6Ay24C  - however, I am looking to extract the public keys, such as 02b96c2739e9543bdc17bbe58b73a3a9a16aedf2ed554faca9e5acf0b279f5d0e1.

The following code worked for me in the Electrum console and was able to give me all of the addresses in a single command.
for i in listaddresses(): print(i + " = " + getpubkeys(i)[0])

You cannot get all of them in one go. You can call getpubkeys("address") for each address (or do it via the GUI by going to the Addresses tab, right clicking on an address, and selecting "Public Keys")
Alternatively, you can get your master public keys (xpub) and derive from those.

Thank you for the input!
Would I be better off generating them directly from the xPub using something that generates addresses in the same fashion?

If you're doing it often enough, having the xpub will likely help/save time. Electrum's client is open source, so you should be able to find the xpub->address code in there, and plenty of implementations exist in other languages


text:
Can one recover the full list of public keys generated in electrum with the seed/private key?
I used the wallet.change_gap_limit command in the electrum console in order to generate some 20.000 public keys.
Would I be able to recover all of these using my seed after completely removing electrum from my system, reinstalling it and running the change_gap_limit command again?

Yes.
As a plan B if that fails, you should be able to use piped bitcoin explorer bx commands offline. This is because Electrum v2.0 and above uses the same BIP 32 Hierarchical Deterministic (HD) technology that bx supports.
However, the Electrum HD paths are different from the BIP 44 convention. See It appears Electrum uses: m/0/0 for wallet addresses and m/1/0 for change addresses. Additionally, the English Electrum Seed Word List is quite different from the newer English BIP 39 Seed Word List, and I don't believe Electrum uses a PBKDF2 stretching function that is not invertible. See stretch->passlib.pbkdf2 for high level details for what bx mnemonic-to-seed is doing. Unlike BIP 39, an Electrum private key should be invertible to a group of Electrum seed words.
For the synthesis of BIP 44 paths for Bitcoin m/44'/0'/0'/0/0 private key and M/44'/0'/0'/0/0 public address using bx, see Example 7. See BIP 44 path-levels.  The change level is set to 0 for external addresses that you share with others to receive funds. The change level is set to 1 for a wallet's internal return addresses.
If the information above is too pedantic, read Chapter 5 of the Mastering Bitcoin Book. Albeit, details about Electrum are scarce.

Thank you so much for your input and the valuable information you've shared with me.

Yes. This is the way HD wallets work - the "deterministic" part means that you will get the same exact keys when you run it again. For verification purposes, you can try it yourself and see before you deposit any money.

@cpe871 Note however that electrum doesn't handle such large wallets very well. You may want to create multiple wallets if you want a lot of addresses. File > new/restore, enter a unique filename and proceed with on-screen instructions to create a new wallet. file > open will let you switch between them.

Thank you so much for your input and the valuable information you've shared with me. Do you think someone who played around with the source code would be able to generate large datasets of public keys that are identical and circumvent electron's inability to handle such massive sets? I would like to generate at least one million public keys for one address. Do you know of any other services capable of this?

source: Stack Exchange

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

sort: votes


text:
Network Time of Bitcoin
Bitcoin uses UNIX time for timestamp. Unix Time is really accurate. I want to know why there is a "70 minutes" offset is allowed in Bitcoin network adjusted time. Is there any distribution used to get to this "70 minutes".

The leeway exists mostly because timekeeping is not very synchronized, overall. Computers can easily be off by several minutes, and around daylight time changes it's not uncommon to see computers off by an hour or so.
Having stuff like NTP makes things more in-sync, but one cannot expect all participants in the network to be using services like NTP.
Counting up from the Unix epoch is very accurate, yes. The ability of various computers to maintain that accuracy is not.

Doesn't the timestamp uses UTC time, therefore, it does not have daylight saving.

Yes, the timestamp is based on unix time, which inherently does not have DST. However, it is verified against the clock time of nodes, which can be impacted by UTC, especially when the clock time is set manually (in which case it may just be adjusted by an hour, but the timezone may not mention DST)

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/


text:
How does timejacking enable double spending?
http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html
I went over this blog, but I am still not clear how double spending is achieved by this attack. From what I read, the attackers submit wrong timestamps to a target node. During this period, the target wouldn't receive legitimate transactions confirmation because the target node is behind network's median time. However, I am not clear how double spending can be achieved from this.

The blog you linked to talks about a fairly sophisticated attack, involving large scale network manipulation.
The basic premise is:

You are able to identify the node that belongs to the person/entity you want to execute a double spend against
You trick that node into thinking that the network time is far behind what it actually is (up to a difference of 70 minutes against the node's own system time)
Optionally, you convince other miners that the network is 70 minutes ahead of the actual time.

This gives us the basic following setup:
The actual time, T (the actual value of this is irrelevant)
The majority miners' network time, T+70.
The victim's network time, T-70.
In Bitcoin, when a node receives a new block, it runs through some validation checks. If any of these checks fails, the block is deemed invalid. One of these checks is to verify the timestamp in the block header.
The node checks to verify that this timestamp is within 70 minutes of the what the node believes the network time to be (the network time is the median of the time the peers a node is connected to have reported).
To execute the attack, the bad actor has created a situation where the victim is 70 minutes behind the actual time, and the rest of the world is mining as if the actual time is 70 minutes ahead of the network time.
Thus, when a valid block is found, when the victim's node receives it, it will be dismissed as invalid, since from the victim's point of view it is around 140 minutes ahead of the network time (T+70 - T-70).
The bad actor then uses his own mining power (it is assumed that the attacker has a sufficient share of mining power to produce a few blocks a week) to mine a block that is within the victim's acceptable time parameters. Note that the rest of the network will either already be on a longer chain, or will find a longer chain soon enough, since the attack does not control the majority hashpower.
By broadcasting this block to the victim, the attacker can convince them that some transaction in that block is confirmed. If required, the attacker can then mine a few more blocks (which may take several days) to trick the victim into believing that the block containing the transaction has been confirmed multiple times.
At the same time, the attacker will make another transaction spending the same inputs on the much longer chain being mined by the rest of the miners. This will also be confirmed, and receive far more confirmations than the chain being created by the attacker specifically for the victim's node.
Finally, once the attacker has convinced the victim of the transaction and reaped whatever benefits, the attacker will let the victim's node connect to more honest peers. This will result in the node recalculating the network time, arriving at a more realistic value.
Once this happens, the victim's node will be able to accept the original, longer, honest chain, which will have more blocks (and more work) since it was being mined by the majority hashpower. This chain contains the double spend of the transaction the victim was tricked into believing was confirmed.
The minor chain on which the victim was convinced of the transaction will then disappear, being replaced by the longer chain, and leaving only the double spend on the blockchain.

Does the targeted node need to make payments in order to double spend?@Raghav Sood

Usually, when executing a double spend, you would get some other value out of it (such as being able to trade your double spent coins on an exchange). This way, the victim only needs to believe they have received the money, and not need to spend it.


text:
how do mining pools expose their stats?
Webistes like https://miningpoolstats.stream/ must communicate with the pools somehow. What protocol do they use to retrieve information such as the pool's hashrate and what blocks have been mined by that pool? If I make my own pool what is the necessary API to expose this information?

Possible duplicate of How do we know which miner or pool mined a block?

I don't think it's a duplicate. This question asks how they get API data from pools, not which miner or pool solved a block.

Mining pools export this functionality via API's.
For example, poolin's API docs are here: https://btc.com/api-doc
Here's F2Pool's : https://www.f2pool.com/developer/api
And so forth.
The way aggregators add value is by compiling all this data from different pools into a neat user interface.


text:
verifying my modifications to bitcoind w/o broadcasting anything
I want to verify that my updates to the bitcoind source code don't break anything. One way that I thought of doing that was through loading the mainnet data into a regtest instance. To do that I first copied the good data folder and then ran my newly-compiled server in regtest mode pointing to my copy. I.e:
./bitcoind -server -regtest -datadir=.../my_data_copy
When I query the server it does not return any data. The debug.log file shows a number of block rollbacks. Why doesn't that work?
Is it possible to run the daemon in a way that it verifies the current code against the data on disk, such that the the current code would generate the same data? Is it possible to copy data from main or test networks and load that in the regtest mode?
I was thinking I needed to use regtest to avoid connecting to the live network. I don't need to connect to the network at all to verify the data, and I certainly don't want to broadcast anything in my test scenario.

Mainnet and regtest have different rules for the difficulty.
As their consensus rules are different, the mainnet chain will not be valid according to regtest rules or vice versa.


text:
How do I broadcast an OP_RETURN transaction using bitcoin cli
I am using Bitcoin Testnet's command line (and GUI). I am curious how, using my own computer and equipment (I already used a faucet) I could send a transaction easily. I tried https://github.com/coinspark/python-OP_RETURN and it failed because it is a newer version of bitcoin. However, I think I could use the CLI to broadcast a message.

Bitcoin Core allows you to create transactions with up to 80 bytes of arbitrary data in an OP_RETURN output. You do this by using the raw transaction process (using createrawtransaction or fundrawtransaction) or the psbt process (using walletcreatefundedpsbt). For all of those commands, when you specify the outputs, you can specify one that is like: {"data":"<hex string>"} where <hex string> is the data you want to send as a hexadecimal string. This will create a transaction with an OP_RETURN output of 0 value with whatever data you specified in <hex string>. The transaction can then be signed and broadcast just like any other raw transaction or psbt.


text:
How to use Bitcoin Testnet2
I am looking to mine bitcoins with ease. But, first, I want to know how can I access an earlier testnet (testnet2). I have future plans to do this. I need to know how to open it up on the command line and I will take it from there. Bitcoin testnet2 has been supressed by the developers and I am curious on how to use it.


text:
How do I broadcast an "alert" message to the network
I am curious about how to broadcast an alert. I  know that this is possible because the system to send alerts has been shut down and this probably won't work, but I am curious about how I can broadcast an "alert" using bitcoin-cli.

You can't. bitcoin-cli has never had the capability to send alerts. It is not possible for a user to push out an alert from any Bitcoin Core node.
Alerts were sent by using a specially modified version of Bitcoin Core which had the particular alert to be sent hard coded into it. Developers have to modify Bitcoin Core and include the alert code in a local build every time they wanted to send an alert.


text:
Is bitcoin the most powerful computer network in the world?
I read an article from twenty THIRTEEN saying, as of then, bitcoin had more power than the top 500 supercomputers. At that time, the difficulty was 21.3 million. Now, it is almost 11 trillion and projected to pass that number within September 2019. So, using that info, the computer says that the network uses 350,000 times as much (SHA256 brute forcing) computational power as those computers did. Is that still true and if so, what is the number of times more powerful now?

bitcoin had more power than the top 500 supercomputers

This is a nonsensical comparison.
Sure, nothing compares to the aggregate of all Bitcoin miners in quickly computing the last 32 bits of the double-SHA256 hash of particularly structured 80-byte inputs.
But at the same time, Bitcoin mining hardware can also literally not do anything else. It can't even multiply two numbers.
You simply cannot compare specialized Bitcoin hashing hardware with general-purpose supercomputers. Each is designed for a certain goal, and very good at that goal.

Is bitcoin the most powerful computer network in the world?

If you're going to define network so abstractly, I'm sure that the Internet has a lot more computational power connected to it.

The hashrate of the bitcoin network is currently estimated to be ~80,000,000 TerraHashes/sec.  In Sep 2013, the hashrate of the bitcoin network was estimated to be ~600 TerraHashes/sec.  That's a 133,000-fold increase.
Source:  https://www.blockchain.com/charts/hash-rate?timespan=all

In reference to Pieter's answer, usually when people pose this question, it's in relation to the possibility of a 51% attack. If the person understands how powerful the network is in terms of hash power, they can out their mind at ease.


text:
CryptoGraffiti.info litecoin alternative
I have some pictures and litecoins, and I would like to be able to upload images to the litecoin blockchain. I also have some bitcoin, but, because of the higher value of bitcoin, I think I would prefer to use the litecoin because it allows more uploads. There is a site called CryptoGraffiti.info that charges bitcoin and bitcoin SV. I thought about using the bitcoin SV, but that would require buying additional crypto, which I can afford (the big BTC, only a couple images for hundreds of $) and Litecoin is both significantly cheaper and more well maintained than Bitcoin SV. So, I want to know how to upload an image to litecoin using this type of tool.
Note: I want to use this to upload original pictures of things like New York City  and my home town.

Note: It should be expensive, you're basically paying for your data to be processed and stored on tens of thousands (!) of computers around the world.

Note: this site doesn't support bitcoin, only BSV.

I can't find much on writing data to the litecoin blockchain, you might need to code something yourself, perhaps taking the data you want to upload, chunk it and write it by using many transactions. To read it back you need to read these transactions from the blockchain and put the data chunks back together.
If I were you I would look into Ethereum instead. Ethereum has the ability to let you write customized smart contracts that can accept files/pictures data and store it forever on the Eth blockchain. If this gets too expensive you can offload storage using IPFS, so that the Eth blockchain would need to store only the hash of the files instead of the whole files.


text:
Can I use an earlier version of testnet?
I am looking to mine bitcoins with ease. But, first, I want to know how can I access an earlier testnet (testnet2). I have future plans to do this. I need to know how to open it up on the command line and I will take it from there.

Why do you need testnet2? It's practically the same as testnet3. If you just want a network that you can basically have full control over, use regtest.

It has a lower difficulty.

So? Regtest has basically no difficulty, you can mine there. Also, testnet3's difficulty is easily gamed down to be the minimum difficulty.

What are you trying to achieve in the long term?


text:
Where is the string that generates the hash with 18-20 zeroes?
When bitcoin miners mine, they have to solve a difficult and extremely repetitive math problem using the SHA256 algorithm. The miners are trying (basically playing lottery and almost always working in large groups) to get a hash with (currently) at least ~18.81 zeroes. (I put a decimal/float number because the value is inconsistent.) But, I want to put the hash into a hash function and get that super hard-to-compute number for a story I have where a superhero calculates this number. How do I get this string (nonce) that calculates to this zeroed hash and where do I find this on a block explorer, such as blockchain.com, or on bitcoin-cli?

Sorry, I'm not secure to undestend the your question, you want have a method for calculate the nonce and you want find the nonce on the explorer, right?

Yeah. That’s what I wanted to do. The nonce has already been computed.

Bitcoin PoW uses double SHA256, sometimes written SHA256d. See https://en.bitcoin.it/wiki/Block_hashing_algorithm for the format of the block header an example. Note this data is binary (aka bits) and 'string' is usually used in computing for characters, so if you are using a program or API designed to hash 'strings' it may not work for bitcoin, although some languages like C++ and python2 do support arbitrary binary strings.

That’s true, I did some research and found that you can get the info as the block heading/header

To calculate the PoW hash, all the data of the header of the block is concatenated. The nonce is also concatenated within that data.
Then, that concatenated data is put through the SHA256 algorithm and the result is compared to the current target. The resulting hash needs to be smaller than the target to be valid.
So, it's not about how many zeros it has, but if it's smaller than the target.
Seeing it in terms of zeros could help to understand it, but that is miss leading. There could be 1 hash that has exactly the same number of zeros as the target and still not be valid, because it may not be smaller than the target.
For example, let's assume that the target is:
00000000000000000004f34860a8c59d52c4472ec3798c16f394a699f5e6d8b6
And our SHA256 hash is:
00000000000000000005f34860a8c59d52c4472ec3798c16f394a699f5e6d8b6
It would not be a valid PoW hash because it's not smaller than the target. They both have the same amount of zeros, but our hash is greater than the target.
Both together:
00000000000000000004f34860a8c59d52c4472ec3798c16f394a699f5e6d8b6 00000000000000000005f34860a8c59d52c4472ec3798c16f394a699f5e6d8b6
If we keep changing a bit the data, by increasing the nonce by 1 and then concatenating it again with the data of the block header, and pass it through the SHA256 alright again and again, eventually we will get a hash that is smaller than the target.
For example:
Target:
00000000000000000004f34860a8c59d52c4472ec3798c16f394a699f5e6d8b6
Our hash:
00000000000000000003f34860a8c59d52c4472ec3798c16f394a699f5e6d8b6
As you can see, our hash now is smaller than the target and is a valid PoW hash for our block.
The hash of the block header data could even be way smaller than the target, and it's valid. It can have more zeros, but finding a hash like this is less probable in average:
00000000000000000000000000a8c59d52c4472ec3798c16f394a699f5e6d8b6
To visualize it better, you can go to this site that has a simple blockchain implementation to visualize how a blockchain works: https://andersbrownworth.com/blockchain/blockchain
I've concatenated the data of the block 5 and passed it through a SHA256 function:
Concatenated data:
529742data0000ae8bbc96cf89c68be6e10a865cc47c6c48a9ebec3c6cad729646cefaef83
SHA256 hash of that data:
0000d73c6ecf38aa53a8fbace738ff59540fd5e519e6d9aa496f61ce70110a09
If we compare the hash of block 5 with this one, it's the same.

If I undestend the your question,
This is an example of the proof-of-work algorithm.
The nonce is a component of the block, the strucure of the block contain the value, inside the blockchain.com you can find the value inside the propiety "nonce"
I hope I answered your question


text:
How do I upload a file to a testnet blockchain?
I want to upload files to the testnet blockchain, specifically the Bitcoin testnet. I am looking for help on how to add a file to the Bitcoin testnet blockchain. I know that these coins are super easy to get via https://tbtc.bitaps.com, so I just want to know how do I do this? I can't use OP_RETURN because the program that sends them says that they don't work and there is an 80 byte limit that makes it harder even if I could easily do it. Is there a way to add data to the blockchain, i.e. by putting multiple addresses that encode information that have no known public key? This could be done with either bash, simple Python, or both. If there is a GUI program, that would be preferred and greatly appreciated. Thanks.

Just don't. It's not designed for that.

Yes, this is perfectly OK. I won't do i to mainnet because mainnet coins have real value and would cost lots of $ because I am not an early miner. (I made my first purchase in 2018 after the bubble quieted down at ~$6,500)

+1 for @PieterWuille, It is not a question of the value of the coins but it is as if I went to the sea with the skiing for the snow. The whole blockchain would be affected

@NumberFile If you don't care about doing it on mainnet, why do you care at all? This is simply not an interesting use case for blockchains.

There are two ways to do it in a standard transaction format that will be relayed by full nodes. However, if you are a miner you will have more leeway into the scripts that you can use to lock your transaction. However, doing this is strictly discouraged as it adds to the UTXO and blockchain bloat in the first case and blockchain bloat in the second case. This answer is meant just for educational purposes.
Trick 1: create a bare multi-sig output (not P2SH) and sending some non-dust value to that base multi-sig address. You would use the bare multi-sig format for encoding like M <pub_key_1> <pub_key_2> ... <pub_key_N> N but here the pubkeys between OP_M and OP_N will be your data that you want to encode padded to the public key length. However, you can lock only up to 3 keys in bare multi-sid which will be 65*3 = 195 bytes. Again I mention that this method is discouraged as it adds to the UTXO bloat.
Trick 2: A better and cleaner way to do it will be to lock some BTC in a hash of the data you want to store encoded in a P2SH address. Then spend these bitcoins where the unlocking script will be the data that you want to store on the blockchain. In this case you can lock a much bigger data but care has to be taken not to exceed 400,000 WU for the overall transaction for spending as it would make the transaction non-standard.


text:
How can I embed data into a bitcoin testnet address?
In the very early days of bitcoin, miners injected data into the address where the coins were going, not knowing that bitcoin would be worth $10,000 in 2019. However, I can get bitcoin for free on the testnet network (it has no value). I would like to embed data into the address, but, when I use the base58 encoder, it says "the data is invalid". I want to be able to embed a small message into a testnet blockchain, and this is one way to do it.

You appear to be asking about Vanity Addresses such as "1VanityeNpkB3BwFXCDynrejjQYpyDTz7". However your last sentence could also mean the contentious practice of using OP_RETURN as per https://en.bitcoin.it/wiki/OP_RETURN. Could you please clear up which you mean?

I mean embed the data inside the address, so that the address contains 20 bytes of text or other data.

What base58 encoder are you using, and exactly what input are you giving it?

A Bitcoin address consists of a 1-byte version, a 20-byte payload (normally the RIPEMD-160 hash of a public key or script), and a 4-byte checksum, all encoded alphanumerically in base58.  This is called Base58Check.  You can see the specific details here, and there are many ready-made implementations in various languages.  In your case, the version byte should be either 111 or 196 (decimal) which are used for testnet pubkeyhash or scripthash addresses respectively.
The reason for your error is probably that you have not computed the checksum correctly.  It is based on a double sha256 of the payload and is explained in the link above.
Note that if you use arbitrary data for the payload (and then include a proper version byte and checksum), you'll get an address which is "valid" and that people can send coins to, but those coins will then be unspendable (since it is not feasible to find a private key for which the hash of the public key equals your chosen data).  So this will effectively destroy any coins sent to that address.
A different technique is a so-called "vanity address", where you use brute force to generate lots of private keys until you find one for which the first few bytes of the address match some desired data.  (The traditional application is to try to make the base58 encoding contain your name or some other meaningful word.)  The classic tool for this is vanitygen.
This lets you embed some data into an address that can actually be used for spending.  However, you won't be able to get anywhere near 20 bytes, since getting n bits of data requires generating an average of 2^n private keys.


text:
Buying 100 kilobitcoins
This is a hypothetical question. Assuming that the price of bitcoin is $8,250 (as of current writing) and I had 25 billion dollars at my disposal, what would happen to the price of bitcoin if I successfully bought 100,000 bitcoins? Would I have enough money? If so, how much would it cost? I am curious about this because of the digital scarcity aspect of doing so.

While I agree with chytrik I would want to suggest a concrete method of approaching this.
Have a look at the combined order book https://data.bitcoinity.org/markets/books/USD you can see that you currently would move the price by 10 % if you baught roughly 10k BTC. Usually after such moves people get alerted and are willing to sell at higher prices so you could wait a little until the order book fills and repeat the process.
Assuming there are always 10k fresh floating BTC available with leads to a 10% price increase. (With regular trading many of the btc on the order books are going to free float afterwards so that assumption is pretty strong) you would have 10 = 100000/10000 price increases of 10 % each resulting at a price of 8250*1.1^10 = 21398 per btc.
You would have to pay roughly 1.4 bn usd which is 8250*10000*(1.1^1+1.1^2+....+1.1^10)
Obviously this is just a simple model build on strong assumptions. Also you would try to buy that much btc otc because you would not want to move the price but obviously you would have to convince holders to sell

The answer entirely depends on what the people who already hold Bitcoin are willing to sell it for. Generally, a massive buy would be expected to push the price up, because you would first buy up all the coins at the current spot price, and then the coins just above that price, and then just above that price, etc.  How high it goes would just depend on the ‘depth of the orderbook’(how many bitcoins people have put up for sale at whatever prices).
If there happen to be 100,000 bitcoins up for sale at the current spot price, then perhaps you could make the buy without pushing the price up at all. That seems less likely, but it is possible. At $8250 per bitcoin, that would amount to $825,000,000 USD. So we should expect it would cost you at least this amount, unless you can find someone willing to sell at less than the market rate (they might be stupid to do so, but it is possible).


text:
Can I buy bitcoin at a lower price?
Let's say that I have some money (not a lot) and I want to maximize how much bitcoin I can get. Is there a way, besides waiting and technical analysis, to get cheaper bitcoins through legal means? (In other words, I want the lowest exchange rate possible.) The reason that I think this is feasible is because bitcoin was two dollars just 7 years ago, and though I don't expect this valuation, I would like to get it in the lower thousands (preferably below the 2018 bottom price) or hundreds without having the price crash. I think that, because of the above reason, caring people would have somewhat of an incentive to sell their bitcoins to an individual buyer through something like a dark pool: the price won't crash and they could sell more of their old BTC. Note: I won't sell it right away unless I bought at the top in order to maximize returns.
Note: mining bitcoin is not currently viable, though it is expected to be even after the impending halving because of the demand created by this halving partly from speculation.

If there was a special place to buy bitcoin at a lower price, peoples or bots will rush it to buy all of them then resell it rendering this special not so special any more.
Still there is some places where you can find some interesting offer I guess, like https://localbitcoins.com/ which offer to buy bitcoin from people in real life and https://bisq.network/ which is a decentralized exchange, I suppose there must be some shady link like on the tor onion network too. Be careful of scam especially those offering to sell discout bitcoin from past hacked exchange.

The best way to buy bitcoin at lower price is to buy via Over the Counter (OTC). They require large amount of purchase at discounted price. Two other ways is using your negotiation skills at either localbitcoins.com or paxful.com exchanges.


text:
What if the mempool exceeds 300 MB?
The bitcoin mempool size is at 108 MB and still climbing according to chain.so. It is slowly approaching 300 megabytes, which is said to be the mempool limit for BTC. What happens after 300 MB?

Each node maintains a separate, individual mempool. While the default limits its size to 300 MiB, each node operator can set their own value. Note that the mempool size limit does not pertain to the serialized data or the transaction weight of the queued transactions (which is what is written to the block and what you see listed on a mempool monitors respectively), but to the actual memory usage of the deserialized transaction data on the node. This memory usage is platform dependent. In result, transactions start getting dropped when mempool monitors reach a block depth of about 80-95 blocks.
When a node's mempool limit is reached, it will drop the transactions with the lowest feerate and increase its minMempoolFeeRate. It will communicate its new minMempoolFeeRate to its peers, basically telling peers not to forward transactions below that feerate for the time being. Note that every node does this individually, so a node with a larger mempool or different architecture may drop transactions earlier or later. Nodes will keep a copy of transactions that are relevant to their own wallet. Even if all other nodes have dropped a transaction, the sender and recipients of a transaction would retain a copy. The sender can either force his node to drop the original transaction and send another conflicting transaction to update it, or their node will continue to try to broadcast the transaction so that it will eventually get relayed on the network again once the queue has receded.
After the queue decreases under the 300 MiB limit and with some added delay, a node will lower their minMempoolFeeRate and start accepting transactions again that it previously expelled.
You can currently observe this happening e.g. on Johoe's mempool monitor¹:
As you can see, the 1-2 sat/B band dropped around 7am that morning when the node's mempool exceeded its limit.

¹Note that there are two BTC views and the linked and relevant in this case is BTC (default mempool))

Firstly, there is no "the bitcoin mempool". Each node on the Bitcoin network maintains its own mempool and each node can have different settings and rules for allowing transactions into its mempool.
The default mempool maximum size is 300 MB. When the maximum is reached (regardless of what it is), a node will begin to evict lower priority (i.e. transactions paying a lower fee rate) and increase its minimum acceptable fee rate. It does this to keep the mempool size at or under the configured size and will remove transactions and raise the minimum fee rate as needed to maintain this.
Since most nodes are probably using the default of 300 MB, many transactions that pay a low transaction fee probably will not be confirmed and will need to be rebroadcast at a later date when fees are not so high. Or those transactions can be replaced with a conflicting one that has a higher fee rate.


text:
jsonrpc-lean VS. cURL?
I wanna try and develop a small miner where anyone could see the backbone of it, so that everyone would know how everything works. Now I wanna ask whether what to use should I use for communicating with the pool, jsonrpc-lean or libcurl, I am not only trying to build just for bitcoin maybe some other altcoin like monero too.
but One big question. Is mining in bitcoin and monero the same? except for the fact that of course you should claculate (decrypt) them differently, what I mean was the way they work with the pool. (request infos from the pool, calculate it and submit it)

It depends on the mining pool and the software they are using. There is no one specific way for mining pools for a specific coins to relay information to their miners. For Bitcoin, most use stratum or getblocktemplate. For stratum, I don't think either of the libraries will work as stratum is not served over HTTP.

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
What's the sense of how lightning network is performing?
I realize that we are still very early in the deployment of Lightning network, but is there a sense of how things have been performing thus far? Is this the solution which BTC has been waiting for? I'm hoping to get a sense from anyone who is well knowledgeable about the project's development.

I'm afraid this question is quite broad and undefined, definitions such as "success" differ greatly from person to person, and it's not really clear what you're asking. Lightning is doing really well so far, but you'll need to ask a more specific question about it

Sorry for the broad question. I'm more interested in eliciting feedback from people knowledgable about the project to provide a opinion about if it is achieving the objectives it set out to accomplish. A specific question I would have is does the fact that there will be very few connections on the side chain initially slow/prevent the processing down to the point that the project is in danger of not catching on?

Quick note that lightning is very different from a sidechain

Might be a better question for [lightning-dev].

Yes, as of writing, there is an overwhelmingly positive sense of how things are performing thus far - more than 800 nodes with 1600 channels are already on the main net, and micro transactions exchanged more than ~40.000 USD.
It is unclear what you mean by "the solution which BTC has been waiting for". Who is BTC? The community, using bitcoins?
The solution can be SEGWIT, Lightning, SCHNORR sigs, Smart contracts ... ??
Maybe you talk about blocksize, or the fee peak problem in December, which has been discussed in several channels, with many politics involved. This peak has meanwhile reduced to normal values, and doesn't exist anymore (see here). There is also a common sense, that with future lightning adoption this will not re-occur.
I want to stress the point, that lightning is on mainnet, but at a very, very early stage. It is not recommended to be used by newbies, it is more for experts to see behaviour in real world (after extensive tests in test environments).

I even read some comments elsewhere that I took to mean that the actual operation of lightning is not even finalised yet.

all_licenses: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/3.0/


text:
bip-schnorr and HD Key Derivation
Is it safe to use HD Key Derivation with bip-schnorr? The bip mentions that you should not throw away the first byte of a generated key.

It is important to not mix up the 32-byte bip-schnorr public key format and other existing public key formats (e.g. encodings used in Bitcoin's ECDSA). Concretely, a verifier should only accept 32-byte public keys and not, for example, convert a 33-byte public key by throwing away the first byte.

Later in the bip, it mentions that you should do this when doing HD key derivation.
Link: https://github.com/sipa/bips/blob/bip-schnorr/bip-schnorr.mediawiki#public-key-generation

Alternatively, the public key can be created according to BIP32 which describes the derivation of 33-byte compressed public keys. In order to translate such public keys into bip-schnorr compatible keys, the first byte must be dropped.

It sounds like its safe for the prover to drop the extra byte but not the verifier. Is this correct?

Is it safe to use HD Key Derivation with bip-schnorr?

Yes, it is designed to be.

The bip mentions that you should not throw away the first byte of a generated key.

Perhaps this is worded confusingly.
It means that you can't use a variant of the signature scheme, which uses full public keys, but then throws away one byte of the public key at verification time. Doing so would just result in 50% of the signatures being rejected (because the public key wouldn't match what was used at signing time).

It sounds like its safe for the prover to drop the extra byte but not the verifier.

This has nothing to do with safety, but about correctness.


text:
Miners and Nodes: what are their role in protocol updates?
What are the different roles of miners and nodes for protocol updates (governance)? Which group is more important?

Both mining nodes and non-mining nodes are important for any changes to the Bitcoin network protocols or to the consensus rules.
The Bitcoin network protocol itself doen't distinguish between miners and non-miners. Initially all nodes were mining nodes.
There are mechanisms by which miners can signal readiness for a proposed change by setting a bit in the header of blocks they create. Obviously this mechanism isn't available to non-mining nodes since they don't create blocks.
However, miners cannot force non-mining nodes to update or change their software. There is no mechanism by which they unilaterally impose changes, other than market sentiment etc. So, in most cases, it probably isn't appropriate or useful to place either group on some scale of relative importance.
So far as I know, changes to the Bitcoin network protocols are mostly (exclusively?) extensions that add new message types etc without removing old ones that are used by older software. This makes it easy for old software to continue to interoperate with new software and makes it relatively painless to update software to accomodate the new features.

I dont know about miners but here is how you can become a node on [protocol governance][1] - https://q.org/blog/calculating-root-node-rewards


text:
What happens to old transactions in case of a fork?
I'm confused about forking. What happens to the 'old' version of a blockchain and related transactions/data in case of a fork. Can they still be deleted or does the new branch still depend on them to ensure continuity?

What type of fork are you asking about?  There are short-lived forks where some blocks are orphaned (made stale) either accidentally or on purpose; there are soft forks that change the consensus rules in a backwards compatible way; and there are hard forks that change the consensus rules in a backwards-incompatible way.

I'm curious about this in relation to both soft and hard forks. Thanks!

What happens to the 'old' version of a blockchain and related transactions/data in case of a fork. Can they still be deleted

In the case of a soft fork, historic data must be kept.  In the case of a hard fork, it's not strictly necessary to keep historic data but it is almost always retained.
Going in to a bit more detail: a soft fork changes the rules everyone follows in a backwards-compatible way by only making the rules more strict.  For example, miners have access to a field called the "coinbase" into which they used to be able to put any arbitrary series of 2 to 100 bytes; later a rule was added that specified in the BIP34 soft fork that the first few bytes of that field had to be the current block's height (distance from the first block).  This is more strict, so everyone who follows the new rule also automatically follows the old rules.  This is backwards compatible because anyone who followed the old rules and isn't already violating the new rules can continue to use their software as normal.
However, for that backwards compatibility to hold true, the data available in the block chain has to not only remain available but stay in basically the same format.  You can sometimes do tricks with that, as segwit did by moving signatures to a new field in transactions, but there's a limit to the scope of changes you can reasonably make.
For hard forks, there rules are changed in a backwards-incompatible way so everyone needs to upgrade anyway.  This gives you a blank slate upon which to make any change to the system you want.  Regarding old block chain history, what you can do is commit to the current state of the system and throw out all history used to arrive at that state.
For example, imagine Alice mines a bitcoin and then pays that bitcoin to Bob.  The block chain will include both the mining transaction and the payment transaction, but if everyone is upgrading anyway, it's simple to just say "Bob starts with 1 bitcoin" and throw away Alice's mining transaction.
If you were to throw away historic data and keep just the current state after a Bitcoin hard fork, you could reduce the current block chain size by about 98%, down to just a few gigabytes.
However, I'm not aware of any hard fork of Bitcoin or an altcoin that ever threw out the historic data and simply committed to the current state.  I don't know why that's the case.

If you discard the earlier transactoin and start with new state, wouldnt that effect the 1:1 coin distribution scheme that comes with each hard fork.

"What happens to old transactions in case of a fork?" nothing. the "old" transactions will still be available. otherwise it is not a fork. both branches of the fork will have the same history until the moment of the fork.
"Can they still be deleted or does the new branch still depend on them to ensure continuity?" today's state is that transactions will not be deleted in general. the old transactions are required to ensure integrity because you need them to track the history of your bitcoins and to re-validate the hash-values of all blocks.


text:
Ethereum Code bots...Scam or not?
So new I cant even afford to trade crypto's yet, but looking and learning. I came across some Ethereum Code bot, promising 13k a day etc etc...one of those "sounds to good to be true" things really.
Research is varied in opinions of being a scam or not. The broker is called FTO Capital, unregistered etc...why would a bot need a broker?
Anyone able to say they have used any of these kinds of crypto bots and done ok? As a father of a daughter with a disability I need to play it safe...she needs equipment I simply cant afford at this point in time.
Cheers in advance,
Buck

"promising 13k a day etc etc...one of those "sounds to good to be true" things "... I think you have your answer already. Any legitimate broker I have ever seen would not promise such an astronomical return, I think it is very safe to say you have encountered a scam.

My thoughts too, hoping someone has tried it/them lol. TY chytrik.

promising 13k a day

It is almost certainly a scam. Stay well away from this.

I need to play it safe ... I simply cant afford

Don't invest in volatile high-risk products such as crypto-currencies.

Ehthereum Code is definitely get rich quick crypto scheme. They are now using fake news to promote this system. There is no technology just random variables that pop up. A quick search for Ethereum Code Scam Gal Gadot reveals how they operate and bait victims.


text:
How can the genesis block contain arbitrary data on it if the script is invalid?
The coinbase transaction from the genesis block contains this script: 04FFFF001D0104455468652054696D65732030332F4A616E2F32303039204368616E63656C6C6F72206F6E206272696E6B206F66207365636F6E64206261696C6F757420666F722062616E6B73
It pushes the text "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks" into the stack.
I heard that scriptsig is invalid unless there is only one entry in the stack and that entry is '1'. So this script is invalid.
Is this why people say that the coins generated in the genesis block are unspendable?

For four reasons (each of which individually would be enough):

The genesis block is valid by definition. It is never validated. It is just by definition the first block of the chain, and every other block has to build on top of it. Put otherwise: the rule for validation of a block at height 0 is "it must match the hash of the genesis block", and not any of the other normal validity rules.

The script you're referring to is the input of a coinbase transaction. Even if the genesis block weren't valid by definition, or if this were to occur in another block, coinbase input scripts are never actually executed. They're only used for allowing miners to insert extra nonce information into blocks, and (since 2012), the BIP34 height-in-coinbase rule.

The rule you're referring to (the resulting stack after execution must contain only a single element) is only a policy rule (i.e. transactions violating it won't be relayed by modern Bitcoin Core nodes), but it's not a consensus rule that every node and miner must obey. This rule was at some point proposed as a consensus rule (in BIP62, but it was never adopted as such and then withdrawn). In BIP342 (taproot script execution), this rule is actually a consensus rule, but the case you're referring to is not such a spend.

The policy rule you're referring to only applies to the final stack after execution of the input (unlocking, scriptSig) and output (locking, scriptPubKey) script. Script execution proceeds by first execution the input script, and then executing the output script of the UTXO being spent on the same initial stack. The rule is only about the final state after both executions, and not after just the input script, so this policy rule doesn't apply. In the case of a coinbase input, there is no output script even, so there is no way it could apply even.

The reason why the genesis coinbase transaction output is unspendable is unrelated to all the above, as it's about its output, not its input. The reason for that is due to the fact the initial software never added the genesis block to its internal database (intentionally or unintentionally), so its output wouldn't be retrievable for spending. The code design in Bitcoin Core is completely different these days, but the behavior of not having the genesis block output spendable was maintained, as the alternative would be hard fork. Instead, in today's software it is simply a hardcoded exception: that particular output cannot be spent.

Regarding your third reason, I think BIP141 essentially requires CLEANSTACK for P2WSH outputs, doesn't it: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#Witness_program? H/T Crypt-iQ: https://github.com/bitcoinops/bitcoinops.github.io/issues/726

You're right, it's a consensus rule for P2WSH as well.


text:
Bitcoin testnet addresses
Why bitcoin addresses in testnet are not the same as in mainnet? For example ethereum address in mainnet can be used in testnet's (ropsten, rinkeby).

Because using the same addresses for both is an enormous footgun. People could accidentally send funds on the wrong chain.

sounds counterintuitive. had the same address been used on both "chains", it would be a simple 1:1


text:
Trying to validade a bitcoin block
So I'm trying to validade a bitcoin block just for curiosity, let's take for example bitcoin block #1 (https://bitpay.com/insight/#/BTC/mainnet/block/00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048)
So the header will be something like:

version = 0x00000001
hash of previous block = 0x0000000000000000000000000000000000000000000000000000000000000000
hash of merkle root = 0x0e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098
time stamp = 0x49676521 (9th jan 2009, 12:54:25 GMT-2)
Target = 0x1d00ffff
Nonce = 0x9962E301 (2573394689 in hex)

So the final header is: "0x0000000100000000000000000000000000000000000000000000000000000000000000000e3e2357e806b6cdb1f70b54c3a3a17b6714ee1f0e68bebb44a74b1efd512098496765211d00ffff9962E301", but when I use this header here: "https://emn178.github.io/online-tools/sha256.html"
I get the first answer "0x8b35dccfcd6775827147594afa923bcc2b10645ef24aa3d22b22c2b0bed17ea2" and I use the first answer to get the double sha-256 but I'm getting "4d154a2d19d08ccc9328bcce8d965bdd3285035a40936fb43fd8da4d9dc5392e" instead of the "00000000839a8e6886ab5951d76f411475428afc90947ee320161bbf18eb6048" that I was expecting. Does anyone have any idea of what I'm doing wrong? Maybe the site is wrong?

I haven't followed the details of your calculation but I noticed:

hash of previous block = 0x0000000000000000000000000000000000000000000000000000000000000000

That seems wrong for block 1 because it should have the hash of block 0 (known as the Genesis block).
In my copy of the blockchain, block 1 has a non-zero value for hash of previous block.


text:
how do I mark coins spent in invalid blocks as unspent?
I was just testing bitcoin (v17) in regtest mode with the local, built-in wallet. If I send money to an address (I don't own), generate 1, and then invalidate that block, the local wallet does not mark the coin spent in the invalid block as unspent. It keeps it in the spent state. Rolling back further, generating more blocks on a different chain, and rescaning the transactions doesn't seem to mark that money as unspent again. How do I respend my coin when it was spent in an invalid chain? From the local wallet CLI, is there a way to mark things as unspent?

I suspect this is an issue with Bitcoin Core's wallet itself and not something that you are doing wrong.


text:
what's the purpose of the chain_id in merge mining?
I'm considering adding merge mining support to coin x. Its parent chain will be coin b. In looking at the spec (https://en.bitcoin.it/wiki/Merged_mining_specification) and Dogecoin/Namecoin sources, I see that there is support for multiple merge-mined coins in a single coinbase payload. That's fine. I also see that I'm given a Merkle tree so that I can verify that my coin x's header's hash was in b's block. That's fine. Given that, what I don't understand is why I would care about x's slot in the Merkle tree in the specific case where multiple coins are being merge-mined. Why would I need to specify a chain_id? Why would I care if my data came back in a different slot than what I requested? Why even request a specific slot? In the Dogecoin codebase it verifies via getExpectedIndex (see https://github.com/dogecoin/dogecoin/blob/0b46a40ed125d7bf4b5a485b91350bc8bdc48fc8/src/auxpow.cpp#L153 ). How does that add to the security of this? Why not let the block creator put the merge-mined coins into a Merkle tree however it sees fit?

I discovered the answer in a blog:

it is necessary to make sure that a miner cannot mine on different
branches of the same child blockchain, as this conflicts with the
rules of the underlying Nakamoto consensus mechanism and would make
double spending attacks possible. Hence, each cryptocurrency must
specify a unique ID, which can be used to derive the leaf of the
Merkle tree where the respective block hash must be located.

Source: https://alexeizamyatin.medium.com/a-technical-deep-dive-into-merged-mining-5b67706e1a19


text:
structure of communicating with bitcoin DNSs to get list of nodes
I want to communicate with bitcoin DNSs to get list of bitcoin nodes.
for now I want some example and structure of messages between I and bitcoin DNS.
I found two DNS names:
dnsseed.bluematt.me
dnsseed.bitcoin.bit

and want communicate with them.
please help me

"Bitcoin DNS" is a bit of a misnomer.
It appears that hostnames such as dnsseed.bluematt.me are not actual DNS servers - you cannot communicate with them using DNS protocols. However they are valid domain names in the normal public Internet DNS system and have multiple "A" records associated with them. You can therefore query the DNS seed hostnames in the normal way (i.e. send DNS queries to your local DNS servers) to get a list of IP addresses that are presumably Bitcoin full-nodes.
You can then, I guess, communicate with any of those IP-addresses using the appropriate Bitcoin peer-to-peer protocols.
Note that some of the returned addresses are IPv6 and some IPv4.
C:\> nslookup dnsseed.bluematt.me
Server:  xxxxxxxxxxxx
Address:  192.168.1.nnn

Non-authoritative answer:
Name:    dnsseed.bluematt.me
Addresses:  2607:fea8:80a0:a1f:b1dc:86a4:62a1:ff7d
          2001:0:9d38:6ab8:1c01:270:bff9:f75a
          2a01:4f8:c0:1328::2
          2a01:4f8:171:d4a::2
          2002:bc7c:110::bc7c:110
          2001:41d0:d:221d::
          2a02:a441:7147:1:70dc:dbc7:fcfe:c605
          240d:1a:124:5300:2cb0:2c4d:b748:3853
          2001:13d8:1c01:2000:2470::1
          2a03:4000:6:416c::43
          2600:1f14:6ae:d900:6550:3fc5:e074:a72c
          2a02:8106:22e:9d50::227
          123.5.48.235
          80.61.148.155
          159.65.33.252
          138.68.93.0
          13.78.125.30
          138.68.174.249
          171.124.53.172
          159.89.25.106
          148.251.83.196
          24.99.150.25
          192.3.11.24
          111.206.188.112
          88.198.39.205
          87.122.81.82
          96.27.129.94
          218.75.140.43
          218.75.158.185
          46.167.117.12
          195.43.141.28
          13.209.0.41
          95.216.26.158

This is confirmed by Bitcoin.org's developer guide which says

When started for the first time, programs don’t know the IP addresses of any active full nodes. In order to discover some IP addresses, they query one or more DNS names (called DNS seeds) hardcoded into Bitcoin Core and BitcoinJ. The response to the lookup should include one or more DNS A records with the IP addresses of full nodes that may accept new incoming connections.

It goes on to describe the protocols that can be used to communicate with these nodes.


text:
Spread crypto-bot
What do you think is there possibility to write crypto bots using spread beetwen asks and bits? For example: buy currency X for 0.025BTC and then sell X for 0.026 BTC in the same exchanges. As a result we have 4% profit - 2*0.25% (exchanges fee) = 3.5%

What if no one wants to buy at 0.026 BTC?

Many exchanges offer an API, and this can be used to write such a bot. As this is not bitcoin related (it concerns any currency), I vote to close this question as being off-topic.

You may rest assured that this is widely happening already, not just with Bitcoin and crypto-currencies, but with other currency markets and the stock exchange.


text:
Graceful way to stop bitcoind in Docker container?
When I issue docker stop <id>, the process doesn't exit cleanly and bitcoind has to roll-forward blocks on the next startup.
018-03-04 04:15:25 Rolling forward 0000000000000000001728efc81b210835048a7321ba3ec93197f698fac080ab (511863)
2018-03-04 04:15:26 Rolling forward 0000000000000000002be2e2792facd65e2358f874bc48f6410b80ecc8a6e756 (511864)
2018-03-04 04:15:26 Rolling forward 0000000000000000004740c4832b47a1c852db87cf4b9aea559db8712d2971a5 (511865)

This seems to be an issue with the dbcache not being written to disk prior to exit. I'm not sure if it's issuing a SIGTERM and then SIGKILL.
What is the best way to stop bitcoind to prevent any database related issues?

I found this to be very useful: https://www.ctl.io/developers/blog/post/gracefully-stopping-docker-containers/

Welcome to Bitcoin.SE! You can help the site by marking answers as accepted if they are correct and address the question so that the question does not remain as "unanswered".

Best way to stop bitcoind is either by calling the JSONRPC interface with the stop command or by issuing a SIGTERM or SIGHUP.
But it may take a couple of seconds to shut down Bitcoin Core since it eventually has to write larger amount of data (time depends on your dbcache, disk-speed, mempool size, etc.).
So the environment layer (docker in your case) must be capable to take this into account (a slow process shutdown).

Thanks! I think docker stop actually issues a SIGTERM, but it likely does a SIGKILL after 10 seconds, which could be the crux of the problem. Would love to vote you up, but i'm at 14 rep =\

@relik yes it is exactly as you point out. Docker is sending SIGKILL after 10 seconds.
In docker compose you can set stop_grace_period:10m and this bumps it up to waiting 10 minutes before issuing SIGKILL.
Also need to be careful if you are launching bitcoind from a bash script (as I was doing) you need to prepend it with exec command so that it receives the SIGTERM from docker.


text:
Bitcoin Cash Sent to Vaultoro
I accidentally sent Bitcoin Cash from my Coinbase wallet to my wallet at Vaultoro. The problem is it didn't show up because Vaultoro only takes Bitcoin.
Can anyone give me a step by step on how to retrieve this? I tried to get Vaultoro to help but they didn't seem to care.
Please help.

I'm voting to close this as off-topic, as you'll need to contact Vaultoro in order to have your funds returned, making this a customer service query.

The only way to recover your coins is to get Vaultoro to do it as they own the private key. Some other services charge a recovery fee for this, others don't even offer a way to recover such funds.


text:
Methods to find BTC addresses collisions with less complexity approaches/attemps
I have one question. I'm trying to lower complexity when breaking private keys for BTC.
If we have that an address is a hash160 from priv key, then we can assume that we have 2^96 per each address.
If we have, let's say, 10M of active wallets (~2^23.25). Then, 160-23.25=136.75 we can assume that wallets are uniformly distributed on 2^136.75 gaps.
If we start to find those wallets from those assumptions, can it work well?
I mean, supposedly this distribution should follow the Gaussian function, or am I wrong?

Which methods else do I have to lower complexity?
Why does this guy say 2^80? https://bitcoin.stackexchange.com/a/83819/131965 can somebody explain?

Why does this guy say 2^80? can somebody explain?

That is explained in the comments to the question you linked.
To paraphrase
As numbers become large the number resulting from the birthday paradox approaches the square root. With Bitcoin these numbers are so large that there's nothing to be gained by trying to be more precise.
Original comments reproduced here for convenience

the actual formula for the birthday paradox is complicated, but as the numbers get bigger, taking the square root becomes an increasingly better approximation to it. When talking about cryptography, the numbers are so huge that the difference isn't worth worrying about. –
Mark Jan 20 '19 at 1:17
Technically, the square root of the number of possibilities gives you a 39.3% probability for collisions (1-exp(-1/2)), that's about where you see the probability go from negligable to negligably not. 1/2 sqrt(n) gives you 11.75%. 2 sqrt(n) gives you 86.5%. In cryptography the exact factor is usually ignored, and we just say that you need approximately sqrt(n) elements to see a probable collision. –
Pieter Wuille Jan 20 '19 at 1:17

we can assume that wallets are uniformly distributed on 2^136.75 gaps.

I'm no statistician but, to me, a uniform distribution  does not imply fixed length gaps. I suspect the ratio can only inform you of the probability that a search of a smaller space will yield an expected number of results.

Related:

https://en.wikipedia.org/wiki/Birthday_attack


text:
Removing stale blocks using prune=1TB
I'm running a block parser that reads blocks/*.dat and I've noticed it dumps the stale blocks as well as the main chain blocks. My project only needs the main chain blocks, and I noticed that Core's pruned option removes stale blocks as part of its storage reduction.
So I was wondering if I restarted my node with huge a prune number (i.e. prune = 1000000), would Core remove the stale blocks while keeping all the main chain blocks. If so perhaps I could restart Core once again, with prune removed (my block parser needs pruned removed), and have what I need - a regular node with all the stale blocks removed from blocks/*.dat.
Basically I'm being lazy and don't want to write the exceptions for stale blocks into the block parser.
(Core V0.20.0 running on Mac)

Great question, Steve
Unfortunately it won't work. Re-starting with prune=1TB will indeed remove the stale blocks from the blocks/*.dat directory, but then re-starting again with the prune option removed will cause an error. Core will detect the switch from prune to non-pruned and require you to resync the node from scratch.
Next time, just write the exception for the block parser.


text:
Need help with understanding this script file
Here is an image of txt file. I had asked someone to help get some bitcoin out and they sent me this code with a price tag of 12$ But I have no idea what its used for as they have not responded. Any help is grateful thanks

They're trolling you. This is just a part of Bitcoin Core's source code.

they sent me this code with a price tag of 12$

You, or anyone, can download that code for free from https://github.com/bitcoin/bitcoin
There is no fee or price, it is free of charge, $0

I have no idea what its used for

As Pieter said, it is the source-code for a computer program, a Bitcoin wallet called "bitcoin core". You use the source code with a program called a C-compiler to create a program that you can then use. But you can just download the already compiled program from the appropriate website. The source code and the compiled bitcoin-core program isn't really suitable for anyone new to Bitcoin. The compiled program is a "wallet" that provides a way of controlling an amount of Bitcoin that you have obtained by  buying from an exchange or by selling something for bitcoin.
It doesn't generate money.

I had asked someone to help get some bitcoin out

If you already have some Bitcoin, you probably already have the means to get it out (convert it into another currency, use it to buy something). You would have a wallet or an account with an exchange or something similar.
If this doesn't make much sense to you, it is quite possible you have been tricked and don't really have any Bitcoin to get out.

Thank you so much for the feedback everyone. Helps me understand. They just sent another email stating If I pay 12$ the other part of this code can be used to get any kind of  wallet info and withdraw it. My intention was never that I said. I have the link for YouTube if anyone wants to see the scammer . My other question , is this guy using this code and a c-compiler as you say to control or withdraw blockchain coin out?
Thanks everyone

@Lisa: This guy is using this source code simply to confuse his victims. He doesn't need this source code for anything, neither do you.


text:
How to Validate Signature with SigScript length 8b?
I created a raw Transaction:
010000000146460fc2adc04c8eefd1e14bbaa2ad683481bb5fdf95d0d4bf847cc78cbc9ff1000000001976a9145e4f04c3ee1941d665eb1312280ca3a0bbbfd3ba88acffffffff02801a0600000000001976a914befa5e3cf184ee71974f9b3a7580bed1816b0d4588ac801a0600000000001976a9145e4f04c3ee1941d665eb1312280ca3a0bbbfd3ba88ac0000000001000000
After Generating Digital Signature:
3045022100cd89b747b9507cb525c5d2d48aa7ebc8941c257621219471dab1e23c6280f99502204823508b23dc61e2868c120f1b90da864902266a3d2ae087720d26e5313d788a
Final SigScript Value is:
8b493045022100a8b021691b6cf9a61f7ad8e4ffa9596e668e14e4e14e29ef17f9f49276722e4e02201ccb70bc0748ff16841cd68a781dc3511fffea76febcb735fe78a4a270023f830141049ea82ac663a76fb872d4a49674762c3f9e60e25d55f7636d76b03efef3d69e838ab749455d3951aa015ccac729ecd9d656e596686af6204534821699e779534b
So, Final Broadcasting Transaction is:
010000000146460fc2adc04c8eefd1e14bbaa2ad683481bb5fdf95d0d4bf847cc78cbc9ff1000000008b493045022100a8b021691b6cf9a61f7ad8e4ffa9596e668e14e4e14e29ef17f9f49276722e4e02201ccb70bc0748ff16841cd68a781dc3511fffea76febcb735fe78a4a270023f830141049ea82ac663a76fb872d4a49674762c3f9e60e25d55f7636d76b03efef3d69e838ab749455d3951aa015ccac729ecd9d656e596686af6204534821699e779534bffffffff02801a0600000000001976a914befa5e3cf184ee71974f9b3a7580bed1816b0d4588ac801a0600000000001976a9145e4f04c3ee1941d665eb1312280ca3a0bbbfd3ba88ac00000000
This Gives error in Validating Signature.
But if my SigScript(i.e. generating Signature of length 8a, instead of length  8b) is
8a47304402205054d068fdcb34e409fa6978ea7ae9612286356f1d273e8fc0b1012e0aa606b102201e0b7dee3cab6448f77186585d9e765450dc424386e4c237b153a08ebe9d56080141049ea82ac663a76fb872d4a49674762c3f9e60e25d55f7636d76b03efef3d69e838ab749455d3951aa015ccac729ecd9d656e596686af6204534821699e779534b
Broadcasting Transaction is
010000000146460fc2adc04c8eefd1e14bbaa2ad683481bb5fdf95d0d4bf847cc78cbc9ff1000000008a47304402205054d068fdcb34e409fa6978ea7ae9612286356f1d273e8fc0b1012e0aa606b102201e0b7dee3cab6448f77186585d9e765450dc424386e4c237b153a08ebe9d56080141049ea82ac663a76fb872d4a49674762c3f9e60e25d55f7636d76b03efef3d69e838ab749455d3951aa015ccac729ecd9d656e596686af6204534821699e779534bffffffff02801a0600000000001976a914befa5e3cf184ee71974f9b3a7580bed1816b0d4588ac801a0600000000001976a9145e4f04c3ee1941d665eb1312280ca3a0bbbfd3ba88ac00000000
The Transaction is successfully broadcasted (TXid):
0377531e44690a2a114f6b6874368de488911cb6ad452292add3d252344e24c5

Could somebody please explain how to broadcast transaction with length SigScript lenght 8b?
Thank you

If you check the scriptSig in the first case, you are pushing 0x49 bytes after 0x8b which is consuming the byte the contains the length of the public key (byte 0x41). Use 0x48 after 0x8b and it will work.

Thank you Ugam Kamat! It worked Perfectly.


text:
Are Satoshi's satoshis less secure than they should be?
So, Satoshi mined a bunch of BTC early on (but not in a "pre-mine" way), and has not moved them ever since.
Doesn't that mean that his coins thus uses the very earliest "format", which, apparently, is less secure? And doesn't this mean that there is a non-zero risk that somebody might crack his wallet(s) and obtain those juicy early Bitcoins, stored in the earliest and least secure manner?

Nobody knows whether he mined any more than the block he used coins from to send to Hal Finney. The wild speculations about that are most likely very overblown.

Most early transactions including rewards for early blocks go to P2PK outputs and we don't know who owns them, Satoshi or others. In these output scripts (unlike the common ones today) we use the public key itself instead of its hash. Some people refer to this as being "less secure" which is both right and wrong.
When you spend from an address you are also revealing your public key. There are a lot of reused addresses in bitcoin. The whole security of asymmetric cryptography is that it is not only safe to reveal the public key but also by design you should do it.
Technically having the hash of the public key (unused P2PKH, P2WPKH, etc) instead of public key itself (reused address or P2PK) adds another layer of "safety", but it is incorrect to say P2PK outputs are less secure because security in this case doesn't have a degree. Bitcoin as a whole is either secure or it isn't. If some day a way is found to solve ECDLP within reasonable time (in simple terms to find private key from public key) Bitcoin becomes obsolete not just those outputs.


text:
Bitcoin HD Wallet using C#
What packages do I need to use for creating Bitcoin HD Wallet in C# using BIP44?
How can I connect to a remote Bitcoin Node to read all the deposit transactions received by various child addresses in the HD Wallet?
Which Node Client can I use for this?

Thank you @Prayank I am using NBitcoin library to create the addresses with BIP44 in a HD Wallet, using path m/44'/0'/0'/0/. I couldn't be see any of the child addresses when I add the seed of the wallet to Bitcoin Core. Can you please point me to any references that will show the steps to creating a HD Wallet with child addresses using NBitcoin and the process for adding this wallet to Bitcoin core?

I advise you just to rely on https://github.com/dgarage/NBXplorer/
This is an API more flexible and more stable than Bitcoin Core to manage HD wallets. There is a C# client, and it integrate nicely with NBitcoin.
You can create PSBTs from it, ready to sign with NBitcoin. (Disclaimer: I am the main maintainer for both NBitcoin and NBXplorer)

In regard to the follow-up questions:

NBXplorer Documentation
NBitcoin Documentation
A small multisig wallet example

NBXplorer.Client is the name of the nuget package to call the documented API.


text:
CLI Tool or API for btc address generation given a xpub
I'd like to script a short tool on the commandline. Therefore I need all used addresses of my wallets derived from a given xpubs.
Don't like to implement it by myself. Is there an already implemented API oder CLI-Tool which derives the addresses and comunicates with bitcoind, electrs ... and checks whether the addresses were used?

Does this answer your question? Derive next HD segwit address from xpub/ypub


text:
What type of wallet support French seed-phrases?
been struggling to find wallet to restore it as it seems most wallets support only English.

BIP39 (the specification for how seeds can be encoded into phrases) specified a number of word lists beside English but it has been widely considered a bad idea to use them. Words can be ambiguous between languages, and many use encodings which are not guaranteed to be consistent or supported on every system. Little software ever supported any language other than English, and as a result none is likely to add it in the future to maintain compatibility.

I am Blockchain guy and And retrieve lost wallet.
But you can do this yourself you can use https://iancoleman.io/bip39/ Select French and paste 12/24 words. It will extract all address with Private Key


text:
Bitcoin BTC wallet receive addresses
I want to create 100 to 500 to 1000 BTC receive addresses. It should not expire. Is it possible ? Is it possible in Bitcoin core ?

It is possible with json-rpc interface and one-time script.

Enable json-rpc port by changing bitcoin.conf used by your Bitcoin Core (usually ~/.bitcoin/bitcoin.conf).

https://ma.ttias.be/enable-the-rpc-json-api-with-password-authentication-in-bitcoin-core/

Start bitcoind/bitcoin core.

Unlock your wallet using RPC walletpassphrase with timeout parameter like 600 or greater.

Obtain new address using RPC getnewaddress. This function creates new receive address under the same account(~wallet).

Write the returned string into the TXT file with appending to the existing list of addresses.

This is to be done via simple python script and for i in range(0, 500): loop.
Use library such as python-bitcoinrpc to easily connect to your json-rpc.
Funds send to any of these addresses you've generated and saved to a TXT file joined to the available wallet balance and will be available to spend in a transaction from the interface.


text:
Bitcoin transactions towards and from a Taproot
I am trying to solve a problem that was given to me as study material for a coding test. The problem requests the following:

Create two Bitcoin transactions in testnet, one spending towards a
Taproot output and another spending from that same Taproot output.
Each of the two transaction should also include an OP_RETURN output
with the string "BFX" in it. Provide the txid of both transactions.

I am new to all this, so despite being a simple problem to lots of developers, I have been working on it for almost 4 hours, and I still have little clue about what I should do.
Any advice on how to perform what the problem requests will be appreciated.

It would be better if you asked specific questions on problem(s) you stumbled upon or thing(s) you didn't understand after 4 hours of work. There are already many StackExchange posts on Taproot transactions if you search for the label taproot or OP_RETURN if you search for the label op-return. If you are entirely new to this then there is quite a steep learning curve.

Happy to send you some testnet Bitcoin if you need it and you provide a testnet address


text:
Hacked/Stolen Bitcoin privete key-List
Is there maybe in the existent a list of all hacked/stolen Bitcoin private key?
Thx!

There is https://allprivatekeys.com/, which also features leaked private keys.

a list of all hacked/stolen Bitcoin private key

(my emphasis)
I am of the view that, in the real world, such a list cannot exist because some victims do not report theft to anyone else. Some victims probably don't know their private key.
Perhaps I am missing something or suffering a lack of imagination but I can't think of any reason why anyone would collect even a partial list of stolen private keys. It's like collecting photos of all torn empty discarded leather-wallets or purses that were ever stolen by pickpockets worldwide in the last two decades. Who would go to the trouble? What would they gain by doing it?


text:
Uncompressed to compressed bitcoin public key with public address?
Is there a script in which i could convert multiple bitcoin uncompressed public keys to compressed and also get public address as well?
I search the web with no luck.
Thanks in advance!


text:
Watch-only bitcoin address, Transaction file?
I m playing around with Electrum wallet, with watch only address. When i open transaction file i see text like(this is just part of it): BegDAAAAAAAAGXapFCDUWmp2JTVwDOngshbjGZQzXbiliKzoAwAAAAAAABl2qRQ+5BM9mR9S/faiXJg04HRax0JIpIis6AMAAAAAAAAZdqkU4mZG24SwYC8ys0taYso8rh+Rt3mIrOgDAAAAAAAAGXapFO9Yr7aXsJRCPOkHIfuxmjWe98UOiKwj4gQAAAAAABl2qRQqOXKrS+InhBUFWUeH0xz2br0eIoisA+AIAAABAP1PAQEAAAABVUNlt7XSzkn0QqfYv1BxvZqqMi/tiRWnHdAHoqR1rRkBAAAA2gBHMEQCIFx9Axsj2VaCBfJWg9POcLNDg5zygAVV7at8ykTYDlqbAiAcN/hNHS8jxjE7yJfuyQV/
What that means and how to read this if possible?
Thanks in advance!

The range of characters, particularly the + and / as the only punctiation, mean that this is base64 encoded. So the first step is to decode it from Base64. You can then view it as Hexadecimal which is generally much more useful for extracting data items from raw binary data records.
I don't see anywhere that Electrum document the format of a transaction file. You may have to work that out by looking for specific transaction data or for item values that you know are commonly found in bitcoin transactions as transmitted over the network.
The general format for a transaction as transmitted on the network are documented

Field
Description
Size

Version no
currently 1
4 bytes

Flag
If present, always 0001, and indicates the presence of witness data
optional 2 byte array

In-counter
positive integer VI = VarInt
1 - 9 bytes

list of inputs
the first input of the first transaction is also called "coinbase" (its content was ignored in earlier versions)
-many inputs

Out-counter
positive integer VI = VarInt
1 - 9 bytes

list of outputs
the outputs of the first transaction spend the mined bitcoins for the block
-many outputs

Witnesses
A list of witnesses, 1 for each input, omitted if flag above is missing
variable, see Segregated_Witness

lock_time
if non-zero and sequence numbers are < 0xFFFFFFFF: block height or timestamp when transaction is final
4 bytes

and so on.
The network order is mostly big endian so a Version no with value 1 might show in hexadecimal as 01000000
There are a handful of different transaction output types. So you might have to test for several types to get the full details.
There's no guarantee that Electrum stores its data in the network format though - it might be completely different.


text:
Why Bitcoin uses UTXO model?
I know what it means. But I can't understand why Bitcoin decided to make such a model, where you have no balance, only unspent transaction outputs. And isn't the same thing as having the balance? I assume if you didn't spend coins, you have them in balance. What advantage does it have over a usual (non-UTXO) model? With comparison with other cryptocurrencies which has no UTXO, if possible, please.

Imagine we have a balance based blockchain, a transaction is produced which sends 1 BTC from Alice to Bob, this transaction is mined into a block and confirmed. Another block arrives which contains the same transaction again. This obviously isn't correct, however it's very difficult for us to create a system where this is not possible.
We either must:

Store a list of all transactions that have happened, refer to it in real time, and exclude any which have already been acted on (the balance deduced, and increased in the ledger).
Have a nonce for each address which increases every time it makes a transaction, and not allow a transaction with a lower nonce than we currently believe to be the case.

The latter, while being most sensible and the system used in Ethereum, is suboptimal. For every individual account as a consensus rule we must store all nonces for all eternity up to a maximum set by the consensus system. We can also not have out of order execution of transactions as they become exclusive actions (if 1 and 3 have happened, 2 can now never happen), this removes the possibility of storing pre-signed but un-broadcast transactions as is used in Bitcoin.
Instead, we store just a list of transaction outputs in the UTXO which have never been spent, and strike them from the database when they have been spent. Replay of an already existing transaction can not happen because it will spend an output that does not exist. This is ultimately the most scalable as spent transactions leave no fingerprint on the nodes storage, and allows for validity checks to happen in milliseconds.
Using a UTXO causes transactions to be atomic, and automatically not re-playable.

you should copy your answer to the question this post was marked duplicate of. The answer on the past is good, but I think yours is a nice explanation, and it approaches the answer in a different way.

Look at the time stamps.

Ah sorry, I made a confusing typo on my first comment, it should say "The answer on that post is good,...". I know you answered here before it was marked duplicate, I just meant to say if that other question is the target for duplicates, you should copy your answer to it. I think it is a helpful answer, and it will get more views if you copy it there (since this question is now marked duplicate).

Underwood, sorry.


text:
How nonce and diffuculty work?
I struggle to understand one concept behind mining. It would be really great if someone could clarify some things.
This is an extract from blockgeeks:
From a technical point of view, mining process is an operation of inverse hashing: it determines a number (nonce), so the cryptographic hash algorithm of block data results in less than a given threshold. (The threshold is difficulty here.)
Source: https://blockgeeks.com/guides/proof-of-work-vs-proof-of-stake/
The question is why cryptographic hash algorithm results in less than given threshold? I always thought it should be equal or higher than threshold. If it can be less then blocks can be created really quickly.
What am I missing here?

If it can be less then blocks can be created really quickly.

This is not the case if threshold is referring to the target. In order for a block hash to be valid, it must be less than the target value. The lower the target value, the less possible solutions exist, because the target value (and block hash) are 256 bit numbers, meaning there is a finite number of possibilities.
There is a difference between target and difficulty. The article confuses the terms threshold and difficulty.
Target
The number that the block hash must be less than in order to be valid. This is a 256 bit number e.g. genesis block target:
0x00000000FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFF
Genesis block hash (notice it is less than the target above):
0x000000000019D6689C085AE165831E934FF763AE46A2A6C172B3F1B60A8CE26F
Difficulty
This describes how difficult, in relation to the genesis block, the target will be to reach. The higher the difficulty, the more hashes (on average) you have to do to find a solution that is less than the target. It is calculated as:
difficulty = genesis_difficulty_target / current_target


text:
Why bitcoin addresses have different number of characters?
With the help of bitcoin wiki I learned that every bitcoin address stands for a number and that shorter addresses are valid just because they happen to start with zeros, and when the zeroes are omitted, the encoded address gets shorter.
Source: https://en.bitcoin.it/wiki/Address
I am not sure I fully understood everything. First of all, I suppose the part about a "bitcoin address stands for a number" refers to hexadecimal digits?
Other point I'd like to clarify:
How the zeros can appear while address is generated in the first place? I thought that zeros (along with l, I and O) does not exist in Base58Check encoding at all.

Bitcoin addresses are 160bit numbers. They are derived by running the public key through hash functions. The result is a number in a fixed range i.e. 0 to 2^160. This is then encoded in base58check or bech32. You could represent it as hexadecimal as well if you liked.
2 and 53 are both random numbers inside 0-100. One takes 1 character to write out while the other takes 2 characters to write out. Instead of writing them in the decimal number system I could write them in hexadecimal and that would not change.
Base58check is just another encoding format. It's converting the number into base 58 number system and adding a checksum at the end to prevent typos.
You can represent zeroes in all of the above number systems/encoding formats. You may do it with characters other than 0 though. In the case of base58check 0 is represented with 1.

Thank you. Could you also clarify how bitcoin address gets "1" at the start? I've read this Technical_background_of_version_1_Bitcoin_addresses . In the end we can see that two 0 are added before encoding into base58check. Why we have only one "1" instead of two "1". The table you provided says that 0 converts to 1.

see number 5 here


text:
Bitcoin script (pay-to-pubkey-hash)
Example for 'pay-to-pubkey-hash' is quoted in Wiki bitcoin script.
I have a doubt that 14 is for bytes to push. But the data to push is 20 bytes.
Please anyone could explain to me?
Script:
76 --> OP_DUP
A9 --> OP_HASH160
14 --> Bytes to push
89 AB CD EF AB BA AB BA AB BA AB BA AB BA AB BA AB BA AB BA --> Data to push
88 --> OP_EQUALVERIFY
AC --> OP_CHECKSIG

20 in decimal is equal to 14 in hexadecimal

As Ugam Kamat commented:

20 in decimal is equal to 14 in hexadecimal

(Community-Wiki answer to remove Q from unanswered list)


text:
Is there any guarantee that mining will be profitable?
I'm not a money person. I deal with it only out of necessity. So say I have $1000.00 worth of Bitcoin and decide to enter the world of "mining". What's the physical process on my end and is there any guarantee that I will come out ahead?

closely related: https://bitcoin.stackexchange.com/questions/41276/5406

There is no guarantee of profitability for any miner. What's more is that it is extremely difficult to estimate how profitable it will be because there are unpredictable variables involved. The mining difficulty is regularly re-targeted to account for increased mining power. The market exchange rate for BTC into dollars (or whatever currency your electricity bill is presumably paid in) fluctuates wildly, and the value of fees paid by users varies depending on mempool size or speed they wish to have confirmations. These variables are entirely out of anybody's control because they're a result of the actions of individuals.
Mining has been largely profitable due to the block subsidy which halves every 4 years. There is no guarantee that mining will remain profitable for existing miners when the next subsidy halving occurs (in 2021). If mining becomes unprofitable for them, they will have to scale back their operations or shut down and auction off their mining equipment. This will cause the difficulty to lower temporarily, which may make it profitable for new market entrants willing to take the risk.
Ultimately, mining is a risk-taking business and may never pay off. There are some obvious ways to try and increase your chance of becoming profitable though: Find the cheapest source of electricity you can and get the most efficient mining hardware for your price point.

Nice answer, but just one nit pick. The next Bitcoin halving is in 2020.


text:
In bitcoin core, how to avoid the dust exception?
When I try to broadcast a transaction, my bitcoin core throw a "dust" exception.
amount: 0.00029
fee: 0.00001
bitcoin core version: v0.16.0

The same transaction can success in testnet, but fail in mainnet.
When I send 0.0003 BTC to an account in my bitcoin core, it can success. So, I think send 0.00029 BTC out of the node is still possible.
I set the fee to such a small number to lower the transaction cost, since there will be many transactions like this one. If this fee will not work, then what is the lowest fee?
I try to set the option "discardfee", but didn't make anything change.
Any advice is helpful, thanks in advance.

The current dust limit fee rate is 3 satoshis/byte. If, at 3 satoshis per byte, an output would cost more in fees to spend that it has in value, then that output is considered dust. If you are sending to non-segwit addresses, this limit is 3 sat/byte * 148 bytes = 444 sats. If you are sending to P2SH-segwit addresses (the default address type in Bitcoin Core), then the fee limit is 3 sat/byte * 91 bytes = 273 sat. If you are sending to bech32 addresses, then the fee limit is 3 sat/byte * 68 bytes = 204 sat.
You can lower your dust limit by setting -dustrelayfee to something lower than 0.00003 BTC/kB (equivalent to 3 sat/byte). However I do not recommend that you change this as even though your node will accept transactions with outputs that are otherwise dust, other nodes will not and your transactions will not be relayed.
Furthermore, you should not set your transaction fee rate to be less than 0.00001 BTC/kB (equivalent to 1 sat/byte) as this is the default minimum relay fee and transactions that have a fee rate less than this will not be relayed. Just because your node accepts a transaction does not mean that other people's nodes will.

There will be many addresses has dust in it, typically 0.0003BTC each. I want to collect them into a single address. How to do the math in this situation?

0.0003 BTC is not dust. The problem is not that you are spending small outputs. Rather the problem is that you are creating a dust output. If the addresses are part of your Bitcoin Core wallet, let Bitcoin Core do the work. You can create a transaction using createrawtransaction which has no inputs and only the outputs that you want the coins to go to with the full amount of your wallet. Then, using fundrawtransaction, you can set it so that the fee is deducted from this output. Core will select the coins and set the fee for you.

The commands are: createrawtransaction '[]' '[{"<address>":<wallet balance>}]' and then fundrawtransaction <tx hex from createraw> '{"subtractFeeFromOutputs":[0]}'

I trying your suggestion. But I still don't fully understand. You mean the problem is that the size of output is too small, even the amount (0.0003BTC) is big enough. But how the app client do the similar transaction? I use Copay to send 0.0003BTC to the address in my bitcoin core. When I try to send the same amount out of bitcoin core, the dust problem occurs.

I believe I have solve the problem. Your advice is really helpful. @Andrew


text:
Mining a new block
Hypothetically, if you only have one node mining in the network, how much time does it take to solve for the nonce assuming for example the current difficulty?

The number of nodes is irrelevant.  What matters is how much hashpower you have; i.e. what kind of hardware is attached to that node, and how rapidly it can perform SHA256D hashes.   If your node is an ordinary computer with no specialized ASIC hardware, then at today's difficulty levels, for all practical purposes, you will never mine a block (on average, it will take several million years to do so).
See https://en.bitcoin.it/wiki/Difficulty#How_soon_might_I_expect_to_generate_a_block.3F to learn about how to estimate the time to mine one block given your hashpower.

We have tons of questions and answers about the basic principles of mining.  See for instance https://bitcoin.stackexchange.com/questions/51756/how-does-mining-process-takes-approximately-10-minutes?rq=1, https://bitcoin.stackexchange.com/questions/148/what-exactly-is-mining/760#760

I am trying to understand how a new block is added to the chain every 10 minutes. If we have thousands or even millions of nodes solving for the nonce, and if it takes 1000s of years to mine 1 block, then how the all of the previous block had been added? The confusion arose from the point that all nodes try to solve for a nonce, once one of them finds it, the remaining will drop their work and start over again. So does the latency come from this point (repeated attempts to solve for block? Because apparently, if 1 block is being added every 10 minuets, then someone, an (ASIC??) is succeeding.

You have to understand the random and progress-free nature of mining.  The concept of "drop their work" is meaningless; in some sense you drop your work after every unsuccessful nonce.  See for instance https://bitcoin.stackexchange.com/questions/3941/does-mining-a-block-force-others-to-restart-their-work


text:
Is bitcoin running over a structured or unstructured overlay?
How nodes are being admitted to the system? Does each node have a sequential unique address?
In other words, are bitcoin nodes considered structured or unstructured?

Bitcoin uses an unstructured network.
The primary reason a network might opt for a structured system is to allow systemic retrieval of information. This is not necessary in Bitcoin, since each node maintains the same information.
Bitcoin does not, however, employ the flooding technique at the start. It uses a set of DNS seeds to get an initial node list, and connects to nodes from that list, before asking them for additional peers. This prevents the bandwidth issues associated with flooding, while maintaining a reasonably decentralized discovery method.
Note that even if all the DNS seeds ceased to exist, new nodes could connect by connecting to any existing node, and then asking for a peer list, and cascading down the peers' peers. In the based, IRC channels were also used for node IP discovery, which again shows how the system can remain functional without the DNS seeds.


text:
Merging cryptocurrency wallets
In my quest to learn about cryorocurrency, as fast as I possibly can, I have registered with about seven wallets, all with one goal, to deposit Bitcoin into one of them, I am yet to do this but I was thinking that maybe working with only one wallet would be easier, anyone, can you PLEASE help ?

You should find a wallet which gives you control of your keys (non custodial, not a ‘web wallet’ with an online login, etc). This will give you full responsibility over your coins, be sure that you safely store a backup (‘seed phrase’) so that you can recover your coins in case of loss.
If you created a wallet but did not use it to store coins, then do not give a second thought to just abandoning it. Do not attempt to ‘combine’ wallets either, this is counter to how they were designed to be used, and it could have very undesirable affects on your wallet security, etc. Just find some software you like and trust, and use it.
This site lists a number of wallet software options, you’ll need to do your own research to figure out which which one will suit your needs best.
This question is a great place for new users to get info: I am new to Bitcoin, how can I get started?


text:
Wallet forensic
Someone who scammed me used this wallet to receive the BTC 12fmomENb5SSxR54Bitua71CZrc4oVQtmB he hasn't moved them from there since July 31st I'm trying to figure it if that wallet belong to any exchange so I can contact them because I have all proof that this person in fact stole from me...

I analyzed a bit with forensic tools and found that with high likelihood either you or the scammer (or both) have an Huobi.com account.
If I understand you right then 03281a511f38992dff51dee176c66dfc5f873e92cd76228956ca5099a27214fd shows the scam transaction and the input addresses on the left side are yours and you initiated the transaction?
If yes then wait until the funds of 12fmomENb5SSxR54Bitua71CZrc4oVQtmB move (as of writing no move), then the flow can be analyzed until the scammer cashes out by sending the funds to a known exchange address.
If no (hacker initiated the transaction): Then address 14trBCQy7eGqGHKTouGC24vFJoFBoofBmn belongs as well likely to the scammer (you should know it if you look into your wallet), address 1BAyMWsePjFXjURd7EAPxs7YzFZAnTuw8e belongs likely to the same person and sent some funds to address 19LoQjvaNvTtKeADkZfqsbWCkWqoyjsTiK which is a known Huobi.com address. In this case it depends on your and spammers jurisdiction and Huobi support and a bit luck if you can identify the spammer with police's help or legal action.
Wish you success!
Update Nov 19,2020:
The coins were moved and the 12fmomENb5SSxR54Bitua71CZrc4oVQtmB had a co-spend with address 12qVmVXgFEtimhPDEMuUdg4AApdgW4gUS4 which deposited and withdrew very likely in other transactions at poloniex.com. The same person very likely received a lot of BTC from bittrex.com . The BTC address 12qVmVXgFEtimhPDEMuUdg4AApdgW4gUS4 sent funds to BTC address 1DfYET2tnEU54K9r5hWxxb8dWr4uko9eP9 which belongs to bitfinex.com. The BTC address 1JEd1Nb5LXYVFiR9s1ZtXFdxvTKAYYCHNg (belonging likely to the same person) sent funds to BTC address 1PsXn2nruFCS2WCVedVo76yPGgaS6UXUrA which belongs to yobit.net .
So if you didn't receive your funds back in the meantime I'd try to involve law enforcement because the loss was not a low amount. The exchanges know if the scammer cashed out (bank account or id available) or if he exchanged into another coin to follow up from there. If the scammer was smart you won't succeed but it's difficult not to leave any traces.
Good luck!

In general, there's no way to know if that address belongs to an exchange.
This is especially true when the funds have not been moved/spent.
Similar questions:

Tracking the wallet owner of stolen bitcoins
Wrongly Transferred!
How can I confirm to whom the bitcoin address I sent a payment too?