text:
Does proof-of-work contribute directly to prevent double-spending?
I know similar questions have been asked before (e.g. How proof of work prevents double spend) but I'm struggling to visualise the solution to double-spending being directly reliant on proof of work.
Imagine a miner, Bob, trying to double-spend 1 BTC by sending to both Alice and Jim.  Either he can include both transactions to Alice and Jim in a single bad block that he mines - in which case the block will be rejected even with a valid PoW.  Or he can broadcast his first (valid) transaction to Alice and let someone else mine it and then mine his own bad block later with the transaction to Jim which again will be rejected regardless of having valid Proof-of-work.  So double-spending is really protected against on the level of transaction-validation which every full node on the network performs?  Meaning PoW doesn’t really directly stop double-spending - what stops double-spending is simply the nodes being aware of previously confirmed transactions.  And the reason we can trust all transactions on the blockchain are "confirmed" is PoW?
If that's right, and PoW is more of a high-level system-wide solution, here's a final question I'm hoping someone can clarify: why can't we replace PoW with an automatic 10 minute block-addition based on a simple timestamp?  Is it because it's such a mission-critical task (involving the trust of the whole system), that unlike Difficulty calculation (where we rely on timestamps), we must find an alternative where no time value can be spoofed? (even though if it was, individual nodes would presumably be able to reject it fake times).  Is it wrong to think of Proof-of-work as basically a replacement for trusting a (hackable/spoofable) timestamp server that could regulate 'blocks every 10 minutes'.

There are multiple definitions of the term "double spending" at play here. First, there is the actual definition of double spending: to spend the same money multiple times. A simple example of this is the coin on a string in a vending machine. You put tie a string to a coin, when you put the coin in the machine, it thinks you paid, you get whatever you want from the machine, then you use the string to pull the coin back out so that it can be spent again somewhere else.
By this definition, the exchange of goods has occurred, but the money used to pay for it is used by the payer to pay for another good later. In effect, you created multiple transactions that conflicted with each other and they are all considered to be settled (i.e. final and irreversible) in the accounting system of that money.
Then there is the definition of "double spending" in the context of Bitcoin transactions. Double spending is often used to say that there are multiple unconfirmed transactions which conflict with each other. But unconfirmed transactions are not considered to be settled, so you have conflicting unsettled transactions under this definition.
The goal of the blockchain is to resolve these conflicting unsettled transactions. It's purpose is to ensure that all transactions do not conflict with each other and to make them considered settled. So to not have double spends, you need two properties for transactions: irreversible, and non-conflicting.
The non-conflicting part is handled by nodes. Nodes validate blocks and transactions. They reject blocks if they contain transactions that conflict with other transactions in that block or in the blockchain. So the thing that prevents the conflict aspect of double spends are nodes.
The Proof of Work is what allows for the irreversible aspect. It requires that miners expend time and energy in order to create a block. In order to change the contents of a block, one must expend time and energy to create a new block which conflicts with one that already exists.
The Proof of Work is also used to resolve blockchain conflicts. If there are multiple candidate blockchains that stem from a common forking point, nodes follow the one that has the most cumulative work because that chain is the one where the most energy was expended to create.
The chain part of the blockchain creates a compounding factor so that in order to replace a block in the blockchain, you must also replace the blocks that are on top of it thus expending far more time and energy. Because there are other people mining on the original blockchain, you must also be able to mine faster than them in order for your blockchain to have more work than the original for yours to be accepted by everyone else.
Because replacing blocks requires significant time and energy expenditure, one can reasonably assume that a block and the transactions it contains will never change once multiple blocks have been mined on top of it. This gives us the irreversible aspect. This is why it is said that confirmed transactions are irreversible.

why can't we replace PoW with an automatic 10 minute block-addition based on a simple timestamp?

Because that is not decentralized. Who creates the blocks? If multiple people can create blocks like with mining, by what mechanism are ties broken? How do you resolve two different people creating different blocks? What stops someone from spoofing timestamps and replacing the blockchain with their own version?
The easiest way to resolve these is to make blocks only produced by a limited and trusted group of people. So it is now centralized. Congrats, you created Paypal, but less efficient.
The whole purpose of the Proof of Work is to allow for a decentralized system where everyone can agree on the truth without some central authority dictating what that truth is. If everyone follows the same rules, then everyone will eventually conclude on what the truth is. The use of energy expenditure in the Proof of Work prevents someone from rewriting history with different blocks because it is expensive to do so. The tie breaking of using the chain with the most work allows nodes to converge on the same blockchain. Use of the Proof of Work answers the questions I gave above without relying on a central authority.
In conclusion, the Proof of Work allows transactions to become settled and irreversible. It allows nodes to converge onto the same blockchain and makes it extremely expensive, to the point of impossible expensive, to rewrite history thus making transactions in the blockchain irreverisble. The actual ensuring that no conflicting transactions exist in the blockchain and thus actually preventing true double spends is left to the nodes that validate the blockchain.

thanks for giving such a comprehensive answer!

@Andrew Chow thank you for the great explanation.  I still have some doubt about the usefulness of the PoW. What if there is an obvious and unquestionable truth for each conflict of blocks, and therefore we don't need consensus anymore. In this situation, do we still need the PoW?

by obvious and unquestionable truth I mean when there's a conflict of blocks, each node can undoubtedly conclude on the same truth about which one is the correct, just like we can always conclude that two bigger than one is true.

@swampcypress Sure, if there were a decentralized way of doing that, then we would not need PoW.


text:
Does Merkle Tree root hash changed when miner node not found POW nonce?
In bitcoin PoW process,if miner does not found the nonce, I understand that he must
to increase nonce and rehash the entire block header again
to mine the new block.
so if nonce defined 4byte[between 0 and 2^31],
goes from 0 to 2^31 finally and even not found the target hash, does the miner rehash the Merkle Tree including coinbase transaction?
And what algorithm for miner to change coinbase transaction?

Not necessarily. If a miner runs out of nonces, there are still other things in the block header he can change. The version number and timestamp can both be changed to effectively increase the number of nonces that can be tried. However there are not as many possible version numbers of timestamps that can be used as they have to fit within certain constraints.
If the miner does not change those, then he will change the merkle root. This is most commonly done by incrementing a value in the coinbase transaction known as the extranonce. This value is stored in the coinbase script where miners are free to place up to 96 bytes of arbitrary data. By incrementing the extranonce, the merkle root will change and the miner can continue with searching through nonces again.
If the miner runs out of nonces and extranonces, he can reselect transactions to be included or reorder transactions, both of which will also change the merkle root.

so does it mean miner change the Merkle Tree's transaction  and increment nonce from 0, repeat this circle until  found the solution?  I think this very randomly and how the network difficulty adjustment  can say that it will found block in 10 minutes?

Yes, that is what they do. The point of this is that it is a random process. There is no guarantee that a block will be found within 10 minutes; it is just that the average time between blocks is 10 minutes.

source: Stack Exchange

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

sort: votes


text:
How to encrypt messages with Pub/Priv keys
I'm wondering if it's possible to use the Bitcoin public and private keys (usually used for signing) for text encryption. This is an example in nodeJs:
import pkg from 'bitcore-lib'

const { PrivateKey, Networks } = pkg
const privateKey = new PrivateKey(Networks['livenet'])
const myObject = {
    privateKey: privateKey,
    P2PKHAddress: privateKey.toAddress(),
    publicKey: privateKey.toPublicKey(),
    wif: privateKey.toWIF()
}

It is possible to use publicKey to encrypt a message and decrypt with  privateKey?
const encryptedText = encrypt('Hello', publicKey)
const decryptedText = decrypt(encryptedText, privateKey)

assert decryptedText === 'Hello'

After some research I found that the ECIES algorithm is what I was looking for. First, I tried the library bitcore-ecies but seems to be deprecated, old and buggy. So I pick ecies-lite. This is the result:
import pkg from 'bitcore-lib'
import * as ecies from 'ecies-lite'

const { PrivateKey, Networks } = pkg

function generateKeys () {
  const network = Networks.livenet
  const privateKey = new PrivateKey(Networks[network])
  return {
    privateKey: privateKey,
    P2PKHAddress: privateKey.toAddress(),
    publicKey: privateKey.toPublicKey(),
    wif: privateKey.toWIF()
  }
}

function main() {
  const result = generateKeys()
  const body = ecies.encrypt(
    result.publicKey.toBuffer(),
    Buffer.from('This message is for demo purpose')
  )
  console.log(body)
  const message = ecies.decrypt(result.privateKey.toBuffer(), body)
  console.log(message.toString())
}

main()

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


text:
Private Key leakage due to reusing same address, how to prevent?
1 What precisely is the meaning of "reusing"? Is it receiving multiple times coins to the same btc address? Or is it also about sending coins?
2 How can people avoid this leaking of information when using a wallet, best practices?
3 How many times of reusing could be enough to seriously allow leakage/reingeneering of the key? Just one time is enough ? Possible to make any estimations?
4 Is this reusing problem only inherent to bitcoin? Or which other blockchains would you know of with same issues?

No, reusing address won't succeed in private key leakage (assuming quantum resistance).

