text:
How does one become a DNS seed for Bitcoin Core?
How does the process work? Do Core devs add a DNS seed based on reputation or what?

DNS seeds are hardcoded in the code, you can see the actual DNS seed available in Bitcoin Core at this link.
The requirements are:

run a bitcoin seeder, which is a specialized software (like this)
meet technical requirements: the DNS seed must be reachable by IPv4 and IPv6 and must have a stable IP address. The DNS seed should have a high-availability setup and must be able to handle a high query rate, as well as unexpected high load.
follow the guidelines
contact the community: reach out to the Bitcoin Core development community and express your interest in becoming a DNS seed. Provide details about your setup and explain why you think you would be a good candidate.

It's important to note that becoming a DNS seed is not a trivial task, and it requires a level of technical expertise, dedication, and commitment to maintain it properly. Also, being a DNS seed is a volunteer effort and the approval is given by the community.
Once your DNS seed is approved, it will be included in the list of DNS seeds used by the Bitcoin Core software, and it will play an important role in helping new users find and connect to the network.

As for the first point: DNS seed operators don't run a full node but specialised software such as github.com/sipa/bitcoin-seeder.
This software has additional functionality such as crawling through the network to check if nodes are online and responsive, and keeping a database of suitable nodes.
On the other hand, it doesn't participate in block or transaction relay and doesn't have a copy of the blockchain, so it's not a full node.

Thank you for the clarification


text:
How to turn a just watch electrum wallet to HD
Hello everyone I have an electrum wallet and it's in just watch mode and I'd like to change it to an HD wallet in electrum. How to go about it if it's possible?

non-HD WO to HD WO
It seems Electrum supports both deterministic (HD) and non-deterministic watch-only wallets but you can't simply convert from one type of watch-only wallet to the other type of watch-only wallet.
You can create a new HD wallet and manually import into it the addresses from the old non-HD watch-only wallet. I'm not sure there is any reason to do this.

WO to spendable
If you want to convert a watch-only wallet to one that can spend the money watched by the watch-only wallet, you can't do that without additional data that isn't in the watch-only wallet (private keys).
It may help to read the description of Electrum Watch-only wallets at https://bitcoinelectrum.com/creating-a-watch-only-wallet/

A watch-only wallet is a wallet without any secrets in it that could be used to spend bitcoin.

If you have the private keys that are omitted from a watch-only wallet, you can import them into a new wallet following the guide at https://bitcoinelectrum.com/importing-your-private-keys-into-electrum/

source: Stack Exchange

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

sort: votes


text:
After signing a message, how to verify the signature with JavaScript/TypeScript?
At the frontend, user signs an arbitrary message (e.g., "Sign this message to prove that you own this wallet"). We can do this via, for example, UniSat's signMessage function (see here).
I want to verify this message at the backend. I want something like this:
function verifySignature(message: string, address: string, signature: string): boolean

How to achieve this? Note that it's address instead of publicKey that is in the function parameter list.
I know Bitcoin wallet Apps or browser extensions use ECDSA to sign a message (or more precisely, the SHA256 digest of the message), but the signing processes differ among various types of Bitcoin address (P2PKH, P2SH, P2WPKH, P2WSH, P2TR). So I want some JavaScript/TypeScript packages that can do this robustly instead of implementing on my own.

bitcoin-sdk-js supports signing & verification for p2pkh, p2wpkh and p2tr with an address parameter.
import * as bitcoin from 'bitcoin-sdk-js'

assert.strictEqual(
  await bitcoin.crypto.verifyMessage(message, signature, address),
  true,
);

Note that segwit address(p2wpkh, p2tr) should follow BIP322 signing schema. However, it's not widely adopted yet, so I'm not sure if the signature generated from UniSat does follow BIP322.
Disclaimer: I'm the owner of the library.

The example in the documentation of signMessage has a line that shows a verifyMessage function.

According to the example the parameters appear to be:
verifyMessage(pubkey, message, signature)
Unfortunately, the function does not appear to be documented in the same GitBook. You could attempt using the function as it is used in the example, and/or try to contact UniSat to request that they document the function.

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


text:
What happens if additional BTC is sent to a source address after setting a specific transaction output?
Let's say you are collecting BTC from multiple addresses and sending it to one particular address. For example, you have 3 addresses:
Address A: 1 BTC
Address B: 2 BTC
Address C: 1 BTC
You want to send all the BTC to Address D, so you would expect to send 4 BTC minus the transaction fee. You don't need a change address since you want to collect all the BTC and then move it to some exchange.
Now, let's say you instruct the blockchain to send 3.9 BTC to Address D and leave 0.1 BTC for the transaction fee.(only example fee for ilustration purpose)
Question:
If someone accidentally sends 0.5 BTC to Address A before the transaction is initiated, will the entire remaining balance (0.5 BTC) be used as a fee for the miner or it will remain there or will the transaction be rejected? Or what would happen to this additional BTC?

No the additional amount won't be included in the transaction.
The transaction inputs are not addresses but references to specific unspent transaction outputs (UTXOs) of the earlier transactions that paid money to your addresses A, B and C.
Each address can be associated with many UTXOs and it is only the specifically referenced UTXOs that are used.


text:
bitcoin-qt import private key doesn't seem to work
I follow this wiki guide and this thread. After executing the command importprivkey mylongprivatekey in the Console, I see a popup window saying
[MyWallet] Rescanning...

and that takes couple of hours to finish. When it's done, I do not see Address Book show up next to Transactions as in the wiki page.
I thought one issue may be that the wallet get locked after the 10 minutes allowance. But I tried longer time, like 4 hours. Same issue.
I'm using bitcoin-0.20.0.
This is what I expect to see,

This is what I see after it finishes rescanning,

