What is the block / confirmation time for NXT coin?

Transactions are being included into blocks in 1 minute in average. Longer you wait - higher a chance that a double-spending won't happen. There is no such a number that guarantees 100% irreversibility.

1 confirmation is not secure at all. 10 confirmations is recommended for small amounts, 720 confirmations - for big ones.


Im using Chrome but on other browsers it should be same...
Browser holds in memory some data about your last login - session, so you have to open several incognito windows(CTRL+SHIFT+N chrome) or open several browser programs, by which I mean, one chrome, one IE, one mozzila. Becose every program has its own cache... But really easiest way is to open chrome and ten incognito windows with ctrl+shift+n...

so
for every wallet go to main page of CHROME browser CTRL+SHIFT+NEW will open incognito and type there blockchain.info


Does a 51% attack depend upon difficulty?

The dependency goes as follows:

The difficulty depends on the total hashing power. As the hashing power goes up, so does the difficulty. This is intended to keep the block generation rate roughly constant at about one block every ten minutes.
As the total hashing power goes up, so does the amount of hashing power needed to accomplish a 51% attack. The total hashing power is the thing you need to accumulate 51% of.

So there is a direct relationship, but it's because they're both directly tied to total hashing power.


Are there any C# Bitcoin libraries and/or mining pool software packages?

Welcome

1) Here's an old project to start from

2) Here is the Bitcoin.it wiki entry on pool servers, including the derelict PoolServerJ

Mining is changing radically right now, with new hardware technology (ASICs) soon to be delivered which will likely increase the network hashrate by some orders of magnitude in the coming months. As a result, the protocols are changing to accommodate this increase, namely to stratum and getblocktemplate, if I recall correctly.

Good luck!


Is offline Bitcoin transaction signing safe?

Lets say I create a transaction at my watching-only wallet. Then I sign it on my offline wallet. That means I just "toggle something"/"add some data that says signed" when I'm signing my transaction at the offline wallet.

That is not how Bitcoin or digital signatures work. By your logic wallets (online or offline) wouldn't work in general. Private keys are not broadcast to the network or given to anyone unless the person who generated them (and thus owns them) does something.

Digital signatures work via mathematics to generate a proof. With a specific message and public key, only the person who controls the private key that corresponds to the public key is able to generate a valid proof. That proof is the signature, and that is what is added to a transaction. Signatures do not require the signing device to be online. Signing is an entirely offline operation that only does math, nothing else.

  Even if I sign it at the online-wallet somebody could just change the sourcecode of the client that he does not need the private-key to sign something.

The signature validation operation is a consensus rule. Every must follow that exact rule otherwise you will be forked off of the network. Sure you can make a client that doesn't do that validation, but then you aren't using Bitcoin, and if no one uses your client and its forked blockchain (as that will happen), then your transaction and coins on that chain are completely worthless.


What's the difference between hashtx and rawtx in ZeroMQ of bitcoind?

After some investigation, I found out that RAW topics actually include entire body of transaction/block descriptor.

See, Raw Transactions.

Actually, you could explore the transaction descriptor content in JSON format by first converting binary data to HEX-string and then by pasting it to the blockchain.info tool or by using RPC call of bitcoind: decoderawtransaction.


You are trying to call the RPC interface incorrectly.  Your curl -

$ curl --digest -u rpcusername:rpcpassword -X POST 127.0.0.1:8332/json_rpc -d "{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"getwalletinfo\"}" -H 'Content-Type:application/json'

has an incorrect path 127.0.0.1:8332/json_rpc you are posting to.  You should create your curl request with the following path - 127.0.0.1:8332/.

Working example, printing verbosely with -v

$ curl -v --digest -u rpcusername:rpcpassword -X POST 127.0.0.1:8332/ -d "{\"jsonrpc\":\"2.0\",\"id\":\"0\",\"method\":\"getwalletinfo\"}" -H 'Content-Type:application/json'


Broadcast raw transaction without input validation

Turns out there are many ways to do this:

Node.js: Bitcore lets you broadcast a raw transaction to the network without any kind of validation, see the "broadcast a transaction through P2P" example.
Python: Protocoin is a library that can do that.
Java: BitcoinJ can do it.
C#: Bitcoincsharp, which is a port of BitcoinJ can also do it.


Why so many warnings about importing private keys?

Importing a private key can lead to non-intuitive behaviour, and that can be exploited by an attacker.

Imagine I'm evil. I give you a paper wallet with 1 mBTC on it. You're happy and import it. I keep the private key and wait. Depending on the client/user, maybe someday you'll put some real money on there as change/received funds. Then I can swipe them right off from you. If you don't bother moving the original money off the key, I can also steal that back.

If not, then at the very least I can trick you next time into thinking you were paid by sending funds to that address. Then I can steal them right back.

Importing also tends to break backups, especially deterministic key schemes. Armory gives you one line of text for all your keys, and then 1 line per imported key. Every time you import, you'll need to redo all your backups.

Because most users don't understand these implications, wallets tend to discourage importing, and instead offer sweeping (moving the funds to an address that was generated by the wallet itself). Supports 90% of the use cases with none of the issues.


Explorer showing different balance then my Blockchain wallet

You don't have just one address.  It is normal for a wallet to hold your coins distributed across many different addresses.  This is for privacy, since it makes it harder for the public to determine your total coin holdings.  For instance, whenever you ask someone to pay you, you would usually generate a brand new address that you have never used before and ask them to pay that address.  That's what the "receive" function on most wallets would do.

It is possible for a transaction to draw coins from more than one address.  Your wallet does this automatically when you make a transaction that is larger than the balance of any single address.

Your wallets may have a way to show all your addresses which currently contain coins; you could look those up in a block explorer and the total should come out right (assuming all your incoming and outgoing transactions have confirmed).


How do you install blackcoin on a headless server or VPS?

You may need to slightly modify the following steps for your needs:

ssh or log into the machine
Make sure that git is installed.

sudo apt-get install git
Clone the github repo

git clone https://github.com/rat4/blackcoin.git
Follow the instructions from the installation documentation  which are:
Install the dependencies.

sudo apt-get install build-essential libssl-dev libdb++-dev libboost-all-dev libqrencode-dev
Run the makefile which will compile the program from the source we just downloaded.

cd blackcoin/src
make -f makefile.unix
Run the newly created binary.

./blackcoind

There is also a #blackcoin irc channel on freenode where there are friendly blackcoiners happy to walk you through installation.


How to compile coins from github? (linux mint/ubuntu)

You have to install the required dependancies first

sudo apt-get update

sudo apt-get install -y git make g++ build-essential libminiupnpc-dev

sudo apt-get install -y libdb++-dev libssl-dev libboost1.48-all libboost-chrono1.48-dev

then

git clone https://github.com/cryptotech/PayCon.git

cd PayCon/src/leveldb

sh build_detect_platform build_config.mk ./

cd

cd PayCon/src

make -f makefile.unix


How can one blockchain with the same block heigth as another, have more Proof-of-Work

How can 2 chains with the same length have different cummulative Proof-of-Work? Is it because they might include block that were mined with different difficulty targets?

That is correct. The bitcoin protocol actually follows the chain with the highest accumulated proof-of-work, not the largest block height.

I believe the original implementation followed the largest block height, but that left the network open to certain attacks, so it was soon changed to largest accumulated proof of work.


How does exactly ICO work? What the advantage of ICO for companies?

Cryptocurrencies, and by extension issued tokens, live in a legal grey zone.

ICOs are just a means to use blockchain-issued tokens as a funding mechanism. If it weren't for the legal grey area, it seems to me that they're exactly the thing that investor accreditation laws are intended to prevent: raising money from people who are vulnerable to being scammed.

From what I've seen so far, almost every ICO is just lots of talk, without any indication that there is a plan or competence to implement anything but the off-the-shelf ICO smart contract. In other words, a modern incarnation of a pump-and-dump scam.

So to answer your question: the advantage is raising lots of money quickly, without needing to follow up on any promises.

I believe that ICOs are putting the whole ecosystem in a bad light, and are likely to result in legal problems.


Why did the core developers choose base64 for PSBT encoding?

Since PSBTs can be fairly large, I wanted to use an encoding that compressed better than hex and was already in use and implemented by many clients. Base64 was already in use by other clients as signed messages also uses Base64. It also works well with command line without escaping or quoting so it seemed like a good choice.


What is ment by the "value of the output spent by this input" in BIP 143?

I thought the whole amount of the input is always spent.

That's correct.

  In case the spender doesn't want to spend it whole, some of it goes to the same address (called change) returning the bitcoins.

No, if the amount in the outputs is less than the inputs being spent, the difference is converted into fee.

Software that creates transactions can explicitly add an output for change that goes back to the former owner. This can be to the same address, but generally isn't. It is called change indeed, but it's not part of the protocol. It's just how wallets deal with inputs that are too large.

  What do they mean by that? Does it mean the full available amount in the input?

Exactly. It's redundant information that is already implied by referencing the transactions that created the outputs. However, it simplifies the operation of some pieces of infrastructure.

In particular, right now if you want to use a hardware signing device ("hardware wallet"), and that wallet wants to show you how much fee you'll be creating, it needs to know the amounts of the outputs being spent (as the fee is the difference between outputs and inputs). That means it needs to be given the full transactions those outputs belonged to - which can be big. Otherwise, the software that created the transaction could lie, and in fact convert a giant portion of your money into fee without you knowing it.

With the fee explicitly part of the signature hash in BIP143, if the wallet software lies about the amounts to the hardware signer, the signature will simply be invalid.


Electrum on Android - where is wallet.dat hidden?

Electrum doesnt use wallet.dat file, those are used by Bitcoin Core. Electrum creates wallet files in %UserProfile%\AppData\Roaming\Electrum\\wallets for Windows, /home/user/.electrum/wallets/ for Linux and /data/data/org.electrum.electrum/files/data/wallets for Android. If forgot seed words, move BTC to another wallet and keep backup info safe if you can.


What are the most popular CPU/GPU miners with scrypt-jane support

There is a working version of cgminer that supports both scrypt and scryp-jane, available here:

https://sites.google.com/site/rmdavidson/


Is the transaction pool global or local?

Do all the miners have one global pool filled with transactions

Different full nodes have a different version of the mempool. Transactions are broadcasted to the bitcoin network on a best effort basis. If a transaction never reaches a node, it would not include it in the mempool. It would not learn about this transaction until it is included in the block by another miner.

  Miner 1 takes Transaction 1 into his candidate block, so Transaction 1 won't be in the transaction pool anymore, Or does each miner has a local pool filled with transactions, so that each miner can take Transaction 1 into his transaction pool.