Yeah, reusing has two meanings - if you use static address it may succeed in lack of privacy. Imagining the situation when you share single address with police department for some contract work, and also you use the same address in your darknet market store (hypothetically).
But reusing is also related to spending from an address, during which you share your public key (it's needed to be shared publicly to confirm transaction signature).

Use BIP44 scheme, don't share one address to more than one person. Use invoices (btcpay server) rather than static addresses. If you want to be even more private, use P2E or Paynym's protocol.

As in example in point 1, once is enough in some case

Address reusal is a problem in utxo-based blockchains. Ethereum, being account-based is much less affected by it, as the privacy on this front is non-existent by default in account-based model blockchains. With bitcoin, utxo model is at least preventing users from obvious mistakes.

Why are you talking about privacy if I was talking about the the private key? You are talking about the public key which is of no interest here. Please try to read questions more carefully the next time. All your answers miss the point. And why do you assume quantum resistance if there is no quantum resistance given in bitcoin?!


text:
Lightning Node Full Pubkey
I have my lnd node pubkey, public IP address and an open port as follows:
0286712a3a81b0d5e54469042146137fbdf7b77802f21fad1261c031a8d917f5da@...
Do I have to set parameters after the '@' sign - in some configuration file or is it enough to just use them when I provide the full address?

You could just test if your node is reachable from outside: just tested and it is, congrats! :)

@darosior - thanks for checking and confirming!


text:
ECDSA public key to private key hex
I have an ecdsa public key how to get the private key of this public key;
0222d2deda24c03b2cc2b458c35780c62b6b5603c088709f17607b7ecf1399e4d7 how to solve this on python I am using Pydroid 3 on my mobile any sources to do this any code for this and also tell me how to do this on termux not random entering public key and finding private key hex can any body can help me

This is not possible. If it were, anyone could steal anyone's bitcoin.

There is no math that would get the private key from a public key. That is the whole point of the Elliptic-Curve Cryptography. You can always get the public key from a private key, but not the opposite since this would mean that anybody could spend the Bitcoins of anybody and Bitcoin itself would be worthless.

Ok do you have any code to do it

https://brainwalletx.github.io/#generator

Thank you how to compress an public key and private key send me python codes

If the y coordinate of the public key is an even number, then the compressed public key starts with the byte '02' followed by the x coordinate. If it is an odd number then the compressed public key starts with the byte '03' followed by the x coordinate. Here is some code from a great book where I learnt a lot from: https://github.com/jimmysong/programmingbitcoin/blob/master/code-ch05/ecc.py

your public key is already compressed since it only has 33 bytes (1 byte for the y coordinate and 32 bytes for the x coordinate) Also, it starts with 02 which means the y coordinate is an even number. If it were not compressed then it would start with the byte '04'

Traceback (most recent call last):
File "", line 1, in
File "/data/data/com.termux/files/usr/tmp/pip-install-4lpak8y9/hashlib/setup.py", line 68
print "unknown OS, please update setup.py"
^
SyntaxError: Missing parentheses in call to 'print'. Did you mean print("unknown OS, please update setup.py")?
----------------------------------------
ERROR: Command errored out with exit status 1: python setup.py egg_info Check the logs for full command out

Can i get your gmail I can't load more

That error usually means the code was originally developed for python 2, but now you are running it on python 3. All you have to do is to open the file that is throwing the error, and fix the "print" statement. In python3, the correct syntax for a print statement is: print("your_message"). You might have to fix a couple of them.

ripemd160.update(hashlib.sha256(s.decode('hex')).digest())
AttributeError: 'str' object has no attribute 'decode'

inputAddr = base58.b58decode_check(keyUtils.pubKeyToAddr(pub))
File "/storage/emulated/0/Bitcoin-Key-Compression-Tool-master/Bitcoin-Key-Compression-Tool-master/keyUtils.py", line 55, in pubKeyToAddr

Traceback (most recent call last):
File "/data/user/0/ru.iiec.pydroid3/files/accomp_files/iiec_run/iiec_run.py", line 31, in
start(fakepyfile,mainpyfile)
File "/data/user/0/ru.iiec.pydroid3/files/accomp_files/iiec_run/iiec_run.py", line 30, in start
exec(open(mainpyfile).read(),  main.dict)
File "", line 11, in
File "/storage/emulated/0/Bitcoin-Key-Compression-Tool-master/Bitcoin-Key-Compression-Tool-master/txnUtils.py", line 53, in getSignableTxn

Can you explain this what to add

Again, these errors are caused by trying to use python2 code in python3. Maybe try to run the code using python2. But if you can't do that for whatever reason, just try to google the errors. Most of them are pretty easy fixes. Your first error, for instance, is giving you a hard time because the syntax inside the sha256() is a python2 syntax. Just replace s.decode('hex') by bytes(s,"utf-8"). The other error messages are incomplete. Good luck!


