What additional considerations are there for dual-funded payment channels?

The issue of waiting for signatures also holds true in the single funded channel.
Let us assume Alice wants to open a single funded channel. As long as she has not gotten signatures for the commitment transaction via commitment_signed message she cannot publish the funding tx.
In the dual funded case there need to be two rounds of signature exchanges (one for the input of the funding tx and one for the commitment tx) but from a risk perspective of an unresponsive peer this is not worse than the situation we already have in single funded channels.

The real difficulties emerge since in the case of dual funded channels it is not so clear who should pay the onchain fees and why (also there is some additional communication overhead (see below))? Remember in the case of single funded channels all fees are paid by the initiator in every case as it was the initiator who had the interest of opening the channel.

Let us look at dual funded channels: Some might argue that this is a service to the purchase inbound liquidity and there should be a service fee. This is discussed in this thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001631.html along this line goes the question and discussion of how to make sure that the channel is not closed again right away: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001532.html

In general there was a nice post on the ML about the initial dual funded protocol. I can't sum this up to quickly but I guess you will find some of the challanges in the thread: https://lists.linuxfoundation.org/pipermail/lightning-dev/2018-November/001682.html


To start bitcoind at startup on a system using systemd, use the service configuration provided in contrib/init/ from the root of the bitcoin-core repository.
You can then manage bitcoind as any other systemd service (and possibly have some other rely on it, such as a Lightning Network implementation's service).
systemctl start bitcoind
systemctl stop bitcoind
# This enables launching the service at startup
systemctl enable bitcoind


Are HD wallets, with multiple hierarchies, supported across all crypto-currencies?

As long as they utilize a form of public key cryptography, I think the answer is yes. My understanding is that BIP32 was meant to be a standard for Bitcoin, but not the only possible implementation of a hierarchy structure for deterministic key pair generation. The examples given in the standard are, however, specific to elliptic curve used by Bitcoin:

  we will assume the public key cryptography used in Bitcoin, namely
  elliptic curve cryptography using the field and curve parameters
  defined by secp256k1

This means that it would work for other types of public key cryptography, though you may have to tweak the generation functions for different size keys (other than 32 bit private keys and 33 bit compressed public keys). Of course the security of the arbitrary scheme depends on the design, but that wasn't what this question was asking.


I have a news feed from https://news.bitcoin.com/ . It sends me news articles in a pop-up window similar to Facebook. I'm assuming that they'll know as soon as the decision occurrs.
For the moment I'm in a watch and see, I'd like to buy more but at what price. The BTCs I now own were bought much lower. If the ETF decision is positive we may never see lower again, if negative or ambiguous who knows where the price will go. Down I suppose, in which case I'll buy more when it settles.


Understanding cryptocurrency exchange working

When users deposit cryptocurrency into an exchange, the exchange takes custody. The cryptocurrency is now the exchange's and the exchange adds a corresponding balance for the depositor to their books. The user specific address is only used to identify whom to credit the deposit to. After the deposit, there is no reason to keep track of the funds in the context of the user.

  So, now his actual balance at his public key would be 8 BTC.

Tracking all trades on the blockchain would be incredibly inefficient. Rather, the exchange updates the user's balance in their books to increase the ETH amount and decrease the BTC amount. Any balance changes of the user on the exchange are only tracked in the exchange's books until the user withdraws from the exchange. When they withdraw the exchange sends an on-chain transaction to the user and reduces the user's balance by a corresponding amount.


What is the most recent pushpool version and where to get it?

Since you tagged your question with litecoin, I believe that you are looking to serve a litecoin pool. For my needs https://github.com/ArtForz/pushpool
did the trick. It added scrypt support and allows you to rewrite the target difficulty (just remove "rpc.target.rewrite": true and replace it with "rpc.target.bits": 18 in the config).


How does MimbleWimble avoid transaction graph leaks?

Yes -- although "without amounts or scripts" gives a clearer idea of what the transaction graph will look like: every output is a uniformly random curvepoint. This story is actually quite a bit better than Bitcoin where there are "addresses" which are often public and often reused.

In general, finding a p2p layer that hides the original, unmerged transactions, seems difficult. Initially I had thought it would be possible for "passive merging" where nodes would just aggregate all the transactions that they saw, taking in unmerged transactions and outputting merged ones. This appears to be very fragile: consider three nodes which each have a transaction, say A, B and C. The first node publishes A, then the second and third latch onto it simultaneously, outputting AB and AC respectively, and now only one of B or C can be confirmed. Observe that this happens even without any adversarial behaviour, and happens even if merging is only done by some special set of "masternodes".

The problem ultimately comes down to the fact that with OWAS, conflicting merges (transactions with intersecting input sets where neither is a subset of the other) look identical to conflicting
 transactions (double-spends). So "unifying" AB and AC to get ABC, which is the desired network behaviour, is just as hard as "unifying" a double-spend. Which, to be clear, is "doesn't even make sense" levels of difficult.

It may be possible to have a p2p layer that does interactive merging somehow, which in Mimblewimble could be made much simpler than Coinjoin in Bitcoin, so that transaction creators have control over what other transactions their transaction gets merged with on the wire. Miners would then drop the signatures or whatever was needed to enforce interaction at the p2p layer and just merge what they got. This might be sufficient to stop the creation of accidental conflicts, but you then have to worry about adversarial behaviour.

It would be possible for users to directly communicate transactions to miners; for a given transaction they'd give a different version to every miner so that nobody but the miner who created a
block would be able to tell what the original transactions in the block were. Absent collusion this would erase a lot of the transaction graph from any specific adversary's view, although it would enforce miner centralization which I find very undesirable.


It is a moving sum, it sums up the volume for the last 24 hours of trade.
Bitcoin trading never closes, so the usual way of calculating volume as the sum of trades that happen between the open and close of the market doesn't apply.


With the Bittrex BTC-BCH pair how do I order enough BCH to exactly spend one BTC?

Thanks for adding another question with additional clarification.

Assuming the interface has stayed the same since May-July 2017 for Bittrex, there won't be a reliable way to accomplish this. This also occurs in other exchanges.

If i submit a trade and want to pay .002 BTC per 1 BCH, that's the upper LIMIT. You can't "force" it to buy BCH that high. It just won't buy anything at a cost greater than .002. In any normal scenario nor would anyone want to pay more than necessary to obtain the desired amount. Most systems work on a "this is what i want to buy, this is how much i'll pay for it". With an order book, if the system can buy it for you cheaper, it will. You are simply setting your upper limit. Thus it's called a "limit order". Limit trading is the most popular because the system will not pay more than what you've specified in reaching the amount of BCH you've specified. Going back to the example, if the system found some BCH for you at a price of .0019, it'll sell it to you for that price.

In every system i've used that has limit orders, there is always left over. It's almost impossible to get a 1:1 ratio. I have benefited greatly from sudden fall's in market price on big purchases because my orders were completing for far less. The same for the sell side. In a sudden shift up in price, i found myself getting more for my sales because people were paying more.

This does have an unintended consequence. You'll have change. Sometimes the change is so small it won't even display. I have about .. 15 currencies all showing zero in Kraken, but actually have a tiny fraction remaining because of this very reason. Can't create a sell order for such a small quantity. Not willing to pay the withdraw fee as the fee is exponentially higher than the tiny value.

I get that it can be annoying, there just isn't a desire to implement something that does a "give me only what i ask for even if it's not a benefit to me". Might even be illegal in the US to "inflate" the purchase price to a buyer just to make sure there is nothing left over.

In sum: There is no way to get the system to provide a 1:1 trade of exactly what you want to sell for the specified price. There is also no way to "calculate" the price unless the system sat still for an extended period with no volume. Anything you attempt to calculate on screen could already be made irrelevant in the back end via API or other traders.

The only other option for getting rid of an "exact value" would be to withdraw it and sell it elsewhere. Shapeshift would be a good example. There you can mess with the values to spend exactly 1 BTC, or enter 1 BTC and it will simply tell you how much BCH you'll get. It's not an order book with a system trying to match up trades.

Note: Basing this "Bittrex" specific information based on some Youtube video's of the exchange and this article: https://medium.com/@scozky/getting-started-with-trading-on-bittrex-55237f482ef5. The bulk of the knowledge was used to confirm that Bittrex uses a system that is almost exactly the same as every other "advanced" trading system (IE: Coinbase = simplistic. No limit prices. You get what they decide to give you) that implements usage of "limit orders".

EDIT: I missed the "fee" aspect here. You'll never "not have enough" The fee's are percentage based. Trade occur in small slices since the system is matching you as a buyer, up to someone else who is a seller, for equal to, or less than your limit. If you wanted to buy 1 BTC at .002 per BCH.. and it found someone that will sell 1 BCH for .002, they take their fee off THAT trade. The trade was worth 1 BCH. When they take 0.25% (assuming their zendesk post is accurate) you get 0.9975 BCH. They keep .0025 BCH as "the fee".

https://bittrex.zendesk.com/hc/en-us/articles/115003684371-BITTREX-SERVICE-FEES-AND-WITHDRAWAL-LIMITATIONS

Final Note: I'm over simplifying the limit system for Bittrex as this isn't part of the question.


Some times the network takes a bit longer to find a block but that does not seem to be the case right now, since there are plenty of blocks found in the last couple of hours?

Is your transaction already included in a block? If not it should be the fee that is on the lowish side.

It really depends on the size (in bytes) of your transaction.
You could check statoshi to estimate the fee for your transactions, depending on the amount of time you are willing to wait.


What if an intruder modify scriptSig to get the same hashMerkleRoot of a block?

I assume you mean scriptPubKey in the outputs of the coinbase transaction.

Assuming that, what you are describing is popularly known in cryptography as a pre-image attack. If you can find a 'collision' with fixed existing message (in your example that is the original coinbase transaction) in such a way that they both produce identical hashes then you have a pre-image attack. If you change the scriptPubKey in the output of coinbase transaction, assuming no 'collision' happens, it will change the txid and hence change the merkleroot, which would in turn change the block header hash.

SHA-256 algorithm outputs 32 bytes, which means there are a total of 2^256 (or 10^77 combination). SHA256 is a one way mathematical function, as a result  you will have to brute force your way to actually produce hash similar to the one before. Running that kind of brute force is not only computationally impossible, but also impossible due to the energy that it consumes (check this).


Getting keys from multibit to export for electrum

You need to export the private keys from Multibit in text format using the 'Export Private Keys' option.  You can then copy and paste the private key strings into your new wallet.


Holy war question in fact.

Yes, using online wallets means that you trust their developers. But the same situation is in standalone applications - you should trust their developers.

Many online wallets do not store your private keys. But it does not mean that they do not have an ability to steal/lose your funds


How to lookup the transaction fee for a particular transaction?

A transaction is an atomic unit. Either the whole thing confirms or the whole thing does not confirm. The transaction fee is the result of all inputs and outputs in concert, therefore it is a property of the whole transaction and not assignable to any single created output specifically. Even when there are multiple recipients, the whole construct is "a transaction".

When you create a transaction, you define a set inputs that will be consumed, and a set of outputs that will be created and at the disposal of your recipients. The free-floating remainder, i.e. the part of the inputs' value that was not assigned to any outputs can be claimed by the miner as a transaction fee.


Chain accepts parameter db, which can have multiple backends.
By default it will be stored in memory. So this tip is coming from memory.

If you want to store it to File(For example full node stores it in PREFIX/chain) you need to pass db with backend(ldb for example) and specify either prefix or location.

prefix stands for general directory where chain and wallet will be stored.
location specifies DB directly.

So if we wanted to store this db in /tmp/testnet-1/chain.ldb We could specify:

const chain = new Chain({
  network: 'main',
  db: 'leveldb',
  location: '/tmp/testnet-1/chain',
});

or

const chain = new Chain({
  network: 'main',
  db: 'leveldb',
  prefix: '/tmp/testnet-1'
});


Vanitygen works like this:

Generate a random 256-bit integer to use as an ECDSA private key
Compute the corresponding public key
Compute the hash of the public key to find the address
Check if it matches the requested pattern (1Mathias in your case)
If yes, halt and output the private key; if no, start over at step 1

Notice that there is no state saved in this process, so you lose nothing in stopping and starting as much as you want.  Each random private key has an equal probability of success; it doesn't matter how many you have already tried.

For a given number N of random private keys tried, one can compute the probability that (at least) one of them would succeed.  This is the "percent" number that Vanitygen reports - it's not a percent completion!  In the excerpt you show, it says that it has tried 2888131518 keys, and that mathematically, trying 2888131518 keys has a 10.2% chance of finding one that works.  It also says that in 18.5 hours, it will have tried enough keys that the chance of success is 50%.  This does not scale linearly!  If you are unlucky and don't find a key for 37 hours, it won't say 100%; it will say 75%.

As an analogy, suppose you have an ordinary 6-sided die, and you want to roll it repeatedly until you get a 6.  Your chances of succeeding with one roll are 1/6 (16.6%); your chances of succeeding within 10 rolls are 83%; your chances of succeeding within 100 rolls are 99.9999987%.  But this number never gets to 100%; there is no number of rolls that will guarantee success.  There is always some chance that, of all the rolls you made, none of them came up 6.

So the "percent" number reported by Vanitygen is never going to reach (much less exceed) 100%.  It is simply intended to give you an estimate of how long the process might take, but since it is random, there can be no guarantees.  If it gets very close to 100%, all you know is that you have been very unlucky; but your odds of success with each new key are exactly the same as they always were.


Can the sender of a MtGox code see which account the code is redeemed to?

Nope.  Or, at least, unless you are law enforcement and have a subpoena.

Or, unless you redeemed it yourself (which would list in your deposit history).

You can tell if it has been redeemed by redeeming it yourself and seeing if it had funds, but that's about it.


Bitcoin transaction 0/3 confirmation. How do i check on this?

If you want to view the details of the transaction, you can search for it (using the transaction id or sending or receiving address) on a block explorer website such as blockchain.info.

Once you have an understanding of the fee paid, in satoshi's per byte, you can see where that fits in the backlog of transactions, using a site that analyses unconfirmed transactions and their fees, like Johoe's Mempool Statistics

Further details on what to do are available on the canonical question about unconfirmed transactions.


How thoroughly has Segregated Witness been tested?

I'd suggest starting here: https://bitcoincore.org/en/2015/12/23/capacity-increases-faq/. There's also a SegWit adoption page on the site somewhere.

Finally, this article has some details on recent testing: http://www.coindesk.com/bitcoin-scaling-segregated-witness-expected-launch/


Why doesn't BTC depreciate in value as its supply increases?

The popular intuition is typically correct in well-saturated markets, but Bitcoin is not yet a well-saturated market. Though the supply of Bitcoin is currently increasing the demand is increasing dramatically faster. This is because we are during the initial adoption curve of a new technology and new demand is created as individuals discover the new tech.

In short, there is absolutely some downward pressure on Bitcoin's price exerted by the inflating supply, but it has been completely overwhelmed by upward pressure from new adoption.


How many Bitcoin addresses can Bitcoin Core create?

As many as you want. While the number of addresses possible is finite, it is essentially infinite as the number of possible addresses is extremely massive. There are 2^160 possible P2PKH addresses (1... addresses) and 2^160 P2SH addresses (3... addresses)

  Is there a limit to number of addresses Bitcoin core can crate?

No.

  Can I use one receiving address for multiple transactions?

Yes but that is not recommended. There are enough possible addresses that you can and should always use new addresses.


Delete a specific private key from an Electrum 3.3.8 wallet via the command line?

When you use importprivkey() with electrum it makes you create a new wallet for the key import. You can't do it on the command line but you can delete the wallet file from your PC (assuming that new wallet you created during import only has that key on it).

   C:\Users\YOURNAME\AppData\Roaming\Electrum\wallets


Will the 1MB block size increase in the future?

If the use of Bitcoin increase in the future, is the 7 transactions per second going to be a bottleneck?

Assuming Bitcoin continues to grow in usage and we run out of possible soft forks that fit more transactions into a block without needing a hard fork (e.g. SegWit, Taproot) then yes fees will continue to rise if the block weight limitation remains the same.

And if so, can the block size be easily increased to grow network capacity?

I don't have a crystal ball but I suspect it won't be easy although hopefully not quite as fraught as the block size wars of 2015-17. There has to be network consensus over a block weight increase which will be extremely difficult. In addition if it is indeed a hard fork it will need years of planning and preparation.

Will this be a hardfork just like Bitcoin Cash?

If there are no alternative soft fork proposals which offer scaling potential then I suspect a hard fork will be proposed (though no guarantees on whether it obtains consensus) under the assumptions I laid out above. Bitcoin Cash's initial hard fork was a 8x increase (it later increased the block size limit to 32MB) and any proposed hard fork for Bitcoin would need to be a smaller multiple than that to have any chance of obtaining network consensus.

And why didn't Satoshi choose a block size greater than 1MB to avoid this potential bottleneck?

As far as I know Satoshi introduced the block size limit to address DoS (denial of service) issues. At the time 1MB seemed reasonable and still does to some respects. Even in 2021 some people think it should be higher, some people think it should be lower which suggests that many years ago it was about right.
Thanks to Murch for the suggested edits.


First of all, your BCC balance won't be shown in Electrum, Electrum shows only the BTC balance.

But there's a changed version of Electrum that supports BCC, Electron Cash (NOT Electrum Cash), and that one doesn't show the BTC balance.

Guess which one is Electron Cash, which one is Electrum!

Here are their icons, the one on the left is Electrum, the other one is Electron Cash


Your work flow looks good, you should wait for a sufficient number of confirmations before  you transaction is fully accepted.  Not sure if you are delivering physical products or digital products,  that could impact how many confirms you choose to wait for.

Check out the following RPC API call:

 move <fromaccount> <toaccount> <amount> [minconf=1] [comment]
 Move from one account in your wallet to another

This will allow you to move funds from one address to another within the same wallet.


How a transaction is permanently accepted by the blockchain?

If the chain of the miner B grows faster than the chain of the miner A, then the transaction A will never be accepted (like it never happened).

The transaction A is still unconfirmed in the mempool for any nodes following the best chain building on miner B's block. Any subsequent block is free to include it. The best chain has only one block at each height. Any competing blocks that don't end being part of the best chain are irrelevant for the network's state. So, if the block mined by miner A ends up being in the best chain, transaction A gets confirmed in A's block. If the block mined by miner B ends up being in the best chain, transaction A is free to get mined in the subsequent blocks following the block mined by B.

Confirmation of transaction is always probabilistic. Theoretically, an arbitrary long part of the chaintip could be reorganized to a better chain. It's just increasingly unlikely the longer the tip is. Many users consider transactions with six confirmations to be reliably confirmed. For smaller amounts, they may even trust fewer confirmations, larger amounts may cause the recipient to wait longer.


Script - Is it possible to build an addresss that allows retrieve a certain amount per address?

Each output can only be spent atomically. Either the entire amount or not at all.

The scripts are not evaluated for any “amount”. The script machine evaluates to true or false.

Of course, it is possible to spend this multisig output to multiple other outputs, each with a separate amount and output script (spending destination).


How to get current BTC rate for BRL(real) using php cURL or javascript

BitPay have a JSON API on https://bitpay.com/api/rates
You can get BRL value with this command and calculate, (this API update every 1 minute)

curl -ks https://bitpay.com/api/rates | python -m json.tool | grep -iA 1 'Brasilian Real' | grep -i 'rate' | cut -f2 -d ':' | tr -d ' '

You will need:
- CURL
- Python 2.7+
- grep + cut + tr


Where do the BCC go if an exchange doesn’t “support” it?

As one popular Bitcoin advocate puts it, "your keys -- your bitcoin, not your keys -- not your bitcoin". Yes, the exchange can pocket your BCC, as well as it technically can pocket your BTC.

Even if an exchange declares BCC support, beware of accounting issues.


Converting NodeID and BitcoinKey from Lightning Network (LND) logs

The values you've pasted are the node public key and the funding transaction output public key. The keys are encoded in compressed form (0x02 | 0x03 followed by the 32-byte x-coordinate of a point on the curve). The first byte indicates whether the y-coordinate is positive (0x02) or negative (x03). The 33-byte public key is the format used throughout the BOLT specs. All values in the BOLTs are encoded in network endian byte order.

There is no "bitcoin address" in either of these, nor are any convertible directly to an address. In bitcoin, the funding transactions use a P2WSH output, but the redeem script for this transaction is not revealed until the transaction is spent (channel closed). The only way to reconstruct the redeem script is if you know both funding public keys for the channel. in which case the redeem script is simply 02 <pubkey1> <pubkey2> 02 OP_CHECKMULTISIG, where <pubkey1> is the lesser of the two public keys.

The way Lightning channels are mapped to a bitcoin transaction is through their short_channel_id, which is a triplet of <block_height>x<tx_index>x<output_index>, encoded as a 64-bit integer. (block_height and tx_index as 24-bits each and output_index as 16-bits).

The full channel_id can also be used to map the channel to a bitcoin transaction, as the channel_id is the txid xor output_index.


6 types of Bitcoin addresses (in parentheses are the data they keep):
Legacy

P2PKH 1... (a public key's hash)
P2SH  3... (a script's hash) (defined in BIP16)

SegWit (P2WPKH/P2WSH) nested in P2SH (defined in BIP141)

P2SH-P2WPKH 3... (a public key's hash)
P2SH-P2WSH 3... (a script's hash)

(these start with three because these addresses are meant to be compatible with existing wallets, who would see those addresses as P2SH wallets)
Native SegWit (P2WPKH/P2WSH) (defined in BIP141 + BIP173)

P2WPKH bc1... (a public key's hash)
P2WSH bc1... (a script's hash) (but longer than P2WPKH)

which kind of script I have? P2PK?

getnewaddress can't return P2PK because you can either pay directly to a script (which can be P2PK) or a script enclosed in P2SH (or its derivatives P2SH-P2WSH and P2WSH). But that's not very useful.
The documentation says:

Arguments:

"label"          (string, optional) The label name for the address to be linked to. If not provided, the default label "" is used. It can also be set to the empty string "" to represent the default label. The label does not need to exist, it will be created if there is no label by the given name.

"address_type"   (string, optional) The address type to use. Options are "legacy", "p2sh-segwit", and "bech32". Default is set by -addresstype.

The legacy type means P2PKH, p2sh-segwit means P2SH-P2WPKH and bech32 means P2WPKH.


I assume this question is about Bitcoin Core's internal operations. This description is valid for version 0.8 and later (up to 0.14 at least).

One part of the system deals with the active chain, which is the longest valid chain of blocks (stored in $DATADIR/blocks) that we know of. This active chain gets blocks appended to - and occasionally removed when there is a reorganization.

  Where is the UTXO stored?

For the tip (the last block in the active chain), we maintain a database with the set of unspent transaction outputs (UTXOs), stored in $DATADIR/chainstate, and aggressively cached in memory. When a new block is received, we remove the UTXOs spent by transactions in the block, and add the outputs of those transactions. When a reorganization happens, we use undo data (stored in $DATADIR/blocks/rev*.dat) to roll back the changes to the UTXO set. In a way, you can see blocks as patches to the UTXO set - but the UTXO set is never explicitly committed to or stored in blocks, it is merely implied by them.

  What happens to the transactions after they are included in a newly mined block? Are they deleted from the pool?

The mempool is a set of transactions that are valid but not in a block. We don't treat those as part of the UTXO set. Rather, it's just a group of transactions that are internally consistent and consistent with the active chain. This means that any mempool transaction only spends outputs that are in the UTXO set, or from other mempool transactions. Whenever a new block comes in, we remove its transactions from the mempool (assuming they were there), and we remove any mempool transactions and their dependencies that conflict with the new UTXO set. When a reorganization happens, we try to move the removed block's transactions back to the mempool.

  Which function handles it?

That's too long to answer here. A significant part of src/validation.* (in 0.14) or src/main.* (in older versions) together with src/coins.* deals with maintenance and caching of the mempool and UTXO set.


There used to be a service by coinvoice.com that did exactly what you're asking. Unfortunately, they're no longer operating. I've heard bitpagos.com does that for Latin America. Otherwise, you're looking at setting up something with coinbase or bitpay to transfer fiat right away for bitcoins.

Best of luck with your business!


What if I don't send the complete amount from my paper wallet?

When you make a transaction, you will make a change output. This output can be to any address that you want, just as if you are sending Bitcoin to someone else. Depending on the software you are using, you can set the change address to whatever you want. You could send the coins back to your paper wallet address or you can create a new paper wallet and send the change there.

It is recommended that you do not reuse addresses, so you should create a new paper wallet and send the coins to that address.


If you search through your BTC-e's profile, you will find that they have MetaTrader which shows all trades.

This site shows data for MTGox which is very good for like how you want though I don't know if they have one for BTC-e

http://www.quandl.com/BITCOIN-Bitcoin-Charts/MTGOXUSD-Bitcoin-Markets-mtgoxUSD


Can I send/receive payments but prevent forwarding payments in Lightning Network?

Yes, there are basically two ways to avoid becoming a forwarding node:

Do not announce your channels, and keep them private
Reject any incoming HTLC that is not destined for you

The first is supported by the protocol itself, and is a proactive measure against forwarding any payment that is not destined for you, while the latter is a reactive measure and would allow you to decide on a per-HTLC basis whether you want to forward it or now.

The protocol allows channels to remain private and not be announced in the wider network:

  Only the least-significant bit of channel_flags is currently defined: announce_channel. This indicates whether the initiator of the funding flow wishes to advertise this channel publicly to the network, as detailed within BOLT #7.

This means that the channel is not going to be included in the gossip, and nodes won't learn about the channel's existence. In order then to receive payments, which requires the sender to compute a route to you through that unannounced channel, you selectively tell the sender about the channel in the invoice using route hints, i.e., the r field in the invoice.

The second method mentioned above involves instrumenting the node such that it accepts HTLCs, but immediately rejects any HTLCs for which you are not the destination. This is has several downsides, among which the fact that you are announcing channels that are fundamentally not operational for forwarding, and you still have to process all HTLCs since you can't filter them out ahead of time. This corresponds to the scenarion that Rene Pickhardt mentioned. The computational overhead consists of:

More messages to process, including the wire encryption/decryption, potentially waking your CPU up if you run on a low-powered device
Decrypting the onion, which is a really expensive operation since it decrypts/encrypts 2600 bytes of data by generating a pseudorandom stream. In addition the onion gets prepared for an eventual next hop.
Need to process the HTLC itself (DB lookups, ...)

Both methods are implemented in some implementations: the mobile version of eclair does not announce its channels by default, lnd is planning to implement a bias against (though not a complete exclusion) channels and nodes that have proven to be unreliable and c-lightning allows you to implement any forwarding policy you'd like as a plugin using the htlc_accepted hook. Furthermore it is trivial to modify lnd and c-lightning to make the announcement of channels configurable.

(Disclaimer: I am one of the spec authors and work on c-lightning)


What is the math behind Bitcoin's elliptic curve?

In ECDSA, the private key is a scalar 256-bit number. The public key is a elliptic curve point on the secp256k1 curve. Elliptic curves are abelian groups made up of the set of points resulting from repeatedly applying its group operation starting with its base point G. The group operation is the addition of two points. So, starting with the base point as the first element, the second element is G+G, the addition of G to itself. The third element is G+G+G, etc. To enumerate all points of the curve would take eons, because the group order is 115792089237316195423570985008687907852837564279074904382605163141518161494337.
Anyway, to find the public key Q corresponding to a private key k, you have to "walk" k generator steps from the base point. We write this elliptic curve scalar multiplication as

Q = G+G+…+G [k-times] = kG

Now secp256k1 is defined as

y² = x³+7 mod P

where P is

P = 2256 - 232 - 29 - 28 - 27 - 26 - 24 - 1.

In secp256k1, the base point is G(Gx,Gy), where

Gx =
55066263022277343669578718895168534326250603453777594175500187360389116729240
Gy =
32670510020758816978083085130507043184471273380659243275938904335757337482424

The addition of two points is defined as

P + Q = R
(xp, yp) + (xq, yq) = (xr, yr)

Which works out to be

xr = (yq - yp) / (xq - xp) - xp - xq
yr = ((yq - yp) / (xq - xp)) × (xp - xr) - yp

Note that the values are limited to [mod P]. So, taking your private key k, you now add G k times. There are some recommended shortcuts like first splitting k into a sum of factors of 2 (e.g. 37 = 1 + 22 + 25), because it will speed up your calculation immensely. Since the numbers involved are kinda hard to keep track of manually, I'd recommend using a software library.

Sources:

Wikipedia: Elliptic Curve Digital Signature Algorithm
Crypto.SE: How to generate a public key from a private ECDSA key?
Jun Wang: ECDSA and Bitcoin II
Wikipedia: Elliptic Curve Point Multiplication


Can't find correct z1 & z2 for transaction


Taking a look at the "How it works" document on their website, the first time they mention the word "Blockchain" is in their "About the company" section in the end of the document. So I would be quite sure that their product has absolutely nothing to do with any kind of blockchain technology.


Novice has bitaddress.org-generated wallet with .08 BTC in it... how can i exchange them for a fiat currency?

The "wallet ID" is specific to blockchain.com account and correspond to its login, if you have generated your address on bitaddress.org you can't have it, you should have instead the bitcoin address and it's private key.
These are the steps to import an external address from blockchain.com support:

To import a bitcoin address from a third party platform, click on +    Import Bitcoin Address and select Existing address generated outside this wallet. Enter the private key of the bitcoin address you want to import. Next, add a label for the address (optional) and select an existing sub-wallet to transfer the funds to, or leave this blank if you want the funds to remain in Imported Addresses. Click Import to complete the process.
In the mobile app, press the three horizontal lines in the upper left    corner to open the menu and select Addresses. Tap the + to the right    of Imported Addresses and then scan the private key's QR code. Next,    assign the address a name and press Save Name, or press No Thanks if    you do not wish to give the address a name.

Anyway, if you have a bitcoin address private key you can import it on any other wallet (you have just to know in which format is).
Once you have imported the address/private key in a wallet then you can send your bitcoin to an exchange and sell them for the currency of your choice.
Here you find info on private keys format and how to import them:
https://en.bitcoin.it/wiki/Private_key
https://en.bitcoin.it/wiki/How_to_import_private_keys


What happens if you send Bitcoin to a Litecoin address?

A Bitcoin or Litecoin address consists of:

a prefix byte
a 160-bit hash of a public key
a 32-bit checksum

all base-58 encoded.

Bitcoin and Litecoin use different prefix bytes; this is why most Bitcoin addresses start with 1, while most Litecoin addresses start with L.

When you use a Bitcoin client to try to send money to an address, it should perform a number of checks on that address.  One of those checks would be the prefix byte.  When it notices that the address doesn't have the correct prefix byte for Bitcoin, it should barf, complaining that you have specified an invalid address.  It wouldn't try to create a transaction at all.

So for practical purposes, the answer to the question is "you can't do it".

The same applies if you try to send Litecoins to a Bitcoin address - the prefix byte would not match the Litecoin client's expectation, so it would reject the address and refuse to create a transaction.

In theory, if you somehow used a broken client that did not check the prefix byte, it might actually generate a transaction whose output specified the 160-bit hash of the public key corresponding to the Litecoin address (call this hash value H).  The hash is the only part of the address that is actually used in creating a transaction.  Since all possible 160-bit numbers are potentially valid hashes, there would be no way to tell that H had come from a Litecoin rather than a Bitcoin key, so this would be a valid Bitcoin transaction.  (I got this wrong in a previous version of the answer.)  The transaction could only be spent by a Bitcoin transaction, signed with a private key whose public key had the hash H.

Now I believe (though I am not completely sure) that Litecoin uses exactly the same ECDSA signature algorithms as Bitcoin.  Therefore, if you (or someone else) has the private key for the Litecoin address, both Bitcoin and Litecoin should agree as to what the corresponding public key is, and agree that it has hash H.  So in principle, the private key holder would be able to import this key into a Bitcoin wallet and use it to spend the coins sent to the Litecoin address by the broken client.  (They couldn't import the key directly, again because the prefix byte would be wrong; but they could decode the base58-encoded Litecoin private key string, extract the 256-bit number which is the actual private key, prefix it with the appropriate Bitcoin prefix byte, recalculate the checksum, and re-encode the whole thing in base 58.  The result would be suitable to import into a standard Bitcoin wallet.)

If I am wrong about this, and Bitcoin and Litecoin handle keys and signatures differently, then most likely there would be no feasible way to find a private key whose public key's hash (computed by Bitcoin's rules) was equal to H.  In that case, the coins sent to that address would be lost forever.


Try this configuration. It worked for me it might work for you too.

server=1
whitelist=0.0.0.0/0
txindex=1
addressindex=1
timestampindex=1
spentindex=1
zmqpubrawtx=tcp://127.0.0.1:28332
zmqpubrawtxlock=tcp://127.0.0.1:28332
zmqpubhashblock=tcp://127.0.0.1:28332
rpcuser=dash
rpcpassword=local321
rpcport=9998
rpcallowip=0.0.0.0/0
uacomment=bitcore
debug=0
testnet=1


What happens to my outgoing txs in a block reorganization?

Will it be included in one of blocks E, F, G or another block?

It's likely already included in one of those blocks. If not, it can be included in a block after that.

  Do I need to resend it?

Probably not. If block D or Tx4 was widely seen by the network, it should get into a block soon. (It might already be in blocks E, F, or G.)

  If yes, can I spend the same inputs I did when creating Tx4?

Yes. When doing a reorg, the Bitcoin client first rolls the chainstate back to the first common ancestor.

The standard Bitcoin client actually includes a database for the sole purpose of rolling the blockchain back. (It's called an undofile.)


nLocktime has always been standard and is used to prevent fee sniping.

OP_CHECKLOCKTIMEVERIFY is currently not implemented and is not enforced.

A non-standard transaction can be mined by a miner, but will not relay around the normal peer to peer network. A transaction who has a nLockTime which has not been passed is invalid, and won't be relayed or included in a block until this time has passed.


where is the bitcoin's private key saved?

You should not ask users for their private keys. Instead, generate new addresses (with private keys) for the users to deposit bitcoin into. Then ensure you keep those keys safe and secure, back them up and keep them encrypted


Check confirmations on blockstream.info

If unconfirmed, open the wallet where you had sent, spend those BTC by sending to another address in same wallet with a fee rate more than what others are paying. Check mempool here: https://mempool.observer

This is called child pays for parent transaction: https://bitcoinops.org/en/topics/cpfp/

If unable to spend those unconfirmed BTC, there will be an option in Electrum settings which you need to enable


Sent bitcoin with no fee, waited and bitcoins disappeared

Export the private key of the address with the stuck transaction, import the PK into something like Electrum, and transfer the entire balance to another of your addresses.


Why does Mt Gox disallow YubiKeys purchased direct from Yubikey.com?

Properties of a yubikey:

A yubikey contains a secret symmetric key.
Knowledge of this key allows emulating that yubikey.
The server needs to know that key.

  The YubiKey AES Key information can never be extracted from a YubiKey device – only programmed to it

So Mt.Gox's insistence on sending the key to you ensures several important properties:

You're not tempted to use the same key to authenticate to other websites, which would allow those websites to break into your Mt.Gox account
You don't need to send the key to the Mt.Gox server through your potentially insecure computer
Nobody but Mt.Gox knows the key stored in your yubikey

So pre-programming yubikeys and sending them to you only after the key was programmed into the device rules out several possible threats, and thus seems reasonable risk management.


Unexpected coinbasevalue in regtest mode

In regtest mode, the block reward halves every 150 blocks instead of every 210000 blocks. See the consensus.nSubsidyHalvingInterval settings in chainparams.cpp.


BIP 341 answers this. It is generally important to be able to prove that the internal public key that you choose is a point with an unknown private key. Otherwise a malicious party could hide a key path spend in the P2TR address, pretend not to have the private key for that internal public key but actually possess it.
BIP 341 also provides instructions on how to avoid leaking the fact that the P2TR address had no possible key path spend when it is spent from. If you don't care about this privacy leak you could just take the suggested point H.

Pick as internal key a point with unknown discrete logarithm. One
example of such a point is H =
lift_x(0x0250929b74c1a04954b78b4b6035e97a5e078a5a0f28ec96d547bfee9ace803ac0)
which is constructed by taking the hash of the standard uncompressed
encoding of the secp256k1 base point G as X coordinate.
In order to avoid leaking the information that key path spending is
not possible it is recommended to pick a fresh integer r in the range
0...n-1 uniformly at random and use H + rG as internal key. It is possible to prove that this internal key does not have a known
discrete logarithm with respect to G by revealing r to a verifier who
can then reconstruct how the internal key was created.

A closely related question is on how to grant access to a key path spend but not a script path spend.


What are the best practices to close and reopen channels in order to increase capacity

Routing a payment will not change your node's balance, it will just change the balance of each specific channel you have open (resulting in a net ~zero change in overall balance). You may have pushed 30k sats to the remote node's balance, but you would have simultaneously had 30k sats pushed to your node's balance in one of your other channels. You haven't lost any of the initial amount, it is just present in a different channel now.
So if you want more capacity, then you should just close that channel, and re-open a new one with the desired liquidity.
To save some money, try to do this while the network isn't busy (ie, the mempool is relatively empty).


What is the need for multiple private keys?

The main reason to use multiple private keys is for privacy. Say you receive 1 BTC at address A, and you want to send 0.1BTC to someone at address X. (We'll neglect tx fees for easy math).

0.1 BTC Address A -> Address X
0.9 BTC Address A -> Address B

Now assume you were trying to watch any spending activity from the User at Address A, how would you know whether they own Address X or Address B? If you send change back to Address A, then it is easy to continue to track the user's spending after the 1st transaction. So, wallet applications keep track of all of the newly generated change addresses (since it generated them), so they can be aware of all the user's unspent Bitcoin.

Another reason might be to manage multiple accounts for accounting purposes. BIP32 is a common standard for generating sub-accounts using the same master key pair.


Calculate the difficulty of Bitcoin network

I think you're confusing terms here.

  Which variable among the components of the block header is computed

The block components which are computed (hashed) are all of the components which make up the block header: version, previous block hash, merkle root, unix epoch time, difficulty target (bits), and nonce.

Difficulty
A value which represents how hard it will be to mine a block. Higher difficulty value = harder to solve. The difficulty of the genesis block is 1. All block difficulties are calculated as a ratio to the difficulty of the genesis block.

Proof of Work
When you calculate a proof of work, you must meet the minimum difficulty posed by the network, as you state. This validation step makes sure that the value of the block hash you provide is less than or equal to the difficulty target.

Example

To illustrate this concept, you can validate one of the block hashes manually.

Grab a block (eg. block 3): Block 3 in json or Block 3 in hex
Concatenate (in this order, little endian, hex format) the version, previous block hash, merkle root, unix epoch time, difficulty target (bits), and nonce. You’ll see you can copy the first 160 characters from the Block 3 in hex link.

01000000bddd99ccfda39da1b108ce1a5d70038d0a967bacb68b6b63065f626a0000000044f672226090d85db9a9f2fbfe5f0f9609b387af7be5b7fbb7a1767c831c9e995dbe6649ffff001d05e0ed6d
Run the command:

$ echo 01000000bddd99ccfda39da1b108ce1a5d70038d0a967bacb68b6b63065f626a0000000044f672226090d85db9a9f2fbfe5f0f9609b387af7be5b7fbb7a1767c831c9e995dbe6649ffff001d05e0ed6d | xxd -r -p | openssl sha -sha256 | xxd -r -p | openssl sha -sha256
Reverse the output from
4944469562ae1c2c74d9a535e00b6f3e40ffbad4f2fda3895501b58200000000 to
0000000082b5015589a3fdf2d4baff403e6f0be035a5d9742c1cae6295464449

And there’s the block hash!


How do Bitcoin nodes know where to send new transactions and blocks to?

Bitcoin is a so-called gossip network. They announce any new object to all of their peers (just the hash of the data). If the peer doesn't know the object yet, it asks for the full object. So it's certainly not a DHT or any smart organisation of data: every (full) node (eventually) learns about every block and transaction. They have to, there is no other way of validating history otherwise.

As for how the client discovers peers, see How do Bitcoin clients find each other?


After receiving bitcoin, they were sent to an unknown address 16 minutes later

I tried so hard to find the answer what happen with my BTC but really has no idea.

One possible explanation is that the BTC were stolen by someone who, at some time in the past, helped generate your private-keys and vanity-address or had access to your wallet and extracted your private keys or who otherwise compromised the security of your computer, perhaps using malware.


What happens to SHA256 based cryptocurrencies when encription break takes no time?

SHA256 is used primarily for "proof of work"
The concept originated as a way to prevent email spam, oddly enough.
https://en.wikipedia.org/wiki/Hashcash

Hashcash is a proof-of-work system used to limit email spam and denial-of-service attacks, and more recently has become known for its use in bitcoin (and other cryptocurrencies) as part of the mining algorithm

The amount of work, the # of leading 0's in the hash that has to be mined is completely artificial, and can be adjusted at will.
So it's not a matter of what will happen when/if SHA256 is broken as much as a misunderstanding of how and what it is used for in the context of crypto-currancies.
Generally speaking they would just come up with another way to do "proof of work"

In contrast to hashcash in mail applications that relies on recipients to set manually an amount of work intended to deter malicious senders, the Bitcoin cryptocurrency network employs a different hashing-based proof-of-work challenge to enable competitive bitcoin mining. A bitcoin miner runs a computer program that collects unconfirmed transactions from coin dealers in the network. With other data these can form a block and earn a payment to the miner, but a block is accepted by the network only when the miner discovers by trial and error a "nonce" number that when included in the block yields a hash with a sufficient number of leading zero bits to meet the network's difficulty target. Blocks accepted from miners form the bitcoin blockchain that is a growing ledger of every bitcoin transaction since the coin's first creation.
While hashcash uses the SHA-1 hash and requires the first 20 of 160 hash bits to be zero, bitcoin's proof of work uses two successive SHA-256 hashes and originally required at least the first 32 of 256 hash bits to be zero. However the bitcoin network periodically resets the difficulty level to keep the average rate of block creation at 6 per hour. As of August 2017 (block #478608) the bitcoin network has responded to deployments of ever faster hashing hardware by miners by hardening the requirement to first 72 of 256 hash bits must be zero.

Now when it comes to SSL/TLS/RSA (asymmetric encryption) that's a whole other issue that while it does affect Bitcoin, would certainly break the internet in some profound ways. So I am sure the powers that be would quickly come up with a replacement. As far as Bitcoin in particular, as I understand it, it would affect mostly the wallets.  Although in truth, I am not that familiar with the "guts" of the blockchain itself so there may be some issues buried in there as well.  But as I said this type of encryption is widely used on the internet (my particular area of expertise) and I am sure it would be fixed as soon as it was discovered.
Just to put a bit of English on it
Hashes are used as a means to verify data integrity not for cryptography.  But this is not the only means that verifies the integrity of the data in a blockchain, there is also a distribution component of this. All the copies have to match.
For example a common use of hashing is when you download a file, you can get a file hash to verify that the file has not been tampered with.  Essentially if you hash your copy of the file and it doesn't match what it was supposed to then some one tampered with it (such as adding malware).  Sort of like those tamper proof seals on juice containers, I call them the pop-o-matic button.
Also as I understand it each block in the chain has the hash from the previous block (which has the hash of the previous block and so on) this is what puts the "chain" in the block chain.  See if you went back, say 9 blocks, and made a small change.  Well you not only have to re-mine the hash for that block, but you have to re-mine all the blocks that follow to the current block, and all these changes of course are not gonna fly when compared to another copy of the block chain.  So in someways being able to hash at lightning speeds could help you re-mine them, but it does nothing to address the second part.


Not in a user-friendly way, no.
Simple version
Your offline Bitcoin client needs more information to identify which coins it is spending, so there needs to be some communication from the online computer to the offline computer. Typically, this is done by preparing most of the transaction on the online computer, then transferring it flash drive to the offline computer to be signed.
Technical version
You need the outpoint, scriptPubKey, and amount of each input you want to spend. The outpoint is composed of the 256 bit hash of the transaction that sent you the Bitcoins, and a small integer showing which output of that transaction you're spending. You also need the scriptPubKey to tell you which key you need to use to sign the transaction. You need to know the amount so that you can specify the correct amount of change to send back to yourself. (Otherwise, the unspent money will just go to the miner.) This requires about 61 bytes of space per input. If a single input doesn't have enough to cover the transaction, you'll need to combine multiple inputs.
You could definitely ask the user to manually transcribe/renter this information, but I think that's asking for a mistake.


can parent private key sign a transaction created by a child address?

No, you cannot. The relationship between parent and child keys is via HMAC-SHA512, not related to ECDSA (the signature algorithm). To ECDSA, the parent and child keys have no relationship, they are both just private keys. So only the child private key can sign for the child public key, not the parent.


Are you considered a money transmitter if your end users sends you their private keys to send funds on their behalf?

That's not a very secure system.

You should set up a 1-of-2 multisig address with the user instead and have them send funds to that address.  They're still placing a lot of trust in you but they don't have to expose their private key.

As far as your original question goes: I don't think so since they're still technically in control of their funds (just you are as well), it's more like a jointly owned bank account.  Of course, I am not a lawyer.

Or better yet (updating this later after thinking about it a bit): Instead, have the user sign a bitcoin transaction, specifying the destination address but have them give it to you without actually publishing it until the condition has been met.  That way you don't have control over their funds at all, but you can still pull the trigger on sending a transaction.  This has the benefit of only requiring a single tx to complete the whole process.


Will hashing bytes from /dev/urandom yield a secure private key?

Short answer: If you are using /dev/urandom as your source of entropy, there is no need to run sha256sum to hash the data. Instead you can use the random data directly to form your key:

dd if=/dev/urandom of=/home/jsmith/private.key bs=1 count=32

Long answer:

The reasoning behind this recommendation is that /dev/urandom is already designed to produce high quality, unpredictable, unbiased random data. Indeed, the most common way to implement such an RNG is to feed raw entropy sources into a cryptographically secure random number generator (CSRNG) algorithm or a cryptographically secure hash function (like SHA-256).

What you are doing by sending urandom's data into sha256sum is almost entirely pointless. If urandom is working correctly, your procedure does not buy you any extra security. If urandom is compromised (e.g. outputting only a few possible sequences), then sha256sum cannot rescue you either, because the hash of a few different sequences is only a few different hashes. However if urandom were unpredictable but badly biased (say it generates 90% zeros and 10% ones), then sha256sum-ing this crappy entropy would help - but this situation is unimaginable for a proper RNG implementation.

To respond to kasperd's comment:

  Due to the internals of SHA256, the resulting key would be slightly stronger if you used count=119. Having count be a multiple of 64 is the worst you can do in terms of entropy of the final output. The optimal values for the input length is 55 plus a multiple of 64, so 55, 119, 183 are good values. But of course what is much more important than the count you specify is the security of the computer you use to generate and store the key.

This assertion is false, but the reason is not entirely obvious. How the SHA-256 algorithm works is that takes an input message, pads it to a block boundary with some specific numbers, then combines the hash state with each block in sequence.

Suppose S0 is the initial state, Bi is the ith message block after padding, and H(S, B) is the hash algorithm's compression function. Then we calculate, S1 = H(S0, B0), next S2 = H(S1, B1), etc. until all blocks are processed.

The non-obvious fact, however, is that H is an invertible function when B is known. In other words, we can calculate S0 = H−1(S1, B0). Hence we can say that H takes a 512-bit block B and uses it to permute a 256-bit state vector S into another 256-bit state vector Sʹ.

Because of this fact, it doesn't matter if the last block being hashed is highly predictable. If the previous blocks are unpredictable, then the state S will be effectively scrambled by hashing these blocks. Because the block compression function H is invertible, it can't "collapse" multiple states into one state, thus hashing a predictable block will not undo the state scrambling from previous blocks.


Types of ScriptPubKey that can contain addresses

Technically, pay-to-pubkey doesn't have an address type. You can derive an address as if it were a pay-to-pubkeyhash scriptPubKey, but there is a subtle difference.

The other type you are forgetting is a pay-to-scripthash type. It's of the format

OP_HASH160 <Hash160(redeemScript)> OP_EQUAL

Then, you get a p2sh adddress by prepending the version byte and appending the checksum to <Hash160(redeemScript)>


No, by design, there is no way for you or anyone to access your bitcoins without the private keys.

Unless you can find the keys somehow, you are out of luck. Sorry.


Nobody gives the block, the miner comes up with it. Think of it as designing a mansion. The possibilities are endless: it can even be an empty block without transactions (there is no mansion, just a garden shed). It only needs to be valid in two ways: no conflicting transactions (the design is physically possible to build) and it has to be cryptographically secured (you have to go through the legal bureaucracy before the construction may begin). In bitcoin world, only the last part takes any significant time, and it doesn't depend on your design at all, it's pure luck.

Only certain blocks are valid, so miners have to spend time manipulating the contents of the block until it satisfies the target hash. The transactions however are merely suggestions, the miner has the complete authority and can "build" whatever they want. When they work on the block to make it meet the difficulty standard, they only "manipulate" the parts that don't matter.


wallet notification not working for multisig address

First of all, the createmultisig will not add the generated address to your wallet, it will only generate the address and the redeemScript.

The addmultisigaddress was probably working for you because you generated both addresses on the same core-client and then added them with the addmultisigaddress command. However, the addmultisigaddress call will not add the multisig address to the wallet if not at least m of the public keys belong to this wallet (Where m is the minimum number of signatures required to spend from this address). This is because you can't add an address to the wallet if you can't spend from it. However, if you are only interested in adding the address for the purpose of watching it, you can do the following:

Generate n public keys for the m-of-n multisig address. Theses can be generated within or outside of the core client
Receive all the public keys on the core client and create the multisig address with createmultisig n '''[<LISTS_OF_M_KEYS>]'''
after you execute the step above you will recive the multisig address and the redeem script. You may store these to a DB if you would like
In order for walletNotify to work you need to import the address with importaddress command (you may want to set the rescan parameter to false since you just created the address anyway)
Optionally, you can add the address to a particular account with the setaccount command

Note: The account feature in bitcoind is planned to be deprecated and  replaced by a labels feature (see: [1] [2] [3]) and this should be taken into account if you want to plan ahead for forward compatability


How are unconfirmed transactions divided into different blocks?

When a miner (call him Pete) learns that a new block (call it X) has been mined by someone else, he will normally update the header of the block he is trying to mine, so that it lists X as the previous block.  (That way, Pete is now trying to build on top of X, rather than trying to replace it.)  At the same time, Pete will note which transactions were included in block X, and remove them from his "memory pool" of unconfirmed transactions that he was planning to include in the block he was trying to mine.  He will rebuild a Merkle tree with the remaining transactions he wishes to include, and update his block headers to match.

In this way, when Pete does succeed in mining a block, it won't contain any transactions that have been contained in previously mined blocks.


Using Bitcoin contracts to run a betting site without the need for deposits?

Giving the operator the power to control the identity of the recipient won't work, since he can participate himself and declare himself the winner. A majority vote also isn't too good because an attacker can make multiple entries, which is cheap to do if he knows he can guarantee a win.

It is necessary that the winner will be decided according to public data (such as the hash of a future block), and that the operator (or majority) will not be able to secure funds before sending payment to the agreed winner.

The only way I can think of is burn-escrow. Each participant sends a tentative payment to the operator which cannot be reversed, it can either be carried through or burned (with a deposit that incentivizes carrying through). Then the operator sends to the winner using his own funds. Then every participant forwards the payment. If the operator does not send to the winner, participants burn the payment and refuse to do business with the operator again.

There is some risk that the operator will be honest but participants will neglect to forward payments, or that the operator will be fraudulent but participants forward payments anyway to get the deposit. But with a properly calibrated deposit, these risks can be mitigated and entered into the pricing.


In short, yes (kinda).

More in detail, Balzac can perform the operations required for HTLC transactions. The following transaction is redeemable by Alice providing the premimage of h, or by Bob after the timelock block 1550000 expires.

transaction T_BtoA {
    input = B_funds: sig(kA)
    output = 1 BTC:
        fun(x,s:string) . sha256(s) == h && versig(kApub;x)
            || checkBlock 1550000 : versig(kBpub;x)
}

So, Balzac can be used to express the transactions of an HTLC, or any payment channel.

BitML is designed to express contracts, and compiles to a set of Balzac transactions.
Thereby, it cannot be used to express arbitrary transactions.
Nonetheless, we can express a similar logic in BitML with the following contract (full code):

(choice
  (reveal (h) (withdraw "Alice"))
  (after 1550000 (withdraw "Bob")))

This contract compiles to three transactions, one similar to T_BtoA above, and other two to move the bitcoin from the first transaction to either Alice or Bob.
Note that all transactions need to be signed by both participants when stipulating the contract, so they cannot be changed unilaterally.

While BitML can be used to express such transactions, at the moment it cannot express payment channels. With BitML you cannot design contract where the values of transactions are not known at compile time, or that require an unbound number of iterations. However, there is ongoing research to extend BitML with these features.


binascii.Error: Odd-length string for Python Implementation of Bitcoin

This is working for me:

import os
import ecdsa
import binascii
import hashlib

private_key = os.urandom(32)
PK_EN = binascii.hexlify(private_key)
print("Your Key" + "  " + str(PK_EN))
PK_CON = binascii.unhexlify(PK_EN)
sk = ecdsa.SigningKey.from_string(PK_CON, curve=ecdsa.SECP256k1)
vk = sk.verifying_key
msg = binascii.hexlify(b'Hello')
sign_msg = sk.sign(msg)
assert vk.verify(sign_msg, msg)

public_key = b'04' + binascii.hexlify(vk.to_string())
print(public_key)

ripemd160 = hashlib.new('ripemd160')

ripemd160.update(hashlib.sha256(binascii.unhexlify(public_key)).digest())

I've changed the way you concatenated the public key with the prefix, and the call to the ripmd160.update, since it was expecting a string, not a Hash object.


The ratio between propagation delay and block interval

As mentioned by Ethan Heilman here:

  According the paper 'Information propagation in the bitcoin network.' by Decker and Wattenhofer. The mean time for a node to see a block is 12.6 seconds, after 40 seconds 95% of the nodes have seen that block.

From my personal experience as a developer, this delay is real and noticeable. Some block explorers catch transactions ~20-30 seconds before others. It may be scary at first but its normal.


Array of individual transactions from blockchain.info

nice - but I promise, it will not be a "little" project :-)

  Will the sum of inputs always match the sum of outputs?

no! There is a general rule, that whatever is the difference, will be miner fees. To be more precise, the miner is free to take it as fees. So this is a reason why you should have always "return" addresses in your transactions.

  How would i marry up which input sent what amount to each output when
  there is more than 1 in each?

The idea of bitcoin transactions is, that they are not linked directly to  addresses, but to previous transactions. And they are not "divisible", but more "additional". I try to explain: funds are transferred from a previous transaction to a new location. Your wallet software might easily handle several addresses. If you send from your wallet to a new target, the wallet might have to take 2 or 3 or 4 previous tx, to send to new address, cause the funds on the single tx where insufficient for the total amount. In this sense, you (your C++ code) can only "match" inputs to outputs (with the derived addresses). Many huge transactions have hundreds of inputs and/or outputs - imagine faucets or exchanges: they create 1 transaction, with many payouts to different owners/users (e.g. https://blockchain.info/de/tx/2062a2717ca2f77c6935ff685d33086aa5db2f554ecd4d5232432cf9cb6a4006).

Taking your example: one can see that 5 inputs were required, to spend 250BTC to 15xif4SjXiFi3NDEsmMZCfTdE9jvvVQrjU and 1mio Satoshis to 1NkKLMgbSjXrT7oHagnGmYFhXAWXjJsKCj. That's nearly all you can say, what happened in this tx. The analogy from Andreas (and his book "Mastering Bitcoin", online readable, highly recommended) is FIAT money. You have maybe 10, 20 and 50 Euro bills in your wallet, but don't know from whom. Now you want to pay 35 Euros. So you give 50, and receive maybe 3 times 5 Euros as change. You still don't know, from whom they came, but just the amount. These "three times 5 Euros" could then be used as 3 inputs for a new 15 Euros transaction.


How to start using signrawtransactionwithkey instead of signrawtransaction

If you just want to sign the raw transaction as it's shown in the tutorial, please use signrawtransactionwithwallet instead. It would be like below.

$ signedtx2=$(bitcoin-cli -named signrawtransactionwithwallet hexstring=$rawtxhex2 | jq -r '.hex')
$ bitcoin-cli -named sendrawtransaction hexstring=$signedtx2
69c9ef4d1adb48596c470146ee9b60593023b6eb870b79ef666a8c9369768469


How much hashpower is needed to double-spend? Is >50% a minimum?

No, 50% is not a minimum to double-spend. From the Bitcoin-Wiki

  Brute force attack

  This attack has a chance to work even if the merchant waits for some confirmations, but requires relatively high hashrate.

  The attacker submits to the merchant/network a transaction which pays the merchant, while privately mining a blockchain fork in which a double-spending transaction is included instead. After waiting for n confirmations, the merchant sends the product. If the attacker happened to find more than n blocks at this point, he releases his fork and regains his coins; otherwise, he can try to continue extending his fork with the hope of being able to catch up with the network. If he never manages to do this, the attack fails and the payment to the merchant will go through.

  The probability of success is a function of the attacker's hashrate (as a proportion of the total network hashrate) and the number of confirmations the merchant waits for. For example, if the attacker controls 10% of the network hashrate but the merchant waits for 6 confirmations, the success probability is on the order of 0.1%

When you have more than 50% of the hashrate, the succeed chance is 100%:

  >50% attack

  If the attacker controls more than half of the network hashrate, the previous attack has a probability of 100% to succeed. Since the attacker can generate blocks faster than the rest of the network, he can simply persevere with his private fork until it becomes longer than the branch built by the honest network, from whatever disadvantage.

  No amount of confirmations can prevent this attack; however, waiting for confirmations does increase the aggregate resource cost of performing the attack, which could make it unprofitable or delay it long enough for the circumstances to change or slower-acting synchronization methods to kick in.


Is there an online wallet service that will allow me to access an rpc server?

It isn't free, but:
 - http://www.microthosting.com/bitcoin-servers.html

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


Mutum Sigillum LLC was the legal entity that Mt. Gox used for transferring funds using account-to-account transfers and for adding to (and withdrawing from) their account using bank funds.

Mutum Sigillum LLC is not registered as a money transmitter in any states.

It may not even be registered as a Money Service Business (MSB) through FinCEN.

FinCEN provided guidance that those exchanging "virtual currencies" (which they misapply, but intend to refer also to Bitcoin) for dollars are money transmitters and required to register.

This action by the DHS may be related to that.

Or it could be related to the Bitcoinica lawsuit in which Mt. Gox is holding funds of Bitcoinica customers that the court-appointed liquidator in New Zealand has requested access to.

Or it could be related to any number of additional factors, including a single illicit transaction in which the funds traveled through Mt. Gox, who knows.


How ./configure Bitcoin Core build to pick up depends build and installation path at the same time?

You cannot set the installation path with ./configure, but only when running make install. You need to specify --prefix=once for ./configure and once for make install.


Can I restore a blockchain.info wallet into a electrum wallet?

In Electrum:

Click File > New/Restore, enter a name and click Next.
Select Standard Wallet and then Next.
Select I already have a seed and then Next.
Enter the 12 words seed you got from blockchain.info (from Settings > Security > Backup phrase.
Click the "Options" button and enable BIP39.
Accept the default derivation key and click Next.
In the next step, set a wallet password and enable encryption.

Now you have your wallet imported.

  if I send fund / receive fund in the new Electrum wallet, will those transaction appear in the blockchain.info wallet?

Yes, they will.


Possibility of validation of transaction TX id

A txid is little-endian representation of the double sha256 of the serialized tx. Hence, if they send you a wrong or incomplete txid there is no way of validating it without the serialized tx.

Moreover, you should be careful when identifying txs just by its txid, if not careful enough (you accept 0-confirmation txs, or txs that has not gone deep enough in the blockchain), they could double spend the same utxo thas has been used to pay you.


How to create a transaction with a custom script?

I would suggest using Python to accomplish this. pybitcointools have what you need to be able to deserialize a hex transaction to JSON, and manipulate that and then serialize again to be able to sign and broadcast via support for blockchain.info.

This example will rebuild the standard script from the ground up:

>>> opdup = 0x76
>>> ophash160 = 0xA9
>>> push20 = 0x14
>>> opeqver = 0x88
>>> opchecksig = 0xAC
>>> pubkeyhash = 0x2dbde30815faee5bf221d6688ebad7e12f7b2b1a

We are going to append hex values by moving them bitwise.

OP_DUP OP_HASH160 2dbde30815faee5bf221d6688ebad7e12f7b2b1a OP_EQUALVERIFY OP_CHECKSIG
This is the hex we want 76a9142dbde30815faee5bf221d6688ebad7e12f7b2b1a88ac

This is one way of doing it

>>> quickfix = 0xff
>>> asm = quickfix
>>> asm = asm << 8 | opdup
>>> asm = asm << 8 | ophash160
>>> asm = asm << 8 | push20
>>> asm = asm << 8*20 | pubkeyhash
>>> asm = asm << 8 | opeqver
>>> asm = asm << 8 | opchecksig

Ant then to check if its the same:

>>> almost = hex(asm)
>>> ready = almost.partition("0xff")[2]
>>> print(ready)

Hope this is what you are after :-)


What are zkSNARK parameters and how to verify them?

It's basically a zero knowledge proof that is easy to verify. The parameters are given on the zcash site. you can check it here
https://z.cash/blog/generating-zcash-parameters.html


The difference between mempool "bytes" and "usage"

From the documentation:

  "bytes": xxxxx,              (numeric) Sum of all virtual transaction sizes as defined in BIP 141. Differs from actual serialized size because witness data is discounted
  "usage": xxxxx,              (numeric) Total memory usage for the mempool

bytes is the size as calculated as vBytes as would be considered for inclusion in a block, usage is the logical size in actual bytes that are consuming memory.


What exactly does redeem in the context of bitcon mean?

In Bitcoin terms, "redeem" means to claim an unspent transaction output (UTXO) by listing it as an input of a new transaction.

All a Bitcoin transaction really does is claim ownership of one or more UTXOs, and combine their value into one or more new UTXOs.  To do this, it must prove ownership of the UTXOs being used as inputs.  Each UTXO has a script that defines a condition that must be met in order to use it as an input (scriptPubKey or encumbrance script).  To redeem, you must supply a corresponding script that meets that condition (scriptSig or redeem script).

The website you refer to is an improvement proposal (that has already been implemented) where instead of specifying a script in a UTXO, you specify a hash of a script.  This means that a transaction that claims UTXO needs to specify both the script that meets the condition, and the original script from which the hash was produced.


BTC-E currently offers trading pairs of BTC/USD, BTC/RUB, SC/BTC, SC/USD, GG/BTC, TBX/BTC, FBX/BTC, LTC/BTC, LTC/USD, RUC/BTC, RUC/USD, RUC/RUB, NMC/BTC and RUB/USD


How to be assured a wallet is on a blockchain?

That's impossible. The only way you can be sure is that you compile the wallet from the source code by yourself. In practice, you should only use wallets that are famous (some of those are Blockchain.info wallet, Bitcoin.com, CoPay, Coinbase, Electrum, BRD,... I can count at least 20 of them). You can search online with the name of the wallet software you want to download and refrain from downloading it if there isn't enough of convincing reviews.


What is the longnest blockchain fork that has been orphaned to date?

11/12 March 2013 Chain Fork at block height 225,430.It's 31 blocks long.


Proving collisions on Bitcoin addresses without discovery of the private key?

To phrase the question in my own words: Can you prove that a transaction output was unlocked with a different private key than originally intended?

Short answer: You can or can't, depending on the situation.

A standard transaction output script works like this:

Assume that the stack starts with two items, with the public key on top and the signature below.
Duplicate the public key (topmost item).
Compute its hash.
Push the expected hash, which is the payee's address (20-byte SHA-256 + RIPEMD-160 hash).
Compare and assert that the top two items are equal.
Restore the stack to the initial state, and use the two items to check the signature.

A standard transaction input script works like this:

Push the signature.
Push the public key (this is now at the top of the stack).

Because of this underlying mechanism, here are the implications:

If an output to a specific address has never been spent before, then the public key has never been seen by the Bitcoin network. Thus the first time that a valid public key shows up (whose SHA-256 + RIPEMD-160 hash matches), it is indistinguishably as valid as any other public key that has the same hash (which is extremely unlikely to find one, of course).
If an output to a specific address has been spent before, then the network has recorded one or more public keys that were used to spend that address. The Bitcoin/blockchain protocol does not mandate that the public key must be the same; in other words there is no notion of "key pinning". Although it is plausible for an individual miner's Bitcoin client to enforce key pinning, I don't expect this to be a feature that becomes implemented.


The idea is that Bitcoin is agnostic when it comes to any sidechains derived from it.  When some coins are brought in from Bitcoin to the sidechain, Bitcoin only sees what it always sees: transaction outputs locked up by an encumbrance script.  The other chain must be aware of Bitcoin's blockchain, and from there, the sidechain's rules will see that the coins have been encumbered such that the coins are now issued on the sidechain's blockchain.

So let's say that Ethereum does not issue ether via mining reward, but rather requires you to lock up bitcoin on Bitcoin's blockchain, thus "moving" that bitcoin from the main chain to the sidechain.  Now the ether can be traded, payed to a smart contract, or anything else that ether can do on the Ethereum block chain.  You can even trade it back to the main chain, thus claiming the bitcoin that was "moved" to the Ethereum chain.  The fact that the two blockchains are fundamentally different doesn't matter, as long as the sidechain is aware of the parent, and can handle moving coins back and forth.

You may want to check out this answer for a more in-depth explanation to sidechains.


It depends by the machine, of course, but keep in mind that difficulty changes as time goes on. You should look at that specific index in order to aknowledge it correctly. By now, it takes about 1 year to get 1 BTC with your hardware, supposing no difficulty increases. I do advise you to mine other currencies (BTB or others) and then convert them into BTC... that's easier this way!


No. That's not possible.

A transaction id is calculated from the raw transaction. More specifically the raw transaction is hashed twice with sha256: sha256(sha256(rawtransaction)).

That means, that the id is always 256 bits long (64 characters).
Because sha256 and hashing in general is a one-way-operation, it's not possible to calculate the size of the rawtransaction just from the transaction id.

if you need more information about a transaction, you have to fetch that from a client. In bitcoin core you can use gettransaction or getrawtransaction. (getrawtransaction only works if the transaction belongs to one of your addresses or you have txindex enabled in your wallet.)


Bitcoin's disappeared from unused wallet

Looks like the tx you are referring to on 2014-03-24, sent the money to

14N9ydxNRhDxkKJvXg1vjqS3gh884vG3UM - (Unspent) 0.039 BTC
1L9Q6EFMH3jn4dWquC2DaWhWK4q4pyUvum - (Unspent) 0.00060405 BTC

They both remain unspent.
1L... address is most likely the change address, that belongs to your wallet, if that transaction was made from your wallet.

Someone could have gotten your private key and moved the money that way.
Since the money has been not spent there is not much you can to in terms of tracing.


How do I get network propagation of an unconfirmed transaction? (e.g. the number of nodes which have seen it)

You cannot reliably get such information. The best that you can do is ask individual nodes whether they have seen your transaction (by sending getdata messages and seeing if they respond) but even then, not all nodes will respond. It is impossible to ask all nodes (as not all nodes are listening so you cannot connect to all of them) nor is it possible to "ask the network".

If you are concerned that someone will try to double spend a transaction that they sent to you, then you can broadcast it yourself and try to get it to as many nodes as possible. Instead of trying to figure out how it has propagated, you just make sure that it has propagated by relaying the transaction yourself.

Also, this method is not a reliable way to protect against double spends. Even if the fee is good and the transaction is propagated, a double spend is always possible and potentially trivial if the fee on the double spend is high enough.


How to run a litecoin miner behind a proxy server?

I got it working for pool-x.eu connecting via port 80 (the proxy server name and port is just what my browser uses):

@echo off
set HTTP_PROXY=http://myproxyserver:myport
START /LOW /B minerd.exe --algo scrypt --url http://mine.pool-x.eu:80/ --userpass myusername.1:mypassword --threads 4 -r -1 -s 5

Not all pools allow connections through port 80, so it does limit which pools you can connect to.


Convert an lower-cased address to a properly capitalized address?

See the related question Can you help me fix this address?.

It should be pretty easy to adapt the code I gave in my answer to try upper and lower case for each letter in the address, and for each possibility, see if its checksum validates.  The address you gave has 28 alphabetical characters, so there are 2^28 addresses to check, which is not too unreasonable.

I would not expect there to be any way that's substantially better than this brute-force approach.  Since the output of a good cryptographic hash function should look random, there shouldn't be any "patterns" in the upper/lower case distribution for us to take advantage of.

There is a chance that more than one possibility results in a valid address.  In that case, there would be no way to know which of them was the address that was actually intended (but if only one of them has appeared on the block chain, that should settle it.)


The softfork defined by BIP 65 activated in december 2015. This means that the whole network enforces the new rules proposed by BIP 65, and it is safe to use CLTV opcodes in scripts since then.


The BitMinter miner also works on Mac OS X. Go to http://bitminter.com and click the "engine start" button. There's no installation, it starts from the browser. It requires Java.

As to what is going wrong with DiabloMiner, I don't know. If it is mining without errors then it should be getting you shares at the pool.


Import watch-only address to 0.18 core wallet, addresses missing

You're using on incorrect bitcoin-cli method to list your addresses.

The command you're looking for is:

bitcoin-cli listreceivedbyaddress 0 true

The 0 parameter means you're requesting information on any address and the true flag means you want empty addresses included.

The original command you were attempting, listaddressgroupings, is described here.


Why is it necessary for Multi-Path Payments in Lightning to be Atomic?

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

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


How do blockchains in each nodes maintain consistency?

Most of the full nodes are operating on normal CPUs which is now basically ineffective for mining. The mining process is handled by specific mining pools. So for full nodes that basically sees the same blockchain (there might be inconsistencies at the tip if two blocks are mined at the same time), they have the same UTXO set. This is because the UTXO set is built based on the transactions that are included in the blocks. Whenever a block is received by a full node, they delete the UTXOs which were consumed by the inputs in the transactions and add the UTXOs that were created in the output. For a mining node it is similar. If they mined the last block at the same time as the other miner, then the first miner would be building the next block using a different UTXO set than the other miner. However, after one or two blocks when the network converges (they cannot indefinitely generate blocks simultaneously) the network would have the same UTXO set.

For mempool the story is different. Bitcoin transactions are relayed on the network on a best effort basis. So it might be the case that some nodes do not see some transactions until they are finally included in the blocks. So, yes there are inconsistencies in the mempool.

  how can a node resume mining after the new block is introduced?

As mentioned above, if two blocks are mined at the same time then some miners would be working on a different version versus others. The accepted principle is to build on the block that was received first. However, this is not always the case. So when a mining node who is still calculating the header hashes notice that a new block is mined, they realize that they have lost the 'race' for that particular block height and try to mine on the block that was most recently received.


When a node receives a transaction, what steps does it do to verify that transaction?

When a node receives a transaction, they perform the following steps at a high level.

Inductively, they already have a set of validated transactions; these belong to the blockchain they have adopted as well as their current mempool. From this, the node has extracted a UTXO.

Ensure that the inputs of the new transaction reference valid outpoints in the UTXO. This ensures that the money being spent is real.
Verify the Law of Conservation, i.e., that the sum of value of the outputs does not exceed the sum of the value of the inputs. This ensures that no new money is being created. The one exception to this is when a new coinbase transaction is received with a newly mined block; in that case, new money can really be created.
For each input of the new transaction, ensure that running the scriptPubKey script attached to the outpoint it connects to with the parameters specified in the scriptSig of the input, leaves the Bitcoin Script stack with a non-zero value at the top. Most of the time, this is the step where the digital signature validation happens and ensures the money is being spent by its rightful owner.

The last step above has many subcases and can function in various ways depending on whether the transaction involves a segregated witness or an attached indirect script, for example.

Lastly, once a transaction is validated by the above steps, the UTXO of the node is updated so that they can validate further transactions.

None of the above has anything to do with block validation. Block validation is a separate mechanism from transaction validation. Transactions are validated even when they don't belong to blocks. One of the block validation steps is to validate all block transactions with the above algorithm. Transaction validation does not require calculating any block hashes.


Electrum 2FA Wallet - Deriving the Third XPub

After looking into the source code for the Electrum Wallet a bit further I was able to come up with a working implementation in JavaScript.

The problem I described in my question was that the long_user_id is 32 bytes while you only need 4 bytes to derive a child key. It turns out that the third xpub is actually not a child of the hard-coded signing xpub, but rather a root key derived from that signing key (i.e. it has a completely different chain code and its index is 0).

Here's the function I wrote which takes the two wallet xpubs (found under x1/ and x2/ in the wallet / keystore file) and the hard-coded xpub from Trustedcoin and derives the third xpub.

import HDKey from 'hdkey';
import crypto from 'crypto';
import secp256k1 from 'secp256k1';

function getCosignerXPub(xpub_x1, xpub_x2){
    const signing_xpub = "xpub661MyMwAqRbcGnMkaTx2594P9EDuiEqMq25PM2aeG6UmwzaohgA6uDmNsvSUV8ubqwA3Wpste1hg69XHgjUuCD5HLcEp2QPzyV1HMrPppsL";

    const xpubs = [xpub_x1, xpub_x2].sort().join("");
    const long_user_id = new Buffer(sha256(xpubs), 'hex');

    const hdkey = HDKey.fromExtendedKey(signing_xpub);

    const data = Buffer.concat([hdkey.publicKey, long_user_id]);

    const I = crypto.createHmac('sha512', hdkey.chainCode).update(data).digest();

    const IL = I.slice(0, 32);
    const IR = I.slice(32);

    const hd = new HDKey(hdkey.versions);

    hd.publicKey = secp256k1.publicKeyTweakAdd(hdkey.publicKey, IL, true);
    hd.chainCode = IR;

    return hd.publicExtendedKey;
}


Why do we need to chain the blocks (creating blockchain) in a permissioned blockchain?

I think you might already know the answer, based on your question. The "chain of blocks" has value in Bitcoin because of the proof of work. It is also provides a data structure that can be used in an efficient way to verify the integrity of the chain, but that is not really what makes it interesting.

A permissioned blockchain, obviously, requires permission to join, so a proof of work isn't really necessary. If someone misbehaves, they can be removed by whatever process prevents the whole world from joining. The proof of work provides a consensus mechanism in a distributed permission-less network.

Another problem is the word "blockchain" is very over-hyped term that has different meanings in different contexts. The reason why the "chain of blocks" or "proof of work chain" Bitcoin Whitepaper is interesting is that it solves the problem of distributed consensus. Any other definition isn't nearly as interesting.

Based on that, it appears that many companies are trying to figure out how to make a profit on the "blockchain" hype and one way is by creating their own coin. Unfortunately companies are used to controlling their products and that is why you see premines and closed blockchains because that is how companies have traditionally made money. I look forward to more solutions where companies provide solutions on top of the existing infrastructure (e.g. like building web apps on the existing internet) rather than trying to control it.


"State of the Coin 2012" and the mention of Satoshi Dice

There was a very controversial and heated discussion among developers and on forum started by Matt Corallo: Huge increase in satoshidice spam over the past day. Essentially he proposed to police transactions priority for block inclusion to punish websites which doesn't take measures against overburdening Bitcoin Network.

It's worth to note that SatoshiDice by no means was trying to DDOS Bitcoin Network. The amount of transactions is the result of its successful business model and somewhat careless implementation.

Personally I think SatoshiDice is a very good thing, it pushed Bitcoin Network to its limits, but not to the point where it could become dysfunctional. SatoshiDice revealed that network's choke point was disk access time to verify transactions rather then ECDSA verification time. As far as I know LevelDB implementation to store transactions history to reduce disk access time was the direct result of SatoshiDice spam. It is also accelerated development of Ultra Prune method to reduce storage requirements.


How does solving math problems create bitcoins?

The problem that mining solves is the problem of providing secure transactions without a central authority. There is value to solving these problems because otherwise, there would be no way to securely exchange Bitcoins.

Bitcoin uses proof of work as its means of solving the double spend problem without a central authority. If I try to send the same Bitcoin to two different accounts, the miners choose one transaction or the other and use it as the basis of the computations they do. Because nobody else can outcompute all the Bitcoin miners, this makes it possible for others to determine which transaction "wins". Without this mechanism, there would be no way to resolve conflicting transactions.

Because this proof of work costs money to do, it's not likely that it could be accomplished without some incentive. Mining rewards provide this incentive.


How has the problem of waiting for confirmations been eradicated?

Perhaps they are referring to the green address technique.  Some exchanges support this now:

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

Or they might be referring to the ability to protect against a race attack by listening to many nodes so as to learn of any double spend race attack attempts.  That doesn't eliminate the risk entirely but helps to bring it to a level that the merchant can manage.  There has been progress towards doing this listening with varying results ( http://www.transactionradar.com and http://blockchain.info/double-spends ) but there is no service built yet for merchants that provides transaction monitoring and alerting when double spend attempts are detected:

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


Not with its consensus mechanism: you need the scarce ripples to prevent abuses to the network precisely from spam and DoS.

But there is the older two phase commit design to implement the ripple concept as a decentralized protocol (that wasn't implemented) and didn't need ripples or any kind of "HostCoin":

http://archive.ripple-project.org/Protocol/Protocol

It has some advantages and disadvantages over the current implementation:

+Better privacy

+Even faster transactions??

-All intermediaries in a Ripple transaction must be online

-Lack of thin clients, people that can't be always online are expected to use a server as a service

Privacy is not a priority for the current implementation right now, but there's plans to improve it through obfuscation.

The ledger could even act as the "register" for "hidden transactions" more similar in properties to the ones of the old 2pc protocol. So it may be more convenient to extend or modify the current protocol than to implement the old one.


Is it possible to transfer blockchain data from one machine to another?

You can simply copy the entire data directory from an existing bitcoin-core installation on another machine over to your machine, then start the bitcoind daemon.

Be aware you'll want to create a backup of the wallet.dat file from the destination machine so you don't inadvertently overwrite it.  You may also want to confirm the bitcoin.conf settings work for the destination machine.  Specifically, you may want to modify the rpcpassword, memory configuration, etc.

On Windows, the data folder is installed by default into %AppData%\Bitcoin


The only thing you can do is ask the owner of the address you sent the bitcoin to to send the bitcoin back to you. There is no such thing as a "declined" transaction in bitcoin; transactions that get included in a block are final.