The second part is correct. Every miner creates their own candidate blocks using transactions from their own mempool. In case a miner is affiliated to a managed pool, the pool operator creates a block template (by including the transactions) and sends the header to the respective miners that are attached to the pool.


Can a miner give themselves less than the maximum block subsidy if they wish to do so?

Yes, it would have. In fact, this has happened before in many different blocks.

The Bitcoin wiki has two instances of this documented:

  In block 124724, user midnightmagic solo mined a block which caused one less Satoshi to be created than would otherwise have come into existence. Therefore, all calculations from this block onwards must now, to be accurate, include this underpay in total Bitcoins in existence. Then, in an act of sheer stupidity, a more recent miner who failed to implement RSK properly destroyed an entire block reward of 12.5 XBT in block 501726.


Who decides the block reward in Bitcoin?

When the creator of Bitcoin published the original Bitcoin client, it came with rules for an inflation schedule. As a means of bootstrapping the system and distributing the initial supply, miners were allowed to create 50 new bitcoins per block, but this subsidy would get halved every 210,000 blocks. The inflation schedule is a so-called consensus rule which is enforced by every single full node in the network. If any miner creates a larger amount, all other network participants recognize the block to be invalid and reject it. This happened once in July 2019 when a miner accidentally tried to create more new bitcoins than the allocated subsidy. You can think of the consensus rules as the least common denominator that keeps various implementations converging onto same ground-truth in the decentralized Bitcoin network. As they are so central, changes to consensus rules tend to meet resistance and it can take years to establish support for amendments.

Miners do have an important role in the Bitcoin network, but if a cabal of them unilaterally stopped adhering to the consensus rules, they would simply no longer get paid: newly minted coins can only be spent at the earliest 100 blocks after they were created, and only in a block that directly derives from the block that created the funds. As seen in above mentioned incident, even a single block with an excessive block subsidy was a major news item when it happened. It is extremely unlikely that the greater ecosystem would go along with it, and that means there is no market to sell the coins, meanwhile every block comes at an actual cost.

Incidentally, we happen to be close to third subsidy halving: In approximately 16 days, at block 630,000, the block subsidy will halve to 6.25 bitcoins per block. This happened twice before, in 2012 the subsidy halved to 25 bitcoins, and in 2016 the subsidy halved to 12.5 bitcoins per block.

Related reading:

How many bitcoins will there eventually be?
Where do bitcoins come from and what gives them their value?
How is the bitcoin 21 million cap implemented?
Why was 21 million picked as the number of bitcoins to be created?
Will there be 21 million bitcoins eventually?
How much inflation does Bitcoin have, year by year?
How many Halving Days will there be?


What encoding is "pubkey" from the JSONRPC validateaddress command?

The public key is in the format returned by OpenSSL and is a straight hex-encoding of the bytes.  If the first byte is 0x04, then it is a 65-byte uncompressed key (32-byte X and 32-byte Y).  If the first byte is 0x02 or 0x03, it is a 33-byte compressed key (32-byte X and one bit for Y sign).

The recID is encoded as part of the signed message.  Check the verifyMessage() method in the ECKey class to see how it is extracted.

The column on the right is correct and it matches what you got from validateaddress.


Bitcoin core: why does the wallet file contain transactions?

You can't spend bitcoins without having the transactions in which you received the bitcoins. Bitcoin Core also needs to actually know about your transactions to display them with RPC commands like listtransactions. Reconstructing this data from the block chain is extremely slow. Try running Bitcoin with the -rescan switch, which searches the entire block chain for wallet transactions: it often takes 15 minutes or more. Sites like blockchain.info can only get info about addresses and transactions quickly because they maintain huge indexes of addresses/transactions, but Bitcoin Core does not maintain such indexes. Also, it is very likely that Bitcoin Core will eventually start throwing away most block chain data to save disk space. If this happens, then you will be unable to recover your wallet transactions without downloading a big chunk of the block chain again. So saving these transactions is in fact pretty important, and they should be backed up along with your keys in wallet.dat.


How to obtain the Channel_ID from the Short_Channel_ID?

The short_channel_id points to the funding transaction of the payment channel by the format blockheightxtransaction_indexxoutput where the x is used to seperate the 3 values and the three values are depicted in decimal. This is at least the BOLT 1.1 agreed format for the short channel id. Previously the shortchannel id might have been encoded and depicted differently depending on the implementation. For example c-lightning used a colon instead of an x to separate these fields.

According to BOLT02 the channel_id is created as follows:

  This message introduces the channel_id to identify the channel. It's derived from the funding transaction by combining thefunding_txidand thefunding_output_index, using big-endian exclusive-OR (i.e.funding_output_index` alters the last 2 bytes).

as the funding_txid is a hash of its fields this has no relation with the short channel id. So without looking at the blockchain data I believe it is impossible transfer the short_channel_id to the channel_id or back.


Deriving hex private key from a HD wallet

The mnemonic represents a BIP32 extended private key: xprv9s21ZrQH143K4BbpSvRBDykoXLhwtznbp7qAfKVLw1QdJtJsmgS5rZJfSgZNtgk7e39uRNiYHbcRQnYvruqfftfG6WFmuiCspehEz1VS3YM

The function you are calling accepts a regular private key.

You can derive child private keys from the extended private key and use these to generate addresses.

It it be possible to derive the corresponding private key of either the children of this extended private key or the corresponding private key itself using the toWIF method in the bip32 JS library. See https://github.com/bitcoinjs/bip32/blob/master/index.js

You can see some examples of the use of BIP32 here:
https://github.com/bitcoinjs/bitcoinjs-lib/blob/a6f2cc2924df170537f0b588254178f5445d7dc8/test/integration/bip32.js


yesterday evening I send out 0.97 BTC. I checked transaction and It says : " lock time 459355"

No, your coins are not lost. Either they get confirmed and become available to the recipient, or they are unspent and remain yours.

All transactions created with Bitcoin Core (and maybe also other wallets) set their transaction to be confirmed only with the next block at the earliest. This is done to discourage fee-sniping.

In your case I assume that the current block was 459354, so the transaction was created locked to the next block 459355. Since we're currently at block 459475, the delay of confirmation for your transaction would not be related to the locktime.

For more information please see Why is my transaction not getting confirmed and what can I do about it?.


What makes a transaction a SegWit transaction or a non-SegWit transaction?

It depends for what purpose.
When do segwit validation rules apply?
P2WPKH/P2WSH script validity rules apply on a per-input basis.
Only inputs that spend a segwit output can have a non-empty witness.
When is extended serialization used?
BIP144 defines a new way for serializing transactions. It is used whenever at least one input has a non-empty witness. It cannot be used when all witnesses are empty (as is the case for legacy spends).
When do the malleability protections afforded by segwit apply?
Only when all (relevant) inputs are segwit inputs do these protections work. However, say a transaction has a multisig segwit input and a legacy single-sig input from yourself, you may be fine, as the single-sig input may be considered non-malleable.


Where is the witness data stored in the raw block data

If your question is about how witness data is transmitted to other peers in the P2P protocol, the right place to look is BIP-144; the P2P side of the segwit specification.
In short, the witness data is inserted after the transaction output data in every individual transaction, together with a special marker after the version number to indicate whether or not witness data is present. Full blocks then consist of the block header, a transaction counter, and a concatenation of all transaction (which include that witness data).
Note that this is not the only way that blocks are transmitted. BIP-152 (compact blocks) send blocks where the transactions are replaced with short hashes, anticipating that the receiver will already have those transactions (including their witness data).
As for how witness data is stored: that is an implementation detail that is up to the client software, and not specified in BIP documents. Bitcoin Core stores blocks using the same serialization as used in the P2P protocol, as described above.


Can miners collude to bypass the penalty based revocation system of the lightning network?

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


How do people actually try double-spends?

Edit

You could practically open two separate bitcoin clients (such as MultiBit and Bitcoin-QT). Prepare a transaction that is using the same input. As for output one would use the payee's address, while the other client would use your address (you're double spending right?).

At this point you'd just have to send the transactions at the same time and hope your payee has gotten the correct transaction instead of the double spend. I doubt there's a client that automates this procedure.

You could also make this happen with a higher success rate if you send the valid transaction directly to the payee's client, while you send the double-spend to the node of a pool. This would increase the chances that your double spend will actually make it inside a block before the other.

Of course to do this would require you to get your hands wet with lower level bitcoin clients such as sx or directly bitcoind. Actually I'm afraid you'd have to program this functionality yourself studying the protocol and making sure you know how to broadcast to specific nodes instead of the entire network.


Vanitygen: Why is it easier to generate an address that starts with a capital letter?

I'm copying this from deepceleron's post on bitcointalk:

  The change happens at a particular address:

  prefix difficulty: 77178 1QLa
  prefix difficulty: 78362 1QLb
  prefix difficulty: 4553521 1QLc

  This is a quirk of how the 25-byte (50 digit hexadecimal) Bitcoin
  address is converted into Base58 (represented by numbers and letters),
  and the different maximum values that can be stored in 25 base256
  digits vs 34 base58 digits.

  The Bitcoin address in it's native binary form (that you never see) is
  25 bytes, it's parts are:
  byte 0: Network ID Byte (0x00 for main
  bitcoin network)
  byte 1-20: ripemd160 hash (20 bytes) of sha256 hash
  (32 bytes) of 0x04+public key (65 bytes)
  byte 21-24: checksum: first
  four bytes of sha256 hash of sha256 hash of bytes 0-20 above

  This would be 50 hexadecimal characters long (base16), with a possible
  digit value between 0-F.

  We will ignore byte 0, it is always 0x00, and Base58 conversion always
  preserves this leading 0 byte by directly encoding it as a "1".

  That means the "vanity" part of the address is bytes 1-24, 24 bytes of
  random hash output, or 48 hexadecimal digits. The maximum value that
  this can be is 0x FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF FFFF
  ffff ffff (the lower case "f"s are the checksum, and won't be all
  FFFFs for the maximum ripemd160 value.) We can guess from the output
  below that this maximum possible address value encoded in Base58
  becomes 1QLbxxxxxx.... something:

1QLa8LNNFeYs7KJWvxMdR5YtRjkwtQtkyb
1QLabhman6ZQyz3musbqV1RjFmE3pyT29j
1QLaJHv2LCSYo8WgT9qPf4rdttduRGyozX
1QLarwzJCUWGuQEZ4uWPsYVz8N2P5XmeQU