text:
Can you verify partial blockchain information from a third party, without yourself having an entire blockchain?
I'm considering consuming, or if unavailable, I'm considering providing, a bitcoin blockchain querying service along the lines of json rpc.
Would it be possible for me as a consumer of such as service, to verify the integrity of returned data from such queries, without myself running a full node? (If not there wouldn't be much point using such a service!)
Would it be possible for me as a provider of such a service, to provide enough data for a consumer to verify the validity of the data I send them, when the consumer is not running a full node? (If not there wouldn't be much point providing such a service!)
My end goal is to run something like a bitcoin blockchain explorer website on the cloud, but the cost of running a full node (particularly storage) on the cloud is more than I can afford. Obviously I have some feature ideas I've not yet seen on other explorers

Question edited to confirm I do mean bitcoin. I call it a "blockchain querying service" as the service would relate to the bitcoin blockchain, but not extend to (for example) the bitcoin lightning network.

You could use the Simple Payment Verification, or SPV, protocol.
In a nutshell, this works by synchronizing only the block headers for the longest chain. Once the chain is established, individual transactions are proven by using merkle paths leading up to the merkle root in the previously synced block headers.
Note that this only allows for proof that the supplied data exists in the chain - it does not allow the user to verify that you have provided them with all data - it is possible for operators on SPV systems to Lie by omission and simply claim a transaction or block doesn't exist.
Consumer wallets usually get around that by querying multiple such nodes - if at least one node is honest, the wallet is able to detect the lie.


text:
Very slow sync on low end PC - what to upgrade?
[Hi, I have to re-ask this question because I cannot recover my account from the last one. Sorry about that.]
I am a newbie to bitcoin. I am trying to sync a full node on my low end PC: 2g RAM, dual-core 2ghz, 250 gb regular HDD. Fresh install Linux. It is in pruned mode. The internet connection tests at 5mb download/1mb upload speed. The initial 15% synced in a few days but now the process is fluctuating wildly around 2-7 weeks. It's been on for a month & is only at 35%  right now... Suffice to say it is very slow.
My main questions are: how much will adding some RAM improve the syncing speed? And will adding new RAM reset the blockchain download? Also, I have heard repeatedly that using a SSD HD will help. Is there a way to carry over my present 35% progress onto the SSD, or do I have to re-start the process?
I have already adjusted these settings: dbcache=900, banscore=10, listen=0, server=1 (upnp=0 also shows up on the bitcoin core gui/options, but not in the config file.). I don't really understand what these settings do, I am just going off recommendations. So hopefully they are good(?).
I am worried that putting in the RAM will "reset" the blockchain download and I will have to start syncing from 0% again. This already happened to me when I was tinkering with the dbcache setting - Which I will have to do again in order to take advantage of any new RAM. (right?)
Anyway I hope that was coherent. Any response is very appreciated. :)

Yes, an SSD will help. Shut down your node and wait for it to finish. Then move datadir onto an SSD. Don't use USB-Sticks for they are unreliable.

Probably you are limited by slow hard drive. Even if you're pruning, the hard drive is still accessed. That means you should get a SSD hard drive.
There's a tool on Linux called iostat you can use to see where your computer is spending the most time.
iostat -y 1  # will repeat at 1 second intervals

If your operating system is installed on the non-SSD, then you probably will want to move that also, because operating systems read and write files while they work. For transferring the bitcoin sync progress you basically just need to copy the .bitcoin directory in your home folder, assuming you're on a Linux computer. Probably same for Windows but the directory location is going to be somewhat different.

Increasing the computer's memory will not speed up the process.
You can copy the bitcoin directory to another disk, install bitcoin core and it will continue from where you already downloaded. On a Linux system it's on $HOME/.bitcoin
To carry data in the safest way I would use rsync:
$ rsync -avhSP /home/user/.bitcoin/ /mnt/external_disk/home/user/.bitcoin/

OP is running in pruned mode, which only needs a few GB of storage.

@PieterWuille thanks, I missed that


text:
What happens to unclaimed Open Assets (colored coins) asset quantity units?
I'm trying to understand the Open Assets transaction example given here.

Everything makes sense, more or less, until the end of the description:

Output 6 receives the first 3 units of input 5. Input 5 has the asset ID A2 so the asset ID A2 is assigned to output 6.

What happens to the remaining 6 units of Asset A2? The unit count starts at 9 for input 5, and output 6 claims 3 units. That leaves 6 units unaccounted for. Input 5 is spent after this transaction, so it's not clear how it can be reclaimed.
What am I missing?

Did you forget to add something? "Also"?

@StephenM347 No - just a stray word from earlier edit. Fixed it.

I had the exact same question when reading over that specification document. I'm not sure if that is a mistake in the example, but the conclusion I reached is that the colored coins are destroyed.
I tested this with the Python Open assets library and the transaction that claimed less than the full possible number of assets was still a valid colored coins transaction.
So, unlike normal coins where the 'leftovers' are given to the miners, unclaimed open assets are destroyed.

Unclaimed Open Assets units are indeed destroyed, which (depending on the use case) could be a problem for you. Other protocols such as CoinSpark (ours), Counterparty and Omni Layer don't have this accidental destruction problem, because the assets always go somewhere by default, if they are not explicitly reference.
In CoinSpark this default place is the last non-OP_RETURN transaction output. In Counterparty and Omni, the default place is the addresses where they were originally kept (they can do this because in their model, assets sit at an address, rather than in a transaction output).

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


text:
Why is JSON-RPC over SSL "strongly discouraged"?
The Wiki contains a page that simply states:

JSON-RPC over SSL is strongly discouraged

Why?
I found a method for enabling JSON_RPC over SSL here. The post mentions nothing about JSON-RPC over SSL being strongly discouraged. What risks do I run by using it?

Note to other readers: This question is about the use of a command interface for Bitcoin software, and does not really have anything to do wtih JSON-RPC.

The RPC interface isn't designed to be used in any scenario which would require SSL, which would be access over the internet or other untrusted networks. It doesn't have the necessary denial of service protections or review to make it safe for use this way, and so letting potentially malicious clients connect to it would be incredibly unwise. If you need to talk to a remote bitcoind instance you are better off tunneling with SSH or stunnel which will provide a secure, authenticated path without exposing the socket any further than localhost.
As of 2017, support for RPC SSL has been completely removed to support the continued move away from reliance on OpenSSL in the daemon (unfortunately BIP70 mandates its inclusion for the GUI client).
As of 2019, all reliance on OpenSSL has been successfully removed from bitcoind.

can I add this to the bitcoin wiki??? ermmm Screw it I'm doing it!

the year is now 2017, and it seems RPC SSL support has been dropped altogether. Instead, the release notes recommend using OS specific tunneling mechanisms. Cheers. https://bitcoin.org/en/release/v0.12.0#rpc-ssl-support-dropped

Also hence the release notes when SSL was dropped. Mentions some solutions: https://github.com/bitcoin/bitcoin/blob/d6a92dd0ea42ec64f15b81843b4db62c7b186bdb/doc/release-notes.md#ssl-support-for-rpc-dropped

can I use IPSEC ?

i didn't quite understand the reasoning; passing sensitive information in cleartext is a bigger problem, it's a big no-no. (it's listed as a common weakness https://cwe.mitre.org/data/definitions/319.html )

It's not the responsibility of Bitcoin Core to provide a secure transport. The RPC interface is supposed to be used locally to a system where encryption is not required, if it is to be used remotely, a user can provide their own transport such as wireguard or even SSL if they so choose, but it's not safe for it to be a built in. The prior existence of SSL in Bitcoin Core has directly resulted in memory corruption in OpenSSL leaking secure memory from the client.

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


text:
Bitcoin privacy metrics?
I'm looking for a numerical privacy scoring system that estimate the degree of linkage between the members of a key pool (or even just individual key pairs). Ideally, the method should be easy to understand and apply.
I'm aware of "taint analysis" as offered by blockchain.info. There's also discussion in these papers:

Anonymity of Bitcoin Transactions
Evaluating User Privacy in Bitcoin
Privacy-Enhancing Overlays in Bitcoin
Quantitative Analysis of the Full Bitcoin
Transaction Graph

What else has been done to quantitate Bitcoin user privacy? I'm most interested in ways to compute a benchmark score that tells a user how closely linked the the members of a key pool are, or how closely linked two individual key pairs are.

This doesn't answer your question, but it may nonetheless interest you. It's an attempt at quantifying the ability of several software wallets to improve their users' privacy: Bitcoin Wallet Privacy Rating Report.

Here is a great video in which they asked: given 1 address I know belonging to someone, how many other addresses can I associate with that particular wallet. It turned out to be about 75%.
The method detailed in the video uses a few assumptions about how wallets work.

Multi-input heuristic: All inputs in a transaction belong to the same wallet.
Shadow change heuristic: Change public keys have never been seen before on the blockchain.
Consumer change heuristic: Transactions from consumer wallets have 2 or less outputs.
Optimal change heuristic: Wallets do not spend unnecessary outputs. This means that a transaction with say 2 inputs of 0.5 each and 2 outputs of 0.6 and 0.4, the 0.4 is assumed to be the change address belonging to the same wallet. This is because if the intended payment is 0.4, the wallet would have chosen a single 0.5 input.

The question is asking about a method to quantify how closely related two addresses are. Your answer is related to the topic, but doesn't address the question. If it is answered in the video, please include the relevant points in your answer. Otherwise, I think this post is to be classified as "not an answer" on this question.

Sure, I'll edit the response to answer the question.

To quantitify user privacy there is the Bitcoin privacy score which is available for all BTC addresses which were ever used in the blockchain. It's a score between 0% and 100%. Close to 100% means excellent privacy:

No address re-use
several analytical heuristics to group the address with others belonging with high likelihood to the same entity (co-spend ...) not successful
No path to one of the millions of known exchange addresses (deposits)
No path from an exchange address to the subject address (withdrawal)

The lower the score the worse the privacy of the bitcoin address.
If you want to try it out here the link:
Bitcoin privacy score
(Disclosure: As co-programmer I'm affiliated to the btctester site)

It looks like you are affiliated with the site that you link to. Please disclose that you are affiliated with the website in answers where you do link it. As our site rules (https://bitcoin.stackexchange.com/help/promotion) state "you must disclose your affiliation in your answers." Otherwise your posts may be removed as spam.

I understand and was not aware, thanks for information and apologies! I edited and added a disclosure statement.


text:
How many unique public keys have been published to the block chain?
There have been estimates of the number of published addresses. For example:
https://blockchain.info/charts/n-unique-addresses
(this chart seems to be underestimating the address count)
However, I'm interested in the number of public keys. Most of them would be obtained from transaction inputs containing P2PKH response scripts.
This article suggests there are at least 56 million, but doesn't describe how this number was found or if the raw data are available:

... I obtained around 56 million pubkeys from the blockchain (mid-January) [2015] ...

Is there a convenient source that gives the number of published public keys in real time?

We've had a similar question recently and if memory serves (I'll find the link) the only way to do this is to parse the Blockchain data using a library like Python-bitcoinrpc in conjunction with a full node of bitcoincore

@WizardOfOzzie: I think you might be talking about Extract all public keys from blockchain

The concept of "number of unique keys" (that article) is different from "number of published keys" - I can't really tell from your question which you are after.  Seems like the latter.  Can you please clarify?


text:
What prevents miners in a pool from retaining the reward?
From what I understand miners submit their hashes to the pool. What prevents a miner to disengage the pool as soon as she finds the right hash?

possible duplicate of What prevents a pool miner from stealing an entire block?

The payout address for the miners mined blocks is the pool's moderator address. If the miners are working on blocks with a different payout address (ex. their own), the pool moderator can tell and act accordingly by either banning them or simply ignoring their work.

They have to be mining the entire time on a block template created by the pool -- i.e. a block that pays the coinbase transaction to the mining pool and not to themselves.
The hashes they are trying depend on that template, so they can't change the template after they got a good hash, otherwise that would invalidate the block entirely.

authors: Юрий Дроздов


text:
What is a "serialized signed transaction"?
Shown in the gray area here, describing how to apply, I think, Segwit to a transaction (particularly a Bitcoin Cash tx).  The last section is titled "serialized signed transaction" however it doesn't appear to be the final form of the raw tx that you can copy and paste into a bitcoin cash wallet to use "sendrawtransaction".  Or is it the final raw tx form in spite of what it appears to be to me?
Example of final copy and paste form of a bitcoin cash tx:
Tx f0b9313fc11ce5ec5ac619f35dcf332530e99d185d8ee79b913bcc0b8b5e6df1

01000000
01
f5a6acfe637ceb57552e703bd4a3bb7ae10c75e81886646cf4ca641881daa4a3
00000000
6b48304502210088b72059940330faa94940a6f37b1be4d926a4d246abda8a1e6174a3a00659
040220
06e0627d6525afa275c4e730799ac11c037eed2e35a0839afcc62dfe710afb3d
4121
035e366a13be81aaada32f309b289ca26741fd55c582d6d8d394f9be7c7519974f
feffffff
02643fcb1d00000000
1976a9149b52b7016d89c5ad7645a8bbc34719b46131545288ac
0094357700000000
1976a914787b7c14737c3956456f40cf7abfca9b641afd5788ac
00000000

What the original webpage shows (but not for the same tx):

01000000
00
01
02
fff7f7881a8099afa6940d42d1e7f6362bec38171ea3edf433541db4e4ad969f
00000000
494830450221008b9d1dc26ba6a9cb62127b02742fa9d754cd3bebf337f7a55d114c8e5cdd30be
0220
40529b194ba3f9281a99f2b1c0a19c0489bc22ede944ccf4ecbab4cc618ef3ed01
eeffffff
ef51e1b804cc89d182d279655c3aa89e815b1b309fe287d9b2b55d57b90ec68a01
00000000
ffffffff
0220
2cb20600000000
1976a9148280b37df378db99f66f85c95a783a76ac7a6d5988ac
9093510d00000000
1976a9143bde42dbee7e4dbe6a21b2d50ce2f0167faa815988ac
000247304402203609e17b84f6a7d30c80bfa610b5b4542f32a8a0d5447a12fb1366d7f01cc44a
0220
573a954c4518331561406f90300e8f3358f51928d43c212a8caed02de67eebee
0121
02
5476c2e83188368da1ff3e292e7acafcdb3566bb0ad253f62fc70f07aeee6357
11000000

The one from the example website shows the "00" and the "02" being added near the beginning and that huge mess of stuff after the final output is mentioned.  Yet the first example I gave is the raw data straight from a "getrawtransaction" through the bitcoin cash wallet and it does not contain those things and yet is still considered to be valid.  Or is all that other stuff just basically "extra"?

Why does it not appear to be the final form of the raw tx?

I would like to comment on your "mess of stuff"... maybe not the best way to get support, if you don't understand what it is, and define it as such. I decode it here for you:
VERSION
 01000000

SEGWIT (BIP141): this is a segwit tx, marker=00
       (BIP141): flag=01

TX_IN COUNT [var_int]: hex=02, decimal=2
 TX_IN[0]
  TX_IN[0] OutPoint hash (char[32])
  9F96ADE4B41D5433F4EDA31E1738EC2B36F6E7D1420D94A6AF99801A88F7F7FF
  TX_IN[0] OutPoint index (uint32_t)
  hex=00000000, reversed=00000000, decimal=0
  TX_IN[0] Script Length (var_int)
  hex=49, decimal=73
  TX_IN[0] Script Sig (uchar[])
  4830450221008B9D1DC26BA6A9CB62127B02742FA9D754CD3BEBF337F7A55D114C8E5CDD30BE022040529B194BA3F9281A99F2B1C0A19C0489BC22EDE944CCF4ECBAB4CC618EF3ED01
  TX_IN[0] Sequence (uint32_t)
  EEFFFFFF
 TX_IN[1]
  TX_IN[1] OutPoint hash (char[32])
  8AC60EB9575DB5B2D987E29F301B5B819EA83A5C6579D282D189CC04B8E151EF
  TX_IN[1] OutPoint index (uint32_t)
  hex=01000000, reversed=00000001, decimal=1
  TX_IN[1] Script Length (var_int)
  hex=00, decimal=0
  TX_IN[1] Sequence (uint32_t)
  FFFFFFFF
TX_OUT COUNT, hex=02, decimal=2
 TX_OUT[0]
  TX_OUT[0] Value (uint64_t)
  hex=202CB20600000000, reversed_hex=0000000006B22C20, dec=112340000, bitcoin=1.12340000
  TX_OUT[0] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[0] pk_script (uchar[])
  76A9148280B37DF378DB99F66F85C95A783A76AC7A6D5988AC
 TX_OUT[1]
  TX_OUT[1] Value (uint64_t)
  hex=9093510D00000000, reversed_hex=000000000D519390, dec=223450000, bitcoin=2.23450000
  TX_OUT[1] PK_Script Length (var_int)
  hex=19, dec=25
  TX_OUT[1] pk_script (uchar[])
  76A9143BDE42DBEE7E4DBE6A21B2D50CE2F0167FAA815988AC

WITNESS TXIN[0] stack elements: hex=00, decimal=0
WITNESS TXIN[1] stack elements: hex=02, decimal=2
 WITNESS data[0]:
  47304402203609E17B84F6A7D30C80BFA610B5B4542F32A8A0D5447A12FB1366D7F01CC44A0220573A954C4518331561406F90300E8F3358F51928D43C212A8CAED02DE67EEBEE01
 WITNESS data[1]:
  21025476C2E83188368DA1FF3E292E7ACAFCDB3566BB0AD253F62FC70F07AEEE6357

 LOCK_TIME
11000000

So the 02 at the beginning indicates two inputs (TX_IN COUNT), and it's witness data is displayed at the end.


text:
What is the smallest sensible transaction?
While the smallest fraction of bitcoins currently implemented is the Satoshi (10-8 BTC or 10 nBTC (nano-bitcoins)), due to transaction fees there seems to be a minimum amount of BTC to be spent that is larger than one Satoshi. What is currently the smallest amount of BTC one can spend at comparably little to no fees. i.e. what is currently the smallest sensible unit of microtransactions?

I personally think that the most smallest and sensible transaction is at least 0.0001
HOWEVER NOTE: If you want a confirmation in 10 or 20 minutes, you will need to post a minimum transfer fee of 0.0001
So technically If you want to transfer 0.0001 to a account you will need at least 0.0002
If you want to transfer a bigger amount, the transaction fee will not need to be changed
e.g. If you want to transfer X amount to a account you will need at least X amount + 0.0001
I have tried to transfer 0.00005593 with no transaction fee, and there is still no confirmations: https://blockchain.info/tx/15ee5484920eed92457643a1709629d8ff579b15fc805b0060a9cf0efdcbb8ed
Transfer More faster = Pay a Higher transfer fee
Just to note: transfer fee same as Miners Fee same as transaction fee

Hi Astad, welcome to Bitcoin.SE. Please don't solicit donations for your answers; the reputation system is all the currency we need here.

@Astad Greg is fully correct, the Bitcoin.SE is not for collecting tips.

You're allowed to put your address in the profile, and you can put an address into an answer if it is relevant. A tipping address will never be relevant, and we reward users with up votes.


text:
Will old accepted blocks ever be removed?
Or are they kept forever such that the chain from the Generation Block will always remain verifiable?

Reaching consensus on which old blocks should be removed is very complicated. Bitcoin, being decentralized, requires you to check for yourself and add-up all the transactions from the very beginning.
If you keep a partial version of the blockchain, how do you verify that it is consistent with the entire blockchain? If you keep a partial blockchain someone could easily broadcast to you a blockchain with incorrect values, and there would be no way for you to understand whether those transactions are valid without checking the entire blockchain for yourself.
Fortunately however, the size of the blockchain isn't really an issue if you use a  Simplified Payment Verification (SPV) client such as MultiBit, as it's able to verify the integrity of the blockchain with just the block headers. This reduces drastically the size of the blockchain.
To answer your question, for bitcoin to work, old accepted blocks cannot be removed.

But won't we have a problem when old accepted blocks will simply increase, and increase, and increase...


text:
What is entropy mean in this context?
"The Bitcoin nonce forms part of the block header, which is used by miners to provide entropy as part of the Proof of Work process, to try and find a hash meeting the difficulty requirement."
Quote taken from the following article.
https://blog.bitmex.com/the-mystery-of-the-bitcoin-nonce-pattern/

It means randomness. In computing, if something a source of entropy means that means it is a source of randomness.

In order to prepare a valid block header, transactions from the mempool should be selected, merkle root should be computed, block version, previous block hash and difficulty value should be filled. Finally, time should be set and with nonce=0 hash calculations will start.
As far as I understand, what the author meant was: by incrementing nonce you continue to search for a valid hash, i.e. provide entropy. nonce is the fastest mechanism to try a new hash, until it maxes out.
Obviously, mining hardwares today uses mechanisms like extraNonce but it is a whole another issue.


text:
Block chain and its uses cases for a non-financial asset market
So i have been reading a lot about block chain technology and its use cases in the finance and cryptocurrecncy markets. One thing that guarantees blockchain's success in the cryptocurrency market is the prevalent financial incentive for the miners to validate blocks of transactions to make it part of the public ledger (they are rewarded with bitcoins). This financial incentive is associated with a financial asset block chain and partly explains the ongoing boom in the price of Bitcoin. However, as an  economics and technology enthusiast, i am curious to learn more about the inherent incentive structure that would prevail if the block chain is for a non-financial asset (let's say it stores patient's data- a use case for blockchain in the healthcare market)? How can we incentivize miners to validate and solve pending blocks in cases where a blockchain stores a non-financial asset and therefore giving a financial incentive seems impossible?
I would appreciate any resources(articles, books etc) that you guys can share below in the comments. I look forward to doing more research. Thanks!

It's far from obvious that any such system would be usable or secure. But in many places "blockchain" has become a alternative way of saying "cryptography", "digital signatures", or "distributed system" -- all of which might be useful.
Storing patient data "in a blockchain" is one of the more horrifying concepts that I've encountered. I've never seen a good reason for it and in fact there seems to be a perfect mismatch in the technology:  What Bitcoin invented was a way of building a public system of a sort that was previously trivial to build privately.  There are many issues with medical records, making them less private is not generally considered one of them. :)
To me a lot of the blockchain hype feels like "Bitcoin appears to solve a complex problem.  Peace in the middle east is a complex problem, thus the technology from Bitcoin can solve it!".

You probably should rethink the mining process. In bitcoin, a miner gets rewarded, because he is competing among other miners, and mining is expensive.
You could design the mining process drastically different. You could use a consensus system that does not depend on solving hard math, but that requires some secret (signed certificate) or other private asset, then provide theses "miners" to the system for free.
How to create trust in this system is a whole other question.
In the end, bitcoin is just one way to have a distributed trust system that allows for having publicly acknowledged transactions, nothing more.

Yeah that's what i thought as well; to have some sort of digital certificate or pvt asset available to the miners. Does that mean that we will have more of such digital assets as blockchain develops new use cases in other markets? And does that mean these digital assets would not be an overly-hyped bubble (what many ppl accuse Bitcoin of) but instead an integral part of the overall blockchain technology? I completely agree with the fact that it will be difficult to have the trust system going on for such newly created assets. Bitcoin didn't have such wide acceptance at one point.


text:
Etherium based tokens
When we say certain crypto currency is based over etherium, for instance TRON, does it mean they have used etherium code from github and modified as per their use case? Or is it something completely different?

I'm voting to close this question as off-topic because it would be better asked on the ethereum stack exchange.

It is completely different.
Ethereum offers a standardized way to create new tokens on its blockchain called the ERC-20 protocol. ERC-20 is not a piece of code, software, or technology. Rather, it is guidelines that facilitate the integration of various currencies.
Tron is an ethereum based token that means it is powered by Ethereum blockchain. It will use resources of the ETH blockchain Tron is not a blockchain started from scratch.

Actually ethereum based token uses Ethereum blockchain for transaction purposes and the code will be developed by their own according to their need  by using Solidity as the language most of the times.
But now Tron has come up with the mainnet that means they run their own blockchain and you can get the Tron explorer here https://tronscan.org/#/
If you observe carefully the public address of Tron it starts with "T" where as in Ethereum it starts "0x"

Does it mean they have used etherium code from github and modified as per their use case? Or is it something completely different?

It is something completely different.
It means that transactions involving the token happen on the Ethereum blockchain. You can see TRON transactions happening on the Ethereum blockchain here: https://etherscan.io/token/Tronix

So doesn’t it mean that TRON should be complying with etherium ecosystem, meaning TRON transaction should also be validated by etherium miners? But TRON has generated all its tokens at once and doesn’t allow mining on its currency.

Indeed, TRON cannot be mined, but TRON transactions happen on the ethereum blockchain and hence are validated by ETH miners. You can see the TX on the ETH blockchain that created TRON here: https://etherscan.io/tx/0x9299ff8878c8a22306be0b79a740b6dcc76a4dc5307717a292879923930ba9bc . Notice how it paid a fee of 0.019416159 ETH for gas.

So basically Tron company pays etherium miners for validation of trx transactions?

@Safdar Mirza Anyone sending TRON tokens to anyone else pays ethereum miners for the TX. If you send TRON to someone named Bob, you pay the TX fee in ETH.

@SafdarMirza Just like if you send ETH to someone you need to pay an ETH fee, since the transaction happens on the ETH blockchain. If you send an ETH token like TRON to someone you need to pay an ETH fee since the transaction also happens on the ETH blockchain.


text:
How does the bitcoin network remove duplicate blocks being generated by multiple miners?
Say there are two minersA&B and each of them have produced the next block almost at the same instant. In this situation how is the network going to decide which one is the main block and abandon the other block?
Also, say if the txns contained by the first block are T1,T2,T3 while txns in the second block contains T2,T3,T4,what is going to happen to the uncommon transactions if either of the block get abandoned, i.e.T1or T4?
I am sure that from the txn pool, multiple miners would be picking up the same txns and start racing for the next block creation and insert that txn in the new block.

Possible duplicate of What happens to extinct blockchains, and transactions inside of them? or Strongest vs Longest chain and orphaned blocks

You're right on track to describing what is called a "orphaned" block. Check the answers on this thread for some explanations and discussions about it.

Also see: https://bitcoin.stackexchange.com/q/8172/5406, https://bitcoin.stackexchange.com/q/12427/5406


text:
Is it possible to create a wallet service, which doesn't have all the blockchain downloaded?
Is it possible to create a wallet service, which doesn't have all the blockchain downloaded? Like not running a full node itself?

Yes, simply because the network is designed that you can broadcast transactions to it by signing it with your private key on your machine.
You only need to find the API service that exposes endpoints to interact with the network.
Then maybe a couple of years of programming and you'll have your wallet service:)

Yes it is possible. But as mentioned above there are trade-offs.
I do think it is better to not download the full blockchain when you want to prototype something quickly or just play around.
For that I know Bcoin has a full node you can point at (this is the pruned node)
There are some other services too like https://bitcore.io/ (I've never used it)

Without any security trade-off vs. running validating nodes, there is no way to create a wallet-service without downloading and validating the blockchain.
If SPV node security trade-offs are acceptable, you may consider running the wallet service with these.
SPV nodes do not fully-validate the blockchain, and only download the longest header-chain. However, since they only validate POW in the header-chain, and do not index all transactions (only those related to the wallet service addresses), they need to obtain a proof that a tx of interest is confirmed via. another full-node peer. This proof can be delivered a merkle-proof, which represents a specific branch of the merlke-tree beginning with the txid of interest, of which the root is committed to each block header.
The security trade-off for SPV nodes is two-fold:

Privacy: Since the wallet service is interested in tx's pertaining to specific addresses, some information about addresses will necessarily leak to the queried full-nodes.
Potential for omission: Peers can always remain silent about specific confirmed transactions without the SPV client being able to prove this, potentially requiring cross-comparison heuristic across validating peers.
A SPV client does not validate any consensus rules, thereby not knowing whether the chain/branch it is following correctly validates according to the validation rule set the user supports.

so any waller service provider, like Electrum, let's say, has all blockchain on their server 200+ gb ? I mean, that costs a lot, which means that sooner or later the service of wallet itself will stop being free? Is it correct?

It represents the cost of validating your transactions yes. Although once validated and indexed the chain can be pruned to reduce storage. Validating for others without revenue is not sustainable longterm, unless there are other ways the service is cross-subsidizing the validation.


text:
bitcoin back-end blockchain storage
bitcoin uses blockchain
so blockchain is peer to peer,
every peer stores the data

so I wonder where does the data of all the bitcoins is stored?
who is peer in case of bitcoin?
so that peer gets data related to bitcoins all over the world?

as the bitcoins grow isnt it becomes slower and slower to retrieve information?

Each non-pruning full node (peer) stores a complete copy of the blockchain - pruned nodes store a complete copy of the current state, but may not have all historical blocks available.
When a node validates a transaction or a block, it is only validating it against its local view of the blockchain - this means that looking up data is pretty fast, since all of it is available locally.
As the blockchain grows, access time for most data still remains mostly the same due to the nature of the key-value store used by bitcoind - look up times for a key value store are roughly constant, although data that is cached in memory can naturally be accessed faster.

To put it simply, blockchain is essentially a history of transactions, with built in measures to confirm that this transaction history cannot be altered. That being said, transactions can be either spent or unspent. Spent transactions are transactions that have already been used as inputs in another transaction. Unspent transactions are transactions that have not been used. It is these unspent transactions that make up your Bitcoin balance. The key thing to understand from this is that you don't actually own a wallet that has Bitcoin in it, you own keys which allow you to spend these unspent transactions by the process of signing.
Since the blockchain is a history of all transactions, it does indeed grow in size and requires more disk space as new blocks are mined. As of today, the Bitcoin blockchain requires around 236 GB of available disk space to store the blockchain data. There are ways in which one can operate a node that does not require the entire history, but that's a topic for another question. Having the entire history of all transactions is useful for tracing the history of a given transaction. If a transaction is going to be used as an input for a new transaction (i.e. you want to send BTC, so you will be spending one or more of your unspent transactions), then the input's prevhash property, or the hash of the transaction in which the coins we are going to spend were received to the given address, can be validated, and the blockchain data can also be queried to ensure that this input has not already been spent. At the end of the day, though, the only thing that says that you have BTC in your wallet are the unspent transactions (abbreviated UTXOs).
We could get into a lot of other topics here, like the fact that the hash of the next block to be mined is based on the hash of the previous block, which can be followed back all the way to the genesis block and ensures that transaction history cannot be altered. We could also get into how the block data propagates through the network, and other important matters like the 51% attack, but the key takeaway I wanted from this response to your question is the notion that your wallet is actually just a keychain, and the keys are what allow you to sign the transactions you've received when you wish to spend them in a new transaction.
So in conclusion, while it seems so simple to say "Well gee, I've got 0.5 BTC, just store that in memory and let me use my money" there is actually a lot more going on behind the scenes, which is important because its what allows Bitcoin to be the trustless distributed and decentralized ledger that it is.


text:
api limit workaround
Are there any ways to avoid limitation for api calls (5/sec)?
I need the info about transactions and balance (of certain account), UTXOs and the ability to broadcast my transaction.
Currently I am using public blockchain explorers such as
https://www.blockcypher.com/
https://chain.so/
https://etherscan.io
However they have limits on their calls, which is unacceptable for cases if my service in use of at least 1000-2000 people.
I am begginer, so after some surfing I understood that the only way to tackle that issue is by saving the info in my own database or run my own full nodes (for each currency I have - eth/etc/bitcoin/btc/doge/dash.. etc)
which might be pretty expensive and time-consuming.
Can you suggest any good solution?
Thank you!

Looks like you've already found the solution, which is to run your own nodes. Free services have API limits for a reason, and bypassing them is likely against the terms of service. Moreover, you should not be relying on a third party to confirm such things - if they lie to you, you have little recourse against false balances and withdrawals.

@RaghavSood seems like cashing data about my transactions in my own database (mapping account_address => array of transactions) would be much faster
Even if I had my own node, it would take a lot of time to scan all blocks and receive the info I need, Idk how it is implemented in etherscan or chain.so but seems like they use special data structures etc (since I didnt find the method in JSON RPC to receive transactions by address)

All the APIs you mention essentially extract all the information block by block into separate DBs and query it - You can check the source for open source explorers such as Insight to get an idea of how they are structured.


text:
How can I buy Bitcoins with Australian Dollars?
Please! I just want to get them! How hard does it have to be? I've spent some 5 hours today trying to figure it out. I am in Australia.

Why the close vote?

possible duplicate of How do you obtain bitcoins?

This question answers the more general question "How do you obtain Bitcoins?"  Most commonly, people use a Bitcoin exchange to exchange local currency for Bitcoins.
Here is a list of exchanges split by currency and whether they're currently active or not.

At this time, MtGox's fee starts at 0.6% and decreases with your trade volume over the past month.

Don't use MtGox!  It has big problems with withdrawals of USD and Bitcoin.

LocalBitcoins.com has buy and sell online in AUD and also AUD cash trade:
https://localbitcoins.com/country/AU
If you buy from a trader with good reputation history and fast response times you can get bitcoins within an hour.

In Australia there are currently a number of options for buying Bitcoins. Below is a list of exchanges that I am aware of that accept AUD.
Fixed Price Exchanges: (Create order at fixed price and transfer funds after order is created. Usually same day service)

Bit Innovate Accepts over the counter bank deposits (our site)
Spend Bitcoins Accepts over the counter bank deposits
bitXoin Accepts over the counter bank deposits

Another good resource is https://en.bitcoin.it/wiki/Buying_bitcoins which usually contains up to date information on all the ways to buy bitcoins in all countries.

https://www.spendbitcoins.com/buy/ - You can deposit at any NAB, Commonwealth Bank, Westpac or ANZ bank across australia

This is identical to another answer from March 7th (by someone with the last name as you). :)

I have to send a big shout out for the crew at my two favorite exchanges bitXoin [https://www.bitXoin.com/] and spendbitcoins [www.spendbitcoins.com.au] as they are both local to me (Gold Coast) and fast, safe and professional to deal with.
In particular, if you want to buy bitcoins over the counter and you are in the Gold Coast area then visit the bitXoin offices there at Chevron Renaissance Centre in Surfers Paradise.
Prices are very low (basically lower than Mt. Gox prices) and processing happened within an hour or two depending on what time I get the deposit into the bank (mornings seem slightly faster).
Disclaimer: I have no affiliation with any bitcoin companies and my opinion is based on over 10 seperate transactions since start of 2013. Hope this helps.

These people are Australian-based, and accept AUD.  They also have a merchant service.  I haven't tried them yet, maybe when the price goes down again...
http://coinjar.io/

bitcointrader is becoming a favored Australian exchange for cash over the counter deposits offering competitive rates and good service
https://bitcointrader.com.au

I think WeExchange accepts AUD.
However I personally wouldn't recommend it, since for me it has shown some worrying login problems.

Try using http://purchasebitcoin.com.au they are Australian owned and they deliver in less than an hour.

Here's a list of BTC/AUD exchanges:
http://exchangewar.info/coinprice?btc_aud

You can also Buy Bitcoins at BTC Markets an Australian Bitcoin Exchange.


text:
How can I enable more GPUs in Ubuntu for poclbm?
I have an Ubuntu set up (11.10) and 2 ATI Radeon HD 6870 cards. It detects one, but not the other for some reason when I try to run poclbm.
When I run lspci, it finds both cards.
Any help?

Try the command  display=:0  .

Maybe this is not going to help you, but... Ubuntu is a  distribution strongly oriented towards casual users, are you sure it's a wise choice to use it for mining? Couldn't you just use, for example, debian?

lspci lists PCI devices. ./poclbm.py lists OpenCL devices. If the former finds the device but the latter does not, your second GPU must not be registering as an OpenCL device.
Ubuntu 11.10 has a notorious reputation for multiple-GPU bugs. (See here and here.) I personally have had issues with 11.10 mining that were resolved simply by switching to another release. I would suggest you instead use Ubuntu 11.04 (Natty Narwhal); it is generally regarded to be the most reliable Ubuntu version for mining.
If that is not an option, or installing 11.04 doesn't fix the problem, try the following steps:

Uninstall whatever version of Catalyst/SDK you have (make sure to remove all configuration files) and install
Catalyst 11.6 and SDK 2.4.
Run aticonfig -f --initial --adapter=all again. Make sure it runs without errors.
Run aticonfig --list-adapters. You should see two.

Those steps should fix any configuration issues. If your problem persists, it's either a hardware issue (or an Ubuntu 11.10 issue).

Try not booting into graphical mode at all, just command line. Leaving compiz/gnome/gdm/drivers off should alleviate most confusion, as the cards should both be in default modes (and one in VESA/VGA) and for the most part will be untouched by system specifics (more like normal PCI devices)

Unfortunately, that won't work; ATI OpenCL under Linux requires an X server running.


text:
Are competing blocks a problem to weak participant of the network?
Let's say Alice has two CPUs, and Bob has only one. Let's assume Alice and Bob are the only miners in the Bitcoin network.
What will happen if Alice did the following:

Calculate the nonce for the next block and send it occasionally.
Whenever Bob solves and transmits a block, DON'T accept his block, but instead try to solve another block at the same height, and a successive block.
When done calculating, send both blocks to the network. They should be accepted instead of Bob's transaction, and since you're 2 times speedier than Bob, in average you'll be able to prevent Bob from mining coins.

While this is a somewhat artificial example, I think that it might represent a real problem. A group of strong participants can prevent weaker players from mining, even if this group does not control the majority of CPU resources in the network.

This isn't something that can happen unintentionally. If everyone plays by the rules, someone who has x% of the hashrate will find x% of the blocks, no matter how small or large x is (of course, for very small x the variance will be substantial, but without any change in the expectation).
You can attempt a double spend even without having >50% hashrate, but the probability of success is small. The chance improves as your hashrate approaches 50%. What's special about >50% is that you are guaranteed eventual success, no matter how many blocks the receiver waits.
There's a little-known hashrate amplification attack (discussed here and here) that allows you to find more blocks than your hashrate normally allows, which doesn't require >50%. It still requires a relatively large hashrate, about 41%. For example, with 46% of the hashrate you can get 51.29% of the total blocks. For >50% hashrate you get 100% of the blocks.

Can you give a reference to the little known attack?

-1 for "little known attack" without any kind of link or reference.

@Lohoris That was a bit harsh. Anyway I added a link.

@MeniRosenfeld harsh? sorry, I just posted it as a fact, nothing personal.

@Lohoris I meant that downvoting for this reason is harsh.

@Lohoris - for the record, I agree. It deserves a comment, not a -1.

@MeniRosenfeld, yep, this is more or less what I had in mind. Note that those "Cartels" don't have to do that intentionally. It can be one strong player releasing two blocks at a time instead of one, for efficiency reasons, getting a similar result. What bothers me is, that it can cause the bitcoin network to be ruled by few big cartels, impenetrable by layman users, which will make more similar to banks-controlled economy than we want it to be.

I miss your point. I put the -1 because it lacked a source, now she added the source and I changed it to +1. That's how it is supposed to work.

@Lohoris: We understand that, what we're trying to say is that my transgression was too minor to have deserved the initial downvote. 0 -> comment -> fix -> +1 would have been more appropriate than -1 -> comment -> fix -> +1. Anyway, I'm male.

@MeniRosenfeld oh, sorry for the misunderstanding :)

@ElazarLeibovich: Honest miners release blocks immediately, lest they risk losing the block's reward. The discussed effect isn't a result of randomly releasing two blocks at a time if they happened to be found quickly, it can only be a result of intentionally holding on to blocks and releasing them in strategic circumstances.

That is essentially a 51% attack. It is a very real, but unlikely threat to the Bitcoin network. Historically as it turns out, it is more lucrative to simply add more processing power to the network than fight it.

It could happen without intention. If there are many strong players which calculate really fast, slower player would rarely be able to mine any coin. I didn't do the math, but I'm not sure you actually need 51% to make such an "attack" effective.

@ElazarLeibovich That's how it is at the moment.  If you only have 1% of the hashing power, you only get to mine 1% of the blocks.  But that's different than >50% of the network deliberately ignoring blocks from weaker miners.

@ElazarLeibovich You actually need 51% to make such an attack effective. Otherwise, you lose more than you gain with this attack. If the rest of the network finds a block before you find a second block, you lose the first block you found.

@DavidSchwartz you lose more bitcoins than you gain, but you can psychologically deter small players from mining, which would leave the mining fields to big and rich players only (say, with the resources to use special purpose hardware), setting an effective lower bound for CPU power to begin mining, leaving the mining field more centralize.

@ElazarLeibovich: mining already is exclusive to special purpose hardware, AFAIK mining with normal GPUs costs more in electricity than the bitcoins produced.

@Lohoris: No, it doesn't. ATI series 5+ cards are still profitable to run and even to buy used (maybe not new), and that's probably were most of the network hashrate comes from. This is starting to change as special-purpose products are now entering the market.

@ElazarLeibovich Mining is essentially a zero-sum game. The block reward is fixed and the block discovery rate is nearly fixed. Any strategy that causes one miner to lose more than they gain necessarily gives the other miners a better shot. It's hard to see how that would deter anyone.

@DavidSchwartz As I see it, one miner may be willing to lose his rewards, to ensure that no client with less than X CPUs will mine. Similar to big company selling items below their net worth, so that competitors will move to other business.

@ElazarLeibovich It doesn't matter whether they're willing to do that or not, it just plain won't work. If the miner has less than 51%, this strategy is a net loss to him. So all it does is reduce the difficulty and ultimately increase everyone else's mining returns. If you mine a block and it doesn't wind up in the longest chain, it's no different than if you never mined the block at all, which is no different than if you weren't mining at all.

It appears that some strongest players - e.g. manufacturers of ASIC devices - purposely give up their chance at monopoly in exchange for immediate profit (sell their devices to multiple customers) - precisely to increase the reliability of the network.
While the network is vulnerable to the "51% attack", its result will be an immediate, catastrophic and permanent crash of the bitcoin economy. All of the investment in hardware that let whoever did it achieve the 51% hashpower will be irrevocably lost - as they will be able to dominate the market for a worthless resource, compromised bitcoin being deprived of any value.
The big players understand it and willingly give up a part of their hashing power, simply to keep Bitcoin strong, reliable, and desired - keeping the prices up. That way they produce less but earn more simply because that unit is more valuable.
In other words, it is in best interest of anyone producing or owning a lot of bitcoin to keep the bitcoin network running smoothly = keep value of bitcoins they produce/have high. Bitcoin is a network of trust; break that trust and it loses all value.
Such an attack would be possible e.g. by a financial institution with a grudge against Bitcoin, or some government. It would be costly but its only returns would be in whatever profit destroying bitcoin entirely would bring. Any immediate profits of corrupting the transaction process would be relatively small, and very short-lived compared to the damages (including own hardware becoming worthless) - so it is in best interest of anyone holding any power capable of doing it not to do it - a powerful economic incentive against this.


text:
What happen if the Bitcoin network is down, or all miners stop keeping records?
I am not sure I understand Bitcoin very well. What I understand is that Bitcoin is there because of the network.
What happens if the network is down for any reason?
What happens if the miner that keeps my records of Bitcoin dies or doesn't want to open his computer again?

Bitcoin network works on a Peer-to-peer mode, so "taking the network down", would require taking at least a good portion of the Internet. Should something like this happen, Bitcoins might not be the biggest of your worries.
A Bitcoin miner stores little to no information about the network itself. It works in a simple terms of fetching data, calculating some hashes and returning results. It does not need much more than that, so miners going offline for awhile wouldn't hurt the network much, asides slowing down block generation for awhile.
A Bitcoin client on the other hand stores all the data from the Bitcoin network. Should it go offline, it still stores all the data on the hard drive and will try to reconnect when it can. Should a good chunk of the network go offline, the blockchain might fork, as each part of the network would try to work only with the data it possesses. Some parts of the network might see only a part of the transactions, while others would see other transactions. When such "islands" would meet, all the clients will try to establish which blockchain is the longest. The shorter blockchain will have all its transactions extracted from it and if there is no double-spend, those transactions might be included in future blocks.
All in all, it is very hard for the Bitcoin network to go down, and the main Bitcoin client is prepared for possible network segmentation.

Is there a time limit for such a "transaction extraction" from the shortest blockchain, once the "islands" reconnect? If a small country gets disconnected from the rest of the globe yet keep Internet working internally for, say, 1 month - would all their bitcoin transactions be honored by the rest of the bitcoin network, assuming they don't use lolally mined coins?

@JoePineda I don't see why not - as long as a transaction is not invalidated by one that is in a block, they should be added to the list of transactions to be processed (which in turn might reject transactions without fees and otherwise bending the rules [low-output, etc]).

Nothing happens. The longest chain of blocks in existence, so long as it builds off the latest checkpoint) is always the valid chain, no matter what. So long as at least one node brings it back eventually, there's no problem. (And you can keep it yourself if you're particularly worried about it. If you're running the standard client, you already are.)
Unlike a bank account, your Bitcoin balance doesn't have to exist in any particular place to be valid. The miners create the mathematical relationships that prove it's valid such that anyone at any time can tell that it's valid just by looking at the mined data.
If you connected to any Bitcoin node right now and presented a longer chain of blocks (so long as it included the last checkpoint) than they already had, they would switch over to your chain of blocks and it would become the official chain. It wouldn't matter that prior to introducing it, you had the only copy. It's mathematically valid, so the network would accept it.

