text:
Is it possible to reduce the field size without disrupting generation of public keys?
I have a curious question, i am aware of the curve parameters of secp256k1. i was wondering if its possible to reduce to field to a 130 bit or lower without disrupting the actual functionality.. what i mean by this is the actual generation of secp256k1 public keys should not be disrupted.

i was wondering if its possible to reduce to field to a 130 bit or lower

No, that would be woefully insecure. The security of elliptic curve cryptography scales with the half of the field size. A 133-bit curve would only have 66.5-bit security. That means that with ~266.5 curve operations one can compute the private key for a given public key. This is tiny amount of work for a competent attacker.

without disrupting the actual functionality

Even if it weren't a terrible idea, this would be an extremely invasive change, requiring the entire ecosystem to adopt and switch to a different, smaller, curve. All Bitcoin software would need to adapt.
As far as I know, there aren't even any recommended standardized curves with a size below 160 bits.

what i mean by this is the actual generation of secp256k1 public keys should not be disrupted.

If this were possible, the Bitcoin ecosystem would already have embraced it. secp256k1 uses a specific finite field, the integers modulo 2256 - 232 - 977. If you use a different field, it's a different curve, with different private/public keys and everything.

"there aren't even any elliptic curves standardized with a size below 192 bits" what about secp160k1?

@VojtěchStrnad Huh, fixed! I had checked https://www.secg.org/sec2-v2.pdf and didn't see anything below 192 (I guess secp160k1 got removed?).

Yes, it's from SEC 2 Version 1 (https://www.secg.org/SEC2-Ver-1.0.pdf) which goes as low as 112 bits with secp112r1 and secp112r2. Yikes.


text:
Can two people generate the same exact wallet or seed phrase
Can 2 or more people generate the same exact wallet. And if so, what happens then?

Also see: Is each Bitcoin address unique? How does the Bitcoin protocol deal with address collisions in wallets?

Thanks @VojtěchStrnad, I voted to close as a duplicate and also added the other two questions you proposed to the duplicate targets.

Yes it's possible. One of them would spend the coins if it happens.
Recent example: https://www.cve.org/CVERecord?id=CVE-2023-39910

It's only realistically possible with broken random number generation.

source: Stack Exchange

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

sort: votes


text:
Cannot find bitcoin.conf on macOS
I want to run a pruned node. I mistakenly referred to a guide for a full node to connect to Sparrow wallet, which required adding server=1 and txindex=1 in the bitcoin.conf file. I reached this file by opening preferences in the Bitcoin Core menu on a Mac.
Now Bitcoin Core will not run as the error repeatedly appears that a pruned node is incompatible. My issue is I can not locate the bitcoin.conf file in order to remove the txindex=1 or perform whatever fix is necessary. I have attempted the typical paths suggested on all guides for a Mac and cannot find a way to open this file let alone locate it.
I have tried deleting Bitcoin Core and redownloading but the same error appears after opening.
I would love some assistance to figure out how I am able to run my pruned node or at least restart the whole process again.

Does this answer your question? Where is bitcoin.conf location on MacOS with Bitcoin core v0.15.1

Does this answer your question? Where is the data folder for Bitcoin-Qt?

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


text:
Bitcoin API with bech32 support
Since a while, I have been using the insight-api to view bitcoin transactions. However, recently I have found out that bech32 addresses are not supported.
Now I try to fix this issue and I am open for any suggestions.
It there some other suitable api that also supports bech32-addresses? Or, also appreciated, is there some workaround available for the insight-api

There are bunch of blockexplorer APIs that support Bech32 addresess:

Blockonomics
ChainFlyer
BTC.com

It looks like bitcore replaced the insight-api

Does this mean there is a new api for bitcoin? Isn't bitcore another crypto-currency?

No, these are all just different implementations of the bitcoin core protocol. Just like how you can use Google Chrome or Firefox to access the web, you can use insight-api or bitcore to access bitcoin data.

Thanks for the comment! This makes it clear to me.


