Is this a safe method for cold storage? Here is the method I plan to use for creating a cold storage. I am very new to all this, and have never used Bitcoin before. I am not very technical either. Anyway, here it is:

Create a live-cd with Ubuntu (on a DVD, not install anything on the hard-drive, I assume everything will be deleted once I turn off the system).
Install Armory on Ubuntu, create an encrypted wallet using the client (encryption just in case the wallet files does not delete for some reason when I turn off the OS). I write down the encryption key on paper.
Generate an address for receiving bitcoin, write down the private and public key on paper.
Generate a paper backup for my Armory wallet, write down the root-code to this on a paper using the "create paper backup" feature of Armory.
If I ever want to send any bitcoins from my wallet and address I delete the wallet and address later. I only send bitcoins by generating a send signature using an Armory offline wallet that is temporary installed on a live CD, and activate the send signature with a "watch only" online wallet. The offline-wallet will never and have never touched the Internet.

This way I should be able to always have access to receive and send my bitcoins if I still have the paper where I wrote down wallet encryption key, bitcoin addresses and wallet root code, and don't have to worry about data corruption or other hardware/software problems.

Is this a safe method? I plan to put about US$10000 in Bitcoins in cold storage now, but I just want to hear what you think about it before :)

Sorry for beeing a noob to this. I have read about generating codes offline using bitaddress.org as an HTML file, but I have not heard from enough people checking their code to see if the "random addresses" is pre-generated by some way and not as "random" as one might think.

It sounds like a lot of hassle to send bitcoins because you have to re-install you offline armory each time. Also, the fact you're trying to do it on a live CD tells me you likely don't have an air-gapped machine. If you think your wallet won't "touch the Internet" in such a case, think root-kit. I would advise against this.

Instead, get a cheap Raspberry Pi (disable the Ethernet) and use that as your offline wallet. If you encrypt the wallet and generate your paper backup, your coins will be very safe, (provided you don't lose your paper backup) and will be less of a headache to access your funds.


How do I delete a Bitcoin full node from my hard drive? I was using Bitcoin Core as my wallet (recently installed), but a couple of hours of syncronizing, all of a sudden, I have no space at all in my hard drive. I deleted bitcoin Core, but that did nothing. What files do I need to delete?

Before you delete you Bitcoin data from your hard drive, ensure that you have backed up the wallet.dat file, or you risk losing your bitcoins in case you received them on the addresses generated by Bitcoin-Core.

Ubuntu

The most easy way to remove Bitcoin-Core from Ubuntu is by running:

sudo apt-get remove bitcoind.

When you run bitcoind, it typically (by default) creates a .bitcoin directory in the home directory of the running user unless you have explicitly specified the datadir to where the software will download the blocks and other data. If you're not sure where this path is, you could run the following command to help find it:

sudo locate .bitcoin.

After finding the path you can purge the entire directory by running the command: sudo rm -rf /path/to/.bitcoin.

Windows

Navigate to Start --> control panel --> programs and features and scroll down the list to where bitcoin core/bitcoin-qt is listed, right click and click "uninstall or change a program" and then try uninstalling it that way.

In Windows, by default the block data is stored in the directory C:\Users\your_username\AppData\Roaming\Bitcoin. If you want to delete the entire existence of Bitcoin blockchain from your machine, you can delete the entire folder.

Finally, run regedit (win + r -> regedit). In the search, enter bitcoin and delete all entries matching the list.


How can I get coins from a personal pool? I'm running a node and a private mining pool, does my miner have to solve the block for me to receive any coin?

Yes, it does.
Pools help reduce the variance in payouts, but aggregated over all your miners, it needs to have enough hashrate to at least find a block occasionally.


Bitcoin disappeared from Trezor wallet Originally I installed my Trezor wallet onto my wife's computer (since my computer doesn't have a USB 2.0 port). Later, I bought an adapter and decided to transition the Trezor wallet to my computer. I went through the process and added a passphrase (which I had not previously done on my wife's computer). I am aware that the passphrase has to be exact, because entering a different passphrase will just bring me to a new wallet. I am sure that the passphrase is correct.
Confusingly, it looks like all of my Bitcoin was transferred out of my wallet when I view it on Bitcoin Explorer. I did not make this transaction and frankly I can't really tell what this transaction means. I am at a loss for where it went and how to get it back.
Any thoughts on what could have happened? Is this a bug?

Looks like you must have entered it in a phishing site that looks like trezor suite.
AFAIK you don't need to enter a seed phrase to transact from Trezor, because the hardware wallet does all the transaction signing for you.
SEED phrases should never be disclosed
Always use the official website https://wallet.trezor.io/


How private key is generated from password in Bitcoin-clients We all know that private address is a 256bit number. But is the process of converting your password to this 256bit number standard across different clients?

I can imagine that a "strong random 40 character password" after transformation/hashing et c might become the stupid 0...000000123 or something like this :)

If this process is standard, does this mean, that backup of wallet.dat is not required, you should remember only the password?

It's not standard across all clients. You mentioned wallet.dat, which I associate with the Bitcoin Core client; that does not use a password to generate private keys; it generates each set of private keys randomly when a new supply of them is needed for transactions.

Some other kinds of wallets, however, are known as HD, or hierarchical deterministic, wallets. When they are initialized they generate a random master key that they use as a basis for generating all of the wallet's subsequent private keys in a deterministic (non-random) way. And many HD wallets, the very first time they're used, display a sequence of natural language words known as a recovery seed. You write down the recovery seed word list on paper and keep it securely secret. If the wallet is lost or destroyed you can input the words into another one of the same type of wallet to re-generate your private keys and hence your coin balance. If you're interested in the technical details, look at the specifications for BIP32 (HD wallets) and BIP39 (recovery seeds).

An HD wallet which uses a recovery seed may allow the user to specify a passphrase, typically intended to be memorized rather than written down, which is used along with the recovery seed to (re-)generate the private keys. For the ones that I've encountered a passphrase is optional.


Eclair Lightning network node is not public I'm using Eclair and have a conf file with content:

eclair.chain=testnet
eclair.node-alias=mynodename
eclair.node-color=ff0000
eclair.api.enabled=true
eclair.server.public-ips=["<ip one>","<ip two>"]
eclair.api.password="my-eclair-api-pass"
eclair.bitcoind.rpcuser=aqaqaqaqaq
eclair.bitcoind.rpcpassword=aqaqaqaqaq
eclair.bitcoind.zmq="tcp://127.0.0.1:29000"
eclair.gui.unit=sat

still I can't see my node in https://explorer.acinq.co/
I can open channels

[Edit 1] My pubkey is 03125205d1b5ae747064491d2b3b30b41fd7ec4e96e0ccede2f71c55891995f675

For future reference:

Lightning Network explorers are also nodes and just make their own "world view" of the network publicly available
Your node will only become publicly visible once a channel has been opened and that information is announced to the network (and reaches the Explorer)
Explorers do update irregularly, so it makes sense to give it some time and check multiple explores


How can I execute `getnewaddress` at my full node from a remote server? I have a full node running on a digital ocean droplet. I have an app running at heroku, and I want to execute getnewaddress from this app. I'm trying to generate BTC addresses to which users can send payment to for payment processing in my app. How can I do this? Thanks in advance.

My app is in Python, for what it's worth.

As chytrik said, a better way of generating new addresses on a remote server would be to export an extended public key (xpub) from your wallet and put only the xpub online. Then your private key material would remain offline, and you could generate new child addresses from the xpub using BIP32.

If you still want to execute getnewaddress on your node, you would have to expose the bitcoin RPC by adding server=1 to the bitcoin.conf file on your node in order to accept JSON-RPC commands and call the getnewaddress directly.


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

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

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

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

Source: http://lightning.network/lightning-network-paper-DRAFT-0.5.pdf

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


Importing keys to a brand new wallet After I imported keys to the brand new wallet I tried to test that it is imported properly so I ran salvagewallet command to verify my new wallet but got these errors!

2014-08-21 12:17:28 WARNING: CWalletDB::Recover skipping key:
2014-08-21 12:17:28 WARNING: CWalletDB::Recover skipping key: Error reading wallet database: CPubKey/CPrivKey corrupt

Could you please help me to understand/solve this problem?

How can you verify a wallet ?

I think you should use

"C:\Program Files\Bitcoin\bitcoin-qt.exe" -zapwallettxes  -dbcache=3000

it will clean the transactions and give you the edge of faster reload.


Why does ScriptSig contain public key, since it can be recovered from the signature and message? Using ECDSA, given a signature and the message signed, it is possible to recover the public key. So it seems to be a waste of up to 65 bytes in each transaction. Why does bitcoin do it? Which cryptocurrencies use the key recovery approach?

it is possible to recover the public key

Yes. But this operation is slow (comparing with other bitcoin script operations). May be Satoshi Nakamoto did not know about it. Anyway, the hard-fork required to implement it. So, you are welcome to create hard-fork or altcoin with this feature implemented.

Have a look to this discussion: https://bitcointalk.org/index.php?topic=6430.0 I can not explain better


Understanding blockchain 'under the hood' how a block is created Bitcoin newbie here: I'm trying to understand the concept of the blockchain but what I don't get is what's going on behind the scenes?

So let's say that there are only 10 miners in the universe and Alice sends 15 BTC to Bob, what happens now?

I understand that a verification needs to happen (to ensure that Alice has 15 BTC to transfer)