1QLckWG2tx17suupYU2FfeWunTCZMuJKW
1QLcMk7NVLwvg8gw2ihJTuG8x7WLYCjMg
1QLcLr6AoN687CpH1JZnfeMmWvUka5NHX
1QLc47945bSCv4J1Z4yRuvUbtooQqmGJ1
1QLcU9NNxaqfvqMRXD8dFtL2SktL3YmBT
1QLc1D24uDbvy327MzifEChVvATAeDsbF

  See how the 1QLa addresses are full length, but the 1QLc addresses are
  one digit shorter? That is because the only way to have an address
  starting at 1QLc or greater is by having a binary address that is 59x
  smaller.


How to select a leader in RAFT consensus protocol

In the RAFT algorithm if a candidate who wants to become a leader in the network then his proposed "term value" will be checked at the beginning.
1) If it's less than the present "term value" then he will not be selected as a leader.
2) If it's more than the current "term value" then his current "index value" will be checked.
a) If his index value is less than the current index value then he won't be selected.
b) If his index value is more than current index value then he will be selected as leader.

In this case "Candidate 4" will be leader as in every round his term value is not lesser than current term value and his index is updated to current node.


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


Bitcoin core wallet transactions and synchronisation

With Bitcoin Core you'll run a full node. So, for every transaction someone does to your business, your Bitcoin Core wallet need to be synchronized with the complete blockchain.


How is the size of a bitcoin transaction calculated

Since the activation of Segwit, transaction size is expressed in Weight Units (WU). Weight Units can be converted to a "virtual size" or virtual bytes (vB) by dividing by 4 and rounding up. The virtual size dictates how large your transaction is when paying fees.

Non-Segwit Transactions

For now, let's focus on Non-Segwit transactions. Each Non-Segwit byte of data is counted is 4 WU when determining size. Each transaction consists of the following fields:

Version (4 bytes)
# of Inputs (VarInt, 1 byte for numbers up to 252)
Inputs (varies)
# of Outputs (VarInt, 1 byte for numbers up to 252)
Outputs (varies)
Locktime (4 bytes)

Let's break each of these fields down by looking at a non-segwit raw transaction:

0200000001d2eed35b0d55763981c635cab7788c28e3683af3d329947a17d7f6005390e6ef010000006a47304402200ffaac8f12e56f4af66109220812b76c7d6bb0e5906cf2de235b79496b3e080b0220037304894b648fa0b50e0d82ef9f58b537233ee282ab31fc04fb3d169d2c97cc0121030120a287eb98922752a89b39df64f7f3314036f6f096341c9189b0cb3c692aaeffffffff02404ff200000000001976a9140b818b11f9624e6a2d5b757a3e8fe45db3f6647788ace0b4b401000000001976a914a1e5e47fce1c5c0868107dba3851eb696c2ead5388ac00000000

Version

The version of this transaction is 02000000 (2 in little-endian). The version is always 4 bytes (16 WU).

# Of Inputs

The number of inputs is 01 (1 in VarInt notation). This indicates there is 1 input being spent by this transaction. This adds 1 byte (4 WU).

Inputs

All Inputs consist of the following fields:

Referenced Transaction Hash (32 bytes)
Output Index (4 bytes)
Script Length (VarInt, 1 byte for numbers up to 252)
ScriptSig (varies)
Sequence (4 bytes)

For our example transaction, the values are:

RefTX: d2eed35b0d55763981c635cab7788c28e3683af3d329947a17d7f6005390e6ef
Output Index: 01000000 (1 in little-endian)
Script Length: 6a (106 in VarInt notation)
ScriptSig: 47304402200ffaac8f12e56f4af66109220812b76c7d6bb0e5906cf2de235b79496b3e080b0220037304894b648fa0b50e0d82ef9f58b537233ee282ab31fc04fb3d169d2c97cc0121030120a287eb98922752a89b39df64f7f3314036f6f096341c9189b0cb3c692aae
Sequence: ffffffff

In total, this input adds 147 bytes (588 WU).

# Of Outputs

The number of outputs is 02 (2 in VarInt notation). This indicates there is 2 outputs being created in this transaction. This adds 1 byte (4 WU).

Outputs

All Outputs consist of the following fields:

Value (8 bytes)
Script Length (VarInt, 1 byte for numbers up to 252)
ScriptPubKey (varies)

For our example transaction, we have 2 outputs. The first output is:

Value: 404ff20000000000 (15,880,000 satoshi, in little-endian)
Script Length: 19 (25 in VarInt notation)
ScriptPubKey: 76a9140b818b11f9624e6a2d5b757a3e8fe45db3f6647788ac

In total, this output adds 34 bytes (136 WU).

The second output is:

Value: e0b4b40100000000 (28,620,000 satoshi, in little-endian)
Script Length: 19 (25 in VarInt notation)
ScriptPubKey: 76a914a1e5e47fce1c5c0868107dba3851eb696c2ead5388ac

In total, this output adds 34 bytes (136 WU).

Locktime

For our example transaction, the locktime is 00000000 (0 in little-endian). Locktime is always 4 bytes (16 WU).

In total, this transaction is 900 WU. Converting to vB gives us 225 vB. With an Input Value of 0.4491 BTC and a combined Output Value of 0.445 BTC, the total miner fee is 0.0041 or 410,000 satoshi. Converting this to sat/vB gives us a feerate of 1,822 sat/vB. (incredibly high!)

Segwit Transactions

A Segwit Transaction is any transaction which spends a Segwit input (aka an address beginning with "3" or "bc1"). Segwit Transactions include a few extra pieces of information like Witness data. Segwit Data is counted as 1 WU/byte and is therefore cheaper to include in transactions. This is why Segwit saves on fees. A Segwit Transaction consists of the following fields, with fields counting as Segwit Data being bolded:

Version (4 bytes)
Marker (1 byte)
Flag (1 byte)
# of Inputs (VarInt, 1 byte for numbers up to 252)
Inputs (varies)
# of Outputs (VarInt, 1 byte for numbers up to 252)
Outputs (varies)
Witness Data (varies)
Locktime (4 bytes)

Again, let's break each section down in an example Segwit Transaction:

02000000000101caba4ccb61cca412fe29ec553d286134a02335c04355a9cc1e056fe2403692cf1400000000fdffffff026406010000000000160014093c864a10516154d18d2accd61c6b2920a2040f60361e000000000017a9140195e8dd3d1527038a0a77e0b0e4515d6c8ab195870247304402200760efedbcee3bbd913661fb40c364caed622b331ee3b5bc70ac25df2d3763d5022020efdb41ef325089d146eb48948b6aaec85c086fa38a3df4d2a51ee729645ebc012102be338e0362fb01101a873a7502012cb82f7d9d303b4943fa0702829a763e49762b550900

Version

The version is, like before, 02000000 (2 in little-endian) and is always 4 bytes (16 WU).

Marker

The marker is 00 (0 in VarInt notation). The Marker indicates that this Transaction is a Segwit Transaction. Nodes running Segwit will see this marker and know to parse the transaction appropriately, and nodes not running Segwit will treat the marker as the "# of Inputs" field, discarding it as invalid for having 0 inputs. This adds 1 byte (1 WU).

Flag

The flag is 01 (1 in VarInt notation). The Flag indicates that Witness Data will be present in the transaction, and adds 1 byte (1 WU).

# Of Inputs

The number of inputs is 01 (1 in VarInt notation) indicating this transaction has 1 input. This adds 1 byte (4 WU).

Inputs

The first (and only) input is as follows:

RefTX: caba4ccb61cca412fe29ec553d286134a02335c04355a9cc1e056fe2403692cf
Output Index: 14000000 (14 in little-endian)
Script Length: 00 (0 in VarInt notation)
ScriptSig: [EMPTY]
Sequence: fdffffff

This input adds 41 bytes (164 WU).

# Of Outputs

The number of Outputs is 02 (2 in VarInt notation) indicating there are 2 outputs created in this transaction. This adds 1 byte (4 WU).

Outputs

The first output is as follows:

Value: 6406010000000000 (67,172 satoshi, in little-endian)
Script Length: 16 (22 in VarInt notation)
ScriptPubKey: 0014093c864a10516154d18d2accd61c6b2920a2040f

This output adds 31 bytes (124 WU). The second output is as follows:

Value: 60361e0000000000 (1,980,000 satoshi, in little-endian)
Script Length: 17 (23 in VarInt notation)
ScriptPubKey: a9140195e8dd3d1527038a0a77e0b0e4515d6c8ab19587

This output adds 32 bytes (128 WU).

Witness Data

The witness data consists of Data Pushes. I will not go into the details of Witness Programs in this answer. The witness program for this transaction is:

02 47 304402200760efedbcee3bbd913661fb40c364caed622b331ee3b5bc70ac25df2d3763d5022020efdb41ef325089d146eb48948b6aaec85c086fa38a3df4d2a51ee729645ebc01 21 02be338e0362fb01101a873a7502012cb82f7d9d303b4943fa0702829a763e4976

The Witness Data adds 107 bytes (107 WU).

Locktime

The locktime for this transaction is 2b550900 (611,627 in little-endian) and is used as the Block height at which this transaction's outputs can be spent. This adds 4 bytes (16 WU).

In total, this transaction is 565 WU. Converting to vB, that's 142 vB. With an Input Value of 0.02118172 BTC and a combined Output value of 0.02047172 BTC, the transaction fee is 0.00071 BTC (71,000 satoshi). The feerate of this transaction is 500 sat/vB. (also extremely high!)

Estimating Fees

With this knowledge, how does a wallet know how much to use as a fee given a feerate?
It's quite simple. See this answer for information on how a wallet handles this information given different address types. Your wallet estimates how much satoshi to set aside as fee based on the inputs, outputs, address types, and desired feerate before signing the transaction.

As for how wallets create transactions with the lowest fee possible, and how fee estimation algorithms that look at the current mempool work, they are wallet-dependent.


The bitcoinj private keys are 32 bytes long. You would also want some sort of indexing around them so that you could access them efficiently.

If you used a deterministic wallet you would only need one seed and a chain code per customer and generate the addresses as required. I think they are typically 32 or 64 bytes long.


Is Ripple's distributed exchange scalable?

It is designed to be highly scalable.

Offers are aggregated with others offers of the same currency pair in the same direction of the same quality (rate). The ledger has a "next index" operation and offers are indexed by quality, so finding the best offer in an order book is as simple as computing the index for the base of the order book and looking at the next ledger entry.


Running a Bitcoin node (behind Firewall / NAT or anything else? disallowing inbound connections)