text:
OP_CHECKLOCKTIMEVERIFY . Include / reject or will not included in block?
What happened if I translate to network transaction with the folowing redeem script:
[now + 3 months] CHECKLOCKTIMEVERIFY DROP
DUP HASH160 [Bob's Public Key Hash] EQUALVERIFY CHECKSIG

This tx will be accepted (included in block) and after 3 month Bob can spend bitcoins?
Transaction will be rejected, and can only be accepted by the network when 3 month is reached?
Transaction will be accepted immediatly, but can be confirmed (included in block) after 3 month ?

Does it depends to input script (scriptsig)?
If yes, can you provide an example pls?
According to wiki, I just need to push some value to stack?

A transaction with a CLTV output can be created at any time, and can be accepted and confirmed immediately.
Spending such an output requires a transaction whose nLocktime field is at least the CLTV-specified time. That transaction will only be accepted and confirmed when its nLocktime field matches the real time.


text:
Why is it so hard for alt clients to implement Bitcoin Core consensus rules?
I understand that one can never be certain that an alt Bitcoin client is fully in consensus, but what is it about the consensus rules that makes them so hard to implement in other clients?

Because they're not known.
This may sound surprising, but you have to realize that Bitcoin's consensus rules are defined by what (economically relevant) full nodes actually enforce. We can assume at this point that that is mostly various versions of Bitcoin Core, and derived projects, but that may change over time.
However, they are certainly not defined by some document that people blessed into being the rules. Even if we would somehow create such a document, and everyone would agree to it, what would happen if we realized that there was a bug in actual implementations? In that case, you could call the implementation buggy, but you can't just change it. Any (uncoordinated) change to implementations could result in them ending up in their own fork, resulting in all preexisting coins being spendable twice on each side (the precise thing the blockchain was designed to prevent). Thus, in such a situation there would be no choice but to change the document. Essentially, Bitcoin's consensus rules can be described, but not prescribed.
All of the above is to illustrate that it is not sufficient to replicate any specific intended behaviour; you must mimic the exact behaviour of existing software. You must:

Accept every valid block, but also reject every edge case exactly that causes rejection.
Guarantee that nodes can find each other.
Guarantee that nodes continue to download blocks from each other in various circumstances.
Prevent transitive disconnects/bans (A should not be able to relay a block to B – which possibly runs different software – in such a way that when B relays it to C, C disconnects or bans B).
Take performance considerations into account. If a block or transaction can be constructed that takes a significant amount of time to validate, you simplify selfish mining attacks. If validation time can be caused to take close to the block interval time (10 minutes), convergence across the network may fail entirely.

Even worse, all of these properties must be maintained under adversarial circumstances. Blocks may not only contain randomly stumbled-upon edge cases; people may actively try to trigger them.
Mimicking the behaviour of software exactly is a very hard problem. While there is some progress in the field of provably correct software (which includes proving equivalence between two programs), it is nowhere near advanced enough to apply to something like Bitcoin's consensus rules. As a result, the only approach for replication is reimplementing the rules as you believe they are implemented already, without strong methods to guarantee you're right.
In short, in order to replicate the behaviour, you must know the existing behaviour. And history has shown that in many cases, the existing behaviour is not exactly known:

The OP_CHECKMULTISIG redundant stack pop. This one has been known for a long time, but it probably was not known in the first months or even years of Bitcoin's history. The OP_CHECKMULTISIG opcode pops one more element off the stack than needed. People have worked around it by pushing an extra OP_0 when spending a multisig output. BIP 147 has been proposed to require that to be an OP_0 even. In Bitcoin's early days, a reimplementer would likely have incorrectly replicated this.

Compressed and hybrid public keys. According to various specifications, secp256k1 public keys can be encoded in uncompressed, compressed or hybrid formats. Bitcoin initially only used uncompressed keys (comments in the source code indicate that the original author of the software was not aware of compressed keys), but as every node at the time was using OpenSSL for validation, people were able to just start using compressed keys and the network accepted them. In this case, an unknown part of the rules was 'abused' for an improvement.

OP_SIZE does not pop the stack. All opcodes that inspect a stack element also pop that element. There is one exception to this (OP_SIZE), which at least one reimplementation got wrong.

The distinction between signature validation failure and script execution failure. Some reimplementations have initially treated signature failures as script failures (which is a correct assumption for almost all scripts, but not all). Consider a script of the form <pubkey> OP_CHECKSIG OP_NOT. This is a script that consumes one signature from the stack, and requires a signature that is invalid in order to pass.

Serialized size vs. normative size. Various resource limitations exist on the size of blocks, transactions, scripts, ... However, these sizes are defined in terms of the number of bytes that would be produced by serializing the data structure. Sometimes, multiple valid serializations used to exist. At least one reimplementation for a period of time used the size of a block – as sent on the wire – to check against the block size limit. However, a 999999 byte block could have been sent using a longer-than-necessary serialization of the number of transactions in it, resulting in perhaps 1000001 bytes. This is a valid block, but the reimplementation would reject it.

OpenSSL's inconsistent DER parser. OpenSSL used to support signatures encoded using various deviations from the DER standard, often with arbitrary restrictions and weird differences (an integer could be encoded as a struct containing an integer), implemented in thousands of lines of hard to read C code. At the time, every reimplementation that did not use OpenSSL could have been trivially forked off by creating a transaction that abused one of those weird deviations. This is a very good example, as it is likely that nobody ever exactly knew what OpenSSL accepted and didn't. This was eventually fixed by BIP66 which made signature parsing much more restrictive, and allowed us to move away from OpenSSL after it became a network rule.

OpenSSL signature parser inconsistency. The OpenSSL signature parsing story goes further: it was discovered that one of its permitted DER deviations was platform dependent. A particular length descriptor was allowed to be up to 4 bytes on 32-bit systems and 64-bit Windows, and up to 8 bytes on others. This resulted in Bitcoin Core instances on different platforms to be inconsistent with each other even, much less be consistent with reimplementations at the time. This discovery was indirectly fixed by BIP66 as well, by requiring that the shortest possible length descriptor be used. The full timeline is in this disclosure.

The BDB lock limit. Early versions of Bitcoin Core (before it was called that way), up to version 0.7.x, used a chainstate database implemented in BDB. BDB is a multi-process database environment (something we don't need) that needs a preallocated number of locks to prevent concurrent access to records and deadlock detection. Turns out that the number of locks chosen was mostly enough for processing Bitcoin blocks, until one unfortunate block on March 11th 2013. This was a block with a remarkably large number of inputs (and few outputs), resulting in way more transaction records in the database model of that time being affected. The preconfigured number of locks was exceeded, the database operation failed, and Bitcoin was unable to process that block. As a result, a fork appeared. It was compounded by the fact that many miners had already upgraded to version 0.8.0 (which used LevelDB and no longer had this lock limitation), while many other nodes had not. More information can be found in the post mortem document BIP50.

... Who knows which things we don't know about yet?

For additional reading/listening Pieter discussed this on the Chaincode Labs podcast: https://btctranscripts.com/chaincode-labs/chaincode-podcast/2020-01-28-pieter-wuille/ And Christopher Jeffrey discussed it at SF Bitcoin Devs: https://btctranscripts.com/sf-bitcoin-meetup/2016-09-28-christopher-jeffrey-bcoin/

As in many computer science problems, you can solve 99% of the problem and yet only have expended 1% of the necessary effort to solve the entire problem.

Maybe worth for someone to update this answer with the other reimplementation failures we've seen in the wild since it was written? For instance the BTCD witness deserialization bug (https://bitcoinops.org/en/newsletters/2022/10/19/?ref=nobsbitcoin.com) which led it to refuse a perfectly valid Bitcoin block.

Another one. Self plug but figured it was worth sharing. Btcd did not reimplement FindAndDelete correctly. https://delvingbitcoin.org/t/cve-2024-38365-public-disclosure-btcd-findanddelete-bug

Niklas Goegge also found a few bugs in the in-development libbitcoin v4 codebase where they decided to reimplement the Script interpreter from scratch: https://github.com/libbitcoin/libbitcoin-system/issues/1523 and https://github.com/libbitcoin/libbitcoin-system/issues/1526 .

Another old one is a reimplementation bug in bitcoin-ruby discovered by Peter Todd: https://bitcointalk.org/index.php?topic=260595.0 .

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


text:
Do all block explorers show all unconfirmed transactions?
If I want to show someone that I just made a transaction without showing them my wallet, could I expect that it would be recorded on a block explorer immediately?

There is no guarantee that a transaction propagates through the network at all.
Blockexplorers can only show transactions that they see. They're often configured in a way that will make them be more likely to see transactions, however.

Yes, all the block explorers* I know will show unconfirmed transactions as soon they pick them up in the network. If "someone" is the recipient, his wallet will also show the unconfirmed transaction.
*I don't know all blockchain explorers on the internet, but all the big ones I have seen (this list for example) have this behaviour.

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


text:
Custom signet without importprivkey
To deploy a custom signet miner the instructions at https://en.bitcoin.it/wiki/Signet rely on the deprecated importprivkey rpc method.
Is there an alternative approach so that the private key can be seeded or imported so https://github.com/bitcoin/bitcoin/blob/master/contrib/signet/miner script can still be used?

In the end I just enabled legacy wallets with the setting below:
deprecatedrpc=create_bdb

It would still be good to know if a custom signet can be enabled with Bitcoin Core's default HD wallets.


text:
How is Transaction malleability affected by SIGHASH flags?
SIGHASH flags allow for the flexible alteration of a transaction.
Given that there are legitimate usages of SIGHASH, and changing a Tx (and presumably the TxID as well), what is the correct way of using Sighash w.r.t. a TxID and tracking its progress?
What malleability risks do SIGHASH transactions incur by virtue of their usage?

SIGHASH flags allow for the flexible alteration of a transaction.

Yes, but the SIGHASH types mainly allow for incremental progress towards creating a full/final transaction, such as combining multiple transactions signed with SIGHASH_SINGLE. Once the transaction is fully created, there are certain tweaks that can be done to it that don't invalidate the tx but change the TxID, and these tweaks can be done regardless of how it was signed.

What malleability risks do SIGHASH transactions incur by virtue of their usage?

I think the SIGHASH signing types allow for the alteration of transactions before they are final. Once a transaction is final, the malleability issues persist regardless of how it was signed. In fact, ECDSA signing itself (regardless of which SIGHASH type is used) is non-deterministic, so you could sign the same transaction twice and distribute them, and they would both be valid (but conflicting), but have different TxIDs.

Given that there are legitimate usages of SIGHASH, and changing a Tx (and presumably the TxID as well), what is the correct way of using Sighash w.r.t. a TxID and tracking its progress?

To track a transactions progress, you will probably need some other way to identify the transaction other than the raw TxID (double hash of tx data). i.e. Some number associated with a transaction that is passed around to all who are editing it, or keeping track of the outputs of the transaction.

need some other way to identify the transaction other than the raw TxID Perhaps you could identify transactions by signature hash?


text:
Gitian building not working
I followed this instructions https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md
but on this step: https://github.com/bitcoin/bitcoin/blob/master/doc/gitian-building.md#setting-up-the-gitian-image
i have got an error:

cp: cannot stat
  ‘base-trusty-amd64-bootstrap/usr/lib/x86_64-linux-gnu/lxc/lxc-init’:
  No such file or directory debian@debian:~/gitian-builder$

How to fix it?

install 64 bit libraries

Commenting from far in the future for anyone coming across this today. Bitcoin Core now uses Guix for bootstrappable builds. This gist shows the practical workflow.

Gitian has a couple of different virtualization modes, each with their own quirks and issues. It appears that you are using LXC, which in my experience, no longer works.
You could try the same commands with KVM mode (drop --lxc and don't set USE_LXC=1) or docker mode (use --docker instead of --lxc and set USE_DOCKER=1 instead of USE_LXC). I have found that the docker mode is much more reliable since all of the setup for the container is handled by other projects.
For building older releases, you may need to slightly modify gitian-builder to use different apt package sources as Ubuntu moves them to their archival locations.

For building more recent versions of Bitcoin Core, Gitian has been replaced with Guix. But it's still useful for those who are interested in building older versions of the software.

you have to make sure you are using AMD64 version of debian jesse


text:
What is the rate limit of the Esplora instance blockstream.info
Blockstream.info provides a free API, for example: https://blockstream.info/testnet/api/tx/d4b1add055db58343500157a6525a73ceb9c8850f0fb435f1f60071e8cad6540
I would like to know what the rate limit for this Esplora instance is?

Does this refer to https://github.com/Blockstream/esplora ?

@RedGrittyBrick Yes, but I'm asking about Blockstream's service which might use different rate limiting than the default?


text:
Is there a point on the secp256k1 curve for any given X coordinate?
There function in libsecp256k1 that allows you to directly set the field element to 32 bytes of your choice. Does secp256k1 always return a valid group element for any 32 byte value?

secp256k1_fe_set_b32(&xpoint, bytes)
secp256k1_ge_set_xo_var(ge, &xpoint, 0)

The size of secp256k1's coordinate field is 2256 - 232 - 977.
That means there are only 232 + 977 (about 4 billion) possible 32-byte combinations that are not a valid coordinate.
Only slightly less than half (around 2255 - 1.17 * 2127) of those are the X coordinate of a point on the curve (in fact, for every valid X coordinate, there are either exactly 0 or exactly 2 points on the curve).

Could you elaborate how you arrived at "around 2^255 - 1.17 * 2^127"?

I divided the curve order by two. You can find the curve order in the secp256k1 specification, or you can compute it using mathematical software like Sage.

FWIW, that order (=equal to the number of points on the curve, including infinity) is 115792089237316195423570985008687907852837564279074904382605163141518161494337.


text:
Bitcoin private key and address generator in golang
I am looking for a golang alternative to https://github.com/richardkiss/pycoin . So far I have found https://github.com/btcsuite/btcd but have not figured out how to generate private keys and addresses using btcd. The Python pycoin has a very handy ku utility to generate private keys and addresses from integers.
Is it possible to generate private keys and addresses from integers using https://github.com/btcsuite/btcd ?
TIA.

btcd does no support this functionality by design, however you can use btcwallet which is written in golang and support what you want
https://github.com/btcsuite/btcwallet
here is a similar question https://github.com/btcsuite/btcd/issues/1308


text:
How do I view information on the peers my Bitcoin Core full node is connected to?
I would like to view information on the peers my Bitcoin Core full node is connected to. How do I do this?

As 0xB10C posts here you can get a peer dashboard to bitcoin-cli that looks like this.

You can get this dashboard by using
watch ./src/bitcoin-cli -netinfo 4

and you can use the -asmap flag too.
This netinfo feature was merged into Bitcoin Core in September 2020 and is included in the release of Bitcoin Core version 0.21 . (The feature was built by Jon Atack.)
Additional guidance for using this feature was added in this PR.


text:
How to know my ip address in network
With getpeerinfo command I can get all directly connected peers ip addresses, how to know mine in the bitcoin network?

getnetworkinfo will tell you the IP address of your node if it knows what it actually is (or thinks it knows). It will be in the localaddresses field. Note that it may not contain your IP address or have the right IP addresses as it is difficult to know what your IP address is unless someone external tells you what it is.

What I am trying to do is to connect to other node with -addnode, or -connect options, but the question is how to know other nodes address. Both nodes are mine.

The node's IP address is the IP address of the machine it is running on. On that machine, you can go to a website like https://www.whatismyip.com/ to find your IP address.

So if I have two different bitcoin nodes running in different networks I can use their external ip-s to connect them?

Yes, you use their external IP addresses. Connecting them works in the same way that other nodes connect to your nodes.

Strange thing is that after addnode I am checking the status with getaddednodeinfo but 'connected' is always false.


text:
Who can see my IP address while using Electrum
Who exactly is my IP exposed to when sending transactions in Electrum.  I'm assuming the server operators can see it every time I connect (to query the servers about my balances).
When I make a transaction, is my IP recorded and logged into blockchain.info (or is it the IP of the server who relays the transaction).
If so, does this make Electrum unsafe to use with larger balances? i.e tying large amounts to a single IP?

Your IP is exposed to the Electrum server(s) you communicate with. Since anyone can run an Electrum server, you should consider this to be public exposure. These servers could record your IP if they wish to, and use it for any purpose. This is more exposed than running an ordinary full client: in that case, your IP is exposed to your peers, but even your immediate peers don't know it was you who created a given transaction. In either case, someone could record the IP they first saw the transaction from, which would often be geographically near you (maybe even your IP).
This does not make it unsafe in the "people can digitally steal my coins" sense, but it does reduce anonymity. This might make it unsafe in the senses of: "people can more easily find me and beat me until I tell them my password so they can steal my coins" or "people can arrest me for my actions" (if you're doing something illegal).
If you're concerned about that, you could run through Tor to hide your IP.

In addition to using Tor there are some servers that run as hidden services .onion

While using Electrum, your IP address can be seen by the Electrum servers you connect to for transactions and blockchain data. To enhance privacy, consider using a VPN or Tor.


text:
Where can I access the original, Satoshi written Bitcoin code?
The articles of https://bitcointalk.org/index.php?topic=41718.0 seem to be annotated walkthroughs, and I'd like to see the raw code, as it was originally written in the first release.

This claims to preserve it without source: https://github.com/trottier/original-bitcoin

The Bitcoin client has been hosted on GitHub for a while now. It's very close to what Satoshi initially wrote. Here's the first commit dated back to 2009: https://github.com/bitcoin/bitcoin/tree/4405b78d6059e536c36974088a8ed4d9f0f29898
You could also browse all the commits from way back: https://github.com/bitcoin/bitcoin/commits/master?page=151
Some other research points me to the actual first email sent to the cryptography mailing-list by Satoshi where he actually delivered the 0.1 version: http://www.metzdowd.com/pipermail/cryptography/2009-January/014994.html
Here's the direct link provided by Satoshi but it doesn't seem to work anymore: http://downloads.sourceforge.net/bitcoin/bitcoin-0.1.0.rar
Googling a bit I found this, which is what you're looking for: https://bitcointalk.org/index.php?topic=68121.0

So earliest on github is - https://github.com/bitcoin/bitcoin/tree/v0.1.5

This page contains files for the first three available Bitcoin codebases written by Satoshi Nakamoto.
http://satoshi.nakamotoinstitute.org/code/

Here is the first version uploaded to sourceforge:
https://sourceforge.net/p/bitcoin/code/1/tree//trunk/

As it indicates, they has been added by Martti Malmi (2nd bitcoin developer), Its not added by SN.

We are developers & we'd better speak accurately. I've always been grateful when someone has helped me correct myself by giving hints. I didn't intend bothering you, so I guess you'd better consult Code of conduct one more time. Thanks in advance.


text:
Understanding IP address tracing via Bitcoin Transaction
I recently met a person who helped police track the IP address of a Bitcoin transaction. I wanted to learn more about it but he didn't have time to discuss about this topic in the meet.
I am curious in understanding how cryptocurrency transactions can lead to trace back of the IP address from which the transaction originated.
How does this stuff work?
EDIT
IP address is bold because I do not mean wallet transaction address.
I know originating wallet address can be traced back with blockchain.

I have no doubt that the person claimed they were tracing the IP address...but like with Andrew's answer, I'm skeptical.

If an entity runs a large amount of relay nodes on the network, they could figure out which of their nodes was the first to see a transaction, and which peer that transaction came from.  That does not necessarily tell them the originating IP, as it could have been a a node relaying a transaction rather than sending one.
This leaves a large amount of uncertainty in the trace.  Due to the decentralized nature of Bitcoin, no single entity is likely to be in control of the majority of relay nodes.  Let's say, for arguments sake, that there is a company that runs 40% of all relay nodes.  They have a very good chance that a wallet sending a transaction is directly connected to one of their nodes, and therefore they can work out the originating IP.  But what about the other 60% of nodes?  Can they ever say for sure that a transaction didn't bounce around the other 60% for a few hops before they saw it?  No, and odds are petty high that just that happens often.  And to my knowledge, no single entity runs that many nodes.
Point is, the more relay nodes there are, the less possible it is to trace an originating IP address.

And that's without beginning to consider the effect of onion routing if the originating node is using Tor.

I find that claim (tracing the IP address of a transaction) highly suspect as transactions don't have an IP address associated with them. Once a transaction has been broadcast, it is incredibly difficult to figure out what IP address first sent the address. To do so requires that you have a connection to every single node and wallet and determine the IP address by seeing which node first broadcast a transaction. Otherwise you cannot figure out what IP address a transaction originated from.
The person you met may have meant that he traced the Bitcoin addresses in a transaction to figure out who spent created the transaction. That is far easier to do and far less expensive as you only need a copy of the blockchain to do so.

Actually www.blockchain.com used to have this at the bottom for each address:

"These IP addresses were the first to relay a transaction involving the selected address. It does not necessarily mean they are the transaction's owner."

I think what they did is to simply record what IP the txid came from, and having many nodes could give you a good guess. But never 100%

Thats not 100% accurate it all depends on the platform and device along with many other variables like for a quick example if on the victim device and it was there coinbase account that was compromised then yes it is very possible to trace the IP plus there are other ways as well they may be long and tedious but like my momma always told me use the internet as you would talk to god because its there for people to see forever don't really know why she said that never went to church lol I don't think I've found anything yet that trully is anonymous the ones running this circus would never let privacy ever happen they know that when were not distracted and gather in groups in private we share knowledge and are not so blind and if we see things for what they really are we are a threat everything is just a security blanket so you feel safe just like Delete/Format is a joke anything can be recovered  how many of you read the privacy policy really good for the default keyboard on your cell phone just your default onscreen keyboard thats just the tip lmao oh and thats old stuff were in the age of A.I. in everything

Welcome to [bitcoin.se]! I feel like your answer would be a lot better if you cut down on the fluff ...


text:
Which opcodes where disabled by Satoshi Nakamoto for cve 2010 5137
Lot of opcodes where disabled over the years.
But which opcodes where disabled Satoshi himself and specifically for the any one can spend any coin bug?

You can find opcodes disabled by cve-2010-5137 in bitcoin core, where script interpreter throws SCRIPT_ERR_DISABLED_OPCODE error.

specifically for the any one can spend any coin bug?

I guess what you ask is about 2 fatal bugs in very early version of bitcoin, which did not disable opcodes but changed how interpreter works. Related opcodes are OP_RETURN and OP_CODESEPARATOR, but those are not disabled ones. There's already good answer from old post of here, which demonstrates how to exploit.


text:
Does a P2PKH transaction send to the hash of the uncompressed key or the compressed key?
Simple question but I didn’t find a reference. Is it the compressed public key that is used or the uncompressed public key ? Or can it be both ?

As far as Bitcoin's consensus rules are concerned, compressed and uncompressed keys for the same private key, are distinct keys.
The answer to your question is: whatever the receiver's wallet uses. As the receiver is also the one who creates the address generally, the sender does not need to know or care about this. New software should generally only use compressed keys, as they are cheaper at spending time.
In P2PKH both can be used. In P2WPKH only compressed keys are allowed by policy. P2TR uses a different (x-only) type of key altogether.


text:
Migrate from blockchain.info to bitcoin-qt
I currently have my wallet with blockchain.info.
Is there any way that I can import this address into the bitcoin-qt client?

Its best you don't reuse addresses anyway so there is no harm in just moving your coins across to a new wallet.

Plus, you can be sure that actually nobody grabbed the private key of that address from your browser or from Blockchain.info.

Login to your blockchain.info wallet
Select Import/Export
Select Export Unencrypted
Select Bitcoin-Qt Format from the drop-down list

You'll then see information that look like this:
"priv":"5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS"
Ignore the other information, what you're looking for are your private keys that look like this: 5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS
Then just follow Rick's instructions to import each of your private keys into the Bitcoin-Qt client:

Run Bitcoin-QT
Select Help (to the right of Settings)
Select Debug Window
Select Console
Next to the > input box type importprivkey <bitcoinprivkey>

Example: importprivkey 5KJvsngHeMpm884wtkJNzQGaCErckhHJBGFsvd3VyK5qMZXj3hS


text:
What if the miners allowed invalid transactions, and other nodes did validation?
Here Peter Todd writes:

[A]s an optimization
  Bitcoin goes a step further and disallows invalid transactions to be published
  in the blockchain at all, but that's the thing: that's just an optimization
  that full-nodes don't actually need to operate.

Maybe I'm misunderstanding this, but it seems to be an interesting idea: the blockchain can contain invalid transactions, but all validating nodes will ignore them. I'm thinking, what if bitcoin was designed this way, or if someone created such hard fork, could it work? If yes, what drawbacks should be expected?
Correct me if I'm wrong, but probably Counterparty already works in this way, since they use bitcoin blockchain.

I'm thinking, what if bitcoin was designed this way, or if someone created such hard fork, could it work? If yes, what drawbacks should be expected?

There are two I can think of:

No SPV
Right now, to trick an SPV client, you need to get 51% of miners to include an invalid transaction. However, if all miners include all transactions, then SPV is not possible.
No safe softforks
P2SH was a softfork that made it possible to send money to a hash of a script. If you didn't run P2SH enforcing code, enough miners ran it that your node would still agree with everyone else.
However, if rules are not miner enforced, then two clients running slightly different code can look at the same blockchain and get two entirely different pictures of who owns what.

Last point is very solid, but I think bitcoin has or will have similar problem with fungibility: e.g. exchanges which don't want to share btc-e destiny will avoid accepting provably stolen money. OTOH, it doesn't actually mean the lack of consensus on blockchain.

I believe Peter Todd was talking about a model where transaction validity is not part of the consensus rules, and nodes simply ignore transactions that are in violation, rather than rejecting the chain entirely.

@PieterWuille Right. I think that's what he meant too.


text:
How to test your Litecoin mining hash rate?
I don't know if there exists a service to quickly check what your mining hash rate is for Litecoin as the following does for Bitcoin
http://bitminter.com/test
I'm looking for something that doesn't require to install or configure anything, or if necessary to do so with the less possible fuss.
Any ideas?

You can go to https://litecoin.info/Mining_hardware_comparison and see the hashrate corresponding to the equipment you have, assuming you know what is inside your computer. Actual results may vary, but usually this is a good estimate. Of course, if you overclock, you will get better hashrates, at the cost of increased power usage. If you want to actually mine, you will need to register at a mining pool and configure your miner to log in to said pool. The website you linked uses Java code to test hashrates, and this will not give accurate results (even for Bitcoin), as Java is usually slower than machine language.

So the Java test is useless to test actual mining rates, and nothing beats actually joining a pool and mine? :( I had seen the "mining hardware comparison" page above, since it lists 4 different hash rates for Radeon 7750 (and I understand a number of configurations can modify the rate further) I wanted to get actual numbers without having to install or configure anything.


text:
Understanding transaction with hundreds of inputs and outputs
I've been trying to follow a transaction with hundreds of inputs from different addresses and hundreds of outputs.
This is the transaction I'm looking into:

https://www.blockchain.com/explorer/transactions/btc/0adc86b59ef3329c3d85eaafbde3ef071c6030e3b58386980e3122a68f679eef

I understand how a "basic" BTC transaction works but I can't find any reference to these types of TX around. Any reference or explanation that could lead me in the good direction would be appreciated.

You are looking at a CoinJoin transaction, likely created by Wasabi. It's a type of collaborative transaction that mixes the funds of many users together to break the links between individual inputs and outputs in order to improve each participant's privacy.
As an example, consider the first two inputs (21.47483648 BTC each) and first two outputs (20 BTC each). You could reasonably assume that these each belong to the same pair of people, but there is no clue as to which of these two is the owner of which output. There is of course much more going on here, seeing as the transaction includes a few hundred inputs of multiple different denominations, but this is the basic principle of CoinJoin.

Ok, thanks for the explanation, this is what I was expecting but needed confirmation of what I was understanding. As this is transaction is involved in a BTC theft is there any way of tracing this kind of TX having that the same address made many TX like this one?
One approach I was thinking is following dest addresses and look for coincidences or something in that sense, but want to ask for potential known ways to do it.

I'm sorry to hear that, but in most cases there is no point in trying to recover stolen bitcoin, the money is gone. Also see: How do I recover from a cryptocurrency scam?

Yes, I understand it's almost impossible to recover the funds, I'm just interested in tracking the funds for educational purpose alone.


text:
File format -- rev*.dat
Can anyone help me to find out the format of rev*.dat file?
There is an array with [F9BEB4D9 + 32byte number + variable raw data] for each element.
What is that 32b number? And may be how to understand what is the other variable data?

The rev*.dat files (the "undo files"), contain all UTXOs spent by the inputs of a block. It was introduced in Bitcoin Core 0.8, and contains a concatenation of records, one for each block. This mimicks the structure of the blk*.dat files which contain blocks.
Each block record consists of:

4 bytes: network magic (0xf9,0xbe,0xb4,0xd9)
4 bytes: size of the CBlockUndo record (LE32)
data_size bytes: CBlockUndo record
32 bytes: double-SHA256 of the serialized CBlockUndo record

A CBlockUndo record consists of a serialized vector of CTxUndo records, one for each transaction in the block excluding the coinbase transaction. Vector serialization first writes a CompactSize-encoded length of the number of records (the transaction count - 1, in this case), and then serialized all the records themselves sequentially.
A CTxUndo record consists of a serialized vector of CTxInUndo records, one for each input in the transaction.
A CTxInUndo record consists of:

varint: 2*height (+1 if it was a coinbase output): the height of the block that created the spent UTXO
varint: creating transaction's version [only when height > 0]
CompressedScript: spent UTXO's scriptPubKey
CompressedAmount: spent UTXO's nValue

Until Bitcoin Core 0.14.x, the height is zero for all but the last output of a given transaction being spent. In Bitcoin Core 0.15 (to be released soon), it will be present for every spend.
For more information about the detailed encodings, see the comments in the Bitcoin Core source code: CompactSize, VarInt, CompressedScript, and CompressedAmount.

A CBlockUndo record consists of a serialized vector of CTxUndo records what does it mean? For example when size of CBlockUndo record = 1 and the record is 00. In this case dsha256 present in data and not equal to zero. It seems strange

Read the next sentence.

Doesn't CompressedAmount come before CompressedScript?

authors: сергей алексеенков


text:
I want to start my new bitcoin web wallet! Coding and steps! PLEASE GUIDE
I want to start my new bitcoin web wallet but no idea where to start. coding and steps no idea. please help.

Hey, between you and me, if you don't know how to code a wallet, you probably shouldn't offer a service where you use said wallet to manage other people's money.

It will be my personal wallet. can you teach me how to code a wallet?

The question does not provide enough detail to answer it satisfactorily. OP hasn't specified any programming language, should there be a server, and so on. There are lots of implementation details in building a wallet, so much so, the actual mechanics of signing are only a small part of the project.. The question should request specific details, and not how to realize an unspec'd project.

As I said in the comment above, you're talking about a service to manage actual money. Please don't offer this service to other people until you're sure it's working properly and it doesn't have security flaws.
You should try to make your wallet work with the Bitcoin Testnet first. The Testnet is a clone of the Bitcoin network that gets reset every once in a while. Therefore, its tokens are valueless. However, it allows you to experiment with your software and test functionality because it behaves like the Bitcoin network.
Now, depending on what your favorite programming language is, there are different libraries for Bitcoin already. If you're fine with Java, it is my understanding that bitcoinj is rather comprehensive and well-kept. There are also some open-source Bitcoin wallets already that use bitcoinj which you might use to inspire yourself how to solve some issues. One such wallet is the Bitcoin Wallet for Android.
From there, I suggest that you apply standard software development techniques: Define use cases, structure work into manageable chunks, design a solution, define testcases, and implement functionality.


text:
What is the required input for python-bitcoinlib getrawtransaction command?
I am running a bitcoin node on my machine, fully synced with RPC commands enabled, rpc server live and txindex=1.
In the command-line I can run the following RPC call and obtain the information about the transaction I require. I am using the cli as I need to process 2.5 million transactions.
./bitcoin-cli decoderawtransaction $(./bitcoin-cli getrawtransaction b601fc820d66b6516f89557fba9b40943df962de96b914547dec72b0f047c2f3)
Which returns a JSON output of the transaction.
However, when run with the python-bitcoinlib library it seems to give the following error message
import bitcoin, bitcoin.rpc
bitcoin.SelectParams("mainnet")
rpc = bitcoin.rpc.Proxy()
rpc.getrawtransaction("b601fc820d66b6516f89557fba9b40943df962de96b914547dec72b0f047c2f3")

InvalidParameterError: {u'message': u'parameter 1 must be of length 64 (not 128)', u'code': -8}

What am I doing wrong, isn't b601.. the transaction id?
Edit: As per comment
I fixed it by replacing rpc=bitcoin.rpc.Proxy() with rpc=bitcoin.rpc.RawProxy(). But I would still like to know why the previous fails.

I fixed it by replacing rpc=bitcoin.rpc.Proxy() with rpc=bitcoin.rpc.RawProxy(). But I would still like to know why the previous fails

I suppose there's a difference parsing the hexstring when you use Proxy vs. RawProxy.

getrawtransaction requires little endian format of the trxid, like:
import bitcoin.rpc
from bitcoin.core import lx
p = bitcoin.rpc.Proxy(service_url='http://usr:pa@ip:port')
trxid = lx('7e195aa3de827814f172c362fcf838d92ba10e3f9fdd9c3ecaf79522b311b22d')
rawtrx = p.getrawtransaction(trxid)
print(rawtrx)

Comments from Mr Peter Todd on that:
https://github.com/petertodd/python-bitcoinlib/blob/master/examples/spend-p2pkh-txout.py#L41

authors: Леонид Гаварушкин


text:
When bitcoin forks, how do they decide which fork gets the original name?
Bitcoin has had a number of forks over the years. The biggest one was Bitcoin and Bitcoin Cash.
Bitcoin seems to have won out in this fork, and is much more popular than Bitcoin Cash.
However, how was this naming scheme agreed? Why did Bitcoin end up still allowed to be called Bitcoin, whereas Bitcoin Cash needed a new name?
Arguably the fork that had the original name had a much bigger advantage in "winning out" over the one with the new name.
For example, Ethereum also had a fork and it was the original Ethereum that needed a new name (Ethereum Classic) and in that case, the new Ethereum (the fork we know now) was the one that won out.

One might think that the network maintaining the same consensus rules would be considered the original, and the project introducing a consensus rule change and thus creating a new network would be considered the derivative, but you've already pointed out an exception to that rule with the ETH DAO fork. Various arguments can be made why one or the other network should have been named ETH in that case. Similarly, with Bitcoin and Bitcoin Cash, proponents of Bitcoin Cash had attempted to claim the name Bitcoin for their own network.
Looking at a few fork events, the rule seems to rather be that the dominant fork gets to keep the name. However, it might not be obvious prior to a split which project will end up being recognized by the majority. In the advent of the Bitcoin Cash fork and the Segwit2x fork attempt, futures markets gave some indication how the public valued each proposal. Yet, in the end, it's an emergent social phenomenon. Whatever "everyone" ends up calling Bitcoin is Bitcoin. Often this conflict is resolved when one of the two networks rebrands.


text:
do transaction merkle trees have any use outside individual blocks?
as i understand it, merkle trees are useful for operations within individual blocks, but do they have any use outside of each block? for example, are the merkle-roots from each block ever used in combination for any other purposes such as blockchain validation?

The merkle tree means that you can verify the existence of a transaction in a block while only having the header, the transaction, and the merkle tree itself. It allows SPV clients to act extremely quickly and securely while only using the bare minimum of bandwidth. MultiBit is a SPV client that works in this way, and is extremely quick as a direct result.

thanks. spv uses bloom filters and the merkle paths within the relevant blocks to prove that the transactions specified by the peer really did occur as claimed. however i'm asking if this is the only way that merkle trees are used in bitcoin? ie are merkle trees only ever used within a block and never across more than one block, for example?

Not at the present, the transactions within a block are the only place I'm aware of that Merkle Trees exist.

Actually you only need the branch for your transaction and not the whole tree.


text:
bitcoin exchange for other virtual (centralized) currencies
i was wondering if there are any exchanges which trade centralized virtual currencies for decentralized virtual currencies. for example, air miles for bitcoin or vice versa. my thinking is that this might externalize the charge-back problem inherent with fiat currency - ie the problem where someone sends fiat to the exchange, in return for bitcoin, then claims the money was stolen or the transaction was somehow illegitimate, and the bank takes the money back off the exchange leaving the user having paid nothing for their bitcoins.
of course i'm thinking that the centralized virtual currency also would not have chargebacks, but this may not be the case? here are some examples:

linden dollars from second life
amazon coins
air miles
gift voucher codes

https://www.virwox.com/ is an exchange for virtual currencies, trading among other things Linden dollars.

A few of them trade Ripple. Try bitstamp.net


text:
Bitcoin-cli balance minconf
When I use the getbalance command in bitcoin-cli and I set minconf to 1. Will it display the bitcoins with 1 confirmations and more? If this is true, what is a good amount of confirmations that will make the transaction safe but also fast?

To answer your question, yes, setting minconf to 1 will display the balance of your wallet that is summed up by combining the transactions in your wallet that have a minimum of 1 network confirmation.
Your secondary question is really a question between balancing the security of your transactions and the speed at which you wish to spend your funds, because waiting, say, 2 network confirmations will be faster (~20 minutes), but will not be confirmed long enough on the block chain for the transaction to be "secure".
This is essentially a form of the "50 percent attack":
An attacker that controls more than 50% of the network's computing power can, for the time that he is in control, exclude and modify the ordering of transactions. This allows him to:

Reverse transactions that he sends while he's in control. This has the potential to double-spend transactions that previously had already been seen in the block chain.
Prevent some or all transactions from gaining any confirmations
Prevent some or all other miners from mining any valid blocks

The attacker can't:

Reverse other people's transactions
Prevent transactions from being sent at all (they'll show as 0/unconfirmed)
Change the number of coins generated per block
Create coins out of thin air
Send coins that never belonged to him

With less than 50%, the same kind of attacks are possible, but with less than 100% rate of success. For example, someone with only 40% of the network computing power can overcome a 6-deep confirmed transaction with a 50% success rate.

It's much more difficult to change historical blocks, and it becomes exponentially more difficult the further back you go. As above, changing historical blocks only allows you to exclude and change the ordering of transactions. It's impossible to change blocks created before the last checkpoint.

Since this attack doesn't permit all that much power over the network, it is expected that no one will attempt it. A profit-seeking person will always gain more by just following the rules, and even someone trying to destroy the system will probably find other attacks more attractive. However, if this attack is successfully executed, it will be difficult or impossible to "untangle" the mess created -- any changes the attacker makes might become permanent.

The above was taken from https://en.bitcoin.it/wiki/Weaknesses
Hope this helps

Thanks. But I don't think anyone wants to use his power to block a transaction from less than 1btc. So I think i am safe with 4 confirmations.


text:
Duplicate addresses in transaction possible?
I am making a bitcoin laravel package.
I have a table with all transactions.
The txid and the address are unique together.
So it is possible to have only one column with the same txid and address.
Is it possible to send a bitcoin transaction with the same address twice?
Because when it is my table structure isn't right.
Sample transaction(address: amount):
1BoatSLRHtKNngkdXEeobR76b53LETtpyT: 0.01
1BoatSLRHtKNngkdXEeobR76b53LETtpyT: 0.04
1NsC7NJfkFgp9ppeJdD38PrY3Yy92o88cu: 0.06

Is this transaction possible?
Or would it be automatically this
1BoatSLRHtKNngkdXEeobR76b53LETtpyT: 0.05
1NsC7NJfkFgp9ppeJdD38PrY3Yy92o88cu: 0.06

A transaction can have several inputs come from a single address and can have several outputs go to the same address.
It is also possible that there are more inputs in that same address and that they're spent in a different transaction or that money is sent to addresses which have already been used (and may or may not still hold money).
You may also want to have a look at this when coming up with data structures: https://en.bitcoin.it/wiki/Transaction_Malleability

I see the listtransactions has a vout key. Can I use this to check if transaction already exists(in my imported transactions) or is there another way to see the difference between the transactions? Because the time, amount, address, confirmations and txid can be the same..

The thing here is that you have to define for yourself what it means that 2 transactions are "the same". One possible definition is that 2 transactions are "the same" if and only if all their scripts match.

I just tried making a transaction with multiple of the same addresses in the output. And this was the result: Invalid parameter, duplicated address: . So is bitcoind just blocking it or is a duplicate address in the transaction not possible in bitcoin?

authors: Андрей Павлов


text:
Unconfirmed bitcoins 258: txn-mempool-conflict
I made a transaction a few days ago, but the fee was to low so it doesn't get confirmed. So I want to give the transaction a higher fee. But when I resend the transaction I get this error:
258: txn-mempool-conflict
I restarted my server.
I tried leaving the output the same but added an input.
I tried changing the output to an higher fee and left the input the same.
I tried the abandontransaction command but that returns Transaction not eligible for abandonment.
But the error is still there. How can I resend my transaction so it will get confirmed?

Are you using Bitcoin Core? Did you try using -zapwallettxes or -abandontransaction? Have you seen Why is my transaction not getting confirmed and what can I do about it?

-zapwallettxes doesn't work because I run bitcoind in prune. And -abandontransaction returns the same error.

abandontransaction wouldn't work, because the offending transaction is also in your memory pool.


text:
How to generate the public Nextcoin key (NXT)?
There doesnt seem to be an API call that returns the public key for my NXT account (with which I have not sent out any coins yet).
The NXT wallet does display the public key after I log in, but how do I calculate this public key programmatically?

There is now a getAccountPublicKey API request. But as you indicated, the public key is shown prominently in the NXT reference client (NRS version 1.3.2 currently) when an account is first opened with a secret passphrase.
This public key can be used along with the account ID (which is derived from the public key) to fund the new account from another account, thus securing the new account by adding the public key to the blockchain. If a different secret passphrase were then to be used which results in the same account ID (such a collision being a distinct possibility), it could not open the account since its corresponding public key would be different from the one already stored in the blockchain.
The public key will no longer be displayed prominently in the NXT client, but it still can be viewed by sending a transaction, then clicking on the timestamp of the transaction as displayed in the client, then clicking on "Transaction Details". The first field in the pop-up window is "Sender Public Key".
If you are interested in the algorithm for computing the public key from the secret passphrase, refering to the Whitepaper:Nxt:

The secret passphrase is hashed with SHA256 to derive the account's
private key.
The private key is encrypted with Curve25519 to derive
the account's public key.


text:
difference between litecoin and bitcoin transaction id format
i will be storing litecoin and bitcoin transaction ids in the same table in my database, and i want to make the transaction id into a primary key. if litecoin and bitcoin transaction ids overlap then i can work around this by appending a BTC or LTC to each transaction id. can someone tell me if they do overlap?

They do not overlap. A transaction is always unique. a cryptographic hash algorithm is designed in such a way that they do not collide. This is one main requirement  of a hash function.
The inputs to create the transaction ID is partially based on the inputs which are being used to create the actual spend request in the chain, thus you will never have a collision between Bitcoin and Litecoin.

One issue however is that a single transaction can have multiple outputs so you might want to make your primary key a concatenation of the transaction id and output address. That way if you have someone build a single transaction that pays more than one of your addresses, it'll still work.

it sounds like you are saying that it is impossible for a collision to happen? is this the case, or is it merely extremely unlikely? thanks!

Collisions are extremely unlikely since the hashes for both are sha256. (10^77 possibilities)


text:
descriptions of the bitcoin-qt files
bitcoin-qt creates files under ~/.bitcoin/ in my file system. i know that the ~/.bitcoin/blocks/blk*dat files contain the blockchain, but what do the following other files contain:
~/.bitcoin/blocks/rev*dat
~/.bitcoin/chainstate/*sst
~/.bitcoin/blocks/index/*sst

i know sst stands for "sorted string table" and i gather these files belong to a leveldb database, but i'd like to know in more detail what is in each of them.

Bitcoin data directory files details are here: https://en.bitcoin.it/wiki/Data_directory


text:
Why does Antpool mine so many empty blocks?
AntPool, the largest mining pool mines a lot of empty blocks (quick stat over the last 100 blocks they mined at time of writing shows 20% <10kB).
While I understand that sometimes it is useful to mine an empty block when one has not had time yet to validate all transactions in the previous block. This validation should be very quick compared to the average 10min block time (validating a full block of like 2000 transactions should not take more than a few seconds on a modern PC, no?).
So, why the hell is Antpool mining so many empty blocks???
Just to compare, the same stat for the 2nd largest pool, F2Pool, gives only 4% blocks <100kB and 0% <10kB.
EDIT: I pulled out some more stats over the last 500 transactions as of 16/12/2006 11:25 CET
- 18 blocks < 5kB (3.6%)
- AntPool mined 98 blocks, out of which 16 < 5kB (16.3%) covering almost 90% of empty blocks
- Empty blocks came on average 6.6min after the last block so yes faster than the overall average 10mins but still plenty of time to include transactions
- Only 16% of these 18 were very quick empty blocks <1min

This article gives a nice summary of potential causes and solutions to empty blocks mining: https://bitcoinmagazine.com/articles/decline-empty-blocks-has-increased-bitcoins-transaction-capacity/.
AntPools may just be late at implementing the solutions...

The linked article has a quote from AntPool saying they have a solution to avoid mining empty blocks, there not late, maybe they want to mine empty blocks.

Bitcoin's miners are behaving irresponsibly - signaling crappy "power-grab" versions that move more control to them.  Gaming the system with empty blocks.   Basically screwing with the protocol.
Maybe Bitcoin's premise: that you can use game theory to get a distributed group of people to behave responsibly - is falling apart.

The answer is full of rhetoric, can you please improve your answer by supporting your claims with some sources?

There are valid reasons for mining empty blocks. Certainly it is not something miners want to do sequentially or frequently. The phenomenon is not entirely due to the devious reasons you state.


text:
Do new SIGHASH types need a hard fork or a soft fork?
There have been a few new sighash types proposed.

SIGHASH_NORMALIZED : Use a 'normalized' TXID in the inputs when serializing for signing. This normalized transaction id is calculated by removing the scriptSigs of the transaction that you are spending from before serializing.
SIGHASH_NOINPUT : Just remove TXIDs from the inputs entirely. Useful for thwarting malleability, but allows funds sent to that same scriptPubKey again to be stolen, so you would only sign an input with this if you are sure you are never going to use that scriptPubKey again.
SIGHASH_WITHINPUTVALUE : Include the input's value when replacing the scriptSig with the previous scriptPubKey, so signers can prove knowledge of exactly what they are giving away (useful for hardware wallets).

AFAIK, however, if an unidentified sighash flag is used, then the standard client treats it like SIGHASH_ALL (source). Isn't introducing a new sighash flag a hard fork, then? The sources linked to above give conflicting statements on whether new sighash flags require a hard or soft fork.

It is in fact a hard fork, if it is done natively. However, it can be done through a soft fork if the sighash types are only included in serialized redeemScripts for P3SH (P2SH but with OP_EQUALVERIFY instead of OP_EQUAL), or via re-purposing one of the OP_NOPs to be a new op with similar functionality to OP_CHECKSIGVERIFY.
Source: http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf

To mitigate malleability, it requires changing which contents are signed by the participants. This is achieved by creating new Sighash types. In order to accommodate this new behavior, a new P2SH type or new OP_CHECKSIG is necessary to make it a soft-fork rather than a hard-fork.


text:
Generating bitcoin core -rpcauth argument using golang
We're developing a Blockchain deployment solution kotal, and generating -rpcauth argument from the supplied user name and password.
The problem is when we try to use the same user and password using curl, it writes ThreadRPCServer incorrect password attempt from 127.0.0.1:55566.
Here's how we're generating -rpcauth from password in golang.
user := "kotal"
password = "s3cr3t"

salt := make([]byte, 16)
rand.Read(salt)

hash := hmac.New(sha256.New, salt)
hash.Write([]byte(password))

rpcauth := fmt.Sprintf("%s:%x$%x", user, salt, hash.Sum(nil))

What's wrong with our golang implementation ?

What you are adding to your bitcoin.conf? You need to pass exactly what is there, and core will get the hash.

@DavidsonSouza so I can't simply pass --rpcauth cli argument to bitcoin process ?

The issue is that your salt is a byte array, which you are passing directly as the hmac key, and then printing out the hex. This would require bitcoind to interpret the salt hex as a hex string and convert it to the bytes represented by the hex. However that is not what bitcoind does.
Bitcoind takes the salt as is, and uses it directly has the hmac key. So you need to do the same thing - convert the byte array to a string, and use the bytes of that string as the key.
This code works:
user := "kotal"
password := "s3cr3t"

salt_data := make([]byte, 16)
rand.Read(salt_data)

salt := hex.EncodeToString(salt_data)

hash := hmac.New(sha256.New, []byte(salt))
hash.Write([]byte(password))

rpcauth := fmt.Sprintf("%s:%s$%x", user, salt, hash.Sum(nil))

You could use or take inspiration from the rpcauth script in the Bitcoin Core repository that does exactly this, but in Python.

we've cloned this script into go,  but it doesn't work


text:
Does the alternative stack make Script Turing complete?
The wiki documents the presence of an "alt stack" in Script:

OP_TOALTSTACK Puts the input onto the top of the alt stack. Removes it from the main stack.
OP_FROMALTSTACK Puts the input onto the top of the main stack. Removes it from the alt stack.

It appears then that Script may qualify as a Two-Stack Pushdown Automaton. And this system is known to be equivalent to a Turing Machine. For example:

To see the equivalence, just think of the first stack as the contents of the tape to the left of the current position, and the second as the contents to the right. Start by pushing the normal "bottom of stack" markers on both stacks, then we can simulate the TM by popping from the right stack and pushing to the left to move right, and vice versa to move left. If we hit the bottom of the left stack we behave accordingly (halt and reject, or stay where you, depending on the model), if we hit the bottom of the right stack, we just push a blank symbol onto the left.

https://cs.stackexchange.com/questions/2832/is-a-push-down-automaton-with-two-stacks-equivalent-to-a-turing-machine/2833#2833
Wikipedia defines "Turing complete" as:

In computability theory, a system of data-manipulation rules (such as a computer's instruction set, a programming language, or a cellular automaton) is said to be Turing complete or computationally universal if it can be used to simulate any Turing machine.

https://en.wikipedia.org/wiki/Turing_completeness
This thread makes reference to the alt stack, claiming that its presence makes Script Turing complete:
https://www.reddit.com/r/Bitcoin/comments/7yb3is/where_is_the_evidence_that_bitcoin_is_turing/duf1rt9/
That thread links to this thread, which contains the following:

While it is a well known CS result that a two-stack push-down automata has the same power as a Turing Machine, Bitcoin Script cannot operate as a two-stack push-down automata. Even though Bitcoin Script has two stacks, Bitcoin Script doesn't have an associated finite state machine that you can create.

https://reddit.com/r/btc/comments/6hjxiy/new_craig_wright_interview_part_2_on/diz9g69/?context=3
In other words, there may be two stacks, but there's no way to sufficiently power them to create a Turing Machine.
Is Bitcoin Script Turing complete given the presence of the alt stack? If not, what specific functionality is missing?

Yes, that makes it as turing-complete as ethereum (or since none of them can implement 'infinite tape' required for TM, either of them aren't?) Deeper question you might want to ask is about the effect of time it takes for script validation.

No, the alt-stack doesn't make bitcoin script a Turing-complete language.
While script has two stacks, in order to simulate a two-stack pushdown automata (which is Turing complete), one has to be able to implement a finite-state control unit. This cannot be done in bitcoin script, since there is no looping or conditional branching available. It is possible to write a script that goes through the motions of running a Turing machine program by unrolling loops, but that will only work for a machine and input combination that terminates. It is very simple to write a Turing machine with a finite input string that loops indefinitely eg. consider the Turing machine defined by
states: q0 (initial), q1 and q3 (final)
and tape alphabet {0, 1}
where the transitions are
(q0, 0) -> (q1, 0, move left)
(q1, 0) -> (q1, 0, move left)
(q1, 1) -> (q1, 1, move right)
Given input 01, this machine will just loop infinitely, as simulated here:
http://turingmachinesimulator.com/shared/ojvubpsgkm
Attempting to "unroll" this as a bitcoin script will never finish.

You may be interested in a post I wrote. I wrote a Turing Machine (by utilizing the two stacks) and made a test transaction.
Basically if we assume that our program will halt, then it requires only a finite number of instructions, which is supported by the Bitcoin script. Unfortunately the Bitcoin script VM only allows a limited number of operations to be executed so only very short programs can be written in practice.

Yes but sometimes clarke the bitcoin source of Autoscope interesting, sometimes we need to see the beginning of the first things of the next.
Confirmation of none technical aim can terminate me asking task bitcoin interested layer at low @ understanding per jam dot net.
where the transitions are
(q0, 0) -> (q1, 0, move left)
(q1, 0) -> (q1, 0, move left)
(q1, 1) -> (q1, 1, move right)
Given also input 01
urgent. thanks


text:
bitcoin-cli can't connect to server
I'm trying to put up a simple system for some penetration tests.
I have an Ubuntu server 16.04.1 with apache2 and bitcoin.
all running "Hiddn service" through tor (and bitcoind proxied 127.0.0.1:9050).
Now, using easybitcoin.php , the apache shows getinfo, send receive, all good.
but using bitcoin-cli nothing works! "couldn't connect to server"..
my bitcoin.conf is:
server=1
listen=1
proxy=127.0.0.1:9050
rpcuser=myuser
rpcpassword=mypassword

Any ideas why bitcoin-cli can't connect?

Did you try using the rpcuser and password params from the cli

yes, same error.

how do you run bitcoind? with regtest?

no, just with it's conf file, no parameters. in crontab on boot.

Try issuing the command netstat -tulpn | grep bitcoin and report back what it returns

tcp        0      0 0.0.0.0:8333            0.0.0.0:*               LISTEN      1233/bitcoind
tcp6       0      0 ::1:8332                :::*                    LISTEN      1233/bitcoind
tcp6       0      0 :::8333                 :::*                    LISTEN      1233/bitcoind

You should try adding daemon=1 to your bitcoin.conf file.


text:
How to buy and sell on the 15 minute time frame
Hallo I wanna write my first trading bot on python.
The bot should buy and sell on the 15 minutes time frame,
when the rsi is undersold or oversold.
How i can tell my bot to focus on the 15 minute timeframe ?
My code look like this

import talib as ta
date = []
price = []
volume = []
pair = eth_usd

while True:
    tikcer = bteapi.getTicker(pair,conn)
    date =  ticker('server_time')
    price =  ticker('last')
    volume =  ticker('vol')
    price = np.array(price)

    if len(price) > 13
       EMAPrices = ta.EMA(price, 14)
       rsi = ta.RSI(EMAPrices, 55)


text:
How are 21 words seeds generated
Apologies for the noobie question.
I was wondering how a range of wallet addresses (eg. BTC address 33ELbMhwHw5AaKHU4u3MzVSFvvK7aa7HZL) is algorithmically converted into seeds (eg. 12 words). Any help?
I tried to google around but I only find articles related to ledgers, wallet recovery and so on.
Thanks

The base system is described in BIP32 and BIP39.
Essentially, the conversion goes the other way around. We don't convert a list of addresses to a seed. A seed is converted to a list of addresses.
BIP32 described how hierarchical deterministic (HD) wallets work.
BIP39 describers how these can be encoded into mnemonic phrases, or seed words.
There's an excellent open source tool by Ian Coleman - BIP39 that lets you play around with the various derivation and entropy options. You should, however, be wary of entering any seeds containing funds or using it to generate secure seeds, as always.


text:
Get BCH from blockchain.info after fork
I had a fraction of BTC on blockchain.info before the 1st of August and I didn't touch them at all afterwards.
I never got my private keys (nor the 12 words) from my blockchain.info wallet (or if I did god knows where they are).
Question: if I try to get my private keys (bip39) now will they be the same so that I can get BCH following this guide http://www.coinpurveyor.com/how-to-claim-bitcoin-cash-from-blockchain-wallet/?
Thanks
(PS. another useful guide: https://coinomi.freshdesk.com/support/solutions/articles/29000013719-how-to-get-bitcoin-cash-from-many-wallet-software-services-with-coinomi)
UPDATE - THE ULTIMATE SOLUTION:
https://www.coindesk.com/couldnt-claim-your-bitcoin-cash-btc-com-now-has-a-tool-for-that/

Note: if you instead kept your Bitcoin on Coinbase they stated that you'll get your BCH on 1st Jan 2018.

Yes.
Haven't looked at those guides in particular, but I was able to redeem BCH from a blockchain.info wallet by exporting my private keys following this guide: https://bl4nkcode.info/bitcoin/how_to_export_blockchain_wallet_private_key, and then importing them into Electron-Cash.

Blockchain.info supports this now. Go to https://blockchain.info/wallet/#/settings/info Settings-general page and scroll to the Bitcoin Cash section. I was able to recover my amounts completely.

Yay! Awesome :)

From August 22nd 2017, limited Bitcoin Cash support is coming to Blockchain.info over the next 8 weeks.
https://blog.blockchain.com/2017/08/22/bitcoin-cash-update/

Any update on this? I don't see any BCH support yet.. :(

@GaSacchi https://cointelegraph.com/news/blockchaininfo-releases-full-bitcoin-cash-support-users-receive-coins

Blockchain.info now has BCH support. You can view your BCH balance under Settings -> General.
They have some information about this on the Blockchain Support Center:  Bitcoin Cash (BCH).

When logging into your Blockchain wallet you'll receive a notification like this:

From here, if you navigate to Settings -> General and scroll to the bottom, you'll see the following:

Upon clicking 'Show Bitcoin Cash Balance' you'll be shown a dialog message telling you what Bitcoin Cash is, how it's different from Bitcoin and a few other bits of useful info. At the bottom of this dialog box is the following button:

Upon clicking this button you'll be shown another dialog box containing your BCH balance and its current value in your wallet's primary currency.

Here you'll have the option to:

Keep Bitcoin Cash - Keep it in your Blockchain wallet, available to view at any time under Settings -> General.
Exchange Bitcoin Cash - Directly exchange it for Bitcoin or Ether.
Send Bitcoin Cash - Transfer it to a different Bitcoin Cash address.

Dismissing the dialog has the same affect as clicking "Keep Bitcoin Cash"; don't worry though, your Bitcoin Cash balance and both the "Exchange Bitcoin Cash" and "Send Bitcoin Cash" options are now permanently available under Settings -> General.

That "Show bitcoin cash balance" button is no longer under settings->general.


text:
What are bitcoin miners really solving?
As with mining, what are the bitcoin miners really solving? I read they are solving hashes, but what does that really mean. Can we see what they are solving? Can someone give an example of what a bitcoin mining machine sees to solve?

Related: http://bitcoin.stackexchange.com/q/148/153

Here is a visual, gamified version of the problem that bitcoin miners are typing to solve. It is literally a bincoin miner, and if you solve the problem then you win a bitcoin.
http://hashhunt.josh.com/

They try to find a random nonce (a little random data) that goes into a block and makes the block have a (SHA256) hash that (in binary) starts with a certain amount of 0's. The more zeroes the more rare hash is. A good hash' outcome is not predictable, and so you have to try a lot of times to find a good nonce.
The amount of zeroes are based on how difficult it is supposed to be to find a block. In Bitcoin it adjusts to have a new block every 10 minutes (on average, given the rate at which previous blocks are found).
Interesting: because the hashes are unpredictable it doesn't matter how the nonce changes! Most of the time it's just a number counting upwards from 0!

Here is an extremely simplified sketch of the problem, but it should give a pretty good idea of what the problem is.
The data:
This is the hash of the lastest block (shortened to 30 characters):
00000000000001adf44c7d69767585

These are the hashes of a few valid transactions waiting for inclusion (shortened).
5572eca4dd4
db7d0c0b845

And this the hash of one special transaction that you just crafted, which gives 25BTC (the current reward) to yourself:
916d849af76

Building the next block:
Now, let's use a gross approximation of what a new block might look like (the real one uses binary format). It contains the hash of the previous block and the hashes of those 3 transactions:
00000000000001adf44c7d69767585--5572eca4dd4-db7d0c0b845-916d849af76--

Now let's do mining by hand! Our goal is to complete this block with a nonce (a piece of garbage) such that the hash of the new block starts with 13 zeros (considering the previous hash, it seems that 13 zeroes is the current difficulty!).
Mining (trying to finalize this block):
Let's try with nonce=1, and compute the hash of the block (I'm using the md5 hash algorithm, but Bitcoin uses double sha256):
> echo "00000000000001adf44c7d69767585--5572eca4dd4-db7d0c0b845-916d849af76--1" | md5sum
8b9b994dcf57f8f90194d82e234b72ac

No luck, the hash does not start with a 0… Let's try with nonce=2
> echo "00000000000001adf44c7d69767585--5572eca4dd4-db7d0c0b845-916d849af76--2" | md5sum
5b7ce5bcc07a2822f227fcae7792fd90

No luck…
…
If we pursue until nonce=16, we get our first leading zero.
> echo "00000000000001adf44c7d69767585--5572eca4dd4-db7d0c0b845-916d849af76--16" | md5sum
03b80c7a34b060b33dd8fbbece79cee3

For nonce=208, we get two leading zeroes!
> echo "00000000000001adf44c7d69767585--5572eca4dd4-db7d0c0b845-916d849af76--208" | md5sum
0055e55df5758517c9bed0981b52ce4a

Continue like this… If you finally find a hash that has 13 leading zeroes… you're a winner! Other miners will now build upon your block, you've just got 25BTC.
But you'll have to be fast!
Back to step 1…
If someone manages to build a block before you do, you'll have to start again from the beginning with the new block's hash (the one of the winner).

Note that you're not actually "counting zeroes". In reality approximately the first four non zero numbers are being compared with something called a "target".  This is stored in compact form in each block in a field called "bits".

Also your example is conceptually heading in the right direction, but the real success is when the sha256 hash of the header is less than the target. Example target: 00000000000001ae00000000000000 is greater than 00000000000001adf44c7d69767585     <-- this would be a valid hash.

"And this the hash of one special transaction that you just crafted and which gives 25BTC (the current reward) to yourself: 916d849af76" How is this transaction crafted?

@Reonarudo: the simplest is to use one of your addresses to produce a single standard output to be spent, but you can forge any kind of custom transaction with custom scripts as well if it pleases you (you are allowed a +25 BTC total balance for this transaction, additionnal inputs were not allowed some time ago, but maybe they are now).

So normally I would just append my wallet address in the end between - and --?

@Reonarudo, not exactly, this is a very simplified sketch of what is actally done. Transactions are made with scripts which are often made from adresses, you can find more info on the Bitcoin wiki.

This basically sounds like a nice (simplified) summary, but at what point does the bitcoin network accept this as the next valid block, and what happens in the (unlikely) event that two different miners managed to submit a valid block almost simultaneously?

Wow, great answer! There're a couple of things I still couldn't get my head around though: Let's say you've been searching for a solution for 6 minutes and there comes a new transaction. 1) what happens now? if I have to start over, then that sounds like everyone has to start over. Then how can blockchain guarantee to find a block in ~10 minutes? 2) How does that transaction come to me anyway? 3) What if I find a solution for this block and then a new transaction comes to me from some other node who accepted it for the block I just closed?

Yes everyone starts over, if you build on top of an old block there's little chance your blocks will be part of the longer chain and they will be disregarded by the rest of the network. There is no guaranty that a block is find within 10 minutes, it's just an average statistical outcome. 2) What transaction? Blocks are broadcast by whoever mined them and relayed by other nodes. 3) Nothing forces you to include all pending transactions, but the more transactions you include the more fees you can collect.

The transaction to be added to current block, the one that caused me and all(?) others to restart the calculation. How does it come to me? And also, 3) Why would I accept it for 0.001 btc if I am to find a new block and get 25 btc?
Thanks Stephane!

The following is a description of the global, statistical gamble which is played every 10 or so minutes.  The interval of the game is controlled by the difficulty which says how many "hashes" are needed per interval.
In other words, the difficulty and target define the "odds of the house" against your chance of getting a winning SHA hash.  The nonce is the "scratch off" area.
Each hash consumes electricity, and emits heat, which requires additional cooling.
This is what is done with each hash:
Step 1
At a high level, the miner software takes a list of active transactions, and then groups them together in something called a "block".
Or more accurately stated: The miner software coverts all the transactions into a summary view called a  "merkle root", and hashes it, which is representative of the transactions.
Step 2
Then mining software converts this to into a binary format called a Block Header, which also references the previous blocks (also called a chain).
Field           Purpose                          Updated when...               Size (Bytes)
Version         Block version number             You upgrade the software and   4
                                                 it specifies a new version

hashPrevBlock   256-bit hash of the previous     A new block comes in          32
                block header
hashMerkleRoot  256-bit hash based on all        A transaction is accepted     32
                the transactions in the block

Time            Current timestamp as seconds     Every few seconds              4
                since 1970-01-01T00:00 UTC

Bits            Current target in compact format   The difficulty is adjusted   4

Nonce           32-bit number (starts at 0)       A hash is tried (increments)  4

Step 3:
The miner hardware changes a small portion of this block called a "nonce".
Step 4:
The block header is hashed and compared to the Target as if it were simply a large number like 10,000,000 > 7,000,000  (the real numbers are much bigger, and in hex).  The target is compressed and stored in each block in a field called bits.
An expanded target looks like this:
  Target   0000000000000083ef00000000000000000000000000000000000000000000000

And the goal is to make sure the SHA256 hash of the block is less than this value.  In the example below "83ee" is smaller than "83ef"
To simplify this concept, you can ballpark the target by counting the leading zeros (as the other answer here explains).  Here is an example:
Here is a sample block with transactions you can view on BlockChain.info. Look in the upper right hand corner of the webpage for this hash:
   Hash 0000000000000083ee9371ddff055eed7f02348e4eda36c741a2fc62c85bc5cf

That previous hash was from today and has 14 leading zeroes.  Let's compare that to what was needed 3 years ago with block 100 which has 8 leading zeros.
   Hash 00000000a8ed5e960dccdf309f2ee2132badcc9247755c32a4b7081422d51899

Summary
So at the end of the day, all a miner does is:

Take a block header as input
Change the Nonce
Test if the Block Header hash is less than the Target.  If it is, you win.
Go to step 2  (or go to step 1 if someone else won the block)

Want to see what Bitcoin-QT does when it finds a block?... I posted it here.. The information in this post will help you understand what happened.

Isn't the nonce (32 bits) far too small to be able to find a hash that must start with 14 leading zeroes (14x4 = 56 bits) ?  Finding such a hash would require on average 2^56 / 2 attempts and with a 32 bit nonce only 2^32 attempts are possible before all possible nonce values are exhausted.  Edit: with the time changing every second, I guess this only applies if hash rate exceeds 4 GH/sec (which I think it does...)

Yup, you're right, ...from the URL on the Block header: Whenever Nonce overflows (which it does frequently), the extraNonce portion of the generation transaction is incremented, which changes the Merkle root.

Best answer I've been able to grok so far. I still don't get how a target is established nor do I fully understand the significance of generating a hash lesser than the target. So a hash is generated closest but lesser that the target, why is that important? Is it because it is theoretically the most complex hash so it's the most (or really close to being the most) difficult hash to crack?

@VanceMcCorkle Among bitcoin mining equipment, it's a race among who can press the gas pedal the furthest without blowing up the engine. Every piston movement creates a hashcode ( so to speak). The significance is only a >>RACE TO BURN OIL<<. Bitcoin should be sponsored by Big Oil and Coal.

@ChristopherJonMankowski Except that where I live here in Washington state is literally powered by rain water (Grand Coulee Dam). Plus I rent green hosting space for miners. Nevertheless, still I have found no clear explanation on the block validation process that makes sense to me yet. Although I have yet to read the Bitcoin Standard.

@VanceMcCorkle try calculating the cost per Gigahash or Terrahash per energy FOREX cost. That is the industrial cost of capitalism, but not the TCO equivalent of other debts and tradeoffs of ecology not considered as they are hidden by governance and politics to get somewhere.

Mining provides a way to reach consensus on what the transaction ledger should look like and know that nobody is cheating.
That's the non-technical definition of mining.

What exactly is Mining?

The "authority" for double spending is the blockchain.  The blockchain consists of the history of all blocks in the blockchain plus the next block of transactions.  The reward subsidy currently is 25 BTC to the party that submits the next block.  But hey ...you would like that 25 BTC (worth currently about $825) as would I as would everyone else.  So how do you make it so that I can't cheat and claim the block myself?
Well, you put in a system that you and I have to compete.  That's what the proof of work does -- it makes it so that when I claim the reward it is easy to prove that I really did the work involved.  So for me to have a 2% chance of solving a block I need to put in 2% of of the mining work.  There's no way for me to put in less than 2% of all the work and still solve blocks at least 2% of the time (on average).
Thus as a result, when a transaction block is submitted, all the peers verify that there were no double spends, that the right amount of subsidy was claimed, and that the submitter truly expended the work necessary for that solution.  With those three rules, then there doesn't not need to be a central authority managing the process or able to control the outcome.

Bitcoin miners are solving complex mathematical puzzles in a process called proof-of-work, which helps secure the Bitcoin network and create new bitcoins. These puzzles are based on cryptographic hash functions, and the main goal is to find a specific input called a nonce that, when combined with the transaction data and previous block's hash, produces an output (a hash) that meets certain requirements, such as having a specific number of leading zeros.
The puzzles are designed to be hard to solve, requiring a lot of computational power, but easy to verify once the solution is found. Miners are essentially searching for a needle in a haystack by trying different nonces until they find the one that meets the required conditions.
The process of solving these puzzles serves two main purposes:
Securing the network: The proof-of-work process makes it difficult for anyone to attack the network or manipulate transaction data. To do so, an attacker would need to control more than 50% of the total mining power, which is highly unlikely given the distributed nature of the network and the vast amount of computational resources required.
Creating new bitcoins: Miners who successfully solve the puzzle and add a new block to the blockchain are rewarded with newly created bitcoins (the block reward) and transaction fees from the transactions included in the block. This serves as an incentive for miners to contribute their computational resources and helps maintain a controlled and predictable supply of new bitcoins.
As more miners join the network and the total computational power increases, the difficulty of the puzzles automatically adjusts to ensure that a new block is added to the blockchain approximately every 10 minutes. This self-adjusting mechanism helps maintain the security and stability of the Bitcoin network.
Bitcoin miners solve a complex mathematical puzzle, called proof-of-work, to generate new bitcoins and secure the network. This puzzle is based on a cryptographic hash function called SHA-256, and the goal is to find a specific input (called a nonce) that results in a hash value that meets certain requirements. Here's a detailed explanation of the process:
Preparing the block: Miners gather recent, unconfirmed Bitcoin transactions and organize them into a data structure called a block. Each transaction is checked to ensure it's valid and not a double-spend attempt. The block also contains a reference to the previous block in the blockchain (by including its hash) and a timestamp.
Calculating the target: The Bitcoin network adjusts the puzzle's difficulty based on the total mining power to maintain an average block generation time of 10 minutes. The difficulty determines the target value for the hash. The target is a 256-bit number, and miners must find a hash that is equal to or lower than this target.
Finding the nonce: Miners generate the hash by combining the block's data, the previous block's hash, and a nonce (a random number). They repeatedly change the nonce and recompute the hash until they find a hash that meets the target requirement. Since hash functions are unpredictable, miners must try many different nonces before finding a valid one. This process is computationally intensive and requires a lot of trial and error.
Proof-of-work: Once a miner finds a valid nonce, they have effectively solved the puzzle and completed the proof-of-work. The valid nonce proves that the miner has expended a significant amount of computational effort to find the solution, thus securing the network.
Broadcasting the block: The miner broadcasts the solved block, along with the valid nonce, to the entire network. Other nodes in the network verify the block and its proof-of-work. If it's valid, they add the block to their local copy of the blockchain.
Block reward: As a reward for solving the puzzle and adding a new block to the blockchain, the miner receives newly created bitcoins (the block reward) and the transaction fees from the transactions in the block. The block reward serves as an incentive for miners to contribute computational resources and secures the network.
This entire process ensures that the Bitcoin network remains secure, transactions are confirmed, and new bitcoins are generated in a controlled and predictable manner. As more miners join the network and the total computational power increases, the difficulty of the puzzle automatically adjusts to maintain the 10-minute block interval, keeping the system stable and secure.