Assume miner_1 gets this 'request' and verifies the request as valid. Does he build a block?
How a block is created? Is it created for every request?
How all nodes on the network are being updated that there
s a request/new block?
When SHA256(SHA256(transaction?) occurs? On verification or when adding a block? Is there a good example that shows how this works?
How the miner who managed to find the hash get's a reward?

All miners are gathering transactions that they have heard about on the peer-to-peer gossip network.  This means that when someone broadcasts a transaction it gets propagated to all of the nodes it is connected to which then in turn share it with the nodes they are connected to etc etc...  These transactions are gathered by miners and stored in the mempool.  These are transactions that have not yet been included in a block or "confirmed".  The miner can choose which transactions it would like to include in the block, most miners gather as many TX's as they can to collect a larger reward, some do not some miners can build blocks with little or even no transactions included in it.  It is in the miners best interest to include as many tx's as possible to attain the fees generated by those tx's.  Miners take the aggregated transactions and the hash of the previous block and then generate a random nonce.  These items are all hashed together and if the hash of the block has an appropriate number of leading 0's to pass the current difficulty formula then a valid block has been found.  The miner then propagates the block the same way the transactions are distributed across the gossip network.  When the block is mined a coinbase transaction is created which the miner includes his address in, this address gets the block reward and fees for distribution (usually to a pool of miners).  The network continually adjusts the difficulty formula based on the hashing power of the network to ensure that one block is created about every 10 minutes.  There are some formulas in place to ensure the difficulty doesn't move too fast in the event of a large number of miners going offline at the same time.  Hope this answers your questions.


Depends: libgcc-s1 (>=3.0) but it is not installable (Bitcoind wallet dependency problem on Debian) On Debian I successfully compiled .bitcoind without a wallet, but now I need the wallet.
./configure tells me I need Berkeley CXX headers. Searching for how to do this on Debian brings up a bunch of Ubuntu answers saying to do either
sudo apt-get install libdb4.8-dev libdb4.8++ libdb4.8++-dev

after having added a PPA, or
wget http://download.oracle.com/berkeley-db/db-4.8.30.zip
unzip db-4.8.30.zip
cd db-4.8.30
cd build_unix/
../dist/configure --prefix=/usr/local --enable-cxx
make
make install

Both solutions throw errors. I'm focusing on the 1st solution.
The first solution throws this error:

The following packages have unmet dependencies:
 libdb4.8++ : Depends: libgcc-s1 (>= 3.0) but it is not installable

I'm not sure, but I assume this may be an Ubuntu vs. Debian issue? How can I bypass it?

You probably need a newer version of gcc.
This helped me fix for Ubuntu: https://askubuntu.com/questions/1140183/install-gcc-9-on-ubuntu-18-04
TL&DR: adds custom PPA repo so you will able to upgrade:
sudo add-apt-repository ppa:ubuntu-toolchain-r/test
sudo apt update
sudo apt --fix-broken install


My phones died and can't restore wallet on Copay My phone recently died and I had to reset it all the apps. I tool the 16 character reference I was given in Copay to reinstate my wallet, but there is NOWHERE to put the 16 characters code. Have I just lost all my bitcoin?

Have I just lost all my bitcoin?

Since you haven't practised recovery, that is possible. Likely even.

  there is NOWHERE to put the 16 characters code.

It's not obvious what that 16-character code might represent.

CoPay uses a 12-word recovery phrase (sometimes called a "recovery seed" or "wallet seed")
Bitcoin private-keys are 256-bit numbers usually shown as 64 hexadecimall characters

You normally need one of those or a wallet backup file .

What you can do

Contact CoPay / BitPay
Read the CoPay FAQ
Read about CoPay recovery
Ask new questions here about anything specific you need help with.


Which nVersion bit is the "hard fork bit?" A 2015 draft BIP suggested using a "hard fork bit":

  The most significant bit in nVersion is defined as the hardfork bit. Currently, blocks with this header bit setting to 1 are invalid, since BIP34 interprets nVersion as a signed number and requires it to be >=2 (with BIP66, >=3). Among the 640 bits in the block header, this is the only one which is fixed and serves no purpose, and therefore the best way to indicate the deployment of a hardfork.

https://lists.linuxfoundation.org/pipermail/bitcoin-dev/2015-July/009576.html

If bit indexes increase from left to right, then I imagine the hard fork bit occupying index 31, marked as * below (nVersion is a 32-bit value).

0                   1                   2                   3
0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1|2|3|4|5|6|7|8|9|0|1
                                                              *

According to the proposal, setting bit 31 of nVersion should cause a block to be rejected as invalid.

BIP-9 places further constraints on the available bits, specifically, bits 0-2 must be set as [0, 0, 1]:

  Blocks in the STARTED state get an nVersion whose bit position bit is set to 1. The top 3 bits of such blocks must be 001, so the range of actually possible nVersion values is [0x20000000...0x3FFFFFFF], inclusive.

https://github.com/bitcoin/bips/blob/master/bip-0009.mediawiki

In addition, BIP-9 arranges version bits in increasing order from right to left. That is, version bit 0 is nVersion bit 31, version bit 1 is nVersion bit 30, and so on.

But if this were the case, then version bit 0 would be off-limits. BIP-9 says nothing about this, and in fact BIP-68 was signaled using version bit 0:

  This BIP is to be deployed by "versionbits" BIP9 using bit 0.

https://github.com/bitcoin/bips/blob/master/bip-0068.mediawiki

My questions are simple:

Given my diagram above, which nVersion bit index is the "hard fork bit?"
If I'm correct in my interpretation (I don't believe I am), then how could BIP-68 have been signaled without causing the blocks doing so to be rejected as invalid?

Update: the source of my confusion was thinking that nVersion bit indexing and version bit indexing ran in opposite directions. The don't. To signal readiness for a proposal using version bit 1, for example, nVersion bit 1 is set. BIP-9's rules activate when an nVersion signature is detected. This signature is bits 29-31 set as 1, 0, and 0, respectively. This leaves bit 31 unset.

Peter's answer addresses question (1) above.

As for question (2) BIP-68 signaling didn't cause block rejection because bit 0 was being set, not bit 31.

Bit 31 is sometimes referred to as the hard fork bit.

BIP34 put a constraint on version numbers to be 2 or higher. As the block version is a 32-bit signed integer, setting its highest bit results in a negative number, which would violate BIP34.

As a result, any usage of that bit results in a backward incompatible change to the rules - a hard fork - that is obvious to all participants in the system.


Payment has not arrived at destination! I do not know yet whether is this transaction is confirmed or not because not yet reached the destination !!
https://blockchain.info/tx/962a428acb10ed071b1cf954cbaf763016751b986429df5268424880ee95a7d6.
Can someone help me with advice on what to do

The transaction was confirmed according to the transaction ID you provided (727 Confirmations as of this moment). Have whoever you sent to Bitcoin to check again.


How is Bitcoin supposed to serve as currency when it is all but impossible to spend at the moment (12/2017)? It seems Bitcoin is not standing up to the test of use as currency (that is to say heavy use). I tried to pay someone 0.009BTC (about $150) for some goods which I need in a fairly timely manner. As if I was ordering some supplies from a crafts store. It has been 5 days and the transaction has not been verified. From what I read it may never be verified, i.e. there is no guarantee by design for the transaction to ever be mined, not to mentioned mined in a timely manner. say what you want about the banks, but when I spend fiat currency the transaction goes through immediately and the party I send the funds to can use the funds immediately. And I get my purchased goods in a timely manner. Not so with BTC. As the transaction volume is growing the system is breaking down to the point of being useless as currency. I am not even talking about being able to spend $5 for a hot dog (I am likely die of starvation before the $5 transaction becomes verified). I am all for crypto currency and bypassing the banks, but this model is simply dysfunctional.

Am I wrong? Am I missing something? Is it just growing pains? I think it's like that by design, which is not good.

You were probably trying to pay on the blockchain itself. That's like trying to pay for lunch by moving dollars through the Federal Reserve. You should use some system designed to move small quantities of bitcoins cheaply such as Coinbase.

We don't yet have good decentralized payment systems for bitcoin, so currently bitcoin is primarily being used as a store of value. Think of bitcoin as more like gold than dollars. The Lightning Network is one proposal to provide a way to move small amounts of bitcoin at high speed with low cost.


How can I get more than 1 BTC on testnet? The only way I know of to get testnet coins is through faucets such as the following.

https://testnet-faucet.com/btc-testnet/
https://testnet-faucet.mempool.co/
https://kuttler.eu/en/bitcoin/btc/faucet/
https://coinfaucet.eu/en/btc-testnet/

I found these faucets with a search. They seem to be actively maintained but only give 0.01 tBTC at most. Sometimes they are down or not working for me.
I would like to get at least 1 tBTC to test an application which is expecting more around 0.8 tBTC. How can I get more tBTC? I would be OK with paying for some tBTC. 1 tBTC would take a long time to collect using faucets, and I feel I am abusing their service.

There are no exchanges or services which sell testnet which I know of.
Instead of purchasing directly, mining hardware can be borrowed or rented to directly mine testnet coins. CPU mining is no longer a real possibility for generating over 1 tBTC.
The steps for mining testnet coins would be the following.

Setup Bitcoin testnet full node
Setup pool interface for mining testnet with a SHA256 miner (such as CoiniumServ or P2Pool)
Rent or borrow a SHA256 mining device to generate the coins
Get a testnet address for collecting mining rewards

Ironically, this will probably cost you time, effort and MONEY, but you should be able to get as much tBTC as is needed. Hopefully, there will be an open market for testnet BTC someday.
I also created step-by-step details on how I mined testnet coins which might be helpful.


Not relaying non-standard transactions The following statement appears on the "Script" page in the wiki:

  Note that there is a small number of standard script forms that are relayed from node to node; non-standard scripts are accepted if they are in a block, but nodes will not relay them.

This begs a lot of questions:

What use is a transaction that is never relayed?
How did the transaction make it into a block in the first place if it cannot be relayed? Did this transaction come directly from a client? Was it created at an origin node and put in a block somehow by that node?
What does it mean that the script is "accepted" if it's "in a block"? (I'm aware of the script evaluation process, but the sense of the word "accepted" here doesn't seem to be the same as the standard "evaluate to true" verification process.)
Perhaps most importantly: What good is all this wonderful scripting capability if interesting transactions are not relayed? Won't this cripple the scripting capability for more complex transaction types?

What use is a transaction that is never relayed?

None, unless it is generated by the same person who mines it into a block. But it is not the case that non-standard transactions are never relayed. There are nodes that relay non-standard transactions and miners who include them.

  How did the transaction make it into a block in the first place if it cannot be relayed? Did this transaction come directly from a client? Was it created at an origin node and put in a block somehow by that node?