+1 for "And you can keep it yourself if you're particularly worried about it.". In fact, if you run the standard client, you are doing that already.

@Thilo: Thanks. I added that to the answer.

Miners add new blocks, but every node keeps a copy of each complete block.  There are this many nodes (i.e., tens of thousands):

http://www.weusecoins.com/globe/

Once a block is announced to the network, that miner no longer needs to do anything -- that block has already been signed and gets propagated by peers over the network.


text:
What could be the impact of the distribution of "tainted" Bitcoinica coins?
The hacker was distributing them in IRC recently, and sent some to the Bitcoin Faucet. Is this a reliable method for evading the "Bitcoin Police"?
Here's a forum thread discussing the distribution and a pastebin of the IRC conversation. Pasted below is just the beginning of the pastebin content:
<BitcoinicaHacker> Who wants free bitcoins courtesy of bitcoinica?
<grepix> who doesn't!
<BitcoinicaHacker> post your btc addr
<nanotube> i think bitcoinica wants free bitcoins courtesy of bitcoinica
<Phraust> oooh, i'll take some: 18LSrqYfUwt4q52CvSWXkSqNiDMGDADAao
<BitcoinicaHacker> d43282f1ec433cb896ddf7d4a88faa4a202c97ac6e60568eaecfd1df53d82ef6
<Phraust> sweet, many thanks.
<OneMiner> 121VuNzJi7ihM6FTv28oruemfw4fp4rvPZ I'll take a piece of that. :P
<BitcoinicaHacker> f87f87a6e053157140bd509952c999e56344fe4fa90eaf47288bbcdda7689514
<BitcoinicaHacker> 74358a453321026b197549a250c3aa65b60187f8d4ba4578de1b1422eec2937d
<OneMiner> Thank you very much.
<b00bsman> BitcoinicaHacker, wie ist der Kuchen?
<brwyatt> 12KTki1xe5xVoQneEZy2CED8Ep87ifubx7 I'll give it a try.
<brwyatt> He really wasn't kidding. o.O
<BitcoinicaHacker> 8694268cfe0aa51d7ecb3749b8f4bc8ebe7c56cc8e920f1b7b34862f9992e004
<OneMiner> Ya, seems legit.
<grepix> the BTC def showed up, but for all we know this is just a lazy trolling :D
<brwyatt> yeah
<OneMiner> The balance of the account suggests otherwise.