You may wish to attempt the following: Your router most likely offers you a GUI so you can adjust a few settings. Use your browser to connect to your router whose ip address is something like 192.168.0.1. This will bring the GUI to your browser (you will need to find out the login details giving you access). Once you are connected to your router, there is probably a section called 'advanced settings'. Within that section, you may see a subsection called 'DHCP reservation' which should allow you to choose a fixed internal ip address for your raspberry. Once you have done that, go back to advanced settings and find a subsection called 'port forwarding`. This will allow you to instruct your router to forward any connection attempt on port 8333 to your fixed ip address.

In fact, I have just been paraphrasing bitcoin.org


Mediated transfer of funds between three parties

Your protocol makes sense, but i would modify it as follows

the 1btc sent to trent should also be mutlisig with Alice's signature as the 2nd one, so that if Trent fails to do what he promised he gets no commission. ((the 1btc will stay in limbo, unless Alice and Trent can somehow work this out)
The Tx2 should also be multisig and Carol's signature should be added, that way Trent can't run with the money.


Reserve the connection for local wallets

Bitcoin Core allows you to bind a separate listening socket with specific white listing properties. It has enhanced transaction relaying for use as a gateway and an immunity to banning for bad behavior.

  -whitebind=<addr>
       Bind to given address and whitelist peers connecting to it. Use
       [host]:port notation for IPv6

This command can be used in conjunction with whiteconnections to reserve some of the maxconnections limit for connections to the whitelist socket. maxconnections=128 and whiteconnections=4 will use 8 for outgoing connections, allow a maximum of 116 incoming connections, and reserve 4 additional connections for incoming clients on the whitelisted port.

In this case you would bind the whitelist socket to an internal port, and then point LAN nodes to it. This is also useful for attaching axillary programs like P2Pool or the Bitcoin Relay Network.


How to write OP_CHECKMULTISIG for the following 1-of-2 multisig P2SH script

