Why is my lighting node not routing any transaction? I have set up a lighting node months ago using LND under the tor network.

My node (Caffeine) looks correctly configured and connected to several channels but it is not routing any transaction. In the beginning, I thought it would simply take some time but after months still nothing!

What could be the problem?

Obviously for questions like this I can't give a 100% certain answer as I would have to look at your nodes logfiles and configuration / state. However I can make some (hopefully) educated guesses and we can see if that helps you.

First of all it seems like you kept the standard base fee and fee rate. Following my analysis and video it seems pretty unlikely that payments are routed over your channels as there are many people currently offering cheaper routing.

Secondly if I read the data from 1ml correctly besides 1 channel with lnbig your channels are all channels that you have created in the past. If you have never paid someone the entire balance of the channel is on your side meaning they can only be used for routing if you also have inbound capacity (which seems to be the case only with the lnbig channel)

Last but not least: it is well known that lightning is still not very wide spread. There are currently only a few services and experimental projects using the technology so that many people don't use it for payments yet. For example my node has optimized routing fees and just earned a couple satoshis from a few hundred routing attempts over the last 6 months. Roughly half of the routing attsmps actually fail because I have way more inbound than outbound liquidity (the opposite situation from you)

There could be other errors which would need a close look at your logfiles / configuration.


Mac 0.80b beta - says "database corrupted" and then Bitcoin-Qt quit unexpectedly I can't run Bitcoin-Qt 0.80 on Mac OS X 10.8 any more.

It starts up then says "System Error: Database Corrupted". I then click OK, and the program "quits unexpectedly"

How do I  start again without losing my wallet. Is it just the wallet.dat file that I need to keep, or others as well if I reinstall? I have encrypted the wallet if that makes any difference  to the files I need to keep.

There are lots of BC in the wallet. I can't afford to lose them!!

Is there another program I can use just to open the wallet?

Joric's fork of pywallet can read a wallet.dat, decrypt it with your pass phrase and then you can export the keys.  But if it is corrupted and Bitcoin-Qt can't read it then pywallet may fare no better.

Doesn't hurt to give it a try.


How can I validate that an XRP address is valid? An address like rhe8v7GW1jj4qTXsLF9fwFrum9oQD5VXG7 - how do I know if it's valid in the XRP network?

Ripple addresses, like Bitcoin and most other currencies, are Base58Check encoded. As long as an address validates against the base58check algo, it is a valid address on the ripple network.

Do note that it is possible to generate valid addresses without knowing their corresponding private key. You should take steps to ensure you have the private key for an address before sending funds to it.


send payment from one address to another from my website I want to send payment to bitcoin address weekly from my bitcoin address,I have tried blockchain api but can't seem to find an answer.Need help.

http://blockchain.info/api/blockchain_wallet_api

The api call to send is:

https://blockchain.info/merchant/$guid/payment?password=$main_password&second_password=$second_password&to=$address&amount=$amount&from=$from&shared=$shared&fee=$fee¬e=$note

In PHP, replace all the variables (they start with a $ in example up above) with your actual info. Some of the parameters in the url are optional so visit the page I linked to see which ones are optional. Keep the url as a string and feed it in to this:

$result = file_get_contents($the_url_you_just_made);

This should send a payment as soon as it runs, you may want to read the resulting string, it will contain the error message if anything goes wrong. The response is detailed on the link and you can try out URLs in browser as well, just type in GUID, amount, address, etc in the correct places.


api doc for bitcoin gold on testnet I'm looking for an api doc for bitcoin gold on testnet to create, receive and list transactions and accounts. so far I've found this https://bitcoingold.org/testnet-v3/. I'd be thankful if someone shed some light

The project Wiki on GitHub probably has the info you're looking for:

Technical Spec: https://github.com/BTCGPU/BTCGPU/wiki/Technical-Spec
Testnet v3: https://github.com/BTCGPU/BTCGPU/wiki/Testnet-v3


How efficient are bitcoin markets? There are several bitcoin exchanges which trade bitcoins to $US and also several other markets which trade bitcoin for other currencies.  Each exchange however quotes a different price in effective $US for a bitcoin.

This discrepancy may be a result of differing fees at exchanges, and risks associated with each exchange and so on, but temporary discrepancies may also be a result of market inefficiencies and arbitrage opportunities.

How efficient are bitcoin markets currently (including both $US dollar markets and other currencies), and how quickly are potential arbitrage opportunities eliminated?

First, to clear things up, it isn't up to the exchange to quote a certain price/rate. It's all up to the users of that exchange what they ask/bid for a bitcoin. For example there are two exchanges, X and Y, with both have an ask one 500 USD and a bid on 400 USD. Then person A bids a higher price, lets say 470 (instead of 400), on exchange X. Person B asks a lower price, 430 (instead of 500), but he is one exchange Y, so their offers are never matched by the exchange itself. You however, are smarter. If you buy that coin (lets assume they both offer/ask a whole coin) from B, and sell it to A, you made a $40 profit (minus fees). Caching! Of course, these numbers are not plausible anymore. Think in cents/btc.

The discrepancy on different exchanges can indeed be the results of the effects you name. A few months ago, you could buy 'MtGox bitcoin', with a lower price then normal bitcoin. You weren't sure however that you could return that coin in the future.

But to answer your question, this arbitrage process can be completely automised and therefor fast as hell. There is no handwork involved anymore (just depositing/withdrawing USD/EUR). It is not very difficult to program (I half did it, without any knowledge in php or good programming skills), so there are a lot of scripts running, trying to make a small profit. Every ask/bid that has an arbitrage option is closed within tenths of a second. You cannot do it by hand. If you have made a script by yourself, you can get lucky if you import the data and execute your order at the right time.

edit: you can take a look at this site, they list options of arbitrage.


What is a soft fork? When people talk about possible changes to how Bitcoin works they sometimes say a particular change can be implemented as a soft fork. What does that mean? How does this compare to a hard fork?

What is a Project Fork?

A fork in software development refers to the event of an independent project spinning off from a software project. Such forks sometimes occur in the opensource sphere, when there are irreconcilable plans/goals within a project's community, then often leading to a split in the community and two distinct projects thereafter.  In practice this takes form in the sourcecode being copied and henceforth being developed in a different direction independently by the forkers. For example in this conventional sense of fork, Litecoin is a fork of Bitcoin: Litecoin started as a copy of Bitcoin's code-base, but developed into an independent project (although still closely related).

Softfork and Hardfork in Bitcoin terminology

The terms softfork and hardfork in Bitcoin describe compatibility breaking changes in the Bitcoin protocol: Should the community be irreconcilably divided about such an issue, the old version and the new version of Bitcoin could emerge as distinct projects thereafter. While both versions of the Bitcoin protocol are in use, the differences in acceptance may cause a lasting blockchain-fork, i.e. two distinct longest chains which are both considered valid by part of the network.

Softforks are forward compatible

Softforks restrict block acceptance rules in comparison to earlier versions.

The new rules allow a subset of the previous valid blocks, therefore  all blocks considered valid by the newer version are also valid in the old version. If at least 51% of the mining power shifts to the new version, the system self-corrects:
Blocks created by old versions of Bitcoin Core that are invalid under the new paradigm might commence a short-term "old-only blockchain-fork", but eventually, they would be overtaken by the chain fork created under the new paradigm, as the hashing power working on the old paradigm would be smaller ("only old versions") than on the new paradigm ("accepted by all versions").

However, if less than 51% of the hashing power switches to the new version,  the blockchain-fork will not mend automatically as the chain created under the old rules has more hashing power and is incompatible to the new rules. This can either be remedied by the adopters of the softfork giving up their chain, or more hashing power switching to the softfork chain. The latter would cause the softfork chain to eventually overtake and reorganize the other chaintip.

Hardforks are not forward compatible

Hardforks ease block acceptance rules making previously invalid blocks valid in the new version. Obviously, this is not forward compatible as older versions will not accept the new blocks, causing the users of the old paradigm to remain on their own blockchain-fork indefinitely. To implement a hardfork, without a blockchain-fork, all users must switch to the new protocol consensually.

HF != blockchain-forks

Lately, I've seen "hardfork" being used interchangeably with "chain split". They refer to different things. A chain split is the state of the network when mining is based on more than one chaintip at the same time. This can happen for various reasons, including hardforks, softforks, buggy node software, and simply two miners discovering a block at the same height.


While calculating merkle proof, where are the other hashes being stored? Consider that I have a merkle root made up of transactions a,b,c,d,e,f,g,h.

The root is H( H(H(a)+H(b)) + H(H(b)+H(b)) ) + H( H(H(b)+H(b)) + H(H(b)+H(h)) ).

Now, I have to verify whether transaction C is part of this root (which it is).

I am supposed to get hash of c H(c), which I can using the one-way hash function.

But then, after that I must get hash of other values also: H(d), H(H(H(a)+(b))) and so on in order to verify that c is a part of the Merkle tree.... Where do these hash values come from? Are they stored somewhere? If not, how are they dynamically generated?

And if all hashes are stored, how do I know that my hash H(C) has to be paired with H(D) and not H(A). Similarly for other levels also.
Doesn't storing all hashes defeat the purpose of optimizing space?

These are not stored anywhere, and are calculated by the node.

The order in which transactions are included in the tree is the same as the order in which they appear in the block, which answers your last questions. To calculate a tree, one simply traverses the block's tx list, including them in pairs of two (and duplicating the last one if needed) to build all of the leaf nodes.

When asked if a block contains a particular transactions, nodes will check that block's transaction list. If the transaction exists, they will calculate the hashes you mentioned above to produce a merkle path, which contains the minimum nodes required to verify the transaction against the merkle root.

Since SPV wallets are aware of the block headers, they can verify the merkle root of the merkle path matches the one in the block header.


Unable to find where transactions sent I sent this transaction and it took a long time to confirm as you can see
023d90420161bbb5f97480d673405d19b79de1c4a7383c8977b62b16926d881c.

Now I have asked the recipient and they have said that I used the wrong address. If that is the case. Where are my bicoin now please?

It is very hard to do a typo in a Bitcoin address, as the address format includes a checksum. Have you checked whether you accidentally sent to a previous business partner? Have you checked whether the address that you sent to matches the address that you were asked to? If the latter is true the error may be on the side of the recipient.