Not sure how this would be evading.  The thief was not exchanging coins or trading, is was a one way transfer.  There was no "evading" of anything, it looks like.

The suspicion is that his motive is to mix as many of the stolen coins into the Bitcoin economy as possible, so that people cannot assume that Bitcoins traceable to the theft were obtained illegitimately. The people who receive these coins will presumably spend, mix, and deposit them.

lol, +1 for "seems legit"

I don't think there's really any need to do this to evade "Bitcoin police". Bitcoins are fungible and one is as good as another. Any attempt to track tainted Bitcoins is, at least in my opinion, doomed to fail.

[Imagine] if the FBI regularly published a list of serial numbers of currency that would no longer be honored. Banks would refuse to accept bills on the list, and soon so would grocery stores and so on. That hundred dollar bill you got from the bank, now sitting in your wallet, could appear on that list at any time because the person who deposited it at the bank right before you withdrew might have stolen it.
Think about what using currency would be like in such a world. Could you even have ATM machines? In fact, it would be the death of cash -- forcing people to use cash only for small amounts of money they could afford to lose. Such "tainting", if it hit the Bitcoin world, would similarly be the death of Bitcoin if it caught on in any significant way. - Tainted coins - Who dictates that a coin is tainted?

This also suggests an interesting way to defeat any attempt to taint Bitcoins, assuming such an attempt wasn't doomed anyway. Just take a chunk of the tainted coins and start transferring them to random, active accounts. The standard client doesn't make it particularly easy to quarantine coins nor does it hold newly-received coins separately from old ones. So when you make your normal payments, you pretty much can't help but spend some of the coins you received unsolicited. Soon lots of innocent users would be spending "tainted" coins and innocent merchants would be redeeming them at exchanges, which have to resell them.