From what I understand from your question (correct me if I'm wrong), you want to have a script that in the OP_IF part pays to 1-of-2 public keys. You could try the below script:

OP_IF
  OP_SHA256
  OP_DATA (0x20)
  <hash of secret>
  OP_EQUALVERIFY
  OP_1
  OP_DATA (0x21)
  <pubKey of swap1>
  OP_DATA (0x21)
  <pubkey of swap2>
  OP_2
  OP_CHECKMULTISIG
OP_ELSE
  OP_DATA (size of relative_locktime)
  <relative locktime>
  OP_CHECKSEQUENCEVERIFY
  OP_DROP
  OP_DATA (0x21)
  <pubKey of refund>
  OP_CHECKSIG
OP_ENDIF

You could spend this script with: <0> <sig1> <secret> 1


In order for you to see these scripts you'll have to force the channel on-chain, along with the HTLC. Only then will the HTLC be swept using the script, otherwise you'll only see the P2WSH output for the HTLC being added and then removed if the payment succeeds or fails.
Under normal operation you wouldn't therefore see the HTLC. When testing c-lightning we do however force this case, to verify that it is being handled correctly. There are two ways to force on-chain settlement:

Write a small plugin that simply holds on to the incoming HTLC on either l2 or l3 depending on which channel you want to observe the script.
If you compiled with DEVELOPER=1 you can also provide a file with instructions to disconnect if certain messages are seen. This is a bit more involved, but here's a test that shows how that works. It instrucs the l1 to disconnect as soon as it gets a WIRE_REVOKE_AND_ACK message which completes the addition of the HTLC.

Once the HTLC is stuck at some point you can generate a number of blocks until the HTLC timeout approaches, at which point the nodes will publish a unilateral close. Once the channel is closed, and the HTLC timeout expired, the nodes will sweep the HTLC output with the script you're looking for.


Check if a user pays another user for bitcoin website

I think what you really need here is to be able to, on demand, get a new address for the receiver that is specific to a new order. So, for example, if the receiver of the coins is to get 1 BTC, then you get a new address for that user, associate it with the order, and as soon as it receives the coins you know that this order has been fulfilled.

It may not be so easy to get the user (receiver of funds) to give you a big list of their addresses ahead of time, though. This is where something like BIP32 wallets may come in handy. With Hierarchical Deterministic wallets, you can get an extended public key and generate addresses for someone else as needed without ever needing to know the private keys for those addresses.

Not all wallets are HD wallets, and probably even fewer support getting an xpub to give out to someone for generating new addresses on the wallets behalf. You'd have to do some digging to find a wallet that would let you do this. Obviously, you wouldn't be able to force the payers to use this type of wallet, but if there are relatively few receivers (merchants) you might be able to get them on board with using a more fully-featured HD wallet to receive their payments.

More info: https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki


What is the difference between the mnemonic and the private key?

Your mnemonic is creating an extending private key for deterministic wallets, which is different than a WIF Private Key. An extended private key can deterministicly generate millions of private keys, so that you can regenerate all those same addresses in the future as long as you have the extended private key or your mnemonic seed.

Example of extended private key:
xprv9s21ZrQH143K3S4Ab76xBk6gRfR2Z7Di2m1x75R8bLp6uETwpxB7A6KbbbEu4gPaEqSic6HCKBDAScGMpSHinsxJii7ao3EDWHDZixRp7g2

Here's a tool that can help show more of what's going on behind the scenes with a mnemonic https://iancoleman.io/bip39/


Source: https://www.theguardian.com/technology/2013/dec/09/recovering-stolen-bitcoin-sheep-marketplace-trading-digital-currency-money
I think it just means that some users discovered this address: 1Eg8WSxvfeZaKmqhNZrECTUb58x3y1AWYN and maybe few others involved in their past transactions to the darknet market. They tried to send small amounts to these addresses hoping they could track when its moved.


Multisig where one of the keys specifically is required?

No, but instead you can make a 3-of-4 multisig where you hold both keys A and B, then you give key C to a family member, and D to someone else(just as an example). This way you are certain that you are involved in all transactions. I presume this is the end result you are after?


Because BTC and BCC have the same address type, it this is an easy mistake to make. Try finding the mnemonic or seed used to restore your BCC wallet from bitcoin.com, and instead use it to generate the BTC version of your wallet. Not all wallets provide support for BTC and BCC; some online exchanges don't give users their mnemonic recovery and worse still, a lot of wallets implement BIP 39 mnemonic differently.

This is one of the problems with forks, having multiple chains causes confusion, and people lose their money.


If you want to run bitcoin node on an ubuntu machine, it is always recommend to build it from the source code itself. That way you can be almost 100% sure of its authenticity.
Start with:
sudo apt-get update
sudo apt-get install build-essential software-properties-common
sudo apt-add-repository ppa:bitcoin/bitcoin
sudo apt-get update
sudo apt-get install libssl-dev libboost-all-dev libdb4.8-dev libdb4.8++-dev libqt4-dev libminiupnpc-dev libtool libevent-dev automake autoconf pkg-config bsdmainutils
git clone https://github.com/bitcoin/bitcoin
cd bitcoin
./autogen.sh
./configure.ac
make
make install (optional)

After compiling process is completed:
cd src/
sudo cp ./bitcoind /usr/bin/
sudo cp ./bitcoin-cli /usr/bin/
mkdir ~/.bitcoin
nano ~/.bitcoin/bitcoin.conf

Add your RPC user and RPCpassword value in bitcoin.conf file, save, exit.
bitoind -daemon

Your node will start syncing in background.


How to let surplus go to fundraiser in ANYONECANPAY crowdfunding script?

No, I don’t think it can be achieved using SIGHASH_ALL | SIGHASH_ANYONECANPAY. Because there is always an output with a preset value, as you’ve mentioned, any surplus will be treated as the mining fee in this case.

However, I think it’s still achievable under a more complex design. Let’s take a close look at the problem. Since it’s crowdfunding, we can assume that,

The participants are willing to donate the money, and,
They want their money back if the crowdfunding fails, i.e., the cap is not reached.

The problem is, if crowdfunding with a cap of 10 BTC is reached, while in the end, it receives a total donation of 11 BTC, how can the fundraiser get the extra 1 BTC as well?

Applying SIGHASH_ALL | SIGHASH_ANYONECANPAY won’t help here, the extra 1 BTC will be treated as the transaction fee. Borrowing some ideas from the lightning network, I think a feasible solution can be achieved using Bitcoin Script. Here’s the draft,

Scenario

Crowdfunding with a cap of 10 BTC is initiated. If the cap is not reached in 60 days, the money is returned to the participants. Otherwise, all the money goes to the fundraiser.

Stage One - the participant sends money

The participant generates a secret, called it payment_secret, and hash it to produce payment_hash(for instance, using RIPEMD160).
The participant creates a transaction with an output, its locking script is specified as follows, in which, there are two possible paths to spend it,

If the payment_secret is presented, the money goes to the fundraiser.
Else, if 60 days passed, the money goes to the participant.

The script,

OP_IF
    # To the fundraiser if payment secret is supplied
    OP_HASH160 <RIPEMD160(payment_hash)> OP_EQUALVERIFY
    <fundraiser_pubkey> OP_CHECKSIG
OP_ELSE
    # To the participant after 60 days
    <60 days later> OP_CHECKLOCKTIMEVERIFY
    <participant_pubkey> OP_CHECKSIG
OP_ENDIF

where, the fundraiser can spend it using <fundraiser_sig> <payment_secret> 1, and the participant can spend it using <participant_sig> 0.

Stage Two - the fundraiser collects/returns the money

If the cap is reached, the fundraiser will ask all the participants to reveal the payment_secret to him/her. The fundraiser will be able to get all the money, even it’s beyond the cap. To spend the outputs, the fundraiser use <fundraiser_sig> <payment_secret> 1 to unlock them.
If the cap is not reached, i.e., the 60-day time limit has reached, all the participants can now take their money back, using <participant_sig> 0 to unlock them.

So the surplus problem is solved, but this approach has many downsides,

There are too many transactions, especially comparing to the SIGHASH_ALL | SIGHASH_ANYONECANPAY approach, although it may be optimized.
The participants need to know how much money has been raised. This requires the fundraiser collecting all the transactions and show them to all the participants, which might require a centralized service, e.g., a website.


Where is the number of Bitcoins limit specified?

Every 210000 blocks, the reward for mining that block halves. It started out at 50BTC and now it's at 25BTC. Eventually it'll get to zero and no more bitcoins will be made.


Is there a market for converting my foreign currency and coin into bitcoins?

I think that perhaps you might misunderstand what bitcoin is. If you're looking for a way to sell your physical coins for bitcoin, there are ways to do that. Perhaps bitcoin-otc.com.

If however, you're looking for some way to virtually/digitally trade your physical coins then bitcoin won't help. Depending on what you're actually trying to do, Ripple.com may be the closest digital currency system to help you, see this topic on bitcointalk.org about how one person is leveraging his stash of pre-1964 US silver dimes on Ripple.


Your issue is trying to run ATI and Nvidia video drivers at the same time.

Many people mine on Linux LiveUSB.

This would be different if
a second GPU was so that you could get both of them to mine litecoin at the same time.In that case you would want your GTX680 not only mine but also display, where your other ATI card would do nothing but mining.

This I haven't tried personally but people have using plug and play

The system begins with the graphic card in the PCI-E closest to the CPU, all drivers were installed for Nvidia first

Put 7950 in the machine

Windows will ask to restart the system, I guess to figure out that it's had a hardware change, so restart

Install AMD drivers

For Windows to see the card, plug it into another monitor. Another way is too use a dummy plug: http://www.overclock.net/t/384733/the-30-second-dummy-plug


cpuminer: Running two nodes -The requested URL returned error: 500 Internal Server Error, json_rpc_call failed, retry after 30 seconds

Because new blocks are not generated few days, I got this error.
To solve this I generate a new block using the bitcoin cli:
./bitcoin-cli --datadir=<dir_to_wallet> generatetoaddress 1 <wallet_address>


Yea they can still access your wallet.

When the scammer created the wallet, they will have written down the mnemonic seed phrase for the wallet. With this seed phrase, they can recreate your wallet using some other software, since the seed phrase will allow them to derive all of the same addresses. They do not need the password to do this, and changing the password will not stop them either.

Think of it like this: you have a secret (the seed phrase) hidden in a box, and your password is the lock on the box that protects that secret. If the scammer steals the secret before you lock the box, they won’t need your password. They already have the secret!

So, the best thing to do is just never use that wallet (or seed phrase) again, and stop talking with the scammer.


They are paid nothing. An orphan block is wasted time and energy. A miner must put some effort into maintaining good connectivity to all the other nodes to avoid wasting money.


'Create a new receiving address' is greyed out, why?

This issue is reported in https://github.com/bitcoin-core/gui/issues/105 and fixed in https://github.com/bitcoin/bitcoin/pull/20230


Which file is the source codes of regtest net located?

Because regtest is supposed to be test network, it has to be pretty similar to mainnet. Thus there really isn't separate code for regtest only, most of the code is shared between the two networks. The differences are really only defined by a few parameter changes which can be found in chainparams.cpp.


How do I use the new GPG signing feature with my Trezor?

GPG Keys
"TREZOR can now securely generate GPG keys for signing of emails or documents (using the NIST256P1 and Ed25519 curves). Currently, this update does not allow for GPG decryption, a feature planned for next firmware update. For more information check out the great TREZOR Agent by Roman Zeyde."

https://medium.com/@satoshilabs/trezor-firmware-1-3-6-20a7df6e692#.9nmckr4yh

Complete instructions can be found here:

https://github.com/romanz/trezor-agent/blob/master/README-GPG.md

Generate a new GPG identity:

$ trezor-gpg create | gpg2 --import              # use the TREZOR to confirm signing the primary key

gpg: key 5E4D684D: public key "John Doe " imported

gpg: Total number processed: 1

gpg:               imported: 1

$ gpg2 --edit "${TREZOR_GPG_USER_ID}" trust      # set this key to ultimate trust (option #5)

$ gpg2 -k

/home/roman/.gnupg/pubring.kbx

pub   nistp256/5E4D684D 2016-06-17 [SC]
uid         [ultimate] John Doe
sub   nistp256/A31D9E25 2016-06-17 [E]

Sign and verify GPG messages:

$ echo "Hello World!" | gpg2 --sign | gpg2 --verify

gpg: Signature made Fri 17 Jun 2016 08:55:13 PM IDT using ECDSA key ID 5E4D684D

gpg: Good signature from "Roman Zeyde " [ultimate]"


Is it possible to create private multi-signature transactions?

Currently Private multisignature transactions are not supported. However, multisignature transactions are possible without the privacy.
It is possible to do a private Zcash spend to yourself, then do a globally transparent transaction (which could be a multi-signature transaction), and then the new holder of the funds (possibly you or possibly someone else) does another private Zcash spend to themselves.


tldr: specify a directory not a file and have that folder contain a wallet.dat not a wallet1.dat.

Your error message said

 Warning: Skipping -wallet path that doesn't exist.
 Failed to load database path'E:\bitcoin\wallet1.dat'. Path does not exist.

However the help for the program says

-wallet=<path>
Specify wallet path to load at startup. Can be used multiple times to load multiple wallets. Path is to a directory containing wallet data and log files. If the path is not absolute, it is interpreted relative to <walletdir>. This only loads existing wallets and does not create new ones. For backwards compatibility this also accepts names of existing top-level data files in <walletdir>.

(My emphasis).
An example configuration file says
# Specify where to find wallet, lockfile and logs. If not present, those files
# will be created as new.
# wallet=</path/to/dir>

Your E:\bitcoin\wallet1.dat is a file not a directory
I can reproduce something similar by copying a valid wallet.dat to wallet1.data in a separate folder with no other Bitcoin files in it
C:> bitcoin-qt -wallet=c:\Users\ZZZ\Documents\wallet1.dat

So I think you could

rename wallet1.dat to wallet.dat
specify E:\bitcoin\ not E:\bitcoin\wallet1.dat.


BFT is short for Byzantine Fault Tolerance. Any algorithm that can tolerate Byzantine faults is called Byzantine fault tolerant.
Byzantine faults are faults that are malicious (lying, deliberatly delaying honest nodes, etc). So if you have an algorithm that can tolerate these faults, it is called a BFT (byzantine fault tolerant). But not just that, any BFT algorithm (PoW, PoS , PBFT) solves the byzantine general's problem with some assumptions.
PBFT was the first practical BFT algorithm that can be used.
BFT relates to PoW in that PoW is also a BFT algorithm, because the Bitcoin network can contain malicious nodes that cannot be trusted, nonetheless, we can solve the byzantine generals' problem by PoW.


I would disagree that it is hard to find open source solutions, there are three pieces of software that need to be combined to create a mining pool.

bitcoind (or litecoind etc)
Pool software (pushpool or stratum)
Web front end (SimpleCoin, mmcFE, MPOS)

I am unaware of any commercial out-of-the-box solutions at this time.


A friend of mine told me that The DAO pays dividends in Ether. I can't find this anywhere,

Ether is the default unit of exchange/value/etc in Ethereum.

  but assuming that it's true, how is this possible that it pays dividends if a person purchases The DAO through an exchange, but does not have an Ether address with that exchange?

The DAO tokens are an ethereum asset that can only exist on an ether address. When you buy DAO tokens from an exchange the latter will create an ether address to store your DAO tokens (or put your tokens in one of their existing ether addresses and just have an internal ledger to know who has how much DAO tokens). Remember, what you see on an exchange is not necessarily what exists on the blockchain.

Also note that unless the exchange has some kind of mechanism to allow you to vote for DAO proposals you won't be able to... and they will control your voting power. I would recommend moving the tokens off the exchange to an ether address that you control if you intend to take part on the proposal/voting process.


How to fetch the latest unspent transaction by an address using bitcoind?

Bitcoind does not index transactions for non-wallet addresses. If you wish to build this yourself, you will need to:

Enable txindex=1 in your bitcoin.conf
Rescan the chain
Set up blocknotify and then parse the chain block by block, building an index of which outputs have been spent, and which haven't, and which addresses are involved in each transaction

Then, when working with a specific address, you first query your database for all unspent outputs, and then can use getrawtransaction to get the unspent tx information (although, you could store enough information in your index to not need to make the getrawtransaction call).

Alternatively, you can run something such as ElectrumX or insight, which will do all of the above for you.


Yes!

Bitsquare.io is:

Decentralized – there is no single point of failure.
Safe – Bitsquare never holds your funds.
Instantly accessible – no need for approval from a central
authority.
Private -no one except trading partners exchange personally
identifying data.
Open – every aspect of the project is transparent.
Easy – we take usability seriously.

Many altcoins are supported:
https://bitsquare.io/faq/#altcoins

Here you can see the list of the currently supported altcoins:

“ETH”, “Ethereum”
“DAO”, “DAO”
“LTC”, “Litecoin”
“XMR”, “Monero”
“NMC”, “Namecoin”
“DASH”, “Dash”
“SDC”, “ShadowCash”
“NBT”, “NuBits”
“NSR”, “NuShares”
“PPC”, “Peercoin”
“XPM”, “Primecoin”
“FAIR”, “FairCoin”
“SC”, “Siacoin”
“SJCX”, “StorjcoinX”
“GEMZ”, “Gemz”
“DOGE”, “Dogecoin”
“MKR”, “Maker”
“BLK”, “Blackcoin”
“FCT”, “Factom”
“NXT”, “Nxt”
“STEEM”, “STEEM”
“BTS”, “BitShares”
“XCP”, “Counterparty”
“XRP”, “Ripple”
“XEM”, “NEM”
“ANTI”, “Anti.cash”
“VPN”, “VPNCoin”
“MAID”, “MaidSafeCoin”
“YBC”, “YbCoin”
“CLOAK”, “CloakCoin”
“EGC”, “EverGreenCoin”
“VRC”, “VeriCoin”
“ESP”, “Espers”
“XVG”, “Verge”
“MYR”, “Myriadcoin”
“MXT”, “MarteXcoin”
“GRS”, “Groestlcoin”
“IOC”, “I/O Coin”
“SIB”, “Sibcoin”
“CRBIT”, “Creditbit”
“BIGUP”, “BigUp”
“XPTX”, “PlatinumBar”
“JBS”, “Jumbucks”
“PINK”, “Pinkcoin”
“OK”, “OKCash”
“GRC”, “Gridcoin”
“MOIN”, “Moin”
“SLR”, “SolarCoin”
“SHIFT”, “Shift”
“ERC”, “Europecoin”
“POST”, “PostCoin”


Is "previousblockhash" always returned from getblock RPC calls?

It will only ever not be present for the genesis block.

A block is not added to the block index until all its ancestors are in there too.

The block index is conceptually a tree: every block can have multiple decendents but only one ancestor. A reorganization is switching from one branch of the tree to another, and does not affect this.

Orphan blocks (in the meaning of blocks without known parent) don't exist anymore since Bitcoin Core 0.10 (we only download blocks after validating their headers, so the parent is never unknown), and even before that, orphan blocks were just stored in a queue in memory and not actually added to the index until their parents were found.


What does "Nonstandard output" mean on Tradeblock transaction page?

A bitcoin address that starts with bc1 is a bech32 address. It is possible that Tradblock hasn't been updated to cater for this type of address.

Other Blockchain explorers show the transaction as confirmed.


What is correct way to count LN node stats

I would approach this problem a little bit differently as counting in general is pretty difficult and the assumption of being an average node is pretty strong (not to say as I lay down below probably wrong) My approach however uses also a strong (and also probably wrong) assumption though I think it is not as strong / wrong as yours.

In my video in which I lay out the math for optimizing routing fees / earnings on the lightning network I start with a probability distribution to derive an expectation value for my routing fees that I want to optimize to gain maximum routing fees.

Instead of assuming your node is average I would ask about the likelihood of being on a path of a transaction between two arbitrary nodes? As I lay down in the video this boils down to the betweeness centrality of your node on the fee graph of the lightning network. The fee graph is the network you get when adding the routing fees as edgeweights (it is a little tricky as they dynamically depend on the payment amoun. You could start with just using the basefee). Generally your centrality raises with you lowering  your fees and maintaining more channels. In your case after computing your centrality you would divide the number of settled routing attempts by the centrality of your node to get an estimate of the overall payments made by the network.

As a datascientist I would say that even your data points (n=13 settled routing attempts) are statistically probably not sufficient. However larger nodes could probably use their data to make a pretty good guess.

Also as a disclaimer I should say that my result with the betweeness centrality depends on the relativly strong assumptions that the distribution of who pays whom is uniform so it would be equally likely that you pay any other node. This seems to be another very strong assumption but it is extremely hard to get a better a priori distribution for it. If it was available it could easily be weighted into the formula of the betweeness centrality. Also I assumed that payments all have the same amount to compute the betweeness centrality. This is also wrong but could also be modelled to the centrality measure if the amount distribution was known.


Inflation is newly mined coins added to circulating supply. When block rewards become zero and transaction fees are the only incentives for miners, there won't be any new coins added to circulating supply.
According to https://www.viewbase.com/inflation (In last 24 hours):
1031 BTC mined
Circulating Supply of Bitcoin is 18,504,668 BTC
% of newly mined coins(24h) is 0.006%
Annualized inflation rate is 2.03%


What is the minimum transaction fee used for?

Under Options of the most recent release, v0.7.1, reads:

  Optional transaction fee per kB that helps make sure your transactions
  are processed quickly. Most transactions are 1kB.  Fee 0.01
  recommended.

  Pay transaction fee: 0.00000000 BTC

What that field does is always add at least N BTC fee to every transaction.

When sending a transaction, the Bitcoin.org client will do a computation and insist on a fee to be paid if it determines the transaction will not be processed promptly unless a fee is paid.

Not all transactions require a fee.  If the amount of the payment is not small or the coins are not newly received (or both), then you can likely send a transaction using the Bitcoin-Qt client without paying a fee.

But there's always a chance that without paying a fee that your transaction will not be processed in a timely manner, as it is up to the miner or pool operator whether or not to include your transaction when mining.

So some people will use this optional fee field to make it so that every transaction goes out with a fee and thus no transactions sent will be delayed for the reason that no fee had been paid.

So do you have to pay a fee?   The Bitcoin.org client will generally tell you when you do need to pay a fee and when it does, then yes -- you must pay it or use some other client that doesn't perform this check.   But if it doesn't tell you to pay a fee, then you don't need to pay a fee but your transaction could still end up being delayed as a result.


You are correct, and this is possible.

To summarise the wiki info on wallets, you can backup the wallet in any form you like in order to preserve the key pairs, transaction history and other useful information. The wallet may become badly out of sync but the backup is still fundamentally usable.

As wallets are often implementation-specific and needn't be distributed in the same handy fashion as Bitcoin addresses, your wallet.dat can be fairly large. The Base64 size of your wallet printout will be 4/3rds of the normal wallet size in bytes.

Six point font is smallest reliable size for most OCR applications. If I assume you are using the A4 standard, an single A4 page of 6pt monospace font can contain approximately 20,000 characters or 15 kilobytes of Base64 data. Duplex would make that 30KB per page.

Alternately you could use Version-40 QR codes, the information density per page could be several times higher. Finding an off-the-shelf open source tool for version-40 QRs could be hard, so you would be relying on third-party software; conflicting your question requirement.

When printing to paper instead of plastic, consider flame retardant paper treated with a safe insecticide to reduce the possibility of losing the key to insects or mild fire. Putting the printed key inside a black envelope inside a tamper-evident bag would also be a good idea.


ASIC resistant PoW mechanism that generates new hash functions. How does that work?

Even though i'm a beginner in everything that concerns cryptocurrencies, please let me propose a guess, that others more prepared will correct. The idea is that an ASIC is a very specialized piece of hardware, dedicated to a single algorithm. If you keep changing the algorithm, there will be no way to create an ASIC that will mimick it; to implement such an algorithm, you'd have to use a piece of hardware so generalized that it would have to be a CPU.


What is the age of the youngest known Bitcoin developer?

https://github.com/whitj00

Whit Jackson, 15 is the youngest I can find. Github does not list the ages of PR authors:)