In any case, the coins are now under the control of whomever the recipient address of the transaction belongs to. If

the address is unclaimed: the coins are lost.
the address is claimed by a known entity: you may be able to retrieve them by contacting them.
the address is claimed by an unknown entity: the recipient will do whatever they want.

Try googling the (unique!) respective address to see if someone is asking about receiving an unknown payment. It wouldn't be the first time. ;)


How do I go about installing a Bitcoin daemon in CentOS Linux? I am trying to setup a Drupal e-commerce solution with a payment gateway of accepting Bitcoins during checkout, but I need a bitcoin daemon installed. How do I go about installing the Bitcoin daemon in my CentOS installation?

Is there a step-by-step guide on what I need to type to install this? It would be great if it can be installed via a package manager in CentOS. apt-get doesn't seem to work for me.

I host two bitcoind RPMs (i686, x86_64) on my website which will most likely work fine for you, as they're built for CentOS 6.4. Run this command to install bitcoind :

rpm -ivh http://tvdw.eu/bitcoin-0.8.1-1.el6.`uname -m`.rpm

If you want to download them manually, the files are:

i686:   http://tvdw.eu/bitcoin-0.8.1-1.el6.i686.rpm
MD5:    5be52618594a3eaded19052197c2f6ed

x86_64: http://tvdw.eu/bitcoin-0.8.1-1.el6.x86_64.rpm
MD5:    49ba4acbf9744e96bf12342888bc347a

The packages are unsigned, so install these at your own risk (aka: some level of trust is required here).

[Edit] This is the bitcoin.spec file I use to build these packages :

Name:           bitcoin
Version:        0.8.1
Release:        1%{?dist}
Summary:        bitcoin

License:        GPL
URL:            http://bitcoin.org
Source0:        http://sourceforge.net/projects/bitcoin/files/Bitcoin/bitcoin-%{version}/bitcoin-%{version}-linux.tar.gz

%description
bitcoin

%package qt
Summary:        bitcoin-qt
%description qt
bitcoin-qt

%prep
%setup -q -n bitcoin-%{version}-linux

%build