text:
List of current opcodes?
Anyone know how / where to run
enum optypecode

(or some other method) to get a list of current opcodes? Like this result...

https://www.slideshare.net/gvrooyen/20140220-bitcoin/34-We_just_used_4_opcodesenum

This is the list of opcodes supported by Bitcoin Core v0.14.0:
https://github.com/bitcoin/bitcoin/blob/v0.14.0/src/script/script.h#L46L187

Thanks. That appears to be the section of code from the screenshot.

I don't think there is a command you can run, besides looking at Bitcoin's source code. (look for enum opcodetype)
Note that a lot of the opcodes listed there

are disabled to reduce complexity, (OP_CAT)
change meanings depending on which softforks are applied, (OP_CHECKLOCKTIMEVERIFY and OP_NOP2 have the same opcode) or
may have no meaning in a script. (OP_SMALLINTEGER)

To get a list of ones that can actually be used without making a script fail, you need to look at the code that actually evaluates scripts. (look for Bool EvalScript)
Here's a list of legal opcodes, as of time of writing:
(direct push, opcode 0x01-0x4b)
OP_PUSHDATA1
OP_PUSHDATA2
OP_PUSHDATA4
OP_0-16
OP_TRUE
OP_FALSE
OP_1NEGATE
OP_CHECKLOCKTIMEVERIFY
OP_CHECKSEQUENCEVERIFY
OP_NOP
OP_NOP1-10
OP_IF
OP_NOTIF
OP_ELSE
OP_ENDIF
OP_VERIFY
OP_RETURN
OP_TOALTSTACK
OP_FROMALTSTACK
OP_2DROP
OP_2DUP
OP_3DUP
OP_2OVER
OP_2ROT
OP_2SWAP
OP_IFDUP
OP_DEPTH
OP_DROP
OP_DUP
OP_NIP
OP_OVER
OP_PICK
OP_ROLL
OP_ROT
OP_SWAP
OP_TUCK
OP_SIZE
OP_EQUAL
OP_EQUALVERIFY
OP_NUMNOTEQUAL
OP_1ADD
OP_1SUB
OP_NEGATE
OP_ABS
OP_NOT
OP_0NOTEQUAL
OP_1ADD
OP_1SUB
OP_NEGATE
OP_ABS
OP_NOT
OP_0NOTEQUAL
OP_ADD
OP_SUB
OP_BOOLAND
OP_BOOLOR
OP_NUMEQUAL
OP_NUMEQUALVERIFY
OP_NUMNOTEQUAL
OP_LESSTHAN
OP_GREATERTHAN
OP_LESSTHANOREQUAL
OP_GREATERTHANOREQUAL
OP_MIN
OP_MAX
OP_ADD
OP_SUB
OP_BOOLAND
OP_BOOLOR
OP_NUMEQUAL
OP_NUMEQUALVERIFY
OP_NUMNOTEQUAL
OP_LESSTHAN
OP_GREATERTHAN
OP_LESSTHANOREQUAL
OP_GREATERTHANOREQUAL
OP_MIN
OP_MAX
OP_WITHIN
OP_RIPEMD160
OP_SHA1
OP_SHA256
OP_HASH160
OP_HASH256
OP_CODESEPARATOR
OP_CHECKSIG
OP_CHECKSIGVERIFY
OP_CHECKMULTISIG
OP_CHECKMULTISIGVERIFY