http://www.coindesk.com/15-year-old-developer-ethereum-whit-jackson/

edit: I am not sure of his exact birthday. He may have been 14 when submitting this PR for bitcoin.org:

https://github.com/whitj00/bitcoin.org/commit/b3ef809c7c63c9ededa4f4ad40ef5ff314434fe8


Setting up wallet on new machine with 12 word passphrase - next button greyed out

You can see this FAQ entry regarding this problem. It covers various possibilities.


What is the new segwit network option on binance and how does it work?

On 2020-12-24, Binance announced support for deposits to native segwit addresses.
Segregated witness ("segwit") refers to a soft fork that activated a series of Bitcoin improvement proposals (BIPs) in 2017. Among other things, segwit introduced two new standard output types, Pay to Witness Public Key Hash (P2WPKH) and Pay to Witness Script Hash (P2WSH). These native segwit outputs are more blockweight efficient than prior equivalent output formats, but wallets had to be updated to create them.
After three years, receiving payments to native segwit addresses is considered best practice, and almost all wallets and services are able to send to native segwit addresses.


Can a bitcoin wallet be restored from the files on a drive?

If you used a wallet 8 years ago, you wouldn't have a backup seed phrase (BIP39/44 weren't created until 2013/14). So I have a feeling your timeline is off, or you never had a seed phrase in the first place. But anyways

Without additional info about what wallet you were using:

Generally, you'll want to find a 'wallet.dat' file (or similar), as it will contain the private keys to spend your coins. You will need to either find software that can read the wallet file, or find a way to extract the private keys from the file, and then import them into some wallet software. Private keys are not wallet-specific, but perhaps the wallet file could be. Without more info, it is hard to give specific advice.

Note: Considering the access to your device that the specialists performing the data recovery will have, you may want to consider the possibility of them finding the wallet files themselves. I don't have specific recommendations on how to approach that situation, but it is something to keep in mind.


Why blockchain.info pays network fees by themselves

The fees are about 1 cent per transaction - a small price to pay for attracting customers who may later use their paid services.

Offering a service for free to expose a product with paid premium features is a popular online monetization model, also known as "Freemium".


What stops miners/nodes lying about what time a block was mined?

A timestamp is accepted as valid if it is greater than the median timestamp of previous 11 blocks, and less than the network-adjusted time + 2 hours. "Network-adjusted time" is the median of the timestamps returned by all nodes connected to you.
Whenever a node connects to another node, it gets a UTC timestamp from it, and stores its offset from node-local UTC. The network-adjusted time is then the node-local UTC plus the median offset from all connected nodes. Network time is never adjusted more than 70 minutes from local system time, however.

http://en.bitcoin.it/wiki/Block_timestamp

So, if you want your block accepted by other nodes, you won't mess with anything close to deviating from the current time by two hours.
But the protocol doesn't care how many blocks are being mined, it only will use those durations of the past 2,016 blocks to adjust difficulty when that periodic event occurs.


What does is mean to have input from multiple wallet addresses?

Are each of the wallets mentioned on the left hand side here always from the same person (ie. perhaps change wallets)?
Or, is this transaction taking inputs from multiple (unrelated) people/wallets?

It could be either. A single user's wallet might consume many UTXOs when crafting a transaction, but it is also possible for two (or more) people to supply inputs to a transaction, and they can do so without having to trust one another. So a transaction could have many potential participants, on the input side, and output side.
See:

Common input ownership heuristic info: 1, 2.
Coinjoin
BIP 174 - partially signed bitcoin transactions - Full BIP 174 text
In depth info: Bitcoin Privacy Wiki


Private Brain Key Generation and Public Address Not Matching Java

As bitaddress.org BrainWallet says in its display

Private Key (Wallet Import Format):
5KV1o7tRK8pNqrPNYyi38nrik9r2Y85sjdgFDttnDiT1uZrQ1fj

Wallet Import Format is the usual base58 armoring applied to the privatekey value with 'version' 0x80.
See https://en.bitcoin.it/wiki/Wallet_import_format or in more detail https://en.bitcoin.it/wiki/Base58Check_encoding .
This is basically a duplicate of Is there a way to generate a brain wallet from the command line or console? although that uses bash+dc rather than Java.

Not tested, but it looks to me like VersionChecksummedBytes(0x80,bytes).toBase58() does this.


Neither.  The client chooses the best fit of coins for your spending.  This is known as the knapsack problem.

The coins chosen will be the ones that yield the lowest amount of change, with exceptions for very recent (unconfirmed or newly confirmed) coins.  Even when there are multiple solutions that yield the same amount of change, it will not necessarily choose an older coin versus a newer coin.

Here's an answer to another question that gives more details on this:

https://bitcoin.stackexchange.com/a/1078/153


Does blockchain.info show balances for addresses that are in cold storage?

Yes.

  ... is there any way for me in another country to confirm that what my colleague views is actually accurate and correct?

Since they use Bitcoin Core, yes, there is a way to verify that they hold the addresses that they claim. Have them sign a message with each address that they claim to have the holdings on, using Bitcoin Core you can verify that they indeed have those addresses and check them on blockchain.info to find the current balance. This feature has been in Bitcoin Core for a long time.

Only works in Bitcoin Core currently for addresses starting with a '1' (not Segwit addresses starting with a '3' and not Bech32 addresses starting with 'bc1' - the developers are aware of this and I will remind them shortly.)

In Bitcoin Core, your transaction opposite goes to File -> Sign Message and signs any message with one of the holding addresses. Copy the message, address and signature and send to you via probably plain text format email is the easiest. Repeat for each additional address holding the balance of BTC that they are offering to sell.