Nobody said it "cannot be relayed", merely that this particular piece of software does not, by default, relay it.

  What does it mean that the script is "accepted" if it's "in a block"? (I'm aware of the script evaluation process, but the sense of the word "accepted" here doesn't seem to be the same as the standard "evaluate to true" verification process.)

It means that the client cannot reject it or otherwise ignore it. If it gets into a block, it's officially done and its outputs are spendable if the transaction script rules say si.

  Perhaps most importantly: What good is all this wonderful scripting capability if interesting transactions are not relayed? Won't this cripple the scripting capability for more complex transaction types?

That's a good question.


How do I configure a port in my .conf file? This is what my conf file looks like:
prune=600
maxconnections=12
maxuploadtarget=20
rpcuser=user
rpcpassword=password
keypool=10000
server=1

[main]
rpcport=5040

Whenever I run this from the command line I get the following error:

Binding RPC on address ::1 port 5040 failed.
Binding RPC on address 127.0.0.1 port 5040 failed.

I checked for port 5040 using the netstat -a and it was listening, what's the problem?

Windows 10

Run netstat -ab >file.txt then notepad file.txt and search on 5040. I suspect you will find CDPSvc immediately underneath - on my machine this "Connected Devices Platform Service" is already using your port.

If that's so, search on 5041, then 5042 and continue up until search can't find it. That port is free: change your rpcport to match it.


Correct Approach for Payments on Multiple Addresses I have clients that would like to pay for services in BTC.
TL;DR
To generate a new payment address must I generate a new private key (essentially a new wallet)?
Is it better to generate independent private keys for each payment from each client, or to use a determinstic wallet?
Is it possible to automatically move the BTC to a central wallet address without storing the private key for either solution?
How To Generate Multiple Addresses?
Based on this bitcoin.it article:

Addresses are not intended to be used more than once, and doing so has
numerous problems associated [with it].

Therefore, the logic I have follows that each payment received from each client should be to it's own address.
However, I am confused about the generation of multiple addresses, and the best way in which to do it.
Other questions on here, such as this one and this one, indicate that each private key will result in a single address only.  Am I therefore right to conclude that each address for each payment from each client must have it's own private key?
If that is the case (as in my limited understanding it would seem to be), and I am generating the wallet addresses using software, is it better to:

Use a deterministic wallet that generates each payment address for each client from a single 'master key', or
Generate an indepedent private key for each payment address for each client?

Moving BTC To Central Wallet
I need to move the BTC from the received wallet into my wallet in order to spend it.
In either of the scenarios I mentioned, would the 'master key(s)' be securely stored on the server for programmatic use in order to facilitate moving the received funds into my wallet?
If that is the case, would it be more secure to have independent private keys for each instance of a payment from a client?

Short answer: check out BTCPay, it does what you ask. You don't have to create your own server to use it, you can just create an account on an existing instance, for example this one should be fine to being with.
Long answer: you're right when you say that one private key generates one address, but Hierarchical Deterministic (HD) wallets are made to solve that.
Basically they allow to generate a virtually unlimited number of private and public key pairs from one piece of data. Deterministic means that if you know this piece of data, the "seed", you will always generate the same keys in the same order.
But it gets better than that, as you can derive only the public keys, meaning that you can use an unsecured server to generate addresses and receive bitcoin payments without ever exposing your private keys! That's the way BTCPay server work, and that's why you can use another person server to receive payments without trusting him. Worst case he will only know all your addresses, but can never steal your bitcoins.
I'm simplifying a bit, but that's the general idea.
As for your last question, you could have the private keys on another wallet like Electrum, or a Ledger, and then just use that to spend the bitcoins you received on your BTCPay server. I won't go into more details here, you can have a look at the BTCPay documentation or get in touch with their community.
NB: I recommend BTCPay because as far as I can understand your need I think it is the best option, but if you're not confortable with it you could as well use Electrum or a Ledger and send new addresses to your client in email or a secret pastebin for example.
That's great if your customers are okay to pay you in bitcoins. Stay safe, and remember never ever give your seed, or private keys to anyone or any service on the internet.


Where can I find records of blockchain branches? I plan to analyze blockchain branches to satisfy my own curiosity: how often do they occur, are they increasing in frequency, etc. To clarify my earlier mistaken terminology: I am talking about "garden variety" blockchain branches that occur when two miners succeed in mining a new block "at the same time."

Where can I find a record of blockchain branches? I'd love to find a handy webpage with the data, though I am running a full node if someone can walk me through generating the data.

Thanks in advance! Bruce

There may be websites that index them, however, as blocks only get propagated once they get accepted as new best chain, such branches don't get relayed universally, and every node on the network can get a different view.

Bitcoin Core can be queried for known branches through the getchaintips RPC command.

For example, the output on my node is currently:

  {
    "height": 405040,
    "hash": "0000000000000000030014f0c61351fe2f9e744d4d1c111cca03c94b7dc831f0",
    "branchlen": 0,
    "status": "active"
  },
  {
    "height": 404812,
    "hash": "0000000000000000010f42545dadcf1262ceebcade6629b16282eb59265c937d",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 404548,
    "hash": "0000000000000000010edc4bee21e25e976eb0515da5740d54d060d1579479fa",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 404145,
    "hash": "0000000000000000014fc67e896071d9cc5345fea4d04795ff6ee8f9ae142268",
    "branchlen": 1,
    "status": "valid-fork"
  },
  {
    "height": 404120,
    "hash": "000000000000000002119743ab5f8bb12f5008373d3fb7dda9be82295cfa12d3",
    "branchlen": 1,
    "status": "valid-headers"
  },

This means the the currently active branch has 405040 blocks, but there are 1-long branches forking off at heights 404811, 404547, 404144, and 404119, so my node did observe 4 such forks in the past week. valid-fork means that my node discovered the branch was abandoned after fully downloading and verifying it. valid-headers means that it received the header, but was aware of a better branch beforehand.


Why would people buy bitcoin these days if its too expensive? I'm curious on why would bitcoin rise in the near future since its not affordable anymore. It's actually but for wealthy people only. How could it even reach mass adoption because of its extreme price?

It seems reasonable that people will switch to alt-coins because of their lower prices hence that would cause bitcoin to loose its value over time since people will start to sell it..

How can people/experts make claims that we could see bitcoin over 100k etc. It's total nonsense or am I missing something?

What you are probably missing is the fact that you can buy partial bitcoins, you don't have to purchase a whole bitcoin at once. You could buy a small bit of bitcoin for $20 if you wanted, it can be an affordable investment for anyone.


Why does electrum need connection to server when recovering a wallet from a seed? Why does electrum client need connection to server when recovering a wallet from a seed? Isn't the generation of private keys done locally?

While the generation of the private keys can be locally, to recalculate the account's balance tied to the private keys needs data from the distributed ledger (blockchain). As the electrum client does not keep a replica of the ledger it will need access to recalculate the balance of the accounts and hence of the wallet as a whole.


Where to earn bitcoins? I know that you can mine bitcoins and that you can buy them, but what about places where you can earn them by doing a bit of work?

I've only heard of http://bfg.swfchan.com/ where you get BTC for linking to the site.

Are there any other places where you can earn bitcoins?

I tried to find a list of such places but I can't find one. Is there such a list?

https://en.bitcoin.it/wiki/Bitcoin_Jobs
http://workforbitcoin.com
http://www.btcworkers.com
http://bitgigs.com
http://www.rugatu.com
http://www.bitcoinerr.com
http://www.reddit.com/r/Jobs4bitcoins
http://coinworker.com
http://bittask.com

All of these boards are ugly, though. Wait for StackExchange to start using Bitcoins.


How can I recover the private key for my bitcoin address? I want to make withdrawal from my Bitcoin address to which I just transferred some bitcoins. The address has changed after I made a transactions to the first address. But it was requesting the private key to create the payment. How can i get the private key to spend fund from the address?

Private keys cannot be recovered. If you lose or forget the private key, the bitcoins become unspendable.


Accidentally sent Blockchain BCH to Coinbase BTC? I have made a mistake by sending cash bitcoin from Blockchain to Coinbase bitcoin address ( instead of Coinbase cash bitcoin address)..

i want to retrieve the fund or send it back to my blockchain so i can input the correct address again ? anyone knows how ? please make it as simple as possible because i do not have a lot of knowledge about bitcoin since i am very new to this world..

I have emailed both Coinbase and Blockchain about this matter, it has been two days and no answer..

thanks for your time and help in advance...

There is no way to directly retrieve your fund since they are the one now owning your coins, maybe try to contact their support directly on their social network like twitter to accelerate https://twitter.com/coinbase


"HTLCs don't work for micropayments"? I read this tweet by Tadge Dryja recently. What exactly did he mean? Is this an issue? If so, is this issue fixable?

It takes about 200 vbytes to spend from a Lightning Network (LN) Hashed
Time-Locked Contract (HTLC) output used for routing a payment.  At the default
minimum feerate of 10 nBTC/vbyte, that makes it uneconomical to attempt to
claim a routed micropayment below about 2,000 nBTC ($0.008 USD at $4,000
USD/BTC).  As fees rise, larger and larger micropayments become uneconomical to
claim.

Worse, the default Bitcoin Core mempool policy attempts to prevent UTXO-set
bloat attacks by refusing to relay or mine any transaction containing an output
that would be uneconomical to spend at a feerate of 30 nBTC/vbyte.  This is
called the dust limit.  To obey this limit, LN nodes must not include HTLCs
for very small micropayments in LN offchain transactions---otherwise those
transactions couldn't be confirmed onchain if necessary and other value in the
channel could be stolen by a counterparty.

Currently, when LN nodes are asked to route payments below the dust limit, they
trim those HTLCs by increasing
the potential transaction fee of their channel by the amount of the
micropayment rather than adding an HTLC.  This fee only actually pays miners if
the channel is closed in a state that includes this fee---by mutual agreement
between channel counterparties, the fee can be removed in a later state.  This
creates three possible outcomes:

The fee is removed in a later state because both peers agree that the
micropayment completed successfully, so the amount is trasfered into a
normal-size output that's not subject to the dust limit.
The fee is removed in a later state because both peers agree that the
micropayment failed (either it was rejected or it timed out).  The earlier
state where the funds were held in a larger output is restored.
The two peers get into a disagreement about the payment and close the
channel.  In this case, the funds are actually transfered to miners and are
lost to whichever channel party was technically correct about the final
payment state.

Peter Rizun has
argued that, combined with rising Bitcoin transaction fees, this can lead to "the problem where even $50 payments are not 'trustless.' In the case where $50 is below the dust threshold [...], then HTLCs cannot be used to protect the $50 payment. Customers can lose $50 payments through no fault of their own."

It seems like he might be correct, although there are a few evasions we could
make about the current network behavior:

The amounts involved are currently tiny (about $0.02 at $4,000 USD/BTC).
Node operators who want to eliminate their risk can simply refuse to route
micropayments below the dust limit.
Those willing to accept limited risk can limit their maximum exposure (e.g.
only routing up to 10 payments below $0.02 for a maximum risk of $0.20).

However, what we really want is a fundamental solution to this risk---a way to
make even micropayments trustless.  Happily, the person quoted in the
question---Thaddeus Dryja (one of the original LN architects)---previously
described
how this might be accomplished.

Removing trust from inexpressible values

Above we described micropayments below the dust limit, which is a relay and
mining policy (meaning it can be changed without needing global consensus).
However, LN also allows micropayments down to 10 pBTC, which is 1/1,000th the
consensus-enforced 10 nBTC maximum precision of onchain Bitcoin.

When a channel contains some value that can't be represented onchain, the
remaining value is tracked in a database and LN commitments are made using
rounding.  For example, if 6 nBTC are paid from Alice's side of a channel to
Bob's side of a channel, she might actually send him 10 nBTC in an offchain transaction and the
extra 4 nBTC are tracked in a database to be credited towards subsequent payments.  If the channel is closed at this
point, Alice accepts that she's going to lose those 4 nBTC ($0.00002 USD at
$4,000 USD/BTC).

Given the tiny amounts involved, that seems like a perfectly satisfactory
solution---Bob's unlikely to pay an onchain transaction fee of 4,000 nBTC just
to steal 4 nBTC from Alice.  But, in early LN presentations, Dryja proposed an
alternative technique based on something occasionally discussed among Bitcoin
protocol developers: probabilistic payments.