%install
mkdir -p %{buildroot}%{_bindir}
%ifarch x86_64
cp -R bin/64/* %{buildroot}%{_bindir}
%endif
%ifarch i686
cp -R bin/32/* %{buildroot}%{_bindir}
%endif

%clean
rm -rf %{buildroot}

%files
%doc README COPYING
/usr/bin/bitcoind

%files qt
/usr/bin/bitcoin-qt

%changelog

There's no actual compilation involved, it just puts the files in the right locations and wraps it in a nice little RPM.


Can an unconfirmed transaction fall under the radar? Something very peculiar has happened with a transaction and I would like to understand what network conditions can possibly be the cause of this.

I transferred about 150mBTC from my Android wallet to my bitcoin core HD wallet (v0.13.0) I have done quite a few of these transfers, and typically within at most a few seconds, the transaction is relayed by the network and appears in my bitcoin core mempool. In this case, the transaction still has not been seen by bitcoin-qt for almost an hour. It is a very ordinary transaction with quite a high fee of 0.1 mBTC (for only 225 bytes).

I initially thought that my Android had failed to broadcast the transaction. However, this assumption can be dismissed as blockchain.info has successfully received it, providing me with a transaction id.

I then thought that bitcoin-qt possibly did not recognize the transaction was in relation to my HD wallet. However, it seems that the transaction was in fact never received by my node:

$ cat ~/.bitcoin/debug.log | grep <transaction id>    # nothing appears

So I am now under the impression that the transaction was successfully broadcast but for some reason was never relayed to my node. In fact, something like 5 new blocks have appeared since the initial broadcast and the transaction still isn't confirmed (which given the level of fees and no apparent network bottleneck seems very unusual). So I am now under the impression that some miners may not have seen the transaction either (after all if this can happen to my node, why not others?)

Incidentally I have tried to re-broadcast the transaction with https://blockchain.info/pushtx and the raw transaction id, but it tells me the transaction already exists.

Does anyone have a plausible explanation of what may trigger this sort of rare event, where a transaction is seemingly successfully broadcast, but not all nodes seem to hear about it (assuming this interpretation is valid)?

EDIT:
Actually looking at https://blockchain.info/unconfirmed-transactions, as I was writing up this question until now, the number has been rising and is now showing about 18k unmatched transactions which seems to point at abnormal network conditions (typically 2k-4k)

EDIT:
The transaction was eventually confirmed about 10 blocks later. The fact remains that it was seemingly never relayed to my node until its inclusion in a new block.

It's not a rare event. It's the nature of the network that not all transactions will reach all nodes. There's also the possibility that some nodes have heard of the transaction but then dropped it from their mempool when they encountered higher fee transactions. They do this to prevent DDoS attacks because memory is a scarce resource and they can only hold so many unconfirmed transactions in their mempool.

Once the transaction confirms everyone will hear about it because it'll have been incorporated in a block. So I wouldn't worry about it.


Recommended resources or tuts for Bitcoin/Bitcoin Exchange clone using Ruby/Rails? Are there any reputable resources or tuts for re-building a Bitcoin/Bitcoin Exchange clone using Ruby/Rails (e.g. Michael Hartl tutorial)? I would like to experiment and learn more about blockchain transactions.  Thank you!

The biggest Ruby-related Bitcoin project is Toshi by Coinbase.

You can obviously read through the source code. And read through the documentation in the github repo.

There's also bitcoin-ruby which should get you started on how to program bitcoin stuff using Ruby.


How to start programming your own Bitcoin client? I want to develop my own Bitcoin client in a language that is not yet supported. Are there any resources that can be referenced to help me, or any other future developer with the task, or is the source code for the official client (and other clients) the only thing to go by? Has anyone made some cohesive documentation of the Bitcoin protocol, that if followed would guarantee the finished client would be able to operate along with the existing clients?

I don't believe anyone has published a detailed spec anywhere if that is what you are hoping for.  There is some information on the bitcoin wiki, but your best option is to review the existing implementations.

Check out BitCoinJ (a from scratch bitcoin implementation in Java) and BitCoinSharp (a C# port of BitCoinJ).  They are not full implementations yet, but they are very far along and can do most of the tasks of a bitcoin client.

No matter what language you plan to create your implementation in, looking at these is very valuable because they are very thoroughly commented and much easier to understand than the official C++ client.


Is normal ECDSA verification slower than a verification method based on Public Key Recovery? Background info:

This post on the Cryptography stack exchange shows how to almost uniquely recover the public key from the signature, hash of the signed data, and knowledge of the curve: https://crypto.stackexchange.com/questions/18105/how-does-recovering-the-public-key-from-an-ecdsa-signature-work. I believe it basically produces two public keys for which the signature given will validate for the hash.

Main Question:

Given a public key Q, a signature S, and the hash of some data H, it seems that there are two ways that we can verify that this triple is valid.

We can run the usual ECDSA verification routine, which is somewhat time intensive.
We can run public key recovery with (S, H, Curve) and verify that one of the 2 possible returned public keys (4, really, since each can be either compressed/decompressed) is the point Q. I am not sure if this is more/less time intensive.

So,

Is verification through public key recovery more or less time intensive than the usual ECDSA verification?
If less, then couldn't bitcoin do all it's ECDSA verification through public key recovery and save time? Granted, checking a pubkey-hash would involve taking each candidate public key, OP_HASH160 hashing it and seeing if it comes out to the right 20 bytes of the address. And if none of the 4 possibilities hash to the correct value, then the signature verification failed.

My only reason for asking this is that ECDSA verification is slow, and I read somewhere that public key recovery is very fast, so just wanted to see if anyone has any insight into this.

Verification w/ Public key recovery is never going to be faster than normal verification however it is only marginally slower.  I benchmarked it a while back and PubKey recovery added about 5% overhead.

Changing the txn format would require a hard fork so it is unlikely that is going to happen but the advantage of pubkey recovery is that it trades storage for time.  This could be useful for Bitcoin as processor power is less of a bottleneck than WAN bandwidth especially in residential 'last mile' scenarios.

A typical 2in, 2out P2PkH transaction is 373 bytes with compressed keys and 437 bytes using uncompressed keys).  The same transaction without pubkeys would be 309 bytes resulting in a storage (bandwidth and memory) reduction of 17% to 29% in exchange for 5% increase in CPU time.

Hashing is extremely fast so performing 4 hashes vs 1 hash is negligible but a single byte can remove that overhead.  The protocol would require using a flag with the signature to indicate which form to use when recovering the PubKey.

0x02 = compressed even
0x03 = compressed odd
0x04 = uncompressed even
0x05 = uncompressed odd

This really only saves significant space in P2PkH transactions. For P2SH (i.e. multisig) the script is very likely to contain full pubkeys instead of keyhashes.

While using PubKey recovery initially would have made sense the cost in terms of needing a hardfork doesn't make that change very viable.  If putting a hardfork on the table there are a lot of more interesting things that could be done instead.  For example switching from ECDSA to Schnorr signatures would allow native thresholding signatures.  This would reduce the number of signatures from one (or more in the case of multisig) per input to just one per transaction.  As 64 bytes each that would really add up.


What percentage of merchant Bitcoin receipts are immediately converted into fiat? Does anyone have access to this data from Bitpay or Coinbase perhaps?

If so please break down the data by country and industry if available and how these statistics have changed over time.

The last stats Bitpay published were in December, 2014, so it may be somewhat out of date. They said that 10% of the merchants keep settle entirely in Bitcoin, 41% of the merchants keep a part of their settlement in Bitcoin, and the remainder settle entirely in fiat.

That said, there are plenty of instances where BitPay merchants get settled in Bitcoin, and then use a local exchange to turn that into fiat. This is in instances where, for example, BitPay doesn't support fiat payouts in that country, or BitPay's fiat rate is lower than the local exchange's. I think it's safe to say that the actual percentage is much lower than 10%.

Of the 41% that partly settle in Bitcoin it's hard to know what the average percentage split looks like, and BitPay don't make that information available.


I lost my private key I have BTC in my wallet but I lost my private key and I can't do transactions anymore.
How can I get a new private key or pass the BTC to another address?

If you don't have the private key, there is no way to access those coins.  Period.  The security of Bitcoin as a currency relies on that fact.

Either recover the private key somehow, or consider the coins gone.


Why are there two transaction outputs when sending to one address? I did a small transaction some days ago:

https://www.blockchain.com/btc/tx/4c07a07dfd9d5b79d168ec6835df876c64e82350a8f9211bf586d858a5aeb9ba

Some info:

1JFWE8THcAQQRYx99c43DXSGyoPL9Zs62D is my wallet
1PCGNxgheKTaeT6xvTabcY8ZbS3gDpFtb is the wallet I sent 0.22 BTC

Questions:

Who is 147krm8yWUcVq9Ta25h679TCpsEznzgvRz?
Why there is more than one output?

147krm8yWUcVq9Ta25h679TCpsEznzgvRz is the change from the transaction. There was more than one output because you didn't have any previous transactions (sometimes thought of as "coins") that added up the exact amount of the transaction.

So your client picked some coins that added up to at least that amount and then created a new address to receive the leftover amount. So, 147krm8yWUcVq9Ta25h679TCpsEznzgvRz is you. You just don't know it because the client isn't good at disclosing that you. Essentially you wanted to send 22 cents, but only had dollar bills in your wallet. So the 0.78 was the leftover amount and the client created a new address to hold it rather than reusing 1JFWE8THcAQQRYx99c43DXSGyoPL9Zs62D.

It seems that this behavior of the Qt client (silently creating new addresses that receive the change from transactions) was created for privacy reasons. I believe the thinking was, why send the change back to the original address when a new address could easily be created? In that way, it's not even obvious whether your transaction was a payment of 0.78 BTC with a change of 0.22, or a payment of 0.22 BTC with a change of 0.78 BTC. But it seems to be causing a lot of confusion for users, based on what I see on this stack exchange. In my opinion, it might be better if the default client sent the change back to the sending address. Or if, at least, it showed that change address and its balance somewhere.

Some other wallets do let you manually select which address should receive the change from a transaction.


Recommended way to automatically retry sending of bitcoin via JSONRPC upon failure Sometimes when sending bitcoin out, sometimes bitcoind's JSON-RPC replies with a 500 error. I'd like to safely automatically retry, but it seems that there's not way to set a nonce to safely retry.

I have some complicated ideas to be able to retry in a safe way, but I imagine something like the nonce is easiest. Any safe ways to retry out there?

Try to figure out why you get an http error 500. Check your debug.log, double-check the command you're sending that causes the 500. Try to solve it.
After you sent your Bitcoins or got an error, check if the desired recipient has been payed by fetching your wallet transactions and parsing it after the recipient and eventually the amount. Use listsinceblock or listtransactions. Eventually use the txid for performance from a successful sendrawtransaction (or send* command). Use time-range in case you reuse addresses.
Make sure you flag your transaction as "sent" (in your application / user-flow logic) when you can fetch it over the listcommands (see 2.)
Re-creating the payment transaction in case of a sudden crash or shutdown of your system may be done by forging, signing and sending the transaction again.


Mobile Android Wallet for Dash that lets you do a private dash send transaction? As of today 2018 June, is there an Android wallet that lets you do a dash private send? I know coinomi has Dash, but it doesn't have the privacy send features.

No. Currently, the PrivateSend feature is only available at the Dash Core wallet (desktop). The next protocol release (12.4), expected in the second half of 2018 will include deterministic masternode lists, that will make it possible to implement PrivateSend in mobile wallets.


Confused About Hash In Satoshi Nakamoto Diagram In Satoshi Nakamoto's diagram:

Consider the Hash block in the first transaction block above:

How is that Hash value calculated? I see arrows from an Owner's Public Key and another arrow, so it's confusing. Is the arrow coming from the Owner's Public Key saying that the Hash is encrypted with the owner's public key? If yes, then what is the other arrow? Is that involved during the encryption with the public key? In other words, does the previous transaction's hash get somehow combined with a new hash before being encrypted with the public key? What exactly is going on here?

Thank you.

Firstly, transactions are not blocks, and blocks are not transactions. They are two distinct data structures that you seem to think are the same thing.

  How is that calculated?

By performing SHA256 double on the transaction.

  I see an arrow coming from the left (I'll get to that in a moment)--it seems to depict the Hash of the previous transaction block. But the arrow coming from Owner 1's Public Key confuses me too. Is this diagram saying that owner 1's public key is hashed together with the previous block's hash value? Is that what actually happens in Bitcoin, or is there more detail?

Yes, the public key is part of the data that is hashed in a transaction.

  'd like to see the original block in the depicted hash chain because that original block wouldn't have a previous block hash to reference. So would that mean that the first block's hash is just a hash of the owner's public key?

A transaction is more than just a public key and an output. But the first transaction in that transaction chain does not have any inputs so it does not have any previous transactions that it references. This transaction is known as a coinbase transaction or a coin generation transaction. It is created by miners and essentially produces Bitcoin out of nothingness.

  Are there any good resources that go into more technical detail about the first block in the transaction hash chain and how these hashes are calculated?

Bitcoin.org's developer guide explains most of Bitcoin's details.

  Is the arrow coming from the Owner's Public Key saying that the Hash is encrypted with the owner's public key?

No, it is saying that the public key is used to verify Owner 1's signature. This public key is specified in the previous transaction. In order to know what the previous transaction is, we place the hash of it in the current transaction (Owner 2's transaction). That way we can quickly lookup Owner 1's transaction to retrieve Owner 1's public key.

There is no encryption that happens in the Bitcoin protocol. Nothing is encrypted.

  In other words, does the previous transaction's hash get somehow combined with a new hash before being encrypted with the public key?

Yes, the previous transaction's hash is combined with the other data in the current transaction to produce the current transaction's hash.

Instead of trying to understand the technical details and diagrams that Satoshi put in the whitepaper, you should try to understand how Bitcoin actually works today based on the code and other documentation available. The whitepaper does not describe how Bitcoin actually works; it was written months before the first release and lots of details changed between the concepts in the whitepaper and the actual implementation of those concepts.


Can I regenerate blkindex.dat from blk0001.dat? My copy of blkindex.dat became corrupted, but I still have the whole blk0001.dat file.

Is it possible to reconstruct the blkindex.dat file from the blk0001.dat file or do I have to delete both files and redownload the whole blockchain from scratch?

Edit: Pieter's answer is working for me.  It's taking many hours to run, but at least it isn't using any bandwidth.  I'm wondering, as a related question, whether this bitcoind -loadblock=blk0001.dat.bak technique is a way of being able to get a trusted copy of the blockchain from an untrusted source.  If I download a blk0001.dat from a random website, then import it using this -loadblock command, does that ensure it's correct, and ask the network for anything the download was missing?

While running, the command just said:

SetBestChain: new best=00000000000004411998  height=174305  work=284206530118085534778
SetBestChain: new best=00000000000009a01d64  height=174306  work=284213516218692473063
InvalidChainFound: invalid block=000000000000038181de  height=174307  work=284220502319299411348
InvalidChainFound:  current best=00000000000009a01d64  height=174306  work=284213516218692473063
SetBestChain: new best=00000000000007e352ec  height=174307  work=284220502319299411348
SetBestChain: new best=00000000000006b4b91c  height=174308  work=284227488419906349633

Is that normal, representing an orphaned block?  Or possibly the result of the same disk error that caused the blkindex.dat to become corrupted initially?

This is possible in git HEAD, and will be in 0.7.0. You can move the existing blk0001.dat elsewhere, delete blkindex.dat, and then start the client using ./bitcoind -loadblock=blk0001.dat.bak


How to protect bitcoinj wallet? I am a new BitcoinJ user, I have few questions related about its wallet, can anyone please help:

Is there any way to encrypt the .wallet file? will anyone obtain a copy of the file be able to spend all bitcoin in it?
Is there a chance of damaging the file if I stop my application often or incorrectly?

Thanks a lot.

Yes, you can encrypt the wallet

  It’s a good idea to encrypt your private keys if you only spend money from your wallet rarely. The Wallet.encrypt("password") method will derive an AES key from an Scrypt hash of the given password string and use it to encrypt the private keys in the wallet, you can then provide the password when signing transactions or to fully decrypt the wallet. You can also provide your own AES keys if you don’t want to derive them from a password, and you can also customize the Scrypt hash parameters.

Yes, you can corrupt the wallet, but not if you do things the right way.

  By default the Wallet is just an in-memory object, it won’t save by itself. You can use saveToFile() or saveToOutputStream() when you want to persist the wallet. It’s best to use saveToFile() if possible because this will write to a temporary file and then atomically rename it, giving you assurance that the wallet won’t be half-written or corrupted if something goes wrong half way through the saving process.

Source: https://bitcoinj.github.io/working-with-the-wallet


Confirm transaction in regtest mode I'm testing some wallet features on regtest. Here's the sequence so far:

cash-cli -regtest generate 101
cash-cli -regtest getbalance
500.00000000

cash-cli -regtest getnewaddress newAddress1
yeAPxkjsNk5RZnAyfHM6cjCtKM7oRUvhzX

cash-cli -regtest  sendtoaddress getrawtransaction 148b8ced78037cb8fe3b32b8814dbf6736c144448671a86da548bbdb5670750a 1
//...
{
      "value": 2.00000000,
      "valueSat": 200000000,
      "n": 0,
      "scriptPubKey": {
        "asm": "OP_DUP OP_HASH160 c3bc1c481a15343ceb27d45d950c8770b7a0be1c OP_EQUALVERIFY OP_CHECKSIG",
        "hex": "76a914c3bc1c481a15343ceb27d45d950c8770b7a0be1c88ac",
        "reqSigs": 1,
        "type": "pubkeyhash",
        "addresses": [
          "yeAPxkjsNk5RZnAyfHM6cjCtKM7oRUvhzX"
        ]
      }
    },
//...

dash-cli -regtest gettxout 148b8ced78037cb8fe3b32b8814dbf6736c144448671a86da548bbdb5670750a 0 false
//returns nothing as the transaction is not confirmed. Returns result if we change flag to true

How do I set transaction as confirmed in regtest mode so that dash-cli -regtest <txid> <outid> false would return the transaction output as a valid one?

A transaction is confirmed by including it in a block. This means that you have to mine a block which includes the transaction. You can do this using the generate command.


Can two related "spends" be in the same block? Consider the case where:

Address A has some BTC.
Address B is empty/zero.
Address C is the intended recipient.

B sending to C is invalid on its own, but does make sense if associated with A sending to B first
Can two dependent transactions be put into the same block and accepted?

A ==> B
B ==> C

(Since the net result will be OK, even though the second transaction does not make sense until the first one is completed)

Yes, but only if A -> B is placed before B -> C in the list of transactions.
Here is a graph of the percentage of transactions spending each other in the same block, it is usually around 10%.


How to calculate transaction size before sending (Legacy Non-Segwit - P2PKH/P2SH) I know that I pay the transaction fee per kB, so how can I calculate how large the transaction will be before I send it via the RPC api. I run a site using bitcoins, and I cannot let the user's balance go negative, so I need to know if they have enough balance to cover the cost.

Assuming all the inputs you are spending are from regular "pay to address" transactions, each input will contribute 180 (plus or minus 1) bytes to the transaction.  Each output adds 34 bytes to the transaction.  And there's a fixed extra 10 bytes which are always present.

The "plus or minus 1" comes from the fact that each input needs a signature to be claimed.  The signature contains two 32 byte values, but if either of the values has a first byte of 0x80 or more, it has a 0x00 byte prepended to it.  So I'm assuming one of the two is high and the other is low.  That way I'm off by at most one byte per input.

So if your transaction has in inputs and out outputs, the transaction size, in bytes will be:

in*180 + out*34 + 10 plus or minus 'in'

For example, this transaction has 40 inputs and 16 outputs.  That gives us a transaction size of

40*180 + 16*34 + 10 +- 40

i.e. 7754 +- 40 bytes.  The actual size is 7761 bytes.

If the inputs are from "pay to pubkey" transactions then the inputs are smaller than for "pay to address" transactions.  And this will be different also for "pay to script hash" inputs too, depending on how/if that's implemented.

Edit: This transaction was made with bitcoins stolen in the Linode heist and shows a transaction size of 1337, possibly a deliberate use of leetspeak in the blockchain.

Edit2: Now that compressed public keys are commonplace, each input is 32 bytes shorter and so the transaction size is now:

in*148 + out*34 + 10 plus or minus 'in'


Can we interpret a rolling average transaction count per block as the 'adoption curve' for Bitcoin? It is widely accepted that Bitcoin is both a transaction network, and a currency subject to speculative market action like established fiat currencies. In a sense, it is a transaction network with a 'capacitor' in the middle, which happens to be stored value in the form of the world's first distributed digital currency.

I investigated and performed some analysis around Bitcoin Days Destroyed, and found it a little empty in terms of measuring the adoption of Bitcoin as a tranactional currency. Instead, I simply took a moving average of the number of transactions per block as a straight indicator of real transactional activity. This analysis makes no attempt to measure or attribute meaning to the size of transactions; the focus is exclusively on the volume of transactions.

To that end, the attached is a graph of transactions per block which includes a linear best-fit trend and a 255 sample rolling average. Both show clearly that the transaction count has trended down over the past few months. How valid is this graph as a proxy for the adoption of Bitcoin as a tranactional currency, and what level of activity should we want to see before we'd consider Bitcoin a 'success' as such a currency?

NOTE: in the graph below, the the slope co-efficient is transactions/(block*day), so the implication is that the average number of transactions per block is falling at a rate of 0.0716 per day, or about 1 transaction fewer every 2 weeks.

The main problem I can see with using such a metric to measure adoption is that a tremendous amount of transactions take place on the various exchanges during periods of heavy speculative investment.

During the current downtrend we're probably experiencing a lower percentage of traffic from investors and a higher percentage of traffic from actual users of the currency. The problem is that there isn't really any feasible method of weeding out the MtGox, TradeHill, Britcoin etc traffic from the regular use cases.

The only way that I can imagine being able to weed out such transactions is if MtGox and their ilk actually provided a full list of the transactions they process each day. Armed with a list of transactions from at least the major exchanges we could mostly eliminate speculative use from our measurements and see something closer to actual adoption levels.

Unfortunately to my knowledge no such transaction list exists and without it, it's uncertain if such a rolling average is showing a decline in actual adoption or simply a decline in speculation. One of the big difficulties to be encountered in Bitcoin is that it's simultaneously quite open and extremely closed and can be very difficult to perform meaningful analysis on.


Source code: Where is address encoding performed? I would like to experiment with having fewer characters (trimming a few characters at the end, and fewer checksum) for an address while still retaining enough for adequate security.

I've looked into base56.h but it doesn't seem to actually check addresses?

firstbits.com provides a service that links short values to longer addresses, which might be close to what you're looking for.

You could easily shorten addresses by extending the character set that addresses use, but any non-standard way of sharing an address has to be usable by whatever person or software receives it. I'll leave it to someone else to point you to the line of code though.


Can miners collude to bypass the penalty based revocation system of the lightning network? The core lightning security assumption relies on a punishment mechanism called “Justice Transaction”. However, how can you prevent a malicious user from colluding with a miner, and producing a block with old state transactions without the rest of the network (watchtowers/honest nodes) realising it pre-mining?

When a channel is closed unilaterally, it requires two transactions by the closing party to move funds from a channel back into unilateral control.
The closing party publishes their version of the commitment transaction to the network. The commitment transaction has a special condition for the closer's output.  After the commitment transaction is included in a block, the closing party's funds are locked for a period of time in which only the counterparty is able to issue their penalty transaction. The closing party can only spend their output after the lock expires. Since the two spending conditions are encoded in the output's locking script, the funds remain subject to potential penalty spending until the closing party moves the funds to a different output.
To prevent a penalty transaction from occurring during the wait period, the attacker would need to be able to censor the penalty transaction from being included in any block between the commitment transaction being confirmed and the lock expiring. Censorship of such level would require sufficient hashrate to reorganize any block that includes it.


Generating P2WSH addresses | Is there a standard WitnessScript? For the examples below I am going to be talking of 1-of-1 multisig only derived from a single private key.
For P2WPKH, the address is generated using using hash160 of the public key which acts as the witness program.
For P2WSH, is there any standard witness program? The demo in https://bc-2.jp/tools/bech32demo/index.html uses <pubkey> OP_CHECKSIG[0xac] as the WitnessScript. While bitcoinaddress pip package uses a different approach (see https://github.com/fortesp/bitcoinaddress/blob/master/bitcoinaddress/address.py#L130-L133 )
(Please excuse any wrong nomenclature I might have used in this question)

It is 0 and a 32-byte push of Sha256 of the scriptPubKey (which is the script you use to generate the address). You can find an example here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wsh
The Python example you linked uses WP2PSH as WP2PKH. You can see the how WP2PKH works here: https://github.com/bitcoin/bips/blob/master/bip-0141.mediawiki#p2wpkh


How to calculate block generation time from block's data? I'm working on paper Double-Spending Attacks on Fast Payments in Bitcoin.

And I see they give out the result :

  block generation time is approximately 10 minutes (9 minutes and 54
  seconds), the standard deviation of the measurements was about 881.24
  seconds

They used data from blockexplorer, with data from block #0 to block # 153260.

Here is the data of Block #0 and Block #1

Then I calculate block generation as:

 Block generation time for block#n= (timestamp of block#n+1) - (timestamp of block#n)

But I get the result as below:

Mean: 9.8 minute = 9 minute 48 secod

standard deviation: 1477.469066205157

It's quite different to paper aforementioned paper.

If anyone worked or know how to work with blockchain data, please help me.

Block generation time for block#n= (timestamp of block#n+1) - (timestamp of block#n)

I'd say the block generation time for block#n should be:

genTime(block#n) = timestamp(block#n) - timestamp(block#n-1)

However, this doesn't explain the huge discrepancy.

If you're sure that 1) you're using the same dataset, i.e. the same window of blocks!, and 2) calculating exactly the same quantity as they are, and still arrive at different results, you might want to get in touch with the authors of the paper to compare notes and see where your calculations differ.


What should I tell someone so they can restore my bitcoin from a seed in 20 years? I'm making a metal backup of my bitcoin wallet. It's tedious to do by hand, so I want to add the right info but not to much. This is my current idea, I want someone else to understand it 20 years from now, if i'm dead. This is what i've come up with so far.

Seed:

This is a wallet seed generated with a Trezor wallet in 2017 using bip39.
It can be used to get access to bitcoin. Keep it Safe.

Pass-phrcace (on other location):

This is a wallet seed passphrace generated with a Trezor wallet in
2017, using bip39. Use it with a wallet seed stamped on a similar plate.
It can be used to get access to bitcoin, Ethereum and Litecoin and maybe
other currencies.
Keep it Safe.

The bitcoin seed will contain a small amount of bitcoin and the most will be decrypted with the passphrase.

I'll probably attatch the bip39 specc on paper aswell(anything else) but that might burn up or whatnot so the vital info should be in the metal-stamp.

You probably can get that engraved or something since its a general background information.

But if you do not have the room or want to stamp that much, you could probably get away with a few key words such as wallet recovery seed, trezor, BIP39, etc. One could search those few terms and find out what it's for. Although, it is a bit of a security risk if a random person finds it.


If more than one coin did the "mini-blockchain" proposal, would that make the weaker coin vulnerable? So, I was reading this paper as a proposal to the ever growing blockchain problem. In summary, it's security is provided without a full blockchain by having a proof chain with these fields:

Previous proof block hash
block header hash

Now this is all fine, but one problem I see is what if 2 coins were to adopt this scheme? If one chain was vastly more powerful than another, than an attacker could take the other blockchain and build fake transactions and blocks onto it and then introduce it to the weaker coin's peers. The peers would see it as having a higher overall difficulty/length and adopt it. Other than verifying the genesis block's hash and embedding it within the peer/wallet software, is there any other way to prevent this attack? The paper also mentions trimming extremely old proof blocks, but that doesn't appear to be possible to securely do if the genesis block could be pruned from the proof chain.

While I didn't see it addressed explicitly in the paper, the attack could be defeated by requiring a competing blockchain to have common ancestry in the proof-chain in order for it to be considered.

Out of the proposed triplet account-tree, mini-blockchain, and proof-chain, the proof-chain has by far the least memory requirement with only 512 bit (64 byte) per element. If applied to a coin with a blocktime of 1 minute, one year worth of proof-chain would only have 32 megabytes (containing 525600 proofhashes), while one year worth of proof-chain should be sufficient to allow for any valid competing chains.

The above assumes of course that each of the triplet does what it should be doing. I had one follow-up question though, posted here: Mini-Blockchain proposal: How is the proof-chain secured against injections?


Purpose of unique header in block hashing algorithm https://en.bitcoin.it/wiki/Block_hashing_algorithm said this about the block header:

"Given just those fields, people would frequently generate the exact same sequence of hashes as each other and the fastest CPU would almost always win."

But isn't that exactly what we want?

So, they use the merkleRoot which makes the header nearly unique and "Every hash you calculate has the same chance of winning as every other hash calculated by the network."

I guess this change makes CPU speed less important, but not much less important.  How much less important is CPU speed (or even network latency) with the addition of the merkleRoot to the block header?

I think you might have misinterpreted the article. The MerkelRoots is a representation of all the transaction in the block that you're currently trying to mine. They are unique because the first transaction in each block is unique to each miner. The uniqueness guarantees that the sequence of generated hashes will be different for each miner. And because of this uniqueness, the sequence of hashes generated by a low-powered CPU might occasionally lead to the desired result before a high-powered monster CPU does, whereas if everyone were following the same sequence, the high-powered monster CPU would always find the desired result first. So in essence, the first transaction introduces uniqueness that makes CPU speed less important and not the MerkelRoot.

Incidentally, I had almost finished answering the question in a completely different way when I realized the confusion. In case that answer is helpful, here it is ...

In mining, you're constantly changing a block (by updating the nonce) and trying to find a hash that meets the proper requirements. You're also changing the transactions in a block, (which also changes it's hash), but this happens much less frequently. Hashing the entire block is an expensive operation, but hashing only a small part is not as expensive. Since you're changing the transactions -- by far the largest part -- much less frequently than the nonce, it makes sense to "cache" the change so that the mining hash operation doesn't take so many resources.

The Merkle Root is this cache, that is, it [compactly] represents any changes in the list of transactions. Thus when you hash the header (which includes any change in the nonce or the transaction), you are still hashing the entire block.

Assuming that CPUs scale linearly, the answer to your question about how much less important CPU speed is disappointingly probably not at all. The benefit that you get is that any CPU will be able to calculate more hashes per second than with the alternative, and this should be proportional to the CPU's power/clock-speed.

You also mentioned network latency, but as all of the hashing takes place on individual computers and full transactions are sent throughout the network, whether or not a Merkel Root is used wouldn't affect network traffic.


What is the most common use of Bitcoin? I'm a total newbie here, and I've read a bit on Bitcoin.  I get that it's a cryptographic currency, and that it can't be directly "cashed", etc.

I'm interested in the common purchase using Bitcoin - what do you buy with Bitcoin?

I found this link the other day that shows where you can use bitcoins https://www.spendbitcoins.com/places/?place_type=service  mostly for hosting companies, some poker sites/online casinos & many computer co's that i'm sure most people would never use right now.
Saw an article that a restaurant in NY wanted to accept them soon but probably its a marketing gimmick before the crash to get some free publicity.
there is also that article of the guy in Canada wanting to sell his house for bitcoins. I'm sure he's going to need much more bitcoins now after the 2 day crash unless bounces back.

Many have used them on Silk road for buying drugs too but I'm sure gov't going to crack down on that . Heard they caught some guy in Australia recently for Silk Road.

Hope that helps


Why do small transactions without fees ever get processed? I understand that adding a small transaction fee as incentive ensures block generators will include your transaction.

When you have no transaction fee, what is their motivation then?
Why do some people include it and some don't?
I have read many accounts stating that small transactions are less likely to be included - so is a big (in terms of amount of bitcoin) transaction with no fees more likely to be included, and if so, why?

1) There is no motivation, asides your goodwill, or possibly wanting to support some useful Bitcoin tools, like the Bitcoin Faucet (transaction fees could eat up a lot of coins there).

2) It's a matter of how their pools and clients are set up. Some want to support the community by allowing no-fee transactions to be included in a block (as it costs them nothing), while others want to encourage people to pay fees by only including transactions with fees.

3) Technically, it might be less likely to be included if it gets really big in terms of data size (upwards to filling a block), but in most cases it won't matter (at least for now). Amount of Bitcoins sent doesn't really matter at the moment, but transactions on really small amount of coins can be discriminated against in the future should spamming them become more prevelent.

All in all, it is encouraged that you pay your dues when sending transactions, as it helps the Bitcoin project grow. If nobody was paying to get their transactions processed, the miners might soon not earn enough to get by (especially with reward halving slowly getting closer), which would result in them stopping their operations and weakening the Bitcoin network. It's not much of a threat yet, but in the future it can become important.


How to use the "Bootstrap.dat" file with bitcoin-qt? I have searched around, and nothing I find works for me.
Downloaded the approx. 10 GB Bootstrap.dat file. Now stuck on trying to link it with Bitcoin-QT.

Tried the following command in the console box in the bitcoin-qt app:

bitcon-qt -loadblock=/path/to/bootstrap.dat

Also tried copying the file into the AppData/Roaming/Bitcoin file... Still no luck.

I'm running Windows 7, anyone have step by step instructions on how to set this up?

Okay, it appears after much trial and error, I figured out that you put the bootstrap.dat file in the AppData/Roaming/Bitcoin or ~/.bitcoin folder. You can leave everything else in that folder untouched, just add the bootstrap.dat file in the Bitcoin folder.

I left bootstrap.dat in there, and finally Bitcoin-QT found it, and on the bottom it states "Importing blocks from disk..." I'm currently at 80 weeks behind on the update, compared to 240+.

I was reading crap about using the -loadblock command and extracting/unzipping the .dat file.... well this wasn't needed.  At least it isn't needed on the current version of QT, which I believe is .8.0.5


I sent my bitcoin to my own email adress instead of to my wallet, Now what? I sent my bitcoin to my own email address instead of to my wallet, Now what? I tried to send it fromcoin base to blockchain  instead I sent it to my email address I don't know how to get it to my blockcain wallet from my email

The bitcoin protocol does not support sending Bitcoins to an email address, so I am assuming that Coinbase offers a Paypal-like service that allows sending Bitcoin to family and friends' accounts with their email address. Check the inbox of the email address that you put on there for instructions on how to redeem those Bitcoins at Coinbase, otherwise, contact their support.


Why does the BFL Single produce ~50% stales with P2Pool? I've heard from users on bitcointalk forums that the BFL single doesn't work with P2Pool as it produces about 50% rejected shares, which is insanely high.

Why is this?

Is it possible that the hashing is not actually being done on the chip itself? And it's just taking place on an external server then submitted to the P2Pool node, which would maybe explain why the stale rate is so high due to network latency? (especially since BFL refuse to say what chip they are actually using in their Singles)

Thanks

The BFL single produces high stale rates on P2Pool because of the way its firmware is designed. The BFL does 2^32 hashes and then reports any shares found. This takes it about 5 seconds.

With solo mining or typical pools, the work unit you get is valid for several minutes or until a new block is found (on average, one every ten minutes). So the average delay of 2-1/2 seconds between when you find a share and when it's reported has no effect. But P2Pool operates with an effectively much higher block rate because you're building blocks for the P2Pool chain.

Essentially, it comes down to which races you're trying to win and whether an average 2-1/2 second handicap matters.

Solo mining: You're trying to find a block before someone else does. That happens on average every 10 minutes. So your 2-1/2 second handicap costs you about .4%.

Conventional mining pool: You're trying to find a share before the block is invalid. You can find multiple shares inside the same work unit. Work units typically last at least 4 minutes. Worst case, your 2-1/2 second handicap costs you about 1% (usually less, especially if the pool has a forgiving stale policy).

P2Pool: You're trying to mine a P2Pool block before anyone else finds a share. Multiple shares in a work unit are useless as only one block can come next on the P2Pool chain. The average time to find a new P2Pool block is 10 seconds. Your 2-1/2 second handicap (plus loss of additional shares per block) costs you about 25%.

Unfortunately, all these penalties should be doubled because the same penalty hits you when a new block is first found. All your units spend, on average, an extra 2-1/2 seconds finishing their work on the old block. (Effectively, the entire 5 seconds spent on a work unit while a new block is found is wasted. Any shares found before the five seconds are over are wasted since it's too late to use them, and any shares found after the five seconds are over are wasted since they were based on the wrong block.)

The fix would be a simple firmware change to make the FPGA report a share as soon as one is found. That would solve half the problem. The next change would be to allow the FPGA to start working on a new work unit when a new one is available without having to finish the previous. That would solve the other half of the problem.


Clarification on execution of complex script with OP_CHECKLOCKTIMEVERIFY I'm quoting this example of BIP65

BIP 65 has this bitcoin script code

 IF
    <now + 3 months> CHECKLOCKTIMEVERIFY DROP
    <Lenny's pubkey> CHECKSIGVERIFY
    1
 ELSE
    2
 ENDIF
 <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG

And with this bitcoin scriptSig is possible unlock the transaction

Now with this ScriptSig 0 <Alice's signature> <Bob's signature> 0
after 3 months with this ScirpSig 0 <Alice/Bob's signature> <Lenny's signature> 1

But I don't understand this part of If-then-else

ELSE
    2

When is it executed and what I don't understand inside the if-then-else condition?

Bitcoin uses a stack based language due to which the logical condition that will execute the IF or ELSE statements comes prior to the operator IF or ELSE. Let's take both your cases one by one and see how it gets executed on the stack.

Case 1: ScriptSig: 0 <Alice's signature> <Bob's signature> 0

The stack starts at 0 <Alice's signature> <Bob's signature> 0
Since 0 is on top of the stack, the ELSE condition will execute and drop the 0
number 2 is pushed on the stack
Stack is now 0 <Alice's signature> <Bob's signature> 2
script outside the IF/ELSE statement is pushed to the stack
Stack is now 0 <Alice's signature> <Bob's signature> 2 <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG
This is a normal 2-of-2 Multi-sig operation that will execute by verifying both Alice's and Bob's signature to the public keys

Case 2: ScriptSig: 0 <Alice/Bob's signature> <Lenny's signature> 1

The stack starts at 0 <Alice/Bob's signature> <Lenny's signature> 1
Since 1 is on top of the stack, the IF statement will execute and drop the 1
<now + 3 months> CHECKLOCKTIMEVERIFY is pushed to the stack and verified whether 3 months have passed. If yes, the execution will continue.
DROP operator drops the TRUE on top of the stack if verification is successful
<Lenny's pubkey> CHECKSIGVERIFY is pushed to the stack
Stack is now 0 <Alice/Bob's signature> <Lenny's signature> <Lenny's pubkey> CHECKSIGVERIFY
CHECKSIGVERIFY will consume the top 2 items of the stack. It will check whether Lenny's signature matches Lenny's pubkey. If yes, the execution will continue.
Stack is now 0 <Alice/Bob's signature>
1 is pushed to the stack
Stack is now 0 <Alice/Bob's signature> 1
Script outside the IF/ELSE statement is pushed to the stack
Stack is now 0 <Alice/Bob's signature> 1 <Alice's pubkey> <Bob's pubkey> 2 CHECKMULTISIG
This is now a normal 1-of-2 multisig operation and will execute if Alice or Bob provides a valid signatures to their pub key.


Why does the first bitcoin client only supported windows Starting from version 0.1.0 up to 0.1.5 the bitcoin software could be run only on only Windows 2000 / Windows NT and Windows XP
Was there a technical reason from Satoshi for this choice of operating system, or maybe he wanted his client to be run on the maximum amount of computer, or maybe he had more knowledge of windows ? Linux seem more fit for open source and "Cypherpunk" that windows.

If you want a definitive answer, you'll need to ask him I'm afraid.
My best guess is that Windows development was the thing he was most familiar with (or even only familiar with). The coding style was also similar to one commonly used in the 90's by Windows developers.


Assistance to receive my money Pls, someone introduce Bitcoin mining to me, that I will be receiving 50% of money invested after 6hrs. He has me to pay him in order to fund my wallet. I transfer money to him,  he ask for my wallet ID and password. I refuse in the first instance but he said he want to connect my wallet to mining. The password was released. He funded the account. It reaches 7-8 hrs I didn't see any increase in my balance till the following day. I now decided to withdraw my money back. It then I noticed that there is imported Bitcoin address requesting for private key. I later click on menu to click on addresses  ,I saw archived address again...
Pls, what can I do to  receive my money?
I have changed my password. And I have my recovery phrase with me.
How can I remove imported address and private key. And the archive Bitcoin address.

Looks like you give someone your bitcoin login which is the worse thing you can do. Unless you know that person and can really be trusted, this could be a type of scam. Try to withdraw all your money and if you can't mean he got all your money.

Never invest with random peoples/website <= A very very high risk


At the beginning. when nobody owned bitcoins. what was being minned? what I understood about mining a block is that,
New/pending transactions are to be verified and placed into a block solving the proof of work.
The miners are rewarded for this task.

In the very beginning.. when there were no transactions taking place.. what were they mining? what were in those blocks?
how did bitcoin circulate all over the world?

The first blocks were completely empty and didn't contain any transactions.
The first transaction was in block 170 from Satoshi to Hal Finney, as seen here.

As newly generated coins from mined blocks are only spendable after 100 blocks, the earliest possible block to spend the first coins would have been at block 101.

It is completely legit to mine empty blocks (even if there are pending unconfirmed transactions). Here is an example of an empty block on April 2017.


Lost Exchange Account I transferred some bitcoin from my coinbase account to another exchange to purchase some ethereum.  At that time coinbase did not have ethereum.  However, I do not remember the exchange that I used.  I have the exchange password written down in a secure location so if I can track which exchange I sent it to I can recover the ETH.  The transfer from coinbase is listed on the coinbase website.  Is there a way for me to use the wallet ID which I sent the BTC to to find out which exchange is holding my ETH?

Thanks in advance for your assistance in helping me overcome my own disorganization.

Man, maybe the answer will shock you, but... your amount of crypto is probably lost.
I say ''probably'' and not for sure.
the options may be 2:
1. the transaction was too small, so miners didn't pick it
2. it's fault of the exchange
I don't suggest you to use coinbase, I suggest you buy on spectrocoin -> https://spectrocoin.com/en/
And to trade from crypto to crypto using Binance -> https://www.binance.com/?ref=16821839
Anyway here's a guide to choose the best exchange -> https://medium.com/@bitfinexed/coinbase-insider-trading-litecoin-edition-be64ead3facc


I have 23 words of my 24 word mnemonic (and passphrase) for my ledger nano-s, is it possible for me to brute-force the last word (not in order) I have ended up wiping my ledger nanao S during test (thoroughly stupid I know) and I am left with 23 (!) seed words and a passphrase. I understand that I should have both backed up my wallet, and made sure of my seed words.  I was looking into a program (in python due to there not being too many combinations) that could brute force it due to me knowing that I had written them down in order, just having missed a word, (pasted here due to the massive size due to the size of the word list)

So how would I go about brute forcing it through python, what I have now can (as far as I can see) will give me all of the valid mnemonics, but from there how would I automate the collection of private keys from a bip-39 generator, and the checking of funds in them?

(edit)
I know the order of the words, just not where the missing one is, Ive tried to manually sift through the combinations for if the missing word was the last one

(further edit)
Im using an offline version of this site for turning the mnemonics into private keys iancoleman.io/bip39 but unfortunately I dont know how to canabalise the code or interact with it with python. from there I was going to use a tool like this github.com/gurnec/btcrecover to find the wallet with btc in it. At least thats what I have so far.

There are 2048 words in the BIP39 list, there are 24 possible positions for your missing word.

You need to try 2048 x 24 = 49,152 combinations.

For each one, you need to generate a private key + public key and check whether addresses generated from that have any unspent bitcoin associated with them. You can work with a pruned blockchain and probably further prune based on the known date-ranges of your most recent transactions.

Superficially at least, it seems feasible for an automated process to do this in reasonable time (i.e. less than years).

Having tried all words in one position you should have a reasonable idea of how long this will take.


Is there another wallet that can restore from MultiBit's seed words? We've had a lot of questions revolving around stuck transactions due to apparently non-existent fee estimation and unconfirmed balance bugs on MultiBit in the past weeks. Some get resolved by using the "Repair wallet function", others successfully recovered their wallet by installing MultiBit on another device and restoring from the seed words.

As MultiBit appears to continue to have issues even months after first reports, I would like to be able to recommend another wallet that can simply recover the funds from MultiBit's seed words.

What other wallets can recover the wallet from MultiBit's seed words?

(If this is different between MultiBit HD and MultiBit Classic, please be specific in your answer.)

As far as I know, no wallet uses the same derivation path as Multibit HD so a Multibit HD wallet cannot be restored to another wallet. However, using a site like https://iancoleman.github.io/bip39/, you can get the private keys for your addresses and import them into another wallet.

To use https://iancoleman.github.io/bip39/ to get your keys, first download the page and run it locally, don't actually use the website. See the Offline Usage section of the page for instructions to get it offline. Once the page is loaded into your browser offline, enter your Multibit HD wallet words into the box labeled "BIP 39 Mnemonic". Then scroll down and choose the tab labeled "BIP 32". Click the dropdown box labeled "Client" and choose the "Multibit HD" option. Scroll down to the section labeled "Derived addresses".

These addresses are all of the addresses that belong to your Multibit HD wallet. You can increase the number of addresses generated so that you actually get all of the addresses that you have used. The private keys are available in the rightmost column. You can then import/sweep those private keys into another wallet.


To be more energy efficient, wouldn't be a consensual fork - right now - without the reward of new mined btc for each block helpful? As the reward is lower, less effort is spend in mining new bitcoins. How the transactions fees will evolve would be quite crucial the get the miners activity down (and their energy consumption). I would assume that the transactions fees would stay at very low levels, because every miner has always an incentive to add any transaction with a positive fee.
Additional question: For sure there are some cryptocurrencies which reached that state (of no mining new coins). How did the transaction fees evolve after mining the last coin?

I would assume that the transactions fees would stay or converge to be very low levels, because every miner has always an incentive to add any transaction with a positive fee.

Block space is finite, so users are bidding for their position within the next block. Miners will always choose the transactions which have the highest feerate because it makes their income the highest. Today the fee rate often makes up a significant ($100k+ USD) portion of the total block reward.

https://mempool.space/

How the transactions fees will evolve would be quite crucial the get the miners activity down (and their energy consumption).

Mining activity would reduce naturally if there was less reward, but there's no opportunity for changing core principles of Bitcoin like this.
As a valuable currency Bitcoin needs to be predictable and justifiable, if the rules dramatically changed it would make a fairly lousy currency. You wouldn't be able to invest in mining hardware for example, if you couldn't model even the base income a couple of months into the future. Making even small changes to the economics of the system opens the floodgates for others. ultimately.

For sure there are some cryptocurrencies which reached that state (of no mining new coins). How did the transaction fees evolve after mining the last coin?

There's no useful comparisons to be made, nothing has the scale, maturity, and properties of Bitcoin.


Abandoned transaction - now can't send anything Earlier today I sent a tx with too low a fee (5.4sat/byte). After many hours in BitcoinCore I abandoned the transaction with the right-click option with a plan to send it again with a higher fee. I achieved this by starting BitcoinCore with -walletbroadcast=0 and thereby accessing the abandon menu item

Now none of my transactions small - or - large will broadcast. In BitcoinCore I just get stuck with Status: 0/unconfirmed, in memory pool and when I try to use a pushtx like blockchain.com or viabtc I get the error Validation Error: BitcoindException(super=com.neemre.btcdcli4j.core.BitcoindException: Error #-26: 18: txn-mempool-conflict, code=-26)

Deleting the memcache file won't help either as its clearly in the memcache of other nodes.

In BitcoinCore the funds are showing as spendable and I am able to click send, it just wont broadcast.

What can I do? I run a pruned node so I can't use zapwallettxes and I can't use bumpfee as the Transaction is not BIP 125 replaceable (code -5)

I'm fresh out of ideas other than downloading 180GB full chain in order to run zapwallettxes

Once the tx is broadcast, you cannot simply cancel it. This is because nodes already know about it, and it is a valid transaction waiting to be mined. Since the fee is low, it might sit in the mempool for a couple weeks (see -mempoolexpiry), or until the mempool gets large enough it gets bumped out as the lowest fee rate tx (see -maxmempool default is 300MB). You can do something like replace by fee, which replaces the previous transaction with one that has a higher fee. I think the real question that needs to be asked is Why is my transaction not getting confirmed and what can I do about it? Also, How do transactions leave the memory pool might also be helpful.


Bitcoin check if the transaction is valid When a node receives a new transaction, that node will check if the one broadcasting the transaction has enough coins to initiate it. Bitcoin follows a UTXO model, therefore the node has to check in the past if the sender has enough coins.

Is this check linear in time? Where can I read to know more about it?

The Bitcoin Network does not keep track of 'account balances', instead it uses an 'unspent transaction output' model. Each node will keep an updated list of all unspent transaction outputs (UTXOs), so that when it hears about a new transaction, it can verify that the transaction is only spending valid UTXOs. This check is done quite simply: the UTXOs used in the transaction must be present in the node's UTXO set. If the transaction attempts to spend a UTXO that does not exist (ie, 'insufficient balance'), then the transaction will be rejected as invalid.

See these questions for more information:

How is a wallet's balance computed?

Where is the UTXO data stored?

How big is the UTXO database?

How can a miner verify that a UTXOs is not spent elsewhere?

Why does Bitcoin store all transaction inputs and outputs, instead of just an "account/balance" ledger?


If my phone is powered off will i still receive my bitcoin I sent someone Bitcoin but they said they didn't receive it because their phone is powered off but I got a complete transaction confirmation

The recipient doesn't need to have a wallet online to receive Bitcoins.
This is because the transfer of the money is recorded in the blockchain - which every full node (wallets etc) worldwide has a copy of.
Bitcoin wallets don't actually contain money. So they don't literally receive money. The only really important data in a wallet is the secret number known as a private key.


Does Ripple use an RDBMS? If so, which one? Do Ripple servers use RDBMS?

If so, which one?

I think I remember reading that Bitcoin uses some sort of file database.  Same for Ripple?

The ripple server uses SQLite for structured data and a configurable "back end" for unstructured "bulk" storage.

The structured data consists of things like transactions indexed by which accounts they affected. The unstructured data consists of "chunks" of data indexed by hash that constitute portions of network history.

The preferred back end for bulk storage is currently RocksDB on Linux platforms.


how to start mining with FPGA I found that in my university there are some FPGA's available to test and to play with. I am a software/web programmer and I have never been working with verilog or whatever is used to program FPGA.

So is there a nice tutorial which explains how to start mining using FPGA. I do not want to create a fancy 2 - 10 connected FPGAs to run mine for profit, but I just want to start one FPGA and to see how it is working and what speed it is giving me.

I have checked the question: What software/hardware is required to mine with an FPGA?, but it does not provide information, I needed.

P.S: I also have seen this post: https://bitcointalk.org/index.php?topic=9047.0 , but I hope to hear from someone who started to mine by himself and can share his experience.

So is there an easy to use tutorial for a not microsystem guy who wants to test mining. Or this is so complicated?

P.S. The vendor is Xilinx.

I have two different models:

The model for the simple one is Spartan 3E
The model for the advanced one is Virtex5

So is there a nice tutorial which explains how to start mining using FPGA.

Not really, not a "starting from scratch" one.

  Or this is so complicated?

Yes, it is quite complicated - in order to work with FPGAs, some additional skills on top of software are required.  You need to understand logic design and some (fairly basic) electronics in order to make a successful FPGA.

However, as a learning project, if it's something that interests you, I'd say it's worth a go - you'll learn a lot, but it won't be a quick-and-easy learning experience :)

But start small - first off, write an FPGA which just flashes an LED on and off slowly - that enables you to learn lots of the low-level details without a complex logic design going on.  The FPGA equivalent of "Hello World"!

EDIT:

If you've already done some FPGA work, then "all" you need to do is build a SHA implementation, some method of getting data to and from it and a little control logic.  I haven't done it myself, but I got about that far along a "thought-design" before deciding I wasn't sufficiently interested to pursue it further.


Classifying Miners based on their Location Is there any way to classify the bitcoin miners based on their geographical locations?
Is there any possibility of doing so for the participants in cooperative mining as well?
Thank you

Is there any way to classify the bitcoin miners based on their geographical locations?

According to this answer it's not possible to check IP address of miners: https://bitcoin.stackexchange.com/a/66269
Even if it is possible with a workaround, they can use Tor, VPN, other proxy etc.
Non-KYC mining pools exist so miners do not share their real identity and location with pools. Even if they share such information, it can be faked and not necessary they have all the ASICs at one location.
Lot of journalists and researchers use other information and assumptions to speculate miners location. Example: https://coinshares.com/assets/resources/Research/bitcoin-mining-network-december-2019.pdf


Why do outputs need to be spent entirely? I understand what change is and how it works (and it's analogous to physical money change), but what I don't understand is why this is needed in the first place.

Given that this is all computer based, I thought that money could be sent just by saying “I will give you 0.5 BTC” and verifying that your addresses in fact contain more than 0.5 BTC, and then substracting the spent amount.

So, my question is, why does the protocol define that outputs must be spent entirely? Where's the benefit of doing that instead of just sending the fraction that is needed?

It's in fact a little more advanced than you imagine it. (So expect this answer to be a bit more in-depth.)

There is no such thing as an accounts "balance". It only exists implicitly.

When people make transactions, they actually create outputs for a certain amount of bitcoins. Using a special script language, the person making the transaction can specify the requirement for spending that output. There's a whole range of options you have to specify this.

The most common output script is something that holds the following condition "to spend this transaction, the spender must sign this hash with the private key from this address". So this basically means that the owner of that address can spend it. This are the type of outputs that you will probably generate when you "send money to an address". They are called pay-to-pubkey-hash transactions.

Other possible output scripts can be stupid things like "anyone can spend this" to very complex things like "at least 3 of the private keys of the following 5 addresses must sign this hash", which is a so-called m-of-n transaction.

This brings us back to balances. When your wallet app says you have a balance of X btc, it just searches all unspent outputs that you are able to spend with your private keys; this are all pay-to-pubkey-hash transactions with one of your addresses in them.

Now, when you want to spend some of the money from your "balance" and send it to an address, you will need to make a transaction. The way transactions are created is as follows:

Take a number of unspent outputs from previous transactions and use them as inputs.
Make a new output of which the output amount is equal or less than the sum of all input values. Your wallet will most probably make this output a pay-to-pubkey-hash output to the address you wanted to send money to.
Because probably the inputs will not exactly match, you will add another output so that the sum of all new outputs is equal to the sum of the inputs. This output will also be a pay-to-pubkey-hash output to a new change address or to the same address as you are spending from (different wallet apps do this differently).
Note that if the total output amount is less than the total input amount, the difference is considered the transaction fee and this will go to the miner of the block your transaction will appear in.
Then lastly the wallet app has to prove it has the right to spend the inputs you used in the transaction. It can do this to provide an input script (technically it's called a scriptSig). For the common pay-to-pubkey-hash, this script will contain your public key and the signature you made with your private key. This input script is used by miners to verify if you have the right to make this transaction.
The transaction is then broadcast to the Bitcoin network.

After this transaction has been received by other clients and is verified by a miner, all clients will remove the outputs used in the transaction from their collection of "unspent outputs". So if you would try to spend it again, that won't be possible because miners will not accept it because the output you want to spend does not exist.

I hope you can understand that using this methodology, it is not possible to do a thing like "subtract the amount from person A's balance and add it to person B's balance". When making transactions, you basically destroy some outputs to generate new ones.


Can an SHA256 hash be used as an ECDSA private key? Is it possible to map a pass-phrase directly to a Bitcoin private key by using its SHA256 hash? I remember reading somewhere that not all 256 bit values are valid ECDSA private keys. If so, how can I make sure that the resulting hash is valid, or is there some other canonical way of mapping a pass-phrase to a private key?

While the question isn't an exact duplicate, the answer essentially is, so I'm going to quote this answer by Pieter Wuille:

  As is normal when doing Elliptic Curve encryption, a private key is
  simply a random number. In the case of secp256k1, the elliptic curve
  used by Bitcoin, it has to be a number between 1 and
  115792089210356248762697446949407573529996955224135760342422259061068512044368
  (or in hexadecimal, between 1 and
  FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551.

  This private key is converted to a public key by performing an EC
  point multiplication with the curve's base point. The result is an
  (x,y) coordinate pair, which constitutes the public key.

  Finally, RIPEMD160(SHA256(pubkey)), where pubkey is a serialization of
  those coordinates, is computed, and encoded in base58, together with a
  checksum. This becomes the address.

So the short answer is yes, as long as the resulting hash is less than or equal to FFFFFFFF00000000FFFFFFFFFFFFFFFFBCE6FAADA7179E84F3B9CAC2FC632551 any SHA256 hash is an acceptable privkey.

As for a canonical method of mapping a passphrase to a privkey, I don't believe there is one - after all, this functionality isn't built into the Satoshi client (at least not yet) so there cannot, by definition, be a canonical method. The closest thing I can think of would be the mini private key format used by Casascius physical bitcoins, which could easily be used with a passphrase instead. Indeed Casascius' Bitcoin Address Utility is often the app of choice for those wishing to make "mental wallets" from memorized passphrases rather than random inputs.


Is the blockchain crossplatform? I have the full client running in a local Windows machine but I want to move it to a VPS with Linux.  Will I need to download the whole blockchain again or can I just upload the copy I have on the pc?

I believe the blk*.dat files are just the raw block data, so they should be the same on all platforms.  You'll probably have to regenerate the databases (-reindex) which may take quite a while.

Note that Bitcoin Core needs a couple gigabytes of RAM to run well, which is more than most cheap VPSes come with.  And of course the 120+ GB of disk space for the blockchain data itself.


How are offers matched up on Ripple trades? I'm trying to better understand how buy and sell offers work on the Ripple network.

Let's say Alice creates a new Ripple currency, calls it XYZ, and describes it to her friends Bob and Carol.

Bob loves the new XYZ currency.  He submits an offer to buy 1 XYZ for 3 XRP.

Carol merely likes XYZ.  She offers to buy 1 XYZ for just 1 XRP.

That's the set up.  I'm wondering what happens in the following cases...

What if Alice offers to sell 2 XYZ for 4 XRP?  Will the ripple network transfer 1 XYZ each to Bob and Carol?  Or, must Alice wait until someone offers to buy exactly the number of XYZ she is selling?

What if instead Alice offers to sell just 1 XYZ for 2 XRP?  Only Bob's offer of 3 XRP meets the price. But will Bob spend just 2 XRP (what Alice asked) or 3 XRP (what he offered)?

Finally, what if Alice offers to sell just 1 XYZ for 1 XRP? Will she end up with 3 XRP from Bob, 1 XRP from Bob, or 1 XRP from Carol?

Offers are always filled best first. Among tying offers, the one placed first is taken first.

Once they're placed, offers are always taken at the rate they were placed. Offers are always placed at their original rate, regardless of what crossing offers they take.

When an offer is placed, any crossing offers (existing offers in the other direction that can satisfy all or part of the new offer) are taken. It is up to the person who placed the offer whether counter-offers that tie their rate are taken.

The difference between a "buy" offer and a "sell" offer is only how the offer is placed after crossing offers are taken. For example:

If there are no crossing offers, there is no difference between an offer to buy 1 XYZ for 1 XRP and an offer to sell 1 XRP for 1 XYZ. But ...

If you place an offer to buy 1 XYZ for 1 XRP and crossing offers allow you to buy .5 XYZ for .1 XRP, the remaining offer will be to buy .5 XYZ for .5 XRP. (So, when/if your offer is fully consumed, you will buy 1 XYZ for .6 XRP.)

If you place an offer to sell 1 XRP for 1 XYZ and crossing offers allow you to sell .1 XRP for .5 XYZ, the remaining offer will be to sell .9 XRP for .9 XYZ. (So when/if your offer is fully consumed, you will sell 1 XRP for 1.4 XYZ.)


what is meant by DEFAULT_ANCESTOR_LIMIT in child pay for parent? Why is 25 the max parents a child can rescue in a child pay for parent?

I don't think I understand what DEFAULT_ANCESTOR_LIMIT = 25 means.

Does that also mean that the child transaction has 25 input utxos from those parents?

Bitcoin Core by default does not forward a transaction to its peers, when the full tree of its ancestor transactions contains more than 25 unconfirmed transactions or 101 kvB of unconfirmed transaction data. This limit helps curb spam attacks using long chains of unconfirmed transactions.

Example1:
If you have no unconfirmed transactions associated with your wallet, and then send a single transaction, you may spend the unconfirmed change output of the first transaction in a second transaction. This second transaction would now have one ancestor transaction for the purpose of the above described metric.

Example2: Alice sends funds to you and Bob, but Alice's transaction itself spends outputs from two other unconfirmed transactions. If you use the transaction output sent to you by Alice, you will have an ancestor count of 3. If Bob then also spends his output in yet another transaction, his ancestor count is also 3. Your transaction is not part of Bob transaction's ancestry.

Unless you create a lot of transactions in rapid succession or always pay minimum fees even when there is a large queue of transactions waiting to be confirmed, you will not usually get to 25 ancestor transactions.


Why Bitcoin Core does not support importing extended public keys directly? I'm trying to create a watch-only wallet importing the extended public key from a Ledger Nano (as an example) but is not to easy to do directly to my Node, I should do it through electrum personal server or something like that.
I was trying to find a clear (like 5 years old) explanation of what is the reason for that.
I was trying to do that in the mainnet and from the regtest following the next command in order to get the checksum but all the time a message said that the key is not valid.

bitcoin-cli --regtest getdescriptorinfo "wpkh(vpub5UwuWtLWaprMvQBpnZeufhRAqYsgrYf7ZMxr6Kf7N41aa9M7UzZJ1e7HMwzdxGnfer5g2PaFgcvmNU7iRZAasNXz6EdDW6FGdcKf8m4oF7b/*)"

And there are plans to allow this import function?, I think so it's a very convenience feature.

The structure of the Bitcoin Core wallet makes it difficult to implement importing extended public keys. This structure makes several assumptions about keys available in the keypool which xpubs do not meet. One such assumption is availability of private keys. While it isn't impossible to implement support for it, doing so is difficult to do, difficult to review, and is largely a hack on top of a hack.

Recently, native descriptor wallets was merged into Bitcoin Core so you will be able to import xpubs that are in a descriptor in 0.21. Native descriptor wallets took a long time to implement because of structural changes that had to be made to the wallet to even be able to support this.


When can I send 80 byte OP_Returns? I heard bitcoin-core 0.11 allows 80 byte OP_Returns, but I know miners operate different implementations and was wondering when it would be likely that 80 byte OP_Returns will be swiftly included in blocks.

As you can see, only 10.8% of nodes have upgraded to 0.11 and 29.3% of nodes use a pre-0.10 distribution. (Source: https://getaddr.bitnodes.io/dashboard/#user-agents)

Considering that we don't know the hashing power of these nodes and don't know your definition of "swiftly included", there's no way to exactly answer your query.

However, if you assume hashing power to be equally distributed between nodes, There's about a 10% chance that any give block will be mined by someone running 0.11, so about a 47% chance that a 0.11 block will be mined at least once an hour.


requesting transaction information through peer2peer network got notfound my current understanding is that after i did my "handshake" with a public node succesfully, i should be able to do a getdata mesage about a transaction from a transaction hash and they should respond with an inv message containing my transaction right?

when i do that i instead receive a "notfound" object. does this means i also have to make sure that i connect to enough node that atleast one node have the data of what i wanted.

thanks in advance!

'def main():
    address = ("35.180.184.150", 8333)
    sock = handshake(address)
    send_getheaders(sock) #get 4000 headers and blocks

    #--------------
    #
    global thres
    thres = 0
    while True and thres < 3 : #thres is so that my program doesnt listen to b'inv for eternity
        try:
            packet = Packet.from_socket(sock)
        except EOFError as e:
            print("Peer hung up")
            return
        except Exception as e:
            print(f'encountered "{e}" reading packet')
        handle_packet(packet, sock)
    tx_hash = int("27936a1262df5d27547f8e12549be5301e71d5aa4d8d82a030530336029f77eb",16)
    #tx_hash from one of the block
    items = [InventoryItem(1, int_to_bytes(tx_hash, 32))]#getting tx
    getdata = GetData(items=items)
    packet = Packet(getdata.command, getdata.to_bytes())
    sock.send(packet.to_bytes())
    return sock'

This only works for unconfirmed transactions. Nodes do not maintian an index of confirmed transactions because this is unnecessary, so you will receive notfound.


What did Gavin mean when said minimum fees would be automatically suggested? From the release notes of the Bitcoin version that introduced minimum transaction fees:

  ... note that we intend to replace the hard-coded fees with code that automatically calculates and suggests appropriate fees in the 0.9 release ...

Has Gavin expanded on the implementation of this automatic calculation?

Yes, this has actually been going on for a longer time, and it is expected to arrive in the next (0.10) release.

Citing Gavin:

  Instead of using hard-coded rules for what fees to pay, the code observes how long transactions are taking to confirm and then uses that data to estimate the right fee to pay so the transaction confirms quickly– or decides that the transaction has a high enough priority to be sent for free but still confirm quickly.

In practice, you'll be able to select the priority of your outgoing transaction and the fees will be calculated accordingly, taking the current "market situation" into consideration.

Once implemented, it will no longer be necessary to dictate or suggest the optimal fee centrally, as it is now.

You can read more in the original article by Gavin Andresen.


Primary security risks of Bitcoin QT API use When using an API to operate Bitcoin QT remotely, which security concerns should I be most worried about?

Bitcoin-Cores RPC API is not meant to be available on the public internet. It's not hardened enough and the authentication (HTTP BASE AUTH) is not safe.

If you want to connect to the RPC-API over the internet, you have a couple of options...

use VPN (openVPN, etc.)
use stunnel
use Apache with a reverse proxy and enable SSL (probably most easy to setup)

Also have a look at the 0.12 release notes:
https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.12.0.md#rpc-ssl-support-dropped


bitcoin-cli could not locate RPC credentials I'm running a bitcoind 0.16 and it seem working, blockchain in sync etc..
I've used the "new" rpcauth, which is non deprecated so kind of referennce as explained here: https://github.com/bitcoin/bitcoin/blob/v0.16.0/contrib/debian/examples/bitcoin.conf. I've generated the rpcauth line and the password with
./share/rpcauth/rpcauth.py bob

Copied the rpc line in the ~/.bitcoin/bitcoin.conf file and stored the password elsewhere. The conf file have this [rpc] section:

server=1
rest=1
rpcauth=bob:b2dd077cb54591a2f3139e69a897ac$4e71f08d48b4347cf8eff3815c0e25ae2e9a4340474079f55705f40574f4ec99

I run

./src/bitcoin-cli get blockchaininfo -rpcuser={...} -rpcpassword={...}

The answer is:

error: Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set.  See -rpcpassword and -stdinrpcpass.  Configuration file: (/home/bitcoin/.bitcoin/bitcoin.conf)

It's like the cli can't read the rpc credentials from the command line. It's not saying "credentials are wrong". Also the conf file is the correct one so...

Any clue?

You are using bitcoin-cli incorrectly.

The command line arguments come before the RPC command. Anything that comes after the RPC command will be interpreted as arguments for the RPC, not arguments to bitcoin-cli

So what you should actually be doing is

src/bitcoin-cli -rpcuser={...} -rpcpassword={...} getblockchaininfo