In Bitcoin Core, you go to File -> Verify Message and key the details provided EXACTLY - spaces, new lines and all characters must be an EXACT match. Click on verify and voilà.

I prefer the form of signed message as follows (don't key the top and bottom bar rows for the message, just the contents and you can check this yourself, the bottom row is the signature). I like to key the address used for verifying as a part of the message but that is not strictly necessary:

------------------------------
Something that I want to sign.

bitcoin:1PMUf9aaQ41M4bgVbCAPVwAeuKvj8CwxJg
------------------------------
Signture:
IGaXlQNRHHM6ferJ+Ocr3cN9dRJhIWxo+n9PGwgg1uPdOLVYIeCuaccEzDygVgYPJMXqmQeSaLaZVoG6FMHPJkg=

This contains all of the compact information necessary to verify the message.

Example of verified message:


You are computing just the P2SH address for the segwit script. However it is not just P2SH, it is a Segwit script wrapped inside of a P2SH. You actually have to first take the witnessScript (the multisig script or segwit redeemScript) and make a P2WSH output script with it. Then this script becomes the redeemScript for the P2SH script.

So given

5221021e6617e06bb90f621c3800e8c37ab081a445ae5527f6c5f68a022e7133f9b5fe2103bea1a8ce6369435bb74ff1584a136a7efeebfe4bc320b4d59113c92acd869f38210280631b27700baf7d472483fadfe1c4a7340a458f28bf6bae5d3234312d684c6553ae

as the witnessScript, you produce

002044c55c1da36a576217259c3bc21b0c3943f7eb3ff4e3c381d9fd3502434b9e87

as the redeemScript. This is a P2WSH output script. This is then hashed to create the hash in the P2SH script:

a914771962306e72e479245d48e879dd2a1862225b4c87

which has an address of

3CYkk3x1XUvdXCdHtRFdjMjp17PuJ8eR8z


As far as I know the option is off by default in the new versions. To make sure you can add a line

gen=0

to your bitcoin.conf file.


How does Lightning transaction revocation work?

When you open a lightning channel, you will receive from the other person their revocation_basepoint, and for each commitment transaction, you will send to the other person a per_commitment_point. The revocation_basepoint has a revocation_basepoint_secret which is a secret key that the other person keeps to themselves. The per_commitment_point has a per_commitment_secret which you keep to yourself (for now)

When you create a commitment, you use the the other person's revocation_basepoint and your per_commitment_point to generate a public key, the revocation_key. This key is then used in a witness script which looks like this:

OP_IF
  <revocation_key>
OP_ELSE
 `to_self_delay`
  OP_CSV
  OP_DROP
  <local_delayedkey>
OP_ENDIF
OP_CHECKSIG

This script is used in the to_local output - the the output that will pay you (after the delay) if you have to broadcast this commitment transaction. The other person has a similar to_local output in their commitment transaction.

When you go to make another commitment, you will want to revoke this previous commitment. To do so, you will send to the other person the per_commitment_secret that you used for this commitment. They can use that per_commitment_secret and their own revocation_basepoint_secret to derive the private key for the revocation_key.

If you were to broadcast this now-revoked commitment, the other person now has the information necessary to derive the private key for the revocation_key. They can then use that private key to sign a transaction which spends your to_local output thereby taking your coins and penalizing you for broadcasting a revoked commitment. Since you do not have their revocation_basepoint_secret, you cannot derive the revocation private key and thus must wait for the delay before you can spend the funds.

The details for the lightning specification are available here: https://github.com/lightningnetwork/lightning-rfc/. They are a little hard to read though but do explain in detail how everything in lightning is supposed to work. The spec is still being worked on so some of the things there may change.


where can i do a testnet Lightning Network Reverse Submarine Swap?

you can try sideshift.ai or zigzag.io the first one supports testnet but is still invoite only. For zigzag.io I think this service is only offered on mainnet.


Which branch of bitcoinj should I sync to?

https://github.com/bitcoinj/bitcoinj/issues/1336

  Just ran into this issue and spent a while debugging it (on latest release, 0.14.5). I added rpcserialversion=0 and that fixed the issue, so it's easy enough to work around. If bitcoinj isn't planning to add support for the new format, it might be nice for bitcoinj to realize it is parsing the new format, and throw a more relevant error message, something like "New rpc serial format not supported, see #1336".


What coin to mine to maximise volume of return

Have a look at https://eth.nanopool.org/

Their default payout is 0.2 ETH but you can configure your account to payout as low as as 0.05 ETH

I'm mining at 28 mh/s on an R9 290 and that takes me about 4 days before I see a payout.


What countries are already represented in the Bitcoin network?

If you are interested in Bitcoin nodes, This website seems to keep a count of how many of them are connected by country:

http://bitcoinstatus.rowit.co.uk

Or, if you want more graphical (and cooler looking) data, just look at this globe:

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

It shows you what amount of Bitcoin nodes are connected in each geographical area not only at a country level, but going down to what I believe is a city level.


A Proof of Concept for P2P Bitcoin Exchange?

You might want to check NashX project. It's anonymous online Person-to-Person cash exchange that uses Mutually assured destruction to create Nash equilibrium for traders.

http://nashx.com/


Second, Third, Etc Confirmations taking a long time, why?

I thought confirmations after the 1st were every time a new block was added to the chain.

Yes, as long as the block being added is 'on top' of the most recent block.

  So my question is, why would this transaction take so long for a second confirmation?

Blocks generally come every ten minutes, but that's not guaranteed. Sometimes they come seconds apart, sometimes it takes an hour.

  Bonus Question: Is there some way for me to see how many blocks have been added to the blockchain since the block my transaction is in?

Yes, that's what the number of confirmations represents.


Yes, this should be possible.

A "stealth" transaction still sends the colored coin to a specific ordinary address, and anyone can see on the block chain that this address owns that coin.

The only difference with stealth transactions is that this ordinary address, rather than being generated from a private key by the recipient in the usual way, is generated by the sender using the recipient's stealth address.  This is done in such a way that the recipient, using additional data included in the transaction, can compute the private key.  They can then redeem the transaction like any other ordinary transaction.

In this writeup in the example in Sections 9.1-9.2, the "ordinary address" in question is 1BjqrpQqr4tY5YPQkL8aG7NGkFbTbiuVu.

See also my answer here.


How is data in a blockchain stored? Structure of block and blockchain

How is data in a blockchain stored

So far as I know, the Bitcoin specifications do not mandate any particular structures for storing the Bitcoin transaction-journal (blockchain) in persistent storage (e.g. Hard disk).
Any Bitcoin node is free to store the transaction-journal in whatever form is convenient. For example it might be decomposed as a set of tables in third-normal form in a relational database in "uncooked" storage outside any filesystem. The node might include in the stored data a complex set of indices for fast retrieval of certain types of data (e.g. Bitcoin-addresses).
Bitcoin Core stores the transaction-journal in groups of consecutive blocks in a series of large files whose format I believe closely matches the form used in the Bitcoin network protocols. But there is no prohibition on other software products doing something quite different.

Are blockchains just ArrayLists

That is just one way of representing the data. Note that the ArrayList is a feature of specific programming languages. It may not exist in some languages and quite different data structures may be more appropriate in that case.
The data itself needs to keep track of blocks and those blocks contain data that references data within other blocks. Hence the name. But there are many different ways of implementing these ideas which could all work in a Bitcoin node.

maybe they are stored in some files that are distributed among a P2P network?

Normally, in my field of work, the term "distributed" implies that not all nodes hold all the data. It implies that there is some planned and coordinated division of data among nodes so that specific nodes are designated to be responsible for specific subsets. This isn't really a fundamental design feature of Bitcoin.
I believe that initially Bitcoin used a model that I would more strongly associate with the word "replicated" than "distributed". Initially all nodes each had a full and complete copy of the entire data-set. There was no system to coordinate the intentional distribution of subsets of data among cooperating storage nodes.
Currently nodes, even full nodes, can discard blocks that are no longer of interest to them. This means that many nodes do not contain a complete set of data. Importantly however, any distribution of the data between nodes is essentially unplanned and uncoordinated.
You could argue that there is distribution of data between SPV clients and the servers they rely on for transaction-journal data. However I'm moderately sure this isn't really the sort of distribution of data that database engineers generally mean when they use the term "distributed".

See also descriptions of Bitcoin Core's storage format in these answers:

What is the database for?
What are the keys used in the blockchain levelDB


Why isn't Replace by fee default for all transactions?

It's been over six years and I've done entirely too little research to state the below with confidence, but what I can roughly piece together quickly between cursory research and from what I remember:
There was a big debate about the merits of RBF since at least 2013, when Peter Todd and John Dillon provided a Full RBF patch. Gavin Andresen described it as anti-social and among others pushed for a First-seen-safe RBF variant which would require a replacement transaction to include all outputs of the replaced transaction. It was pointed out that FSS RBF would only protect transactions that only spent confirmed inputs (since transactions that spent unconfirmed inputs could be invalidated by replacing the parent) and that each replacement would add another change output to the transaction adding UTXO bloat.
Regardless, the full RBF proposal saw strong push-back, especially by a number of services built around zero confirmation payments (IIRC e.g. Satoshi Dice, BitPay). The 2015 compromise was then to require transactions to opt-in to Full RBF and to require that replacements pay not only more fees than the replaced transactions but more than their entire descendant tree to curb DOS attacks. Standard transactions were left unchanged in their behavior.
Obviously, RBF is just a mempool policy and cannot be enforced, so nothing would prevent nodes (or even miners) from individually switching to running a Full RBF mempool policy.


Changing wallet password using double quotation marks turn out to be mysterious (Qtum Core)

This is really a Bash question, but I'll bite.

Bash (or any UNIX shell) will treat " symbols as begin and end of a literal. Inside "", spaces and special characters inside that would otherwise have a special meaning are permitted.

One of the permitted special characters inside is the newline. That's exactly what's happening here. Your "test"" plus " on the next line is seen as "test" plus a newline between quotation marks. As a result, your new password is test plus a newline character.

If you would want test" as your password, one way would be to use single quotes instead of double quotes. One of the characters permitted inside single quotes is... the double quote character.

So you could use

walletpassphrasechange 'test' 'test"'


Bitcoin has no "inherent" value; it is a currency.  Value is therefore subjective, and can only be discovered when you attempt to convert a bitcoin into some other currency or good.

In a free, unmanipulated market, the "price" of a currency operates by seeking equilibrium between buyers and sellers.  If there are more sellers than buyers, the price will drop.  Conversely, if there are more buyers than sellers, the price will rise.

If demand for bitcoin drops radically, and the price declines in the same manner, it may become extremely difficult to "get out" of bitcoin since transactions rely on being "confirmed" by mining nodes.  Mining nodes only perform mining activities when the financial incentive is bigger than the cost of performing that mining.  You can see the current "price" of a transaction in various places, including https://bitcoinfees.earn.com/ and https://statoshi.info/dashboard/db/fee-estimates among others.  The function of price-for-confirmation is a combination of how much you, and others, are willing to pay for confirmation, how many confirmations are in the queue, and how the price of bitcoin compared to the input costs of running mining, such as electricity and the cost of mining rigs.  So, if the price is declining, and many people sell causing a lot of transactions, you will need to spend more than everyone else on transaction fees; this could very quickly cause an escalation of fees, and could be considered one of the bearish cases for this cryptocurrency.  Do not put more into bitcoin than you can stand to lose, which is of course good advice for any risk.


two people with same PUBLIC address, how will people/network know how to deliver bitcoin

The network can't tell the difference.  In the astronomically unlikely event that two different people have private keys whose public keys hash to the same public address, then both of them are able to spend any coins sent to that address, first-come-first-served.

To illustrate how unlikely this is: suppose every satoshi of every bitcoin ever to be generated was sent to its own unique private keys.  The probability that among those keys there could be two that would correspond to the same address is roughly one in 100 quintillion.

Of course the probability is only "astronomically unlikely" if the private keys are truly randomly generated.  If they are not, then there can be better chance of someone else being able to guess the private key.  Anyone who does so can spend coins sent to that address.  That was what happened with this vulnerability.

A fun activity, analogous to "leave a dollar bill on the street and see who picks it up", is to make yourself a private key that is a very small integer.  Then send some trivial sum of money to the corresponding address.  There seem to be a number of people watching such addresses so you can see who manages to grab it first (by spending it to a more secure address they control).


Bitcoin client which doesn't use wallet.dat?

This is not exactly what you're asking for, but might be helpful. Bitcoin v0.4 supports encrypting wallet.dat, so you cannot spend without entering the password. Basically you would do something like:

make a copy of wallet.dat
encrypt your copy with Bitcoin client v0.4 and set a long random password (one you will easily forget)

Voila, you have just created your read-only wallet. Because of 100 keypool you will even see some new transactions made with original unencrypted wallet.dat

You can download Bitcoin v0.4rc2 here.


The bitcoin protocol doesn't really support the concept of a transaction sender.

All you can come up with is an address owned by someone who previously controlled the transaction's outputs, which however might not actually be the sender (e.g. for e-wallets) and who may not actually intend to receive anything there in the first place.

Take some time to see a sample implementation written in C# (GetTransactionSenderAddress()).


Do you 'own' Bitcoins purchased via an exchange?

Most exchanges are centralized services, operating in the way you've mentioned. So yes, the exchange owns the bitcoins, so there is significant counterparty risk involved with storing your coins on an exchange.


Ripple times are seconds since 1/1/2000 00:00 UTC. You can add 946,684,800 to a Ripple time to convert it to a UNIX time. If you are writing code to convert from Ripple times to UNIX times, please do your math in a 64-bit variable, not a 32-bit one.


After continous monitoring I've determined it's someone spoofing (attempting to drive the price lower). The bid always starts out $3-$5 out from the current price and as it gets close to the bid it's offer changed a few dollars higher but is never allowed to meet the current price. Interesting.....


What happens when a request expires in Electrum, then I am paid?

Your wallet will receive the Bitcoin. Your wallet is still watching for transactions to that address and will be able to receive Bitcoin at that address at any point in time.
The expiration is only used as a hint to the sender if you give them the payment request or the Bitcoin URI. It is not part of the blockchain nor part of the address. So if you just gave the address, then the sender wouldn't even know that there is an expiration. The expiration is only used by the client software but is not a hard limit.


How to remove a transaction from the memory pool

Try the removeprunedfunds RPC command. It

  deletes the specified transaction from the wallet. … This will effect wallet balances.


What prevents DoS based on near-valid block timestamps?

I'm answering both questions at once. It's not uncommon for the network to split i.e. different nodes accepting different blocks as chain tip. In fact this happens from time to time as two or more blocks are found at the same time by different miners. This gets resolved when the next block is found on top one of the previous blocks. The longest chain is valid.

And a miner can't simply set the timestamp when broadcasting. The timestamp needs to be set before finding a valid nonce. Thus a miner is incentivised to mine with a valid timestamp. If the block doesn't get accepted by the network, the hashrate (and electricity) used isn't compensated.


Generally, CPU mining isn't worth the electricity consumes.  However, we will assume that you've got some adequately efficient cores.
If you are going to do CPU mining, you might have more luck using a scrypt based fork of bitcoin, such as tenebrix, litecoin, or fairbrix.
Because the effectiveness of a setup can vary, as well as the price of various cryptocurrencies, your best bet is to do your own experimentation:

For each coin:

Mine for an hour or so, and determine your average mining rate
Look up the current difficulty of that coin
Use something like the Bitcoin Mining Calculator to determine how much you stand to make
Convert it into $ per day or something similar

You would then compare the profitability of the various coins and choose which is best.

Alternatively, if you wish to assume that scrypt is best for your setup, and that your hashrate will be identical across different scrypt-based coins, you can use CoinWarz to determine the best coin to mine (currently Fastcoin, although they rate fastcoin as having bad stability, so you may wish to drop down to digitalcoin or novacoin if you feel like you need something a little more stable.)


Which cryptocurrencies are better suited to users with limited bandwidth?

Apart from a few cryptocurrencies, including Bitcoin, most of them have very low exchange rates. So although you will find many such virtual currencies, it won't be profitable either way. And mining does not require bandwidth as such, it's only the blockchain synchronization which would be slower with a lower bandwidth. Mining is achieved by your machine and not the bandwidth.

If it's only the knowledge you wish to gain, then you can use the bitcoin testnet to mine test bitcoins, however trading testnet coins is not an option.


If you are worried about physical security and using the above setup (using two wallets, one for savings and one for petty cash), one way to protect anonymity is to CoinJoin the coins when you move them from Savings -> Petty Cash.

In theory, CoinJoining makes it impossible to determine where the coins originated from. It

More information on CoinJoin: https://en.bitcoin.it/wiki/CoinJoin


how coin exchanges protect them self against stealing coins?

Remember that bitcoind is a reference implementation, but bitcoin itself is the abstraction of it.

In production environments not always you run the same software as in a desktop.

There are other bitcoin implementations that are meant for use in production systems at scale. One of them is called bcoin by the folks at purse.io and open sourced. And there are others more even.


Firstly, the 'engine' to keep civic decentralised is bitcoin itself. Its called PKI and anyone can generate as many private-public keypairs as required for free. These keypairs are already used for authentication in applications all around.

The simplest app one can think of is sign something and put it on the blockchain, just so someone knows you are alive. Civic is the app that does just that - helps you put data on blockchain and notifies any interested parties that your phone is still alive.

Secondly, there is no other part. Bitcoin is the 'engine', cypherpunks intended people to assemble the 'car' themselves. But in real-life some prefer to pay for the DIY instruction manual written in ELI5 manner or simply don't even know what they are buying.


If some client's actions do not correspond with the Bitcoin protocol in a disruptive manner (e.g. flooding with invalid messages) a ban counter is increased depending on the seriousness of the violation of the protocol. When the ban meter reaches some predefined value (can be set with the -banscore option in bitcoind, default is 100) connection to that client is interrupted for a day (that's the default at least, but again, this can be changed with the -bantime option).