Probabilistic payments are payments that only succeed a specified percentage of
the time.  For example, Alice wants to pay Bob 1 nBTC, but that's smaller than
allowed by Bitcoin.  Instead she offers him a probabilistic payment of 10 nBTC
(the smallest Bitcoin does allow) with 1-in-10 odds.  Nine times out of ten,
Bob gets nothing; one time in ten, he gets 10 nBTC.  If this is done with a provably fair protocol and the distribution amounts are symmetric to the odds (i.e. there's no house edge), then it's reasonable to believe that receiving 10 nBTC 1/10th of the time is equivalent to receiving 1 nBTC each time.

The exact mechanism described by Dryja is complicated and I don't know how well
it's been reviewed for security.  A large problem faced by all ideas for
probabilistic payments on Bitcoin is that they're hard or impossible to
implement in Bitcoin's very limited Script language.  Sidechains based on
ElementsProject.org, such as Blockstream Liquid, have re-enabled some disabled
math opcodes from Bitcoin plus added an
OP_DETERMINISTICRANDOM opcode
that make probabilistic payments much easier to implement there (although I'm
unaware of any specific work on a definite protocol).  Perhaps someday, these
opcodes or other similar features will become available on Bitcoin if there is
community demand for them.

Probabilistic payments to circumvent the dust limit

In the previous section, we saw probabilistic payments used to trustlessly get
around the minimum consensus precision of 10 nBTC.  We can use the same
mechanism to get around the dust limit trustlessly.  If it's uneconomical to
spend an HTLC output worth less than 10,000 nBTC, then we simply require
probabilistic payments for any amount below that.

For example, Alice wants to route a 1,000 nBTC payment through Bob.  Bob
requires her to create an HTLC paying him 10,000 nBTC with a 1-in-10 chance of
success.  Then the LN is processed.  If both Alice and Bob agree that it failed, they throw away the
HTLC.  If they both agree it succeeded, Alice simply adds 1,000 nBTC to a larger
output of Bob's, circumventing the dust limit.  If they disagree and the
transaction needs to go onchain, the probabilistic payment is run and, nine
times out of ten, Bob receives nothing (Alice gets her 10,000 nBTC back).  One
time out of ten, Bob receives 10,000 nBTC.  This can be made completely trustless, provably fair, and doesn't require any third parties.

As mentioned above, probabilistic payments are currently a lot of work to
implement on Bitcoin and effective use of them may rely on soft forks that are
just ideas now.  Moreover, while transaction fees are low and Bitcoin valuations
still make dust-size outputs worth just pennies, there's no real need to work
on complex solutions to the problem of people maybe losing a few cents---people who don't want that risk can simply disable routing payments below about $0.02.  But if
this becomes a real problem, it's a problem I think we can reasonably expect to
solve in a completely trustless way.

Addendum: an easier, less clever way to circumvent the dust limit

Several hours after posting the description above, it occurred to me that
there's an easier way to create trustless payments below the dust limit that
doesn't depend on untested probabilistic payments.  If Alice wants to route a
1,000 nBTC payment through Bob but the minimum economical onchain HTLC is
10,000 nBTC, she and Bob simply create two offchain outputs at the same time:
one where Alice pays Bob 11,000 nBTC and one where Bob pays Alice 10,000 nBTC.
Both HTLCs use the same hashlock and timelock, so they can both succeed or timeout at the
same time.  The net effect is a 1,000 nBTC payment to Alice if the offchain
payment needs to be settled onchain, plus the regular ability for them to agree on the outcome and update their main balances cooperatively.

Downsides include that this requires that Alice and Bob keep
more balance in their side of a channel than they otherwise would in order to
handle micropayments and that it costs them more fee overall.  This additional burden can be compensated by them
charging a higher fee for routing payments below the economical onchain rate.
This method also solves the problem in a completely trustless way and it's
something that shouldn't require significant research to implement, although
it's still perhaps a premature optimization while the current risk is measured
in pennies.

(Probabilistic payments are still the only way I know to deal with payments
below the minimum onchain precision of 10 nBTC, but that's not the question here.)


Successful national digital currencies Are there any successful stories about coins created specifically for a country? (pre mined and drop)

I have seen cases like Auroracoin, but I want to know if there has been a success story.

Most altcoins have done very poorly. You can see the list of relatively successful ones here. There isn't a country coin that's got a market cap over a million. I would say there hasn't been a success story.


Watch a BitCoin account for incoming payments I want to watch a set of BitCoin addresses and be notified (preferably by email) when they receive a payment.

I prefer me not to write my own software for this and not to install it on my own server, but programming suggestions are welcome.

You need a server which indexes by address. Libbitcoin-server provides this index. All tx’s to or from an address of interest will trigger a notification to your subscribing client.

https://github.com/libbitcoin/libbitcoin-server/wiki

Of course you can always build your own address index.


Order Book Distribution I'm currently building a small bitcoin order book simulator that would mimic user limit orders. What gives order books its V shape appearance? That is, the further away we go from the market price, the more orders are stacked. For sellers, is it mostly profit driven, they want to sell higher than market price, and for buyers, they just want to buy cheaper than the market price? Is it mostly as simple as that? Plus maybe people wanting to trade the breakout?

what gives order books the V shape

I’m not sure what other shape could it be? (other than flat- no orders)? The order book represents all of the bids/asks of buyers/sellers in the market. Generally, it’s displayed in the ‘V-shape’ you mentioned, where the Y-axis of the chart displays the total cost to fill all orders between the market price, and the corresponding x-coordinate on the chart. So as you move further from the market price, there will be more orders to fill to reach that new price.

  Is it mostly as simple as that?

Yeap, it’s just the orders that traders have submitted to the order book, easy as that.


Transaction verification I run a 0-confirmation tool.
To track new transactions I use:

bitcoind getrawmempool
new transactions in new block not available in mempool (it seems I do not receive all transactions in mempool before my client accepts a new block)

I trust my bitcoin client transaction verification process (protocol rules).
(I expect it to do all the steps in: https://en.bitcoin.it/wiki/Protocol_rules#.22tx.22_messages)

I expect I do not have the guarantee the client/person who created the new block has followed the protocol rules for the included transactions, so I want to check the 'missing' transaction from my mempool.

I know 6 confirmations is expected to be 'safe', but I would like to do a 0-confirmation (or 1-confirmation concerning a new block) as safe as possible.

1: Is every transaction checked by my bitcoind client before accepting a new block (local)?
(to be sure every transaction available in mempool and blockchain of my (official) client meet the protocol rules)

2: If 1. is not true: What bitcoind API, or (python) program is available to verify transactions included in a new block if they do meet the (official) protocol rules?

Yes, your client will fully verify each block it receives.

Your biggest issue with accepting 0-confirmation transactions is making sure an attacker can't send your node(s) a transaction that the rest of the network will discard as a double-spend. Basically you'll want to disallow direct connections to your node(s) and connect them to trusted nodes such as large miners.

This doesn't eliminate risk but reduces it somewhat to Finney attacks and an attacker getting lucky with getting the bad transaction to you through a big miner that ends up not putting that transaction in a block before the conflicting transaction is mined.


When is it too late to get BCH and BTG from the fork from an appropriate wallet? Is it enough that the funds where sent before the forks on the blockchain, or should they also have been recieved (enough with 1 confirmation on the blockchain?)  before the forks, and why?

Is it enough that the funds where sent before the forks on the blockchain, or should they also have been recieved (enough with 1 confirmation on the blockchain?) before the forks

The bitcoins must have been recieved BEFORE the hardfork.

  and why?

If I understood it correctly, an unconfirmed transaction during the hardfork means "that the BTC's are still on the sender's adress".
Why? Because the people behind BCH/BTG copy the whole blockchain at one moment and if your transaction is unconfirmed => it's not in the blockchain => they can't copy it.
And that means that the sender of the BTC will have access to the BCH/BTG and the receiver gets nothing of that.


Multisignature technology in bitcoin - math and code I am interested in the math and code behind bitcoin multisignature technology. I've been looking for actual code that creates a multisignature address/pub key, and verifies transactions/digital signatures; that can be executed in one go. I didn't find anything in bitcoin core maybe because I dont know where to look. Does anyone know where I can find the actual code that creates a multisignature adress and verifications. I would also like to know if there are any m of n schemes written in code and the math explanations behind adress /pub key creation and signature verification.

Multisig bitcoin transactions have a fairly simple implementation and don't require any advanced cryptography knowledge beyond the regular ECDSA used for P2PKH transactions. There are no "mutltisig address" or "multisig pubkey", but regular public keys and regular signatures are used. A multisig transaction output essentially contains a list of public keys with their count, and a threshold count which is <= to the pubkey count, and finally the OP_CHECKMULTISIG(VERIFY) opcodes, which check the signatures provided against the public keys from the script.

In terms of creating multisig addresses, there are two RPC commands in Bitcoin Core. createmultisig and addmultisigaddress. The code behind the multisig script creation is in standard.cpp#GetScriptForMultisig, which is quite trivial.

Spending the multisig output is not quite as simple. You need to use the createrawtransaction command, followed by a call to signrawtransaction for each signature required to meet the threshold, and finally you can broadcast the signed transaction with sendrawtransaction.

As mentioned above, there is no standard address type for these transactions, but PSBT (Partially Signed Bitcoin Transactions), also known as BIP-174 defines a standard serialization and textual encoding (in Base64) which can be used for sharing the raw transaction at each point in the above process with other parties if the private keys are not owned by the same user.

There are proposals for doing mutlisig schemes in other ways which utilize key or signature aggregation. None of these have a concrete proposal in the form of a BIP yet. I suggest reading the MuSig paper from Maxwell et al. as a starting point, and have a look at BIP-340, which defines the Schnorr Signature scheme which is likely to be made standard into Bitcoin at some point in the near future. Note that the proposal for OP_CHECKSIGADD in BIP-342 does not by itself allow for key or signature aggregation, but it does allow for more efficient batch verification of multiple signatures.


Are there different ledgers in the bitcoin network? Is it correct to say that in the bitcoin network, there are different versions of ledgers (although the longest chain is the correct one)?

No, there is only one blockchain which is Bitcoin. There are no different versions or different blockchains that other people are using that are also Bitcoin. Such things do not exist. Such other blockchains that are forked from Bitcoin are not Bitcoin but rather altcoins.


How can bitinfocharts.com know the changes in BTC deposited to Binance? I find this page here, which tells me how much BTC is deposited to Binance. How does this (or a similar) page work?

When I deposit BTC to Binance, I am given an address, which I am fairly sure it's unique (since it doesn't ask other information to be supplied, so if it is not unique, I wouldn't be able to be identified).

How can I check that bitinfocharts is right? I know that on blockchain.com I can check the balance of an address, but what balance should I use if I am interested in Binance's balance?

Update

A function which takes a given block, and computes the net flow of BTC to each address:

import requests

def netbtcflow(blocknum):

    r = requests.get('https://blockchain.info/block-height/'+str(blocknum)+'?format=json')
    data = r.json()

    transactions = [{} for x in range(len(data['blocks'][0]['tx']))]
    for transactionindex, eachtransaction in enumerate(data['blocks'][0]['tx']):
            address=[]
            amount=[]
            for eachrecipient in eachtransaction['out']:
                try:
                    address.append(eachrecipient['addr'])
                except KeyError:
                    address.append('KEYERROR')
                amount.append(eachrecipient['value']/100000000)

            try:
                transactions[transactionindex]['from']=eachtransaction['inputs'][0]['prev_out']['addr']
            except KeyError:
                transactions[transactionindex]['from']='KEYERROR'
            transactions[transactionindex]['to']=[address, amount]

    netflowdict=[{} for x in range(len(transactions))]
    for txindex, eachtx in enumerate(transactions):
        #if eachtx['from']!='KEYERROR':
        if True:
            for recipaddress, recipamount in zip(*eachtx['to']):
                if eachtx['from']!=recipaddress:
                    netflowdict[txindex]=[recipaddress, recipamount]

    netflowdict=[each for each in netflowdict if bool(each)]

    netflowdictunique=dict((each[0],0) for each in netflowdict)
    for each in netflowdict:
        netflowdictunique[each[0]]+=each[1]

    netflowdict=netflowdictunique

    return transactions, netflowdict

There are problems with this, for example this one. Would be interested in how to do the method outlined in this answer exactly (ie I would need the Ptyhon script). The above code might be helpful, will update the post if I get it to work.

Based on the address the binance gave you, after they sweep the funds into their hotwallet, you can run common-input heuristic on this deposit address (assuming it was swept in with other inputs). The more addresses and sweeps, the better the accuracy and amount of addresses in the final (result) set.
https://en.bitcoin.it/wiki/Privacy#Common-input-ownership_heuristic
Based on the binance hotwallet you can also assume that all addresses that inputs into this hotwallet are deposit addresses.

Having set of all (assumed) addresses of binance you can run basic script to see balances in/out.


What if Bitcoin gets to the point that all the coins have been mined? What if Bitcoin gets to the point that all the coins have been mined? There will be lots of transactions and no one to process them. My question is who will do all the transaction processing when mining no longer pays.

From the bitcoin wiki:

  It is envisioned that over time the cumulative effect of collecting transaction fees will allow somebody creating new blocks to "earn" more bitcoins than will be mined from new bitcoins created by the new block itself. This is also an incentive to keep trying to create new blocks even if the value of the newly created block from the mining activity is zero in the far future.

When you make a transaction and set a TX fee, that goes to the bitcoin miner.


what is the meaning of Segwit receiving address and segwit change address ..? What is the meaning of different type used in bitgo api like bellow :
Url : https://bitgo.github.io/bitgo-docs/?javascript#add-wallet

m/0/0/0/0 (which is also the ID used to refer to a wallet in BitGo’s system)
m/0/0/1/0 (The first change address of a wallet)
m/0/0/10/0 (first SegWit receiving address of a wallet)
m/0/0/11/0 (the first SegWit change address of a wallet)

what is the meaning SegWit receiving address or SegWit change address..?

A segwit receiving address is an address that specifies that a segwit output should be created. Many wallet software developers have begun using a different key type and BIP 32 derivation paths for keys that are to be used in segwit addresses. Segwit addresses begin with bc1 (for native segwit outputs). Segwit change addresses are the same as receiving addresses except are used for your change outputs. These are not typically shown to the user and are managed internally by the wallet.


Bitcoin core incorrect balance? So I have ubuntu 16x running bitcoin core. Its a full node and fully synched. Run with bitcoind --daemon as suggested. Using a particular address from my wallet, whenever I send money to the address getblanace works fine (bitcoin-cli getbalance XXXX 1). Whenever I send money from the address, (on a completely different system using a web based wallet), it shows that the bitcoins arrive when expected, but my getbalance of my correct address never goes down. I even tried sending all the money out in 10 different transactions and saw it was failing when the the account should have been zero'd out, all the while always reporting that I had my high original balance.

I feel like I am missing something basic but I can't seem to figure it out. Thank you in advance

The issue that you are experiencing is not really an issue. Rather it is a fundamental misunderstanding of how the accounts system works. Because it is so unintuitive and behaves in an unexpected way, the accounts system has been removed from Bitcoin Core.

The behavior that you see is completely expected. Accounts are not involved in the sending of Bitcoin except for the internal account values are decreased. The association of addresses to accounts is a receiving only thing. Account balances are only updated when addresses for the account receive money. Sending money "from" those addresses will not update the balance. The account balance will be decreased only if you use the send* RPC commands which allow you to specify an account to decrement the amounts from.

It is also important to note that "sending from" an account does not mean that coins associated with the addresses in that account will be the only ones chosen for the transaction. Any coins can be chosen, and then the account's balance will be decremented. Because of this, it is also possible to have accounts with a negative balance.

In general, you should stop using the accounts system. Not only is it being removed, but it also has strange and unexpected behavior.


Why does only the earliest transaction matter for double spending? On page 2 of Bitcoin paper, it says:

  The problem of course is the payee can't verify that one of the owners
  did not  double-spend the coin. A common solution is to introduce a
  trusted central authority, or mint, that checks every transaction for
  double spending. After each transaction, the coin must be returned to
  the mint to issue a new coin,    and only coins issued directly from
  the mint are trusted not to be double-spent. The problem with this
  solution is that the fate of the entire money system depends on the
  company running the mint, with every transaction having to go through
  them, just like a bank.

  We need a way for the payee to know that the previous owners did not
  sign any earlier transactions.
  For our purposes, the earliest transaction is the one that counts, so we don't care about later attempts to double-spend. [emphasis added]
   The only way to confirm the absence of a transaction is to be aware
  of all transactions. In the mint based model, the mint was aware of
  all transactions and decided which arrived first. To accomplish this
  without a trusted party, transactions must be publicly announced [1],
  and we need a system for participants to agree on a single history of
  the order in which they were received. The payee needs proof that at
  the time of each transaction, the majority of nodes agreed it was the
  first received.

Why does only the earliest transaction matter for double spending?
I thought that it would be latest as previous owner would have checked till that. But even that is flawed... We need to check all.

Is it because the coin is a list of transactions and only first one is not verified?

"Doublespend" refers to an attempt of spending the same funds twice. In Bitcoin specifically this occurs when a user publishes two transactions that are in conflict due to attempting to use the same unspent transaction output as input. Obviously, only one of the two transactions can be valid.

Before Bitcoin was published, the solution to the doublespending problem was to designate a central actor that decided which of the two transactions would take precedence. The central actor would do this by announcing which of the two it had seen first.

The "first-seen" behavior was at first explicitly encoded in node behavior: nodes would not accept a conflicting transaction into their mempool (the temporary storage of unconfirmed transactions). However, this lead to the incorrect assumption that zero confirmation transactions could be reliable whereas actually the doublespending problem is solved by miners collecting transactions into blocks for confirmation. The blocks may only contain one of the two conflicting transactions, as otherwise the block is invalid. Thus, the blockchain specifies the precedence of transactions by converging on a common journal of the transactions without a central actor.

In the past months, we've seen the "first-seen" paradigm get softened significantly as doublespends (of unconfirmed transactions) have become more or less trivial due to the high demand for blockspace. As it is becoming common for users to update transactions with a higher fee (i.e. a doublespend), the "first seen" paradigm is falling out of use and being replaced by the defacto mechanism of "first-included". Assuming rational miner behavior selecting the most profitable transactions first, we will converge on a full replace-by-fee system eventually.

In other words, when the whitepaper describes the requirement for the Bitcoin system to create a convergent history with "first-seen", it describes a simplified situation that didn't account for the network dynamics of competition for blockspace. From today's perspective this should be understood as "first-confirmed".


Blockchain Payment receive api While using blockchain receive payment api, what if some one send less then require fund or some one send extra fund on same one time generated address.

does fund will automatically refund to sender or not ?

what to do if i want to refund that amount back to user who send less fund or double fund on that address?

any one have information regarding this?

I dont know which api you are talking about , but i am this much sure that ones your transaction is minned and updated in block you cannot revert it or refund it. Blockchain data is immutable. If you want to restrict your client form sending low or high then you have to use some business logic on backend of your code also using JS logic on front end when user inputs the value will help you alot


c-lightning - Unknown Peer I'm trying to create a channel using c-lighting (testnet), but I keep getting an Unknown Peer error message.

I used cli/lightning-cli connect which seemed to work fine.
I used cli/lightning-cli listnodes and I see whole bunch of nodes.
I used cli/lightning-cli listpeers and I see 1 peer.
I used cli/lightning-cli newaddr to create a new address and funded it (3 confirms so far)
I then try to use cli/lightning-cli fundchannel and I get an Unknown Peer message.

Everything but the last Comand looks correct. There is no command channel in c-lightning. In order to open a channel you need to execute

cli/lightning-cli fundchannel id satoshi [feerate] [announce] [minconf]
  Fund channel with {id} using {satoshi} (or 'all') satoshis, at optional {feerate}. Only use outputs that have {minconf} confirmations.

The thing that beginners sometimes oversee is that before opening a channel with a node you need to peer with it first via the connect command like you did.


Determining proper order price on BTCe I am writing a custom bot for trading at different Exchanges, while BTCe is the only one I have currently implemented to about 95%.

Now I am only hanging at one point: If my Bot decides to Sell/Buy, how can I determine the proper price for my order?

My Idea was to get the kist of current buy/sell oderders for e.g. BTC/USD and then calculate for which price I would have to sell/buy so the trade will be executed completely, but then I didn't find an API-method to get a list of current orders here.

Is there any way to achieve what I am trying to do?

The API call you are looking for is the market depth:

https://btc-e.com/api/2/btc_usd/depth

There are also calls for LTC/BTC

https://btc-e.com/api/2/ltc_btc/depth

and LTC/USD

https://btc-e.com/api/2/ltc_usd/depth

All of the above return JSON data including both ASKS and BIDS


Why is it necessary for Multi-Path Payments in Lightning to be Atomic? One way of achieving multi-path payments in lightning is by having the sender use the hash sent by the receiver to send multiple payments along different paths.
The mailing list entry proposing atomic multi-path payments describes a downside where

  the sender fails to
  actually satisfy all the payment flows, then the receiver can still just
  pull the monies (and possibly not disperse a service, or w/e).

But if I understand correctly, if the receiver pulls any flow before all paths are complete, the sender will still end up with the invoice and pre-image which they can use to prove the payment went through, and if the receiver refuses to provide some service, the sender has the same recourse as in the case where the payment was a single-path payment paid in full. Why then, is it necessary to have this atomic multi-path scheme, which makes use of unused bits in the lightning protocol that could potentially be used for something else?

You are pointing out trust issues that exist with any payment mechanism. You can pay for your coffee at Starbucks and still be denied your coffee. That is exactly the case you are pointing out. But, the protocol that is listed provides other benefits that help honest people make payments without having their funds stolen by straddling intermediaries, avoid headaches of refund or use balances across multiple channels to make payment. The concept of sound money transaction involves sending money to other party in a trustless way involving as little friction as possible. This protocol exactly achieves that.

Partial payments: Assume payments along some routes completes while payment along others fail to go through. The receiver, assuming he is honest, now has only two alternatives. Request the remaining payment, or refund the amount. In case of refund, you will again have to pay fees to route the payment which means loss of money in fees. The protocol provides way in which either the entire payment goes through or none of it goes through.
Straddling Intermediaries: Assume a malicious party has channels open with multiple people. Suppose you send your payment along multiple paths with the same payment hash, then this malicious intermediary might use the payment pre-image he learns in the channel he operates along the first path to settle transactions in the channel along the second path.
Use multiple channel balances: Assume you have channel opened across multiple people but none of the channel balance is sufficient to make the payment that is requested. Your only way of sending payment now involves on-chain transaction (either direct Bitcoin on-chain payment, or opening a new channel) which incurs significantly higher fees. With this protocol you can make use of multiple channel balances with fraction of the fee cost involved in an on-chain transaction.


How to withdraw cash from blockchain wallet Is exchanging bitcoins with money from other people the only way I can withdraw my money into my bank account??if there is another way please lead me

Is exchanging bitcoins with money from other people the only way I can withdraw my money into my bank account??

Yes, it's the only way.  You can't "withdraw" bitcoins into your bank account, any more than you could "withdraw" a car into your bank account.  You have to sell them in exchange for money, and then you can deposit the money in your bank account.

See How can I sell bitcoins and transfer the funds to my bank account?


What app should I use to import my wallet keys? I have the private key backup from my Android phone wallet. My phone broke and has been replaced but I can't see any import option in the Android wallet app.

How do I get my BTC back?

Since I don't know what wallet app on Android you're using, I'll give an answer that should work for any:

If you create an account at Coinbase, you can import your private keys and then send them to an address on your Android wallet. This requires the private keys being in plain text. If your private key export is encrypted (with a password you gave it) or encoded in some non-obvious fashion, you'll need something to decode it before using this option.

If it's encrypted in a way that's compatible with the desktop Bitcoin-QT client, you can reclaim it that way.

If it's encrypted some other way, you'll likely need to restore it to your Android phone and enter a password there to get access to your bitcoins. This would be specific to the app you're using.

If you're using Bitcoin Wallet, which seems to be the closest thing to an "official" Android client, choose "Back up Keys" from the menu (on my device, I press the Menu hardkey to open that), and then click "Restore private keys".


How can I transfer my BitCoins to my PayPal? How can I transfer my bitcoins to PayPal?

If you have them in an exchange like coinbase.com: (1) sell them into your bank account, (2) connect your bank account to PayPal, (3) transfer them from your bank account to PayPal.

If you have them on your hard-drive, step (0) is to open an account on an exchange like coinbase.com and send them to your coinbase.com account. Then go to steps (1), (2) and (3).


Can you replicate a wallet somewhere else If I used my 12 seed words in another wallet provider that used the 12 word backup protocal, whether hard hot or mobile, would that then replicate my wallet?

Yes, using the same seed phrase on a different device/in different software will create another instance of the same wallet (assuming both wallets are following the same derivation path, etc).
This is a nice feature of BIP32 hierarchical deterministic wallets: you are not necessarily tied to the wallet software that you used to create the wallet in the first place. If that wallet software stops being developed for whatever reason, you can recreate your wallet using some other software/hardware.


As described on the wiki page about block hashing, the 2xSHA256 hash is taken of the block's header only (not the transactions in it): 80 bytes, consisting of the version, previous block hash, tx merkle root, time, bits and nonce.

Direct quote from that page :

>>> import hashlib
>>> header_hex = ("01000000" +
  "81cd02ab7e569e8bcd9317e2fe99f2de44d49ab2b8851ba4a308000000000000" +
  "e320b6c2fffc8d750423db8b1eb942ae710e951ed797f7affc8892b0f1fc122b" +
  "c7f5d74d" +
  "f2b9441a" +
   "42a14695")
>>> header_bin = header_hex.decode('hex')
>>> hash = hashlib.sha256(hashlib.sha256(header_bin).digest()).digest()
>>> hash.encode('hex_codec')
'1dbd981fe6985776b644b173a4d0385ddc1aa2a829688d1e0000000000000000'
>>> hash[::-1].encode('hex_codec')
'00000000000000001e8d6829a8a21adc5d38d0a473b144b6765798e61f98bd1d'


Can a Bitcoin ( or any other cryptocurrency ) be compromised with a large botnet/s? I'm new to cryptocurrencies, so I recently read the paper from the Satoshi Nakamoto ( link is here ) to know a little bit more about the Bitcoin.And I saw this statement:

  What is needed is an electronic payment system based on cryptographic
  proof instead of trust, allowing any two willing parties to transact
  directly with each other without the need for a trusted third party.
  Transactions that are computationally impractical to reverse would
  protect sellers from fraud, and routine escrow mechanisms could easily
  be implemented to protect buyers. In this paper, we propose a solution
  to the double-spending problem using a peer-to-peer distributed
  timestamp server to generate computational proof of the chronological
  order of transactions. The system is secure as long as honest nodes
  collectively control more CPU power than any cooperating group of
  attacker nodes.

So my questions would be:

Could a large botnet disrupt/hack the whole cryptocurrency system if
the botnet currently holds more CPU power than the friendly nodes?
If yes,would it be feasible at all and or worth the work?

I may understood this whole idea wrongly, so any tips, advice is appreciated!

Could a large botnet disrupt/hack the whole cryptocurrency system if
  the botnet currently holds more CPU power than the friendly nodes?

Yes, this is known as 51% attack. The malicious attacker should control >50 percent of hashing power in the network.

  If yes,would it be feasible at all and or worth the work?

Current network hashing power is around 11 million TH/s. So the attacker should buy another 11 million TH/s. Bitcoin Antminer S9 has 14TH/s so you should buy around 800 000 of these. Let's say one is 2000$ so you have to invest 1.6 billion $.

So it is relatively feasible. (Especially when the current bitcoin market capitalization is $136 billion)

Check also: Would any of the current botnets be able to launch and sustain a 51% attack?.

About is it worth it: this depends of what you consider by worth. It will probably make irreparable damage to BTC if 51% attack is successful, is that worth  investing 1.6 billion $. You can check if there is similar question of what 51% attacker could achieve (he can not gain 136$ billion of bitcoins) for more info.


Does the Mt Gox attack constitute theft of Bitcoins or just a Denial-of-Service attack? What's being reported on the news is that millions of Bitcoins were stolen from Mt Gox.  But the Bitcoin Foundation blog says something different:

https://bitcoinfoundation.org/blog/?p=422

  "Somebody (or several somebodies) is taking advantage of the transaction malleability issue and relaying mutated versions of transactions. This is exposing bugs in both the reference implementation and some exchange’s software.

  We (core dev team, developers at the exchanges, and even big mining pools) are creating workarounds and fixes right now. This is a denial-of-service attack; whoever is doing this is not stealing coins, but is succeeding in preventing some transactions from confirming. It’s important to note that DoS attacks do not affect people’s bitcoin wallets or funds."

So is the transaction malleability issue Mt Gox is suffering from just a denial-of-service attack, or were Bitcoins actually stolen?

Any help would be greatly appreciated.

Thank You in Advance.

As I understand it (and wrote at more length in this question), the statement is technically correct but incomplete.

The result of a malleable transaction attack is that the targeted transaction (in which the victim voluntarily sent coins to the attacker) does not confirm, but an equivalent transaction with a different ID does confirm.  It is true that this does not steal any coins: the recipient gets the same coins they were already getting.

The theft occurs in the next step, not described in your statement: the attacker points out to the victim that the original transaction didn't confirm, and convinces him to resend the amount, in a new and independent transaction.  If the victim doesn't notice the attacker's equivalent transaction, he might do this; then the attacker has received twice as many coins as he was supposed to.


Is there a visualisation tool for discarded block chains in Bitcoin? A lot of papers about cryptocurrencies explain the concept of the "longest chain", which goes along with these kind of figures:

I was wondering if there exist any kind of visualisation tool for these kind of discarded block chains within Bitcoin itself? There are a lot of visualisations available for transactions, but I'm interested in the amount of block chains that did not make it into the final blockchain (blocks that were discarded because they were no longer the longest chain).

There are several sites that maintain this information, and Bitcoin Core can be asked about it using the getchaintips RPC command.

It is however important to know that such information can never be guaranteed to be complete. Nodes only relay new blocks that are part of the (new) best chain.

A fork appears when two blocks are produced at approximately the same time. They both propagate across the network, and one part of the network sees block A first, and another sees B first. Assuming A eventually wins (is extended first), nodes that saw A first and were not connected to a peer that accepted B first, will never see B.


What technical properties does a confirmed Tx have that an unconfirmed Tx does not? From a user perspective, each block confirmation reduces the probability that a transaction payment will be reversed.

However from the perspective of the software, what happens when a transaction is confirmed? For example, I know it is removed from the mempool. Is there any other technical difference between confirmed and unconfirmed transactions? Are both outputs stored in the same UTXO set? Does anything happen on any lower level (data storage, etc) inside a node or on the network or in the protocol once a Tx is included in a block?

Do confirmed transactions have any special properties besides the human perception of safety?

when we speak about specific transaction: no. The unconfirmed transaction looks exactly the same as the same transaction with 1,2.. confirmations.

yes. There are 3 types of transaction: confirmed, unconfirmed, and nonexistent

example of nonexistent are those 10BTC I'll give you tomorrow.

difference between unconfirmed and nonexistent is not "obvious"

When you see an Unconfirmed tx on your PC, this does not "guarantee" that everybody else sees it too. If internet connectivity fails, you may be precisely the only person who sees it.

Unconfirmed transactions can be very different from confirmed, in many ways:

Unconfirmed transaction can spend funds that already have been spend, or funds that never existed.

Unconfirmed transaction get lost in the Internet (never get confirmed).

Unconfirmed transaction can be reversed and be replaced by different Unconfirmed transaction sending the funds to somebody else.

Unconfirmed transaction can contain technical error that prevent it to be confirmed.

Unconfirmed transaction can have low fee (less than dust limit) and this can cause confirmation delay of 12 or more hours.

Unconfirmed transaction can be one of many abusive (spam) transaction (in an attack). Such Unconfirmed transactions will typically never get confirmed and most likely all miners will delete these abusive transactions.

Unconfirmed transaction can be censored by all miners. This can happen if some address belongs to a person who is anti-bitcoin or some large corporation that has a conflict of interest with bitcoin (like a large bank). If all miners agree that they do not wish such entity to transact on bitcoin, they may decide to censor the activity of such an entity or person. This transaction may never get confirmed.


Is my wallet at blockchain.info still mine if the website shuts down I'm a really beginner, I have no client on my computer. I puchased bicoin and store them in my wallet at blockchain.info, and I have downloaded the "backup file" named "wallet.aes.json".
My concern is if someday the website of blockchain.info shuts down, can I get my bitcoins by importing the backup file into a client software? I also have my "key" which is a long code that looks like an bitcoin address, and my understanding is that the backup file also only consist of my address and that key.
Thanks!

You can import this backup to Multibit, and you are good to go, even if blockchain.info is dead. (To be honest, this is my setup as well). Remember to keep your secret safe and use 2FA.


Cheat Lightning network (c-lightning) I want to understand how cheat lightning network using c-lightning.
I understand that if a participant of che channel send not last commitment transaction, it means that he tries to cheat. I'd like to replicate this scenario.
I tried to dump commitments, and I found these informations.
    $ ./hsmtool dumpcommitments 022f495a897360fdd287f7a823302479e62856e47727c0c8c9688faf45f4a92aac 1 2
/tmp/l1-regtest/regtest/hsm_secret mypass
    shaseed: 14d384a3757ea8c750d1325997ed7c0761b1cf2a8845ae0aaf5b6c783bcbe8ef
    commit secret #0: 9d202a2c4df2792d4d77583b969d407dc0b31e9ff38bb9121932ac55e536202e
    commit point #0: 039f4232478aa0629637ba2d8fd9808bd3d06342b5fbc67699d2f09bc1a9c844ad
    commit secret #1: 8cf246e819e78d34ce331f897652909bdc7104b6eac173a4180be1bbcfc46f37
    commit point #1: 03cacc020bcc3a322c41854a3b0337643b5e9b10af79f96ba14ccf4637cd56ba8f

Where can I find the first transaction in order to try to cheat?
Because I want to understand how penalties work and i'd like to decode all commitments transaction

c-lightning doesn't store old versions of the commitment transaction, exactly in order to avoid accidentally cheating. If you compiled with DEVELOPER=1 you can however call lightning-cli dev-sign-last-tx {peer-id} and it'll spit out the fully signed commitment transaction (that's why dev-* commands are dangerous and should not be used if you don't know exactly what you're doing, which is the case here).
Once you have the signed commitment, just perform some other action that creates a new commitment (feerate adjustment, send or forward a payment) and then send the now invalidated commitment transaction you got from dev-sign-last-tx to the network using bitcoin-cli sendrawtransaction and confirm it by generating a block. Both nodes should see the unilateral close and identify it as a cheat transaction. The cheating node will give up, since there's nothing it can do, and the cheated node can punish the cheater by claiming all the funds.


My first full node - no bitcoin.conf So I am in the process of downloading the blocks after installing bitcoin on my ubuntu server. I have followed the guide on https://bitcoin.org/en/full-node.

Everything is working correctly. Blocks are downloading just fine to ~/.bitcoin/blocks. bitcoin-cli commands are working without error.

If I switch users and I try to issue a bitcoin-cli command naturally I get "Could not locate RPC credentials. No authentication cookie could be found, and RPC password is not set."

However when using the correct user where cli commands do work, there is still no bitcoin.conf file inside ~/.bitcoin/ As the node is downloading the blocks and the cli commands work I assume there must be a conf file - yet its not where every single document and support answer claims it will be.

I have tried find . -name "bitcoin.conf" in the ~/.bitcoin directory as well as user ~/ and in /etc all return empty. Where else could this file possibly hide? If it doesn't exists why would I still be downloading blocks and able to issue cli commands?

I am aware this question has been asked countless times but i cant find any answers relating to the fact the node is working and cli commands are working.

When you don't explicitly specify any RPC credentials, bitcoind will autogenerate them for you and store the password in the $DATADIR/.cookie file.

You can then use the username __cookie__ along with the password from that file.


How does a miner verify a transaction which is spending an output of another transaction in the same block? It is mentioned in this post that:

If all validation of all transactions in a block succeeds, the consumed inputs are removed from the database, and all outputs of those transactions added as fresh unspent outputs in the database, allowing them to be spent by future blocks.

But if the UTXO set is updated only after appending a block, and a miner only checks the UTXO set for understanding the spent/unspent outputs, how will verification happen if a transaction (say tx_B) in a block spends an output of another transaction (say tx_A) in the same block? In another word, how will tx_B understand the state of the output of tx_A if the output is not stored in the UTXO set yet?

While a miner is building a block template, they are maintaining a "virtual" UTXO set to keep track of the consumed UTXOs and the newly created UTXOs. A transaction can only be included in a block once all of its inputs are available for spending, so this approach is also sufficient to achieve the required topological order of transactions.


Payment Channels - Securing the private key that locks client funds Do I need to secure an automatic generated private key used for locking an anchor transaction (the one that opens the channel, locking the client funds), since it only serves that locking purpose (not holding money)?

Can I just drop it? Any further advice? Thanks.

If by "anchor transaction" you mean the transaction that locks some amount of bitcoins to a multisignature address from both yours and your partners private key, then you must keep your private key safe because you will have to sign transactions in both the cases when you will pay, or if you need to refund all the bitcoins back to yourself after some time has passed.

After reading you answer again it seems as if you are looking from the perspective of the receiver. In that case you will still need the private key to be able to sign the (last) transaction that sends you bitcoins from the multisignature address.


Mining Bitcoin- Simple Example for transparency I'm spending a lot of time researching bitcoin before I make any decisions about it, and most of the research is getting to know its fundamental network. Most of the easily verified information is very high-level (meaning surface-level info, e.g. the videos on bitcoin.org or bitcoinmining.com).

What I'm looking for is simple C code (or whatever language) that is verifying information from the blockchain, but not through a pool. I understand the economies of scale and how this will not be efficient. Please don't emphasize how this is not profitable-- say I'm only interested in doing it to contribute my fair share to the p2p network.

How do you get jobs assigned to you from the network to perform your proof of work in the first place? Is there a tool to just get used to this procedure?

Initially miners get their work directly from other peers on the network.  The peer to peer network is publishing transactions constantly.  It is through the process of mining that these transactions are distributed to the entire network.  The tool that you need to help confirm transactions on the network is a mining application.  Some examples are cgminer, bfgminer etc. If you are interested in solo mining and contributing to the network I do urge you to understand difficulty and the formula used to generate a block and why you are very unlikely to ever generate a block of Bitcoin thus confirming the transactions that your node has seen on the network (unless you are mining with many ASIC's and have several Tera-Hashes per second).  As you requested I will not discuss profitability only the probability of this occurring.

From another thread I will reference an equation for how frequently a Bitcoin can be generated with a given hashing power:
Current difficulty = 908,350,862
Hashing power(based upon mining hardware) = 1000/Mhs or 1/Ghs
We will be solving for the approximate amount of time that it will take (on average to generate 1 block of BTC)

By solving for time we get roughly every 1083704 hours ~= 45154 days ~= 6450 weeks ~= 124 years.  Sadly we know that the difficulty is continuing to grow exponentially and it gets recalculated every 14 days or so thus making the average time to generate a block increase.  That being said if you would like to solo mine this is how you would do it.

Simply by launching either bitcoind or bitcoin-qt in server mode the application is ready to accept work from your mining application.  You can then direct your mining application to obtain work from this service via IP (generally on port 8333) Mining pools run an application server such as a stratum or http service that helps to calculate how much work is accepted from each miner if you do not have such an application running you will not obtain statistics from the Bitcoin service unless a block is generated by your miner.


is there any daemon available for bitcoin cash (eg-bitcoind for bitcoin)? I am developing a pool for my client. i have already setup bitcoind for bitcoin but can't find daemon for bitcoin cash?

You can use Bitcoin ABC. But be careful because it is a fork of Bitcoin Core and uses most of the same code, including also naming its daemon bitcoind, so you should not install it on the same machine as Bitcoin Core.


How does an exchange calculate the price of a coin? How does an exchange calculate the price of a coin? I know it has to do with the amount of sell and buy orders, but what is the formula to do this?

For example, if GDAX says one bitcoin is $10k on their exchange, how did they calculate that?

It's normally all about offer and demand.

A "formula" for an exchange could be something like: BTC price shown on the website = average amound (in $) paid for 1 BTC within the last 2 minutes [- exchange fees]

If there are 2 trades in this time:
person A buys 1 BTC for 10,000$ and person B buys 1 BTC for 10,100$, the average is 10,050$. And if there are 500 trades in the last 2 minutes, you get a more accurate average price.


How to store 30kb file using Decentralized Blockchain Data Storage on NXT (nxtcoin) by attach messages? I'm curious to how would one store a 30kb file on the NXT blockchain since the NXT protocol can attach a 1000byte message. My test scenario is storing a 30kb midi file on the nxt blockchain and then call it back to form the file again either in the browser or as a downloaded file. I want to be able to do this via the local nxt client through its api and also via online services that have their api open to query the nxt blockchain. What I need to know and confirm is the following:

Due to the 1000byte limit, I'd imagine it would be about 30+ separate messages to form this file.
To reform the file, we would need to mark each message in proper order to concatenate it.
Can all of this be done using only javascript and query remote nxt blockchain api's?
Do we need to turn bytecode into base64 for decentralized storage?
What other issues might we encounter?

If we can get a test scenario working, technically we can store/retrieve/embed data onto our websites/apps without needing a centralized server.

Seems that the new 1.5 nxt version is giving users the ability to attach up to 40kb worth of data in the blockchain. See here:

NXT 1.5 decentralized storage on the blockchain

Also found the discussion of NXT Transient Data where data can be stored on the blockchain temporarily and then removed after a certain amount of time to reduce blockchain bloat. As discussed bye Jean-Luc: https://nxtforum.org/general-discussion/price-speculation/msg126548/#msg126548

  We could add a "transient data" attachment that can have larger size,
  but is only kept in the blockchain for a limited time, say 24 hours.
  The hash of the complete attachment will be included in the
  transaction bytes that are signed and will be kept permanently, so
  that transaction signature can always be verified, but the actual data
  will be deleted after this expiration period. Then the bloat to the
  blockchain and extra traffic will be limited to those attachments for
  the last 24 hours. This wouldn't be that useful for images for goods
  that sellers keep in stock permanently, but for short lived items, or
  even message with picture type of attachment, may work. Just an idea.

Decentralized file storage released on production blockchain:


Does Namecoin support the bootstrap.dat file? If I create a bootstrap.dat file for Namecoin from an existing install will it use it?

No. This feature does not exist (yet) in Namecoin.


What is the maximum number of signature check operations a transaction script can request? As transaction size, the number of signature checks per transaction can affect client performance and the inclusion of many O_CHECKSIG opcodes could be used as a tool for denial-of-service attacks.

I found in CTransaction::AcceptToMemoryPool() the following check:

// Rather not work on nonstandard transactions
    if (GetSigOpCount() > 2 || ::GetSerializeSize(*this, SER_NETWORK) < 100)
        return error("AcceptToMemoryPool() : nonstandard transaction");

Then I suppose the OP_CHECKSIG limit is 2, which is fine for security but this limit prevents users from using the advanced contracts Bitcoin is suppose to allow.

Also there is the limit imposed by MAX_BLOCK_SIGOPS, but the limit applies to whole blocks, and only indirectly limit the sigops of a single transaction.

The error for nonstandard transaction is simply because they are not yet supported by mainline client.  Remember as writing Bitcoin is only version 0.4 so significat portions of the protocol have not been implemented yet.

You will notice the error being thrown is "non standard transaction" which is indicating the client doesn't have support for creating or validating non-standard transactions.

Standard transactions are those with scriptPubKey of:

 OP_CHECKSIG  - transfer to IP Address OP_DUP OP_HASH160
 OP_EQUALVERIFY OP_CHECKSIG - transfer to Bitcoin Address
(hash of public key)

The only other transaction type supported is generation transaction which doesn't have a scriptPubKey to identify it.  It is easily identified because every valid block must always have one and only one coinbase transaction.

Contracts are non-standard transactions and not supported by the client yet.  The code snippet is simply to prevent client from attempting to process, broacast or validate non-standard transactions.


Can I do a replay attack to spend my testnet bitcoin on the mainnet? I think it would be possible to create a legitimate seeming transaction on the Bitcoin testnet that the Bitcoin mainnet would accept.

I've read a bit about the ETC replay attacks, and it seems like it would be impossible, since there was never any hard fork to create testnet.

https://medium.com/@timonrapp/how-to-deal-with-the-ethereum-replay-attack-3fd44074a6d8

But I'm not sure about this. Has anyone successfully done it?

Do you know a good reason why it 100% would not work?

The answer is no, you can't, because the two chains don't share a common history.

Internally, transactions don't spend "from" an address. Instead, they refer to a specific output created by an earlier transaction which they consume.

In order for a replay attack to work, that same transaction whose outputs are being spent must exist on both chains. This is only possible when the two chains share a common history, and the earlier transaction either occurred before the fork (so it exists on both sides), or it itself was already a replay.

As soon as a transaction's history is not identical - meaning it consists of the same transactions leading up all the same to the same coinbase outputs that created the coins - they cannot be replayed, as the txids of the inputs will not exist in both chains.


Does this FinCEN Document mean the Bitcoin Network is a bank? Read this document and see if you think they are talking about Bitcoin.
Here's an excerpt..

  Any individual or group of people engaged in conducting, controlling, directing or owning an informal value transfer system in the United States is operating as a financial institution. Therefore, IVTS operators must comply with all Bank Secrecy Act (BSA) requirements, which include establishment of an anti-money laundering (AML) program, registration with the Financial Crimes Enforcement Network (FinCEN) as a money services business, and compliance with the record keeping and reporting requirements, which include filing suspicious activity reports (SARs).

I found it here: http://www.fincen.gov/news_room/rp/advisory/pdf/advis33.pdf

As the document predates Bitcoin, it does not specifically address the Bitcoin network. While the document may apply according to the phrasing, I am not sure whether the Bitcoin network as such is a legal entity as it does not have any formal structure. I would assume that only participants in the Bitcoin network could be addressed by law, i.e. "a company", "an organization" or "a user", much like laws could be passed concerning "anyone spending more than $100 in cash in one transaction", but not "the group of people that get out of bed with their left foot first".

Concerning participants in the Bitcoin network though, according to CoinDesk Bitcoin miners and investors are not money transmitters. Specifically, CoinDesk quotes there

  “The first ruling states that, to the extent a user creates or “mines” a convertible virtual currency solely for a user’s own purposes, the user is not a money transmitter under the BSA. The second states that a company purchasing and selling convertible virtual currency as an investment exclusively for the company’s benefit is not a money transmitter,” the release states.

So, as far as I understand, regular users, miners, and investing companies neither have to register, nor implement the measures listed in the question, while I'd assume that online wallet services and Bitcoin exchanges have to do so.

IANAL, this is not legal advise.