Bitcoin Wiki has an excellent page on this subject, if you're trying to figure out what is possible in Bitcoin script.

Thanks for the detailed answer and links. Very helpful. (I don't have enough reputation to up-vote your answer)

Many thanks again. Just wondering, where did you get the list of legal opcodes (without hex values)? Did you draft it yourself or is it available somewhere? It's very handy to have it cleanly formatted like that.

@ColmanMcMahon I had a copy of interpreter.cpp. I used grep to find case statements and sed to cut it down. This didn't catch every opcode, because a few push opcodes are handled differently. As for hex values, I can add that to the listing if that's helpful to you.

Thanks. Thanks really helpful. The way you have it here is great for what I currently need (presenting opcodes on a slide). I'm just thinking of when I have to revise the list in the future.

For version 24.x: https://github.com/bitcoin/bitcoin/blob/24.x/src/script/script.h#L69


text:
Curious about the Math that makes Bitcoin/Blockchain work ! Any good resources to learn it?
A bit of a background about me ; Computer Engineer but during my studies i didn't dive too deep into the maths , especially the maths that makes the blockchain and cryptography work
looking for advice from any senior or experienced researchers or practitioners in this field to give me some advice and point me towards the correct direction
E.g one example of the type of math i am looking for = so you know how the term Elliptic Curve Cryptography (ECDSA) keeps coming up all the time ?
i know very little about how exactly are the private keys extracted from an elliptic curve - i'd like to understand how exactly are we able to derive something as vital as a wallet private key from an elliptic curve .. how does this work to help Bitcoin or any blockchain become secure ? That's what i want to understand through the math !
if you can outline exactly which math topics i need to revise and learn - i would be thankful !
P.S : suggestions for any useful and relevant online courses are most welcome !

ecdsa allows people to sign transactions to prove that they authored them and not anyone else without revealing their private key. https://www.maximintegrated.com/en/design/technical-documents/tutorials/5/5767.html does this help?

I'd recommend the first three chapters of Jimmy Song's Programming Bitcoin book (also available to purchase on Amazon and other book sellers). Chapter 1 goes through introductory finite fields math, Chapter 2 explains elliptic curves including the elliptic curve Bitcoin uses (secp256k1) and then Chapter 3 covers elliptic curve cryptography including how to create and verify a ECDSA signature.

I would suggest starting with Jameson Lopp's Page and River Learn, which has a glossary defining terms like ECDSA, secp256k1, Digital Signature Algorithms, SHA-256, Bitcoin Script, and Proof-of-Work.


text:
What should I include in the description of a Bitcoin Core pull request?
What should I include in the description of a pull request (PR) that I open to the Bitcoin Core repo to help reviewers quickly get up to speed and efficiently review and test the PR?

There is currently some (limited) guidance in CONTRIBUTING.md.

The title of the pull request should be prefixed by the component or area that the pull request affects

e.g.  consensus: Add new opcode for BIP-XXXX OP_CHECKAWESOMESIG

The body of the pull request should contain sufficient description of what the patch does, and even more importantly, why, with justification and reasoning. You should include references to any discussions (for example, other issues or mailing list discussions).

It is difficult to explain exactly what should be in the PR description because it will depend very much on what kind of pull request it is. (The description for a new pull request should not contain any @ mentions though.) A small documentation PR will just need a sentence or two explaining the change(s) and the rationale for making the change(s). At the other extreme a consensus change will need a long, detailed description explaining the historical context, linking to prior discussions (e.g. BIPs, mailing list) and convincing reviewers that there is community consensus for this change.
However, the PR author should seek to make the PR as easily reviewable for reviewers as possible. Ideally reviewers should be able to understand what the PR is trying to do and why from the PR description and not have to explore chains of PRs to get the required context. Also pointers on what the reviewer should look out for (especially if there are specific security considerations) or guidance on how the reviewer could test the PR may also prove useful. If it is easily reviewable it is more likely to be reviewed.
fanquake supplied some additional guidance in this PR comment:

The PR description (and commit message) could include:
What is being changed and why is it equivalent to previous checks? When did this change?
e.g. Qt 5.12 isn't the only version of Qt we build against, and our minimum supported is still 5.9.x. If the version of Qt being built against is irrelevant to this change, why is that the case? Link to relevant upstream changes if applicable.

How did you verify / how should reviewers verify that this is a no-op? e.g. "Given that this is a change to a configure check, the binaries produced before and after this change should be identical. You could show that to be the case, maybe using build-for-compare.py."

Adding more information not only means that more contributors can, or will be more likely to review, but any security related change should be better summarized than "some changes happened in a dependency header".

The PR author should also consider making the PR easily testable for new/less experienced reviewers especially if it isn't a complex PR that requires a vast amount of contextual understanding.
A good example of a PR description for less experienced reviewers is this one from Jon Atack. It lays out exactly what a reviewer needs to do to verify that the functionality works as described including the exact commands a reviewer can run.

Testing and review welcome! How to test:

to run the full live dashboard (on Linux): $ `watch --interval 1
to run the full dashboard: $ ./src/bitcoin-cli -netinfo 4
to see the help: $ ./src/bitcoin-cli -netinfo help
to see the help summary: $ ./src/bitcoin-cli -help | grep -A4 netinfo

There is additional guidance from Jon Atack on contributing pull requests to Bitcoin Core here.


text:
How can I spend from a P2TR address on Signet with the Bitcoin Core wallet in 22.0?
Apparently (credit 0xB10C) there are only 20 key-path and 5 script-path spends of P2TR outputs on the Signet blockchain today (July 7th 2021). How can I increase this number today with say the Bitcoin Core wallet in the upcoming 22.0 release? If there are multiple ways (of varying levels of complexity) please outline them all.

This is a draft answer (incomplete).
To get set up on Signet ie sync the Signet chain and claim some Signet Bitcoin, follow these instructions. (You can run a Signet node in parallel with your mainnet node, ie same hardware)
You now have funds at a non-P2TR (i.e. SegWit v0, bech32) Signet address. Now you need to generate a P2TR address to send funds to so you have funds at a P2TR address (so you can spend from it).
You can't generate a P2TR (SegWit v1, bech32m) address in the wallet using getnewaddress:
./bitcoin-cli -signet -rpcwallet=insert_wallet_name getnewaddress "" "bech32m"

returns
error code: -12
error message:
Error: No bech32m addresses available.

So you need to construct a Taproot descriptor manually and then import it into your descriptor wallet.
An example Taproot descriptor is:
tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5,{pk(fff97bd5755eeea420453a14355235d382f6472f8568a18b2f057a1460297556),pk(e493dbf1c10d80f3581e4904930b1404cc6c13900ee0758474fa94abe8c4cd13)})

which describes a P2TR output with the c6... x-only pubkey as internal key and two script paths.
If you only want to do a key path spend you only need the equivalent of:
tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5)

You can import a tr(xprv/insert_xpriv_here) descriptor so that your descriptor wallet has the private key to spend from it.
To do: Send signet Bitcoin to this descriptor wallet, spend back to a SegWit v0 address (sendtoaddress) Include generation of xprv?
TBC
This was also discussed on the bitcoin-dev mailing list.

Can you add an example for how to import the descriptor? I'm trying importdescriptors "tr(c6047f9441ed7d6d3045406e95c07cd85c778e4b8cef3ca7abac09b95c709ee5)" (in the console of Bitcoin Core 22.0) but I always get Error parsing JSON.

@Andreas: Let me know if "Import a taproot descriptor (of the form "tr(KEY)"), as active descriptor (with active=true), where KEY can be a tprv.../* or any other supported key expression." from Pieter's mailing list post resolves your problem. Thanks

The importdescriptors RPC takes as argument a list of objects, each with a decriptor and a few other parameters. Look at the RPC help (help importdescriptors) and the examples there.


text:
Can I sell bitcoin worth five million dollars or more and how can I?
I bought 200 bitcoin in the year 2012 and I've come to the point where I feel I need to withdraw some of it. But I'm having some difficulty doing that. How can I withdraw a large sum of bitcoin and where? An answer preferably includes a step by step guide.

The first fifteen exchanges here are famous and credible. Choose one of them, open an account, verify your ID (KYC would certainly be required), add your IBAN number, deposit Bitcoin, sell it, withdraw it to your account.

Keep an eye on the tax in your country. In Germany for example you have to store Crypto on one exchange or wallet for about one year, so you dont have to pay taxes.
But if you just once traded crypto in that year you have to pay tax for the profit you made.


text:
What is the maximum size of the memory pool?
The memory pool holds unconfirmed transactions in RAM. It seems that memory pool storage could overflow if no block is solved for a very long time and many transactions are published within a short interval.
In browsing the source code, I found no mention of a cap on the memory pool size:
https://github.com/bitcoin/bitcoin/blob/v0.10.1/src/main.cpp#L934
Does such a cap exist? If not, couldn't an attacker use the unbounded size of the memory pool to overflow the RAM of a large number of nodes, knocking them offline?
I noticed two proposals that seemed to address this issue, but neither has made it through the approval process:

Mempool Superblock
Mempool Janitor

There is no cap on the maximum size of the mempool, nor a janitor which cleans up transactions which are not confirming. Loss of unconfirmed transactions isn't a problem as wallets are supposed to rebroadcast transactions if they don't confirm within a reasonable time frame, so it wouldn't be unreasonable to drop them in a critical low memory situation. The limit on free transaction relay is there partly to prevent this from being an issue, it would be fairly expensive to pack the mempool with junk from a fee standpoint.

I think the OPs concern is that an attacker could cause memory overflows just by broadcasting many many transactions.

@StephenM347, you got it. I'll update the question.