The values used are arbitrary (e.g. 100). It all about relativity. I don't know exactly how much penalty you get for which violation, but this can be found in the source code. If someone feels the need to compile a list of the amount of penalty per violation, please edit this answer.


According to this, you need 4096 bytes to align to actually deduplicate (or rather, save space). If I'm reading correctly, that means you would need the same 4096 bytes to occur in the blockchain somewhere at which point you would save space.

Given that each block has all sorts of essentially random data (tx id's block id's, signatures, etc), I would think 4096 bytes aligning anywhere would be highly unlikely. Most likely, you wouldn't actually save any disk space.


Linking Bitcoin addresses based on a private key - is that possible

You are correct in thinking that there is only one private key for one public key (or rather that is one of the assumptions that ECDSA relies on). While technically it is possible for a Bitcoin address to have multiple public keys and therefore multiple private keys, this is extremely unlikely to occur as it requires a hash collision. Of course there are guaranteed to be addresses that have multiple public-private keypairs associated with them because there are more keypairs than addresses.

In practice, it is impossible for such a collision to occur so, for all intents and purposes, an address has only one public and private key. It is the same for BIP 32 HD wallets since the seed is used to generate the private keys for each address. There is no known mathematical relation between two child private keys so it is impossible to determine whether two public keys are derived from the same BIP 32 HD seed.

However, BIP 32 is not the only way to derive private keys as basically any string of 256 bits can be a private key. So people may be using other methods to generate their private keys, and those may have mathematical relationships between each other. So it is possible that this claim you have quoted refers to these other ways of generating private keys.

Alternatively this person is simply incorrect and doesn't understand cryptography, or they are trying to scam you.


Techniques or proposais to require transactions to be included in a block?

If the attacker has minority hashrate, I don't think this is much of a problem. If he excludes all transactions in his blocks but doesn't try to orphan other blocks, the worst thing that can happen is a x2 increase in the average time until first confirmation (no effect on subsequent confirmations). This is fairly minor.

If the attacker has majority hashrate, he can orphan all other blocks and exclude all transactions, and then transactions will never be confirmed. This is a problem and the main variant of the >50% attack. Possible solutions include modifying the branch selection mechanism to prefer blocks with more high-priority transactions - meaning that even with majority hashrate, if you try to deny transaction you're not guaranteed to beat the honest branch.

Incidentally, if the attacker has >40% hashrate, there is a technique to amplify his hashrate and get more than his fair share of blocks. So if, say, he has 49% hashrate and used this technique, he can get close to 100% of blocks, significantly delaying tx confirmation.


how do I transfer from watch only wallet to my other wallets

That's what "watch-only" means. You are only watching the balance and can't spend it. You've likely added only the address to the wallet—which anybody else could have done as well since the address is public information.

If the address is your own, check the wallet that you created the address with. That's the one that can spend it. To spend the coins, you have to have the private key.

If you actually don't have the private key, you don't have the ability to spend the coins. If nobody else has it either, the coins are lost.