If you issue the getaddressinfo <address> command (with <address> replaced by the address that you had hoped to get the key imported for, what do you get?

@PieterWuille You mean issuing the command in the Console? I won't be able to try it until it stops rescanning....

Did you provide a label? Without label I don't think it'll show up in the address book. The RPC I mentioned will tell you whether it was properly imported.

@PieterWuille Yeap. Only complication is this. Because this didn't work the first time, I tried importing the same private key couple of times using either QT or the command line bitcoin-cli. Not sure if it might have confused the app

@PieterWuille It just finished and I did getaddressinfo MyAddr it shows the correct label.

@PieterWuille So, the private key has been imported successfully. Question then is why QT user interface doesn't show the Address Book button. And how do I send bitcoin out of this address, if it has balance (this particular one does not).

Oh that's just because the UI has been changed a lot. That documentation you're looking at is for version 0.7 (which was released in 2012). You don't need to do anything; if it's imported it'll work. If you had received coins on that address (or will receive), it'll show up in your balance, and be spendable.

@PieterWuille Then, is there any way to list all the addresses I've imported into this wallet?

It should be on the receive tab.

@PieterWuille In Receive tab, I don't see my imported address. I see a button Create new receiving address though. But that creates a new address.

Sorry, then I don't know. I don't work on the GUI.

@PieterWuille Is there any command(s) on command line bitcoin-cli to show my addresses?


text:
How do I remove Wallet from Bcoin?
I'm playing with bcoin cli and created lots of wallets. Is there any way to remove wallet via WalletDB Api?

Unfortunately right now there's no way to remove a wallet via the API in bcoin. There is a zap endpoint but I don't think it does anything yet. If you don't care about losing other wallets, you can just delete the wallet db directory from your bcoin directory.

As Bucko commented in August 2017:

Unfortunately right now there's no way to remove a wallet via the API in bcoin. There is a zap endpoint but I don't think it does anything yet. If you don't care about losing other wallets, you can just delete the wallet db directory from your bcoin directory.

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


text:
Are my retrieved BCCs stolen from my Electron Cash wallet?
I installed the Electron Cash Wallet on my laptop (version 2.9.2 downloaded from official site "electroncash.org" with the correct checksum). Then I retrieved my BCCs (from an imported BTC adress in my Blockchain.info wallet) into my Electron Cash Wallet, using the (Electron Cash) Wallet/Private Key/Sweep command (with the private key for the BTC adress as argument). After the "Broadcast" of the transaction the BCC's were added to my Electron Cash balance (on 7 Aug. 01.07 hour). So far so good. After that I closed my (password protected) wallet and put my laptop to sleep. In the morning I started my computer again, opened the Electron Cash wallet again, but saw to my great dismay that at 3:50 hour - when I was sleeping - a transaction has been done (by a unknown person/computer/hacker?) in which all my BCCs have been transfered to a for me unknown adress. So now my BCC balance is 0 again! (see screendumps of the wallet history and the unknown/illegal transaction below). My first impression was that I 'm robbed.

What happened here? Has anyone stolen my BCCs? And if so, how is this possible? After all I closed my wallet and shutted down my laptop. (Some thoughts: could someone have been able to get my private key for the adress in which I received my BCCs in my Electron Cash wallet? And if, so how? Could it be that Electron Cash (2.9.2) is not save, e.g. when using Private key/Export command, by sending secretly a copy to some unknown receiver? Or else?). Has anybody the same experience with retrieved BCCs in Electron Cash wallet, and/or an idea what could have happened. And more important: is there a possibility to get my (lost/stolen?) BCCs back again (and if so how)? (I my opinion I don't have the problem that Electron Cash is erroneously referring to an Electrum Cash BTC server (mentioned on other posts). To be sure I put the server on manual on "electroncash.cascharia.com", but that does not bring my BCCs back. What can I do to get my BCCs back?  Your answer(s) is (are) highly appreciated.

I have the same Issue, but it is still unconfirmed. Is this a software bug or have they been stolen? Did you found out what happened?

Another possibility is that your computer has some sort of malware which detected that you were typing in a private key and used it to steal the funds.  It doesn't have to be a problem with Electron itself.

I would not trust the Electron Cash software. Unless you experience one of the wrong server selected bugs, as other people describe in the linked questions, I would guess that the wallet sent your coins to someone elses address.
There is a warning about Electron Cash from Electrum:

The person who distributes the Electron Cash binaries has decided to
  remain anonymous, and uses the fake name "Jonald Fyookball" in order
  to sign Electron Cash binaries. Thus, if these binaries contain code
  that is designed to steal your bitcoins, the author of the theft will
  be anonymous and walk away safely with your funds.

I indeed now have strong doubts about the security of Electron Cash wallet software. Are there more users of Electron Cash (v 2.9.2)  with similar (negative) experience, that their retrieved BCCs have been "automatically"  transferred to a unknown address by a transaction that they didn't initiate themselves (shortly after the BCCs were received in the Electron Cash wallet)?

@ Ramon: My conclusion is the BCCs have been stolen. How it exactly has been done is unfortunately still not clear (but I don't trust Electron Cash anymore).

Your .498 BCH were sent to 19uUo2Ppdxj241pd9r2DWeQgFQUVJEpbSB and then on to 3Kaj5tacWQdz65JuWMNuEfictjAtTGj6Pv.  Unusual to see addresses starting with a 3 used for BCH - probably a multisig. Interestingly, multisig was broken in Electrum Cash software (but there is no way to know how that P2SH address was created, so just speculating here).
Others have reported strange behavior with Electron Cash, but it is unclear if they were affected by same crypto-stealing malware or an issue in Electrum Cash itself. Furthermore, the developer of Electrum has warned users about the unknown developer and code changes made.
Sorry, I have no further info to share.

I see that my stolen BCH (on Aug.7, 2017) has been transfered on Dec 7, 2017 to a new address.

I see (on https://www.blocktrail.com/BCC/address/3Kaj5tacWQdz65JuWMNuEfictjAtTGj6Pv/transactions) that my stolen BCH (on Aug.7, 2017) has been transfered on Dec 7, 2017 to a new address:   1GxXZqS737quMaXWxuEH2sFT3Zv7H8DaX5. I see furthermore that the thief collected here for 14.76 of (stolen?) BCH (now worth about $26000) from 7 other addresses. Who is this thief? Anybody any idea? Some recognizes this adress?

By the way: the seven adresses all start with a "3". I don't know if this has any meaning (but I mention this, because Jonathan Cross made remark about "3" in relation to "multisig"). The (input) 7 adresses are (P2SH):
3EzaSJNYQN87KhLA1CSNGZkpi3uiHfZqQw(1.04295252)
3Q3rVGht7azs3CcH1eoW4EU253YiNuWxR4(3.29047404)
3Kaj5tacWQdz65JuWMNuEfictjAtTGj6Pv(0.49862345)
3PzurWPWhsHTwqMEvviD7rZdimDdbhWMP2(4.15503946)
3LMN6JdskX22zJdiE1a1KrkSoLWExCyKy1(0.18951550)
3Q4XPvYwqzDo465ALsEfnqiQXPyU1TQpFq(5.08970062)
33ZkwQ5BQAYfNHUYFb6bqND1ksikFkiAR8(0.50274277)
Anybody's BCH's stolen from these adresses?

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


text:
How to extract the internal key of a simple P2TR address?
Is it possible to extract the taproot internal key out of a P2TR address?

A P2TR address encodes a public key using Bech32m, which you can directly decode. This public key is often (as recommended by BIP341) the result of taking a different key (called "internal key") and tweaking it with the commitment to a taproot script tree. The internal key is not part of the address so it cannot be decoded from it and is only revealed when spending via the script path. Since protocols using taproot usually aim to use the key path whenever possible and some even make the script path unspendable (e.g. BIP86), you will not be able to determine the internal key for most taproot addresses (or even determine whether it exists at all).


text:
Safety from quantum attacks
I recently read that China was able to use quantum computer for cracking military grade encryption.
https://thequantuminsider.com/2024/10/11/chinese-scientists-report-using-quantum-computer-to-hack-military-grade-encryption/
The article does admit that the present quantum capability is still in its infancy to affect banks and other services.
But let's say that they are able to advance quantum computing to the extent that they can crack into banks and military. How safe is today's blockchain from such future quantum developments?
What can be done to secure blockchain from such extreme situations?

Also Chinese researchers' claimed quantum encryption crack looks unlikely


text:
Stuck dissecting a P2PKH Bitcoin transaction, what am I doing wrong?
I'm attempting to dissect a P2PKH transaction based on guidance from Rene Pickhardt's video (link). At around the 2:54 minute mark, he calculates the Bitcoin Address from the input. I'm interested in understanding the process behind obtaining the address. Here's the transcription:
pubkey: 03486669962008e0713660b6d69117a65fcecd221d06c1e5077b4d9cd477c0cf98

Check the bitcoin address from the input:
RIPMED160(SHA256(pubkey)): CB226B9CC60C613DDDCB188E984F631764CEF143
Extend with version: 00CB226B9CC60C613DDDCB188E984F631764CEF143

Calculate checksum:
SHA256(SHA256(extended Pubkey)): CE281C015A7230F46041D2DD640A6714725C25A0ED674D5E215318AA206A397F
Checksum = first 4 Bytes: CE281C01
Address in hex: 00CB226B9CC60C613DDDCB188E984F631764CEF143CE281C01

Encode to base58: 1KwjU4UknzbXh1rnP1jAKz9wwjcuYwe9AC

Using this web http://lenschulwitz.com/base58 I can't get the address calculated before by Rene. What I'm doing wrong?

The process of calculating a Bitcoin P2PKH address in base56check encoding format is as follows:

get a public key from the private key
hash the public key with the SHA256 hash function
hash the result from the 2nd step with the RIPEMD160 hash function
prepend 0x00 to the result from the previous step
calculate checksum of the result from the 4th step as sha256(sha256(result))
take the first 4 bytes from the obtained result and append it to the content from the step 4
encode it with base58

So, following these steps, the results are as follows:

03486669962008e0713660b6d69117a65fcecd221d06c1e5077b4d9cd477c0cf98
af1a74e378749900ab079315e518dfd27196193ca139f1e8a037e5851f8a5ecb
cfcc2ce2d8fc82b2b0837b6c1775d5edcffc107f
00cfcc2ce2d8fc82b2b0837b6c1775d5edcffc107f
79ccb53d787d2c54087ca095504d92ee2ad2bc93a0986ef9d19a017ef8232cdd
00cfcc2ce2d8fc82b2b0837b6c1775d5edcffc107f79ccb53d
1KwjU4UknzbXh1rnP1jAKz9wwjcuYwe9AC

Looking at the video you provided, operation RIPEMD(SHA256(<pubkey>)) doesn't give a correct result to him, but it ends up getting a good address. Very strange indeed. I see that in the comments of the video there are also people who had the same problem.
So, the conclusion is that you are not doing anything wrong. Something is wrong (or more correctly say strange) in the video I would say.

Thanks for your quick and clear response. Inspired by your insights, I'll analyze the process myself. Will share any findings. Appreciate your help!

@ifuensan You're welcome


text:
Should different brands of hardware wallets be used in multisig setups?
Is there genuinely a compelling reason to use different brands of hardware wallets in multisig setups? I am contemplating using a series of Coldcard hardware wallets in a multisig setup but some people suggest that it is more secure using different brands within the same multisig setup. I have also contemplated combining Coldcard hardware wallets with Blockstream Jades.

The compelling reason to use different brands in a multisig setup is supply chain risk. Let's say you had a 3-of-5 multisig/threshold setup using brands A, B, C, D and E. A preinstalled vulnerability in the device or firmware of A would not cause you to lose your funds as brand A wouldn't have enough keys to move your Bitcoin. There would need to be preinstalled vulnerabilities in multiple products across different companies (and possibly jurisdictions) which would be much harder to pull off. If A, B, C, D and E are all the same product from the same brand a single supply chain attack could cause you to lose all your Bitcoin. Michael Flaxman discussed supply chain risk on the Stephan Livera podcast in August 2019.
Security is always a complex, multifaceted topic. If there were a dearth of competent, trustworthy manufacturers of hardware wallets/signers then you might still choose to take the risk on a single manufacturer for all five devices A, B, C, D and E. In this case the diversification benefit may be dwarfed by introducing multiple inferior, less trusted devices to your setup. Also the implementation of a multisig setup using multiple different devices is slightly more complex and increases somewhat the prospect for errors in the multisig code or in the user actions (backups etc).
We can't do product evaluations on this site for good reason but the two manufacturers you mention would be among the most trusted and competent in the industry. You may also be interested in the products that Michael Flaxman recommends using in the 10x security guide.


text:
How do I move (sweep, export) my private keys from my Electrum standard wallet to a new HD wallet using Electrum?
My present  wallet which I have been using to accumulate BTC (50+ utxos) is a Electrum Standard, script type is p2pkh, with seed available and the keystore type is bip32. I assume that I should now move all private keys and history to my new hardware wallet which is a Electrum Standard wallet with script type p2wpkh with no seed (except the Satochip settings show the hd wallet is seeded) bip32 and a keystore type HD (Satochip). What are the steps to safely transition to my new hardware wallet? I received this answer from Satochip.io regarding this issue which I don't fully understand.
"Regarding your software wallet, if you have an Electrum Seed (non BIP39), you won’t be able to recover your information from to SW to the HW. In this case, you should send all your Bitcoin from one adress to the Hw one. If your SW seed is BIP39, you can import it to your Satochip HW and will have access to all your wallet information."
Thanks for any clarity you can provide!

Just send your bitcoins to an address in the HW.

You can export your private keys by going to the Wallet menu and selecting "Private keys" > "Export". Then, you can import your private keys into your new HD wallet by going to the "Wallet" menu and selecting "Private keys" > "Import".

My Electrum HD wallet (standard) under "Wallet" menu the 2 choices are Sweep and Export  and Export is grayed out.


text:
Bonus for my friend
I have used original bitcoin client for first time. When I opened it showed the account balance is 1,000.0. Why is this bonus of 1 btc?
Now my friend tried opening client but his account balance is 0. How he can apply bonus?
How much is my balance in €?

There is no bonus, I have no idea what you're talking about.

There is no bonus. There's no way to know what exactly happened to you without sharing screenshots and the relevant Bitcoin address.


text:
Trying to get BCC in ElectronCash - but after priv keys import - empty wallet
I exported the private keys from Electrum, where I had BTC.
Then I send these BTC to a different wallet.
Then I tried to import these keys in Electron Cash. It worked, but the wallet is empty.
Any idea what I did wrong? What can I do now?
===
UPDATE
I tried to import all my priv keys to Bitcoint ABC.
WIth each priv key I imported a rescan took place, so it took 2-3 days to import all the priv keys (after rescan "null" appeared). However my balance is still zero.
I then imported the address in which there should be funds. And yes, the funds appeared, however in "watch-only". Not spendable.
If I try to re-import the key for this address I get null.
If I try to import the key with the true parameter, still I get immediately true without any new rescan.
If I check this address in blockchair.com I see that the funds are still there and not spent. There is a blue X on "spent?" column.
Any idea?

I'm not sure if its related, but there's a warning about Electron Cash on the Electrum website. From that article... "The person who distributes the Electron Cash binaries has decided to remain anonymous, and uses the fake name "Jonald Fyookball" in order to sign Electron Cash binaries. Thus, if these binaries contain code that is designed to steal your bitcoins, the author of the theft will be anonymous and walk away safely with your funds."

Make sure that you are connected to Electron Cash servers, not the normal Electrum servers. This continues to be a problem for Electron Cash as it can't distinguish between which servers use the chain that it wants to use.

@AndrewChow unfortunately I tried to connect it to different server with BCC and electroncash in their names.... it connects, but the BCC don't appear...

I would be very suspicious about the ElectronCash application. There have been multiple reports of users now whose BCC have been stolen. Where did you download the application?

from the official website, and also checked the hash before installing. So the app seems to be genuine. Really strange the stolen in so fast time. I undestand that I import they keys, I see the BCC in the balance, and then after some time they disappear.... but they didn't appear at all.

I added an update to the question. I tried with Bitcoin ABC


text:
How to recover blockchain.info legacy wallet?
I gathered that Blockchain switched to new-style HD wallets sometime in 2016. At that time they used to have logins for both new-style and legacy wallet IDs. They no longer support logins with legacy wallet ID.
I have:

legacy username
15-word mnemonic
passphrase (verified, 15-word mnemonic results in this passphrase using this tool).

Here is the message I get:

Password: superSecret123
Password not working? It may have been changed since the time the
  wallet was created or a browser error. Please contact the help desk
  with your wallet recover mnemonic to have a backup restored from an
  earlier date.
Locked out due to two factor authentication? Please use the following
  link to reset two factor authentication: Two Factor Authentication
  Reset

Blockchain's wallet id/password recovery tools do not work with legacy wallets (this makes sense: how can they send me the new wallet ID if I never had one?)
Their "industry leading" support is not responding. I bet they are swamped with requests like this. Is there a way to convert legacy wallet to new-style wallet given the information listed above?

Didn't you recovered a wallet-id and a passphrase at step 3.?

@Chak: no. I was able to verify that 15-word mnemonic produces the passphrase that I already have. It does not produce wallet ID.

That's weird, it is supposed to recover both wallet-id and passphrase. You better ask blockchain's support,

I recovered the funds. The only way to do that was by talking to blockchain.info support. They were able to provide the new-style HD wallet-ID. @Chak, I am not sure why you and others think this question is a duplicate, as it deals with wallet-ID recovery given blockchain.info's legacy mnemonic.


text:
Mining profitability sounds too good! Where is the catch? (2017 edition)
Given the staggering increase in BTC value over the last few months (nearly 600% in 12 months), I am kicking myself for not getting into the game earlier. I've been lurking around this for years but have been too risk-averse to dive in, and I haven't been paying attention lately. Now, looking into matters again, I am bound to ask: Where is the catch?
(This has been asked before, but the information is outdated.)
A cost/income calculation with present-day numbers (Aug'17) tells me that a dedicated mining device would pay for itself in 86 days and would generate in excess of $2500 per year. That sounds like free money!

If this is really true, then why isn't the whole world up in arms about this new gold rush? Or is it true, and most people are just living under a rock?
If this is true, then why not rush out and buy as many miners as I can afford? Or is it wiser to just buy a bunch of coins instead?

I've tried to take into account current values of:

best hash rate (14Th/s)
difficulty (860,221,984,436) as well as the expected increase
block reward (12, halving to 6 expected in the year 2020)
BTC exchange rate (currently 4162 USD per 1 BTC)
purchase cost of miner ($1288)
cost of miner's power consumption.

Using various online calculators (coinish, blockchained) I arrive at 16.35 USD/day or 2597.50 USD/year when taking difficulty and power cost into account. This still sounds like free money; what's the catch?
(edit: Due to a typo my initial calculation was one order of magnitude too high. These values are now corrected.)

This isn't really a question, so I am voting to close it. Instead of asking a question and then answering it in the same question part, you should post the question and then write the answer to that question as an answer.

I agree with @Andrew.  What is the point of this question?  This is not a discussion forum, but rather a question and answer site.  If you can boil this down to a specific question, you may get an answer.

@AndrewChow and Jestin, if "Where is the catch?" is not enough of a question, then perhaps we should focus on my collateral question: If this is really true, then why isn't the whole world up in arms about this new gold rush? Or is it true, and most people are just living under a rock?

@NateEldredge thank you for double-checking my numbers! I found that I must have mistyped the hash rate as 140000000 instead of 14000000 Mh/s -- clearly an easy mistake to make, is it not? With 14000000 Mh/s I also arrive at 16.35 USD/day or 2597.50 USD/year = not quite as mindblowing, but still a respectable endeavor!

Ah, I see now. Sorry, on my first read of the question, I thought you had asked a question and answered it yourself. Close vote retracted.

as passing reader has anyone thought of capturing the heat generated like they do with heat exchanges assuming you have a number of machines running that would bring down your heating bill and reduce your mining cost

Looking for 2018 edition.

There are many catches.
First of all, the difficulty will adjust and change as new hash power is added. That will then cause profitability to decrease. When new hash power is added to the network, the difficulty adjusts upwards to compensate for that so that blocks continue to be found at a 10 minute interval on average. This means that more work (i.e. more hash rate) is required to mine blocks and thus, given a fixed hash rate, profitability will decrease.
Also, the block reward halves every 4 or so years. That will also effect profitability.

Besides the technicalities of mining, there are also other forces in play that effect profitability. Mining hardware is kind of difficult to acquire; either you have to have millions of dollars to buy something from BitFury or buy equipment from Bitmain which can often be out of stock and unavailable.
Lastly, the price of Bitcoin has a significant effect on profitability. Only recently has Bitcoin's price been high enough to be profitable to mine in the United States (or in many other First World countries). The price of Bitcoin remains highly volatile, so investing a lot of money into mining equipment is extremely risky; the price could drop quickly within a few weeks and make mining very unprofitable.

Thank you Andrew! Your first two points (difficulty and halving) can be taken into account in the profitability calculation, as I have done in the question. Volatility is always a topic in a free market, but given the current value it could even plunge far and still remain attractive. In the end, scarceness of the hardware seems to be the biggest factor

Andrew Chow has mentioned the most important issues.  Here are a few others:

ASIC miners typically don't include power supplies.  That adds another few hundred USD to the cost.
Miners are often rushed to market to keep up with the pace of mining, and may not receive adequate reliability testing.  They may fail before they become obsolete, and you may not have much information on the expected failure rate.  There may or may not be a warranty, assuming the vendor is even still in business by that time, and anyway you are out of mining action until your replacement arrives.  If not then you have to pay to replace it, or give up.
Your 14 TH/s miner draws about 1200 W of power.  For typical house wiring in the US, you can draw about 1800 W from one circuit before your 15A fuses blow.  So you can only run a couple of these in your home before you are going to have to have expensive rewiring done, or else rent datacenter space.
Cooling can be a significant cost.  1200 W is a lot of heat, and you have to extract it from the room somehow.
It takes you time to set up and maintain the machine, and your time has value.  If you have a lot of them, you'll have to hire a sysadmin.

This post is community wiki, so others are free to add more issues.

Being risk averse is a natural response for the human mind. It is designed to keep you safe.
If everybody (I mean everybody) jumped on in it would not be long before the difficulty adjustment made it marginally profitable at best.
Risk aversion keeps many from doing this and in the meanwhile, those that are are making profits. As more people move past risk-aversion the price has to climb incrementally for everyone including new miners to just keep making the same profit.
More miners (presumably, but it does not necessarily follow) also means more people selling Bitcoin (to pay for overheads, since not that many overheads can yet be paid in Bitcoin), placing increased downward price pressure on the market.
As it is, the status-quo seems to be for the market to climb steadily apart from countries making Bitcoin illegal in their jurisdiction making it seem like a good idea, which it is, mostly, if you can afford to risk the losses.


text:
How can I prune my Bitcoin Core correctly? The other way did not work for me. Have I done any unnoticed mistake?
Saving the entire blockchain in my computer is taking mi a lot of space. I looked in this forum for a solution and I saw that there was an option to prune the node and save a lot of space.
I followed the instructions, I went to the Bitcoin data directory, I created a file there and called it "bitcoin.conf" and I wrote "-prune=1100" in it.
Nothing I expected happened, the space it took remained the same, it only started downloading a new blockchain called "testnet".
Have I done something wrong? And how can I fix it in order to save space?
My version of Bitcoin Core is v0.14..2
PS: Latter, I have discovered that, in fact, I have three Bitcoin data directories, and suddenly I have doubts about in which of them shall I place my "bitcoin.conf".
Is having three directory data how it shall be? And in which of them shall I place my "bitcoin.conf".

Can you post exactly the contents of your bitcoin.conf file? Can you also post the command that you are using to start Bitcoin Core with (if you are on windows, right click the shortcut you are using and copy the contents of the Target box).

Can you post exactly the contents of your bitcoin.conf file? prune=1100
And I am using Windows 10. I am not a computer expert so I do not understand the rest of the question.

In the config file you need to use "prune=1100", not "-prune=1100". Is that the problem?

I have tried both ways and it hasn´t work in any of both. Just now I have "prune=1100"

Some questions have multiple answers.  Since my answer is no longer identified as being correct, it will not be subject to mistake by others in thinking that I have answered your question.  In the mean time, I am trying to see if I just need to add one more step to mine to make it work or not.

Possible duplicate of Can Bitcoin-Qt be configured to trim the blockchain?

Have you restarted Bitcoin Core after adding the line to config? It is a startup parameter.

From your description it sounds to me that you may have edited your configuration file while Bitcoin Core was already running.
prune=1100 is a startup parameter. It will take effect once you restart the program.

If you add a parameter to the startup instructions,  parameters start with a dash (-prune=1100), e.g.:
"C:\Users\<username>\AppData\Roaming\Bitcoin\bitcoin-qt.exe" -prune=1100

Please make sure you use the correct path for the actual directory you installed Bitcoin to.
If you add it to the configuration, the parameter must be listed without a dash in the bitcoin.conf:
prune=1100

If you're unsure how to locate your Bitcoin data directory, please see: Where is the configuration file of Bitcoin-Qt kept?

There is no need to manually delete any files from your Bitcoin directory, or to start over the initial blockchain download to enable pruning.
You merely need to restart Bitcoin Core after you've edited the bitcoin.conf. If you don't know how to restart a program, you may find it simpler to shut down and restart your computer.

How do I access to the startup instructions? And, is restarting the program, only, to close and open the program again (becouse I have already tried that)? Or, do I have to do something more?

Yes, go to the menu, quit the program, start it again. At this point the bitcoin.conf gets used to initialize the program. Note that the standard "close window" operation is probably just hiding the program. You have to quit it, not hide it.

I have tried in different ways, I am sure I have restarted Bicoin Core, but it did not work. Now, I have discovered a new things that I will edit in the question.

@AnderAristondo Use the folder from the first picture. Put the bitcoin.conf file there.


text:
Could not locate RPC credentials Error
I am trying to follow the instructions in the following post:
Check status of daemon
When I try to run bitcoin-cli getblockchaininfo I get the following error:

When I look for the configuration file. It looks like it is not even there.
I am on Windows.

Is bitcoind running?

This was the problem. I had to start the daemon with bitcoind first, and then open a new cmd prompt to run bitcoin-cli get bloackchaininfo. Please put this as the answer so I can accept it.

it's "getblockchaininfo" not get blockchaininfo

You're getting this error because bitcoind isn't running. Once it is, it will create an authentication cookie, and bitcoin-cli will be able to connect.
To start bitcoind from cmd prompt, type:
cd C:/Program\ Files/Bitcoin/daemon/

Press enter, then type:
bitcoind

And press enter.


text:
What do electrumx peers do for the electrum server?
The documentation here https://electrumx.readthedocs.io/en/latest/peer_discovery.html explains how peers are announced to each other.  To run an electrumx server you need a full node to populate the database.  It makes sense that the clients can benefit from peer discovery and servers providing a peer list.  Is there any other role that the electrum server peers provide?  I am having a hard time find documentation on the topic.

There are few minor reasons why this might to useful for an electrum server:

Knowing what block height / protocol version other peers are operating via features advertised by peers to verify network issues
Banning bad peers via blacklisted peer list


text:
How to run Bitcoin-Qt over RPC to another machine
I have a full node running bitcoind on computer A.  On computer B I have bitcoin-cli setup to connect to computer A over RPC.  Computer A is a headless machine.  I don't want to re-download the chain on computer B.  I am currently using a wallet that can do this, but I would like to explore my options.  Sparrow wallet is capable of talking to a bitcoind full node, but it is written in Java.  There have been a lot of security vulnerabilities with programs written in Java, so I'd like to avoid it completely.

Is there a way to connect bitcoin-qt on computer B to computer A (running bitcoind) the way bitcoin-cli is able to connect?
What are some common wallets that support this feature? (trusted nodes via RPC or SPV to a bitcoind full node)

Here is the information I have been able to find so far:

Is it possible to run both bitcoind and bitcoin-qt as backend and frontend?
Step by step to make a SPV bitcoin node
https://coldcard.com/docs/ultra-quick

As @Andrew Chow said:

Bitcoin-qt is not just a frontend GUI or wallet handling software. It is bitcoind with a GUI.

There is a WIP project for separating things and make this possible, but it's still very early and not recommended for end users.

What are some common wallets that support this feature? (trusted nodes via RPC or SPV to a bitcoind full node)

Specter Desktop do support connecting to your core via RPC. You can also install an Electrum server on the headless machine and use Electrum or any other wallet that supports this protocol.

I ended up using Electrum with the bwt plugin which runs a lightweight electrum server that connects to my node.  I am going to look into using electrum personal server as this seems to be the recommended method


text:
coinbase.com buying queue
I am trying to buy bitcoins, and I have just recently got my bank account verfied on coinbase.com, and I am trying to buy bitcoins.
When browsing the buy page,  I got the following message

Note! We've exceeded our normal buy limits for today. If you would
  still like to purchase you will receive the market price of bitcoin on
  Tuesday Apr 16, 2013 at 08:24AM PDT after your funds have arrived.
  read more

When I click read more, it just tells me

Due to higher than normal buy volumes, we are unable to provide exact
  price quotes right now.
Instead of pausing buys entirely, we decided to give people the option
  to purchase bitcoin at the market price in a few days. Once your USD
  funds arrive, we will exchange them to bitcoin at the market price at
  approximately Tuesday Apr 16, 2013 at 08:24AM PDT.
Note that you can cancel your order at any time up until your bitcoin
  arrive from the transfer history page.
The market price of bitcoin changes frequently. Below are some recent
  prices to give you an idea. These do not guarantee what the price will
  be in a few days.

It looks like it's allowing you to put yourself in a queue to buy bitcoin, but I have no idea how to take advantage of this feature.
Am I correct about what this feature is? and If I am, how do I take advantage of it?

As far as I can tell the queue itself is not actually functioning. The limit they have only exists for some hours during the day, and at some point they allow you to buy bitcoin and charge it to your bank account. You are then locked in at the rate which you purchased them at, however it takes about 5 days generally to receive your bitcoins.
I think this happens because they are fronting the money themselves to buy the bitcoins, and have a limited amount of funds per day which they can spare. Each day a new volley of bank transfers comes through and they can then afford to front more for people.

I just managed to buy 0.1 bitcoins from them, and It's looking like I'll receive them next Tuesday, which matches the time-frame of the queue, but it appears as though I bought a flat number of bitcoin for a flat rate, so I'm still a little confused by this queue thing

was the message that said they had exceeded their daily limit still being displayed?

no, it wasn't.. .

So the message you have displayed, wont apply to your purchase, and your locked in at the rate you agreed to


text:
Asumming a quantum computer gets deployed. Is it safe to prune the witness area and make blocks 1MB again?
Assuming a quantum computer gets deployed. ECDSA doesn't prove anything anymore. Can we prune the witness area to save space and turn old transactions into a proper anyone can spend?

If ECDSA is broken, aren't pre-segwit transactions also vulnerable? What would this gain?

it would prune storage (save unnecessarily occupied disk space) after the point when segwit gained traction. It will also prune the ordinal spam

Why not prune everything  vulnerable to a break of ECDSA?

Good idea. And soft fork in a new postsegwit area for postquantum sigs.

Can we prune the witness area to save space

You can so do today already, with a pruned node. It precludes the ability to let other post-segwit nodes synchronize from you, and loses the ability to audit which participant(s) spent coins in case of a multisig. Other than that, it's perfectly feasible today; it's not done because it's much easier to prune everything past a certain point (rather than just witness data).

and turn old transactions into a proper anyone can spend?

That is unrelated, and would require a hard fork. Without witness data, no pre-hardfork post-segwit node will be able to synchronize.
From comments:

Good idea. And soft fork in a new postsegwit area for postquantum sigs.

You don't need a post-segwit area for that. Segwit v0 and v1 use ECDSA and Schnorr/BIP340 signatures respectively, but v2 or other future versions could be introduced that use post-quantum signatures.

Without witness data, no pre-hardfork post-segwit node will be able to synchronize. ... I doubt this is the case. As the quantum computer can feed garbage signatures to pre-hardfork post-segwit node and cause bugs anyway.

That would require the quantum computer to forge PoW (as the witness data is committed to by PoW), which very likely remains nontrivial even with powerful quantum computers (you get the sqrt() Grover's quantum speedup, but not the polynomial Shor speedup).


text:
Dont remember the right sequence of words in my private key
A while ago, I purchased Bitcoin and stored the corresponding 24-word private key. However, I am unable to recall the precise order of the words. I intentionally wrote them down in an unconventional manner to prevent potential theft if someone discovered my recovery sheet. Regrettably, I have now forgotten the correct order myself. It's frustrating.
The number of possible permutations is incredibly large! (24! = 620,448,401,733,239,439,360,000). Even if I were able to check one new permutation every second, it would still take millions of years...
So my question is: Have I calculated correctly? Is it practically impossible for me to retrieve my Bitcoin?

If you know like 7 or 8 of the right order from your 24-word mnemonic phrase and know some address that comes from your key and its path, then it is possible to recover your key back.

@Romo I'm afraid I may not possess enough bitcoin in that account to cover his expenses. Additionally, I'm perplexed as to why I am unable to select 24 random words from the BIP39 wordlist and gain entry to a new wallet on my Ledger/Trezor. It simply notifies me that the recovery sheet was incorrect. Shouldn't it instead grant access to an empty wallet? I assumed that all conceivable combinations from the wordlist would generate a functional wallet, independent of a hardware wallet generating the words for you. Perhaps there is some information there that could aid me in accessing my funds?

ChatGPT helped me rewrite that comment. Just to make my points more clear

If you have a 24-word passphrase, without repeated words, and truly do not know the order anymore (as in: every order is equally likely), then it is practically infeasible to recover.

And in that case there would be exactly 620,448,401,733,239,439,360,000 or 24! permutations right? Do i understand BIP39 correctly?

Also is it just as hard to find/generate the public key/address. I don't remember how much Bitcoin there is in there.

@MyAlfred Yes; perhaps it can be a bit less by taking the fact that BIP39 phrases have a checksum into account, but not much. And yes, if all you have is the phrase, computing the address requires finding the private key first.

@peter Alright. That makes sense! thanks

There are 24!=620,448,401,733,239,439,360,000 permutations, which is about 79 bits.
BIP39 phrases include 8 bits of checksum, but even computing that involves one SHA-256 hash per permutation. Modern GPUs achieve about 500 megahashes/sec, which would only get you 2^45 checks per day, taking more than 30 million cards*years just to calculate all checksums.
This unfortunately makes it safe to say it's absolutely infeasible to check every permutation.

i suppose it would be difficult to hire a professional brute force it since i can't even prove how much bitcoin is in there since i don't know the public key?

From a rough calculation using bitcoin network hash rate and block rewards, it would cost at least a double-digit number of bitcoins to produce that many hashes, just for the checksum calculations.


text:
Would exchanges save block space by defaulting deposit addresses to P2TR?
If inputs weigh less in P2TR than other address types, and exchanges conduct big batch transactions for withdrawals, is there a significant efficiency gain in block space they consume if most of their transactions eventually become P2TR?

Related: Is there an economic incentive to switch from P2WPKH to P2TR?

Yeah, I think that your question is covered in the topic that Vojtěch mentioned. If you agree, please vote to close as a duplicate. Otherwise, please edit your question to expand on how your question differs from the linked topic.

I think the linked topic covers it well. Thank you, I’ll vote to close

Murch, I need more reputation before I can vote to close. Can you close this?


text:
"Witness program hash mismatch" code -26 when broadcasting a transaction
I'm trying to broadcast a transaction to my RPC provider:
curl https://my-quicknode-rpc-provider/ \
    -X POST \
    -H "Content-Type: application/json" \
    --data '{"method": "sendrawtransaction", "params": ["02000000000101cc0fc61320a04525c8dabf30241fe9a64b3f8c28ebf61a9700b8a57a76306bac0000000000ffffffff01ea100000000000002251208dace6f04076ca1ea4eb168dcdad6ad61f695ca1c16a3df6b9586cdca1c71db8034025871482b0c7bb14b8c72d5ac44ce069991505a1aeca1c4de5b8d1857831ca87e6f43a3e784c755595574c798892ecf58c7ae525bccba441cdf46862dd405bb47e208dace6f04076ca1ea4eb168dcdad6ad61f695ca1c16a3df6b9586cdca1c71db8ac0063036f7264010118746578742f706c61696e3b636861727365743d7574662d3800387b2270223a226272632d3230222c226f70223a227472616e73666572222c227469636b223a2270657065222c22616d74223a22313030227d6821c18dace6f04076ca1ea4eb168dcdad6ad61f695ca1c16a3df6b9586cdca1c71db800000000"]}'

but I keep getting this error response from the RPC:
{"result":null,"error":{"code":-26,"message":"non-mandatory-script-verify-flag (Witness program hash mismatch)"},"id":null}

I've verified multiple times that I'm signing with the correct private key. On top of that, this occurs when broadcasting to the network, not during signing my PSBT inputs so I've been having trouble debugging.
For some context, I'm trying to attach a Taproot script to my input UTXO. Here is a code snippet of what I'm doing:
const hexData = Buffer.from(
  `{"p":"brc-20","op":"transfer","tick":"${tick}","amt":"${amount.toString()}"}`
).toString("hex");
const publicKeyHex = toXOnly(tweakedSigner.publicKey).toString("hex");
let inscribeLockScript = bitcoin.script.fromASM(
  `${publicKeyHex} OP_CHECKSIG OP_0 OP_IF ${Buffer.from("ord").toString(
    "hex"
  )} OP_1 ${Buffer.from("text/plain;charset=utf-8").toString(
    "hex"
  )} OP_0 ${splitByNChars(hexData, 1040).join(" ")} OP_ENDIF`
);
inscribeLockScript = Buffer.from(
  inscribeLockScript.toString("hex").replace("6f726451", "6f72640101"),
  "hex"
);

const scriptTree: Taptree = {
  output: inscribeLockScript,
};

const inscribeLockRedeem = {
  output: inscribeLockScript,
  redeemVersion: 192,
};

const inscribeP2tr = bitcoin.payments.p2tr({
  internalPubkey: toXOnly(tweakedSigner.publicKey),
  scriptTree,
  network: bitcoin.networks.bitcoin,
  redeem: inscribeLockRedeem,
});

const tapLeafScript = {
  leafVersion: inscribeLockRedeem.redeemVersion!,
  script: inscribeLockRedeem.output || Buffer.from(""),
  controlBlock: inscribeP2tr.witness![inscribeP2tr.witness!.length - 1],
};

psbt.addInput({
  hash: utxo.hash,
  index: utxo.index,
  witnessUtxo: {
    script: inscribeP2tr.output!,
    value: utxo.value,
  },
  tapInternalKey: toXOnly(tweakedSigner.publicKey),
  tapLeafScript: [tapLeafScript],
});

I'm fairly new to this so any help would be appreciated!

"Witness program hash mismatch" in a Taproot script path spend means the Taproot commitment wasn't successfully verified, in other words the internal key tweaked with the taptweak hash (constructed from the script, leaf version, merkle tree hashing partners and the internal key itself) didn't match the taproot output key (see BIP341).
This could be for many reasons, but here are the more likely ones:

You're saying you're "trying to attach a Taproot script" to your UTXO, but you can't attach a script to which the previous output doesn't commit. You need to know before constructing the output what scripts (and their positions in the script tree) will be allowed when spending.
The variable name tweakedSigner suggests it is the internal private/public key pair tweaked with the taptweak hash, which is something you would use for key path spending. For script path spending you need the untweaked internal key.

Awesome, thank you for clarifying!


text:
Are there any commercial nodes available so my transactions won't show my IP address?
Oftentimes my own IP address shows up as the "Relayed by ip" piece of data reported by Blockchain.info.
Is there a commercial node available that I can conract with to act as relay so that my IP won't be known?  (and has as part of the agreement their assurance to not log IPs for transactions)?
I know there are certain well connected nodes that I can connect to, but I don't have the guarantee from them that they aren't collecting and sharing my IP info.

Bitcoin will run over Tor. There an article on the Bitcoin wiki that explains the process.
Just install Tor and let it set up a proxy on its default IP (127.0.0.1) and port (9050).
For bitcoind, use the flag --proxy=127.0.0.1:9050.
For the GUI client, under Options, check Connect through socks4 proxy. Set the proxy IP to 127.0.0.1 and the port to 9050.


text:
Can OP_DROP be used to include arbitrary data?
I have recently been looking into OP_RETURN and its uses in so far as including data in a transaction. Given the fact that OP_RETURN is limited to 80 bytes I thought what if OP_DROP was used? That way it does not create the same unspendable UTXO as OP_RETURN while still allowing the person to include some data in the transaction plus more than 80 bytes can be added.
Am I off track or could we use:
<data> OP_DROP

to pass data that is not restricted to 80 bytes and does not create a new UTXO?
Are there any transactions that I could look at that make use of this (not sure how to search for something like that)?

Are you concerned about UTXO set bloat? OP_RETURN outputs are provably unspendable, so they don't take any space in the UTXO set.

My initial thought came from hearing about people wanting to pass "hidden messages" not realising the OP_RETURN output created. Which got me thinking if there was a less obvious way of passing messages and came across OP_DROP. Obviously it is not hidden, but less obvious than OP_RETURN creating an output (plus the added benefit of longer message size). Just wanted to explore the concept a bit further.

Because it's too late the edit the comment. I know trying to pass hidden messages in Bitcoin is stupid, but it doesn't stop people who don't understand Bitcoin from doing it.

Trying to make a message "less obvious" will eventually make it more obvious, as it will stand out from the other, more common ways of embedding arbitrary data.

OP_RETURN is only limited to 80 bytes by Bitcoin Core's default standardness rules. Some people increase this limit using the -datacarriersize option. Other people have been running Peter Todd's "Libre Relay" patch that removes this and other standardness limits, and automatically connects to other nodes running the patch. As a result, many transactions that exceed this limit have been mined lately, so you might not actually need to devise a way around it.
Moreover, OP_RETURN is one of only a handful of standard output script templates. Putting <data> OP_DROP into the output script will make it non-standard by Bitcoin Core's (and most other implementations') rules. What you actually need is to put it into a script that's revealed in an input, i.e. a P2WSH witness script or a P2TR leaf script. Doing it this way also means your data makes use of the discount on witness data.
However, <data> OP_DROP is still slightly suboptimal if you're looking to push anything large. The largest push size allowed by consensus rules is 520 bytes, so you'd need to split your data into chunks of 520 bytes like <data> OP_DROP <data> OP_DROP ..., requiring multiple drop opcodes. A more efficient way is OP_FALSE OP_IF <data> <data> ... OP_ENDIF, sometimes known as the "inscription envelope" as it was popularized by ordinal inscriptions. (Note that there's currently a movement to make this specific pattern non-standard by default; how likely it is to succeed I will leave as an exercise for the reader.)

So using OP_DROP will create one of those non-standard addresses no matter how it is used?

There's no such thing as a non-standard address, addresses are standardized encodings of standard output script types. And yes, there is no standard output script type that has OP_DROP in it.

Sorry for the confusion, I use the term non-standard addresses to refer to these situations. What is a better way to refer to "non-standard scripts that do not resolve to an address" without having to write all that each time?

Non-standard output scripts never have a corresponding address, so it's enough to use just that.


text:
How to find out if public keys have been used in other transactions
When we get the public keys from a multisig script is there a way to check what other transactions use those public keys?
I know how to check if they have been used as P2PKH addresses, but I'm not sure how to check other output types.

Hi user2334659, I've edited the question to hopefully make it clearer. If I've somehow changed the intent of your original question, feel free to change it back.

For Bitcoin, you can use block explorers like Blockchain.info, Blockchair, or a blockchain API like Blockcypher. They often provide detailed information about transactions, including inputs and outputs.
Here's a high-level approach:

Identify Multisig Transaction: Find the transaction where the multisig script was used.

Explore Transaction Outputs: Look at the outputs of that transaction. Multisig transactions usually involve several public keys.

Search for Public Keys: Take each public key and search for them in other transactions. You may need to decode these public keys to their standard format for searching.

Consider Output Types: As you mentioned, understanding different output types is crucial. For multisig, you'd be dealing with P2SH (Pay-to-Script-Hash) or even more complex script types.

Decode Scripts: Some explorers allow you to decode scripts, helping you understand the script type and extract public keys.

This process might require some programming/scripting if you're dealing with a large number of transactions or public keys. Python with libraries like bitcoinlib or pybitcointools could be helpful.


text:
Creating a P2PKH address
I have been learning about how P2PKH addresses are generated so I thought I would try and work through one myself manually. I start with the following public key hash:
e049ccc9e524a9302c2187bf02c4d78741d9b039
Which I know should come out to address:
1MSvmgVJvYkdtCsopFqsT2g3FNNhpcoeBG
I append the 00 prefix to my hash getting:
00e049ccc9e524a9302c2187bf02c4d78741d9b039
I then go to calculate the checksum by converting this to binary:
1110000001001001110011001100100111100101001001001010100100110000001011000010000110000111101111110000001011000100110101111000011101000001110110011011000000111001
And then running this through SHA256 twice which gets me:
a66d4caa10c1b665d6bca3f06788db9fbea6e9912a9fcf8101eb5992f9e8ab78
I take the first 4 bytes a66d4caa and put them onto the end of my prefix+hash:
00e049ccc9e524a9302c2187bf02c4d78741d9b039a66d4caa
And I wind up with:
1MSvmgVJvYkdtCsopFqsT2g3FNNhsp8jXo
Can someone help me out with where I am going wrong?
EDIT: Forgot to convert it to binary first. But it still doesn't work.

You accidentally converted to binary the original public key hash, not the result of prepending 00 (you can tell because it should start with 00000000). You also might not need to convert to binary at all, many hashing tools will be perfectly happy to accept a hexadecimal input.
The hash you should get after this step is:
296b64c7d7e8cf61a327d3e351b9e92e4451af50dff18227550167fe7a13bee2

You are correct I don't need to convert to binary first but I was doomed from the start regardless. I was using an online SHA256 hashing tool and didn't realise it defaulted to treating the input as text not hex. Once I changed it to hex it worked.


text:
Regular wallets and BIP-39 wallets wordlist
Are the wordlists used to generate the 12/24 seeds different for a regular BTC wallet and BIP-39 enabled BTC wallets?
Also can I edit the seed phrase wordlists to add my own words to it in any types of BTC wallet?
Is there any way of generating seed phrases on my own? How does that work? I read on the internet someone advising to use Ian Coleman's seed generator. Till now I have only been able to generate seeds randomly in the electrum wallet. I never had the choice to select the 12/24 words.

What do you mean by "regular btc wallet"? BIP 39 is the regular one - it's the only standardized mnemonic scheme for key generation. Electrum uses a different method that no one else uses.

Ok thanks. Can I choose my own seed phrase? is it anyway possible?

Also can I edit the seed phrase wordlists to add my own words to it in any types of BTC wallet?

No. The BIP 39 word list is standardized. The Electrum word list is hard coded. They cannot be modified.

Is there any way of generating seed phrases on my own?

You can implement your own software or find other software that is capable of generating seeds.

How does that work?

A large random number is generated and subsequently encoded into the seed phrase. For BIP 39, that process is specified in the BIP.

I never had the choice to select the 12/24 words.

You do not, and you should not, because choosing your own words is unsafe. The whole of cryptography works by choosing large random numbers such that guessing or brute forcing your specific number is basically impossible. The seed phrase is simply an extension of that, as the initial step is choosing a large random number. Skipping that step is reduction in the security of your private keys as the number is no longer random. No longer being random increases the likelihood of someone else guessing your number and therefore your private keys.

Can I choose my own seed phrase? is it anyway possible?

You can choose your own seed phrase, but bear in mind you should consider it unsafe.
There’s a caveat, you’re not free to choose any word for the last word, you only have a subset of the words available to use as the last word (ex: only 8 possible words in a 24-words seed phrase)
What you can do is write 23 words, and than use this python script to find out about the 8 possible candidates for the last word:
https://github.com/veebch/Bip39-Dice
Why is that?
Each BIP39 word represents 11 bits (2^11 = 2048 words in the dictionary)
BIP39 seed phrases encode seeds plus a checksum:

12-words = 128 bits seed + checksum
24-words = 256 bits seed + checksum

The size of the checksum depends on the number of words used.
In a 24-words seed phrase we have 264 bits represented (24*11=264) but we only need 256, so the extra 8 bits are used as checksum for the first 256 bits.
So, the 11 bits representing the last word are bbb + cccccccc where bbb belongs to the seed, while cccccccc are the 8 bits of the checksum. Since cccccccc depends on bbb, everytime you change a bit on the seed, you change the checksum.
Since there are 3 possible bits on bbb, you can choose any of the 8 combinations (2^3 = 8) which will be translated to 8 different words.
Any other word will result in a invalid checksum which means an invalid seed phrase.
As an exercise, I’ll let you find out how many candidate words are on a 12-word seed phrase.


text:
Testing new releases privately on selected nodes?
I think the main vulnerability of Bitcoin is a new release messing things up in a way that it will completely destroy people's faith in the protocol.
By this I mean something like what happened in 2013 with the BerkeleyDB to LevelDB update. That could have ended a lot worse.
If for each release, there is a 0,1% chance of it messing things up, then given enough time some release WILL eventually mess things up.
I wonder if a safer approach would be to first test the new releases privately, in some selected nodes (and miners), that are constatly communicating with each other. I the software in incompatible in some way, they can swiftly coordinate to switch back to the old software. This is much harder to do when everyone has installed the new software because there is no way to communicate with all nodes.
(I know the software is heavily tested in Testnet beforehand, and that is a good thing, but it is not enough, like the 2013 situation showed)

It’s not clear to me how your proposal significantly differs from what is happening already when volunteers run the master branch or release candidates on mainnet before the release. It also seems more like a "give feedback to my idea prompt" than a question.

The main difference is that no miners are involved in the testing. No blocks are actually produced by the software that is being tested, which is problematic in my opinion for the reasons presented above.

I think you misunderstand how merging pull requests and a Git based release process works on an open source project. A new release is just an old release with a bunch of changes (or pull requests) merged. Every pull request that makes it into a new release has been reviewed and tested by project contributors prior to it being merged. The author of the pull request can themselves do testing in private prior to opening the pull request in public if they so wish. You don't have to wait for a new release to run a version of the code that includes changes on top of the old release.
Generally users do wait for new releases rather than running the latest version of the code (the latest state of the master branch). The maintainers of the project won't cut a new release until they are happy with the level of testing that new release has been subjected to. But some bugs or problems will only be identified by users running say on an obscure operating system or running with a strange configuration. Hence after a new release is cut maintainers will often merge new pull requests to address these bugs before updating that release. The way you phrase the question it seems as if you think each release is ultimately final and there are no intermediate steps between major releases.

I wonder if a safer approach would be to first test the new releases privately, in some selected nodes (and miners), that are constatly communicating with each other. I the software in incompatible in some way, they can swiftly coordinate to switch back to the old software. This is much harder to do when everyone has installed the new software because there is no way to communicate with all nodes.

This change was a rather unique change as database formats are rarely switched in Core and no one envisaged this particular change from (temporarily) impacting the consensus rules of the network. If the maintainers and contributors don't identify this possibility and the testing frameworks don't test for it either it needs to be identified in the wild by users testing the release. It slipped through the author's testing, the project's testing and the release's testing.


text:
Is it correct to differentiate between a validated bitcoin transaction and a confirmed bitcoin transaction?
From my understanding, a transaction is first 'validated' by nodes once a transaction is propagated - so in the early stages.
These validated, but unconfirmed, transactions are then collected by miners into blocks and participate in the proof of work (POW) competition to find a winning block.
A transaction becomes 'confirmed' when it is part of a winning block, meaning that the winning block was confirmed by nodes and thus added to the bitcoin blockchain.
Am I correct, or very confused?

You are almost entirely correct.
All nodes validate as much Bitcoin data as they possibly can. All nodes avoid needing to trust other nodes as much as they possibly can. If one piece of data reaches ten thousand full-nodes, that data will be validated ten thousand times. Once by each. No node ever assumes that data it obtains from another is valid, regardless of whether it is new or old, first or last, early stages or late stages, Monday or Tuesday, day or night, raining or sunny. All nodes are untrusted.
Miners create new blocks. A new block, if valid, counts as one confirmation of the transactions in it and an additional confirmation of all transactions in all earlier blocks since the beginning. Each node validates the new block for itself and counts confirmations for itself.

Is it correct to differentiate between a validated bitcoin transaction and a confirmed bitcoin transaction?

Yes, a transaction may be valid but unconfirmed.
Validation is, for example, checking that the sum of outputs does not exceed the sum of inputs.
Miners produce new blocks but other nodes don't confirm those blocks. Confirmation is only a count of how far from the end of the chain is the block that contains a transaction. It is pretty much only an abstract measure of how much money a criminal would have to spend in order to persuade the world your transaction never existed.
Those are two very different things.

Am I correct, or very confused?

It is probably possible to be both correct and very confused. So it may not be an either-or proposition :-)


text:
Is it correct to refer to hashes found through proof of work as "proof of work numbers"?
I've seen come commentators refer to 'proof of work numbers'. I suppose these are the hashes found through proof of work, but not entirely sure.
EDIT** Regarding where I got the 'proof of work numbers' terminology, I believe I first saw it on Reddit. I also saw it being employed in the following explanation, which was also the source used in my reply in the comments.

This puzzle is called the Proof of Work and is an idea that has
been adapted from an earlier system called hashcash. Proof of Work
requires computing a hash of three components, hash(B, A, W) where:
B = block of transactions (which includes the hash pointer to the previous block)
A = address (i.e., hash of the public key) of the owner of the server doing the computation
W = the Proof of Work number

A reference to such usage, or some context, would be helpful.

@PieterWuille, I can't recall the exact source. However, I think I've answered my own question. POW requires finding a hash of certain characteristics. The hash function takes three inputs: (1) a pointer to the previous block, (2) identifier of the node doing the computation, and (3) a random (32-bit) one-time whole number. Only parameter (3) can be modified by the miner. This parameter is a 'nonce', sometimes known as a POW number.

Bitcoin block headers only have a 32-bit nonce. The number of hash attempts per block is typically enormously higher than 2^32 (around 2^77 almost). This is accomplished by making changes to the block candidate beyond just the nonce.

From what I understand, you're saying that " Only parameter (3) can be modified by the miner. This parameter is a 'nonce', sometimes known as a POW number" is incorrect. If so, what other changes are made beyond the nonce?

The coinbase transaction can be chosen by the miner, and it affects the transaction Merkle root, which also goes into the block header. So by changing the coinbase transaction, additional variation can be introduced.

Is it correct to refer to hashes found through proof of work as "proof of work numbers"?

I wouldn't say it is incorrect but it isn't exactly correct either. I'd say The phrase "Proof of Work" (PoW) applies to the overall method and not to any specific data item.
I think you could sensibly say that the sufficiently low hash of a block is a kind of proof of the work that is likely to have been done in obtaining it. This only really applies over a statistically significant sample size I guess.
Calling the hash the proof of work number doesn't seem to me to be a particularly useful description. I guess that if you are going to hang that label on a single data item, that is probably the obvious candidate.
Since no one is in charge of bitcoin, there is no one authority who decides what terminology is correct.

The hash function takes three inputs: (1) a pointer to the previous block, (2) identifier of the node doing the computation, and (3) a random (32-bit) one-time whole number.

The data that is hashed does not necessarily include any reference to the node doing the computation. Some mining pools may insert a pool identifier into their coinbase transaction but that is not required at all.
Your list omits a lot of other data that is in the data hashed. It includes other items in the block header, such as a hash of data in the transactions in that block.

Proof of Work requires computing a hash of three components, hash(B, A, W)

I don't recognise that from Satoshi Nakamoto's whitepaper on Bitcoin nor from Adam Black's 2002 whitepaper on his 1997 HashCash proposal.
I suspect that W, the proof of work number, corresponds roughly to the nonce in Bitcoin's block header. But as Pieter Wuille pointed out, the Bitcoin nonce alone is insufficient for that role.
Adam black wrote

The hashcash CPU cost-function computes a token which can be used as a proof-of-work.

Black defines a non-interactive token as T = MINT(s, w) where I believe s is a service name and and w is the amount of work the user will have to expend on average to compute a token.

If you look at Wikipedia's article and others, I think it is fairly common to see reference to a "proof of work algorithm" or a "proof of work system".
I suspect looking for a "proof of work number" in Bitcoin is not especially helpful to people new to Bitcoin who are trying to understand how it works.

I was def conflating POW as specific data item as opposed to an overall method. Is thinking of it as an overall method controversial though? In the sense that others have in the past objected to characterization?

Which others? What characterization? Thisnis getting a bit vague..

@PieterWuille, the characterization of POW as a "specific data item" as opposed to a "general method". By others, I mean the community at large. I was wondering if there have been past discussions in the bitcoin community regarding the specifics of what the phrase "Proof of Work" refers to.

@StatsScared: I have added to my answer something to address your edit to your question.


text:
Bitcoin Core 0.15 reindexing blockchain looks like its hanging?
and run bitcoind and bitcoin-cli from source so i can start messing around with some of the api calls and hopefully develop some cool stuff.
Unfortuantely running bitcoind says i must reindex the blockchain as i'm building over the top of a previous corrupted blockchain.
Running the call:
bitcoind -reindex -daemon -printtoconsole
I get:
2017-09-17 15:11:12 Bitcoin version v0.15.99.0-e278f86c5
2017-09-17 15:11:12 InitParameterInteraction: parameter interaction: -whitelistforcerelay=1 -> setting -whitelistrelay=1
2017-09-17 15:11:12 Assuming ancestors of block 0000000000000000003b9ce759c2a087d52abc4266f8f4ebd6d768b89defa50a have valid signatures.
2017-09-17 15:11:12 Setting nMinimumChainWork=000000000000000000000000000000000000000000723d3581fe1bd55373540a
2017-09-17 15:11:12 Using the 'sse4' SHA256 implementation
2017-09-17 15:11:12 Using RdRand as an additional entropy source Bitcoin server starting

With nothing ever progressing past Bitcoin Server starting. Then when i run:
bitcoin-cli getinfo
error code: -32601
error message: Method not found
The process is still running correctly and i can't rerun bitcoind as i've got the process already running in the background. Does anyone have any ideas ?
UPDATE:
When i tail the log i now get
2017-09-17 15:10:46 Reindexing block file blk00076.dat...
2017-09-17 15:10:47 tor: Thread interrupt
2017-09-17 15:10:47 torcontrol thread exit
2017-09-17 15:10:47 net thread exit
2017-09-17 15:10:47 addcon thread exit
2017-09-17 15:10:47 opencon thread exit
2017-09-17 15:10:47 msghand thread exit
2017-09-17 15:10:47 scheduler thread interrupt
2017-09-17 15:10:47 Shutdown: In progress...
2017-09-17 15:10:50 Shutdown: done

Is there a reason the node is automatically shutting down as i haven't authorised any shutdown commands ? Is there a way to check?
UPDATE2:
https://gist.github.com/anonymous/eb0d26892161f2b25933917d1d89c139
Left it running again using -reindex and no -printtoconsole still as a daemon.
Trying to interpret the above log, looks like i'm all up and running ? Is there a way to check and next time i start the bitcoind process i do it without a -reindex ?

Can you post more of the log (stuff before this snippet)?

Only ever pass -reindex once. If you shutdown, and restart, it will continue where it left off. If you start with -reindex again, it will start over.

bitcoin-cli getinfo

The getinfo RPC has been removed in the master branch (which is what you are using). Try using a different RPC like getblockchaininfo or getnetworkinfo. The fact that you are getting a response with Method not found indicates that the RPC server is up and running, so the node should be working.
I don't think -daemon and -printtoconsole interact well so you may not actually see the debug lines.

When i tail the log i now get
2017-09-17 15:10:46 Reindexing block file blk00076.dat... 2017-09-17 15:10:47 tor: Thread interrupt 2017-09-17 15:10:47 torcontrol thread exit 2017-09-17 15:10:47 net thread exit 2017-09-17 15:10:47 addcon thread exit 2017-09-17 15:10:47 opencon thread exit 2017-09-17 15:10:47 msghand thread exit 2017-09-17 15:10:47 scheduler thread interrupt 2017-09-17 15:10:47 Shutdown: In progress... 2017-09-17 15:10:50 Shutdown: done
Is there a reason the node is automatically shutting down as i haven't authorised any shutdown commands ? Is there a way to check?

Can you post the full log as an edit to your question and format properly in code blocks?


text:
Are there plans to make a script invalid if there is more than one element left in the stack?
In BIP62, it was proposed to make a script invalid if there was more than one element left in the stack after execution. This proposal was eventually withdrawn.
From what I read, some people have suggested that this rule could eventually be enforced in the future. But the problem is that I think this would make segwit outputs non-valid with legacy nodes?
Take a P2TR for example. To a legacy node, the locking script of a P2TR output is seen as two non-zero data pushes. Together with the unlocking script (an empty byte array), this would leave the stack with two non-zero data pushes after execution, so a P2TR transaction would be rejected by legacy nodes.
Am I missing something?

This is a consensus rule inside (P2SH-)P2WSH witness scripts, and P2TR script-path spends already.
See BIP141:

The script must not fail, and result in exactly a single TRUE on the stack.

And BIP342:

If the execution results in anything but exactly one element on the stack which evaluates to true with CastToBool(), fail.

It would be possible to do a soft fork to enforce this rule for bare scripts and P2SH scripts too, though as you note, doing this naively would interfere with segwit script matching. A potential solution would be to exclude these patterns from the rule, but that may still be undesirable as it would close the door to using similar script extension mecanisms in the future. This was not an issue at the time BIP62 was proposed, as it predated segwit, but still, in retrospect it is probably good that it didn't get adopted as consensus rule.
I think there is little reason to add this rule to bare scripts and even P2SH scripts, as they are effectively obsolete. Newer constructions are cheaper, more compact, more convenient, and offer more features.


text:
I am trying to convert the 12 words into BTC addresses, but they do not match
I am trying to convert the 12 words into BTC addresses, but they do not match the ones shown to me by Safepal, Coinomi, and Trust Wallet. I have tried using several libraries and doing it manually.
I managed to successfully convert to SegWit, but P2PKH and P2SH still do not match.
The words (they are for testing purposes) are:
false deal abstract advance buffalo clock auto banana offer arena wage stumble

The code I am using to convert using the two methods that are not working is as follows:
################# P2PKH ##############
seed = hashlib.pbkdf2_hmac('sha512', mnemonic.encode('utf-8'), b'mnemonic', 2048)
private_key = seed[:32]
public_key = hashlib.sha256(private_key).digest()
ripemd160 = hashlib.new('ripemd160')
ripemd160.update(public_key)
hash160 = ripemd160.digest()
version = b"\x00" # version for P2PKH addresses on Bitcoin mainnet
address_bytes = version + hash160
checksum = hashlib.sha256(hashlib.sha256(address_bytes).digest()).digest()[:4]
addressP2PKH = base58.b58encode(address_bytes + checksum).decode('utf-8')

################ P2SH ##############
seed = hashlib.pbkdf2_hmac('sha512', mnemonic.encode('utf-8'), b'mnemonic', 2048)
private_key = seed[:32]
sk = SigningKey.from_string(private_key, curve=SECP256k1)
vk = sk.get_verifying_key()
public_key_bytes = vk.to_string()
hashed_public_key = hashlib.sha256(public_key_bytes).digest()
ripe_hash = hashlib.new('ripemd160', hashed_public_key).digest()
prefix = b'\x05'
prefixed_ripe_hash = prefix + ripe_hash
address_bytes = hashlib.sha256(prefixed_ripe_hash).digest()
address_bytes = hashlib.sha256(address_bytes).digest()
checksum = address_bytes[:4]
raw_address = prefixed_ripe_hash + checksum
addressP2SH = base58.b58encode(raw_address).decode()

print(['segwitAddress', 'addressP2PKH', 'addressP2SH'])

The output is:
['bc1qfev3mh2mz3cuvsfn3wt6rwv78qjlkcy7dj27dk', '14ZowctPoxYtaUa55XKpUq8h2VWzPvLQ84', '37qZKk7ZpFFX63fR4HLPRaU5jtdhckmcnP']

But it should be:
['bc1qfev3mh2mz3cuvsfn3wt6rwv78qjlkcy7dj27dk', '1D9P3s1Daa3dmLq88QAky3uv4vjT6WZRCV', '3HojBjoLmEHjrHfiiUKAL1NCVXEcmAf7iY']

For P2PKH, you've hashed the private key rather than the public key.
For P2SH, you've hashed the public key and used the P2SH version number, however that is not what a P2SH address should be. Rather P2SH encodes the hash of a script that can be executed - public keys are not scripts. Presumably you mean P2SH wrapped P2WPKH, so the script is the hash of the segwit script (0x0016<pubkey hash>) encoded with Base58Check.


text:
Claimed Bitcoin before high security
I claimed a paper wallet on Crypto.com before the high security went into affect.  I am unable to get into my account and access my currency.  Pass phrases, I.D., s.s., were not part of the process at the time.  How do I claim what is mine?  I still have the paper wallet.

Have you tried "sweeping" your paper wallet into a wallet such as Electrum?


text:
What does Bitcoin Core need to be upgraded to 1.0?
At what point is Bitcoin Core considered good enough to have its next version upgrade be 1.0? I understand there are good reasons to be conservative about versions numbering, but I genuinely wonder what critical milestones are left in terms of software development.
Some would argue bitcoin is not an experiment anymore. It seems hard to say when bitcoin can be considered enough secure, stable, efficient, scalable or private though. Will it ever be <insert_word> enough to be upgraded to 1.0? There are still plenty of PRs to be reviewed, open issues and now multiple organizations sponsoring its research and development. That is great, but also could open the door to abuse. Of course, there are other implementations besides Core.
Anyway, I saw that this question was asked about the client almost 12 years ago, and I feel the answer is still to be determined today.

The last version of Bitcoin Core is 25.0, roll backing to 1.0 would be confusing. :p

I'll keep waiting for 1.0 then... x)

Bitcoin Core is currently at version 25.0.
After version 0.21.0, it was realized that the 0. prefix had become meaningless, and 0.x.0 was effectively treated as stable major release x. Thus, it was decided to drop the 0, and 0.21.0 was followed by 22.0.
There was no special event where suddenly a threshold of stability was reached, that corresponded to this. It's just that over time things had gradually matured, and the numbering scheme had become outdated.

Thanks. I never realized this until now. I could almost feel ashamed for asking this question! Humbling, bitcoin is.


text:
Why there are miner fees now?
I understand the mining fee will be the major incentive when the Bitcoin supply hit its limit of 21m. But right now, new coins are still being minted and are much higher than any fee can compansate. Shouldn't the fee calculation be a WIP improvement protocol that needs to be worked on in the Testnet rather than causing huge innefficeny in the Main Bitcoin network?
I am very sorry if it is naive to think that, but I see that many debates on Bitcoin's future are based on the high amount of miner fees or the long waiting time for confirmations.
Why shouldn't miners just add the transactions randomly and just incentivized by the reward?
I believe the mainstream usage adoption will be provided by the people who can't afford the current miner fees, but still wish there could be a way to actually use the network at least in a fair way where the highest fee couldn't win the confirmation race.
To sum up, I am wondering, why the fee structure shouldn't be tested and worked on on the Tesnet until a good protocol for fee calculation has been developed, and in the main network miners just incentivized by the reward and add the transactions in blocks randomly or by First In First Out method or by some other criteria rather than fee?

Fees are there because of penny-flooding attack, which is a praticular kind of denial-of-service.
Without fees you would have a situation in which an attacker can fill the memory pool with 0-costs pending transactions, which would cause a sensible service degradation.
An attacker could move its funds between addresses of its own, spamming thousands of transactions on the network without losing anything. The memory pool would grow until filled, and since miners are not able to discriminate between honest transactions and malicious transactions, this will result in no (or few) honest transactions being processed and included in the chain.
By adding a fee you are adding a cost to such attack. An attacker is no longer able to generate thousands (or more) of fake transactions at no costs.

There is only a particular number of transactions which can be included in a block and currently this number is smaller than the number of transactions which want to be included. So with or without fees some of the transactions will be omitted in a particular block.
Miners (and almost anyone using any money-related technology) are driven by profits. So if there is a demand (people want their transaction being accepted), and supply is limited (number of tx in a block), the profit (fees) is the natural solution.

Yes, but the current structure is kind of hurting the environment, almost every fork market themselves with lower fees and fast transactions. I just think that if the fee structure is developed privately and not cause a marketing scheme and confuse users, the network would have a relief. And also I believe the actual demand is to use the network, not to pay in order to use it. Maybe the cause of mining centralizaiton is that it became too profitable by the current structure.

@thefrogking The current structure hurts, because it's being abused, some rich folks are degrading the service by artificially making large number of/sized transactions, giving the appearance of a broken network (it's functioning fine, as intended, if a bit slow if you don't over pay in fees).  While people carry out these "attacks" as some call it, they are attempting to sell you a competing product - theirs.  To quote ViaBTC: "if it looks like shit, and smells like shit, you don't have to taste".

That is the pont if you don't pay the high fee, you'll have to wait. You are buying priority like buying a business class ticket vs economy ticket, same destination but different conditions. It's a peer to peer cash system, not a special service to buy premium features, so everybody should have the same conditions and the tx selection for blocks should be based on a criteria where everybody is equal or costing them proportional to their consumption in value not size. I am sorry if my debate is not practical or stupidly idealistic.

@DanielMorritt "some rich folks are degrading the service by artificially making large number of/sized transactions" do you have any proof of this?

@thefrogking It's a peer to peer cash system, not a special service to buy premium features, so everybody should have the same conditions and the tx selection for blocks should be based on a criteria where everybody is equal or costing them proportional to their consumption in value I can start from the same assumption and ask: It is an electronic transaction, so it does not matter how much money am I transferring. The fee for transferring 500b of data over the internet should be the same. It does not matter whether I transfer 1$ or 500$

@SalvadorDali http://www.nasdaq.com/article/the-curious-case-of-bitcoins-moby-dick-spam-and-the-miners-that-confirmed-it-cm852087 read the bit about the fan out, and fan in. https://twitter.com/sbetamc/status/943691309734420480 has a visualisation and https://www.blocktrail.com/BTC/tx/4adb8664a91e92d67864962636d4c8ee8c9ed1ac86c22cc194fc287afc5af4ff is an example transaction of a "fan in".

Thre have already been suggestions to improve transaction selection, on a FIFO priority with added fee priority method (actually it is prioritisation based on fee and wait time - the higher the fee and the longer the wait the more likely a transaction is to be included in a block), but for this method be implemented in a workable manner other changes are also necessary.
Fees have always been included in Bitcoin, it is not a new idea since the beginning. I have always thought of it as a user-pays system but more recently learned it is, in fact, a limited-bandwidth auction model. That is why most recently fees have seemed so high.
Since it is always necessary for miners to be paid for their work, it is not unreasonable for fees to be introduced so early, to allow time for the model to stabilise before block rewards are altogether gone in 2140.

It's like offer and demand.
The offer is limited because the blocksize (and so the transactions per Second) are limited.
But the demand is not limited. It rised because the bitcoin became more popular the last months.
And when the demand is high but the offer is low, the price rises. In this case, it's the price per transaction (fee).


text:
How can all possible numbers in 256-bit space be squeezed into 160-bit space?
Bitcoin addresses are essentially 160-bit hashes of a 256-bit public key. Huh? How can all possible numbers in 256-bit space be squeezed into 160-bit space? Does that mean any given bitcoin address could be derived from more than just one public key?

I’m not sure I understand your question but if it means what I think it does then it will be beneficial for you to read about hash functions in a general setting. They are by design non injective (since they have a finite codomain and a larger domain) meaning there will be two different inputs that hash to the same output but a good hash function is designed so that the probability of one person being able to find two such inputs is epsilon small

It's really 160 bit hash (RIPEMD160) of an already hashed (SHA256) public secp256k1 elliptic curve key. And yes, on the average, every address has about 2256-160=296 pairs of private/public keys.

There is a possibility that it might be easier for quantum computing to 1st identify any one of the overlapping 2^96 public keys, with an already known companion private key, satisfying the associated P2PKH transaction redemption criteria than trying to factor a 256-bit private key.


text:
How to transfer bitcoin bought online to my desktop wallet?
Based on popular recommendations, I have started with Electrum as my Ubuntu desktop wallet and Coinbase as the way to buy bitcoin online.
However, it doesn't seem like there is an easy way to transfer bitcoins from Coinbase to Electrum (not without using a paper wallet).
Is this correct? If I want to conveniently buy bitcoins only, but want to securely store them on my own offline hard drive, what's the best way to do it?

Coinbase allows you to send all your bitcoins to your local Electrum wallet. I think it's in the "wallet" tab on your accounts page.

You can easily send your bitcoins from Coinbase to Electrum.
Once logged into Coinbase click on the Send / Request button on your left hand menu. A form will pop up asking for an email address or bitcoin address.
What you want to do is enter in one of your bitcoin addresses from Electrum. Open up Electrum and click on the tab labeled "Receive". You can pick any address that is listed there under Main Account > Receiving.  Pick one, copy it and paste it in the Coinbase form that asks for an email address or bitcoin address.
From there just complete the form and hit send. Your funds will now be transferred to the address on your Electrum wallet. Be sure to back up your wallet and seed. If your computer crashes/breaks and you don't have a back up YOU WILL LOSE ALL OF YOUR COINS.

I did this today and the procedure is currently (2017-10-31) as follows (Electrum 2.9.3):
Prepare Electrum to receive
* Make sure Electrum is online (green icon bottom right)
* Click 'Receive' and copy the receiving address to your clipboard (there's a little blue icon for that at the right)
Go to Coinbase to send
* Click on 'Accounts'
* At the bottom of the BTC Wallet section, click 'Send'
* Paste the address you copied from Electrum
* Specify the amount of BTC you want to send, click Continue
* In the next window, enter the confirmation code which Coinbase sends by SMS, and click Confirm
Coinbase will now show a window confirming the transaction.
Go back to Electrum and wait until it confirms there the BTC has been arrived. You can check that under the tab 'Addresses'. Note: Electrum shows mBTC.
Coinbase also provides a link to BlockCypher where you follow the transaction.

Also note that it takes time to process the transaction, in my case it took about two hours to receive the confirmation.


text:
Closing address of a Lightning channel
I would like to know if it is possible when closing a Lightning channel to specify an address to retrieve other than the default one?
Thank you in advance for the answers.

Are you asking if this is possible in general per the Lightning protocol, or are you asking for instructions on how to achieve this? In which case, what Lightning node software are you using?

I was wondering if it was possible in general?

Yes, it is possible!
In BOLT 2 you have a shutdown message that looks like this
type: 38 (shutdown)
data:
[channel_id:channel_id]
[u16:len]
[len*byte:scriptpubkey]

The scriptpubkey does the trick. This is trivial.
But the really good thing that you can do with lighting is when you open a channel, you can specify the address where you want to close your channel. So, in this way, you can lose your channel key and when the counterpart force closes the channel, you can take back in a cold wallet the UTXO
You can check this feature inside the open_channel In particular in the TCV types
types:

type: 0 (upfront_shutdown_script)
data:
[...*byte:shutdown_scriptpubkey]


text:
2011 bitcoin HUNT
I am here for some help. I bought bitcoin in 2011 and I unfortunately can't remember for the life of me which wallet I kept it in. I am hoping maybe someone can give me a little guidance. If I had bitcoin core wallet back then how would I access it today? In 2011 was there a seed phrase? Would it have been saved straight to my PC? Any direction will be greatly appreciated and of course anyone that provides me with any useful info that leads me to getting my wallet back a reward will be in store.

Does this answer your question? I have lost my wallet, what can I do?

Try blockchain.com
They used to be blockchain.info
You can go to login and check if you have any wallet ID associated with your mail.
You can also check if you got any mail from wallet@blockchain.info way back
Good luck