Why is the default mempool size in Litecoin so small? This morning there was a bit of a mempool congestion on Litecoin which led to a number of exchanges shutting down their Litecoin withdrawals as their transactions dropped from the mempool when it filled up to the default size of 5MB. What is the reason for the default mempool size to be so small in Litecoin?

To save memory. Back in time LTC was not getting too much transactions for block, there was no reason to eat more mem. I guess this way people could run LTC node on embedded devices. But that was fixed in February and since 0.15.1 default mempool size in Litecoin is 300Mb.


Are all UTXOs locked by an address spent in a transaction? Imagine I have 2 UTXOs locked by my address, each of which allows me to spend 5 bitcoins.

If I subsequently want to send just 2 bitcoins to someone else, will both UTXOs be used as inputs in the transaction, where I now receive 8 BTC change as a single UTXO locked to my address, or as the value I want to spend can be covered by a single UTXO, is only one of the 5 BTC UTXOs spent by the transaction and I receive change in a new UTXO worth 3 BTC locked by my address. So now my address locks two UTXOs, one for 5 BTC which was not needed in this transaction, plus the change I just received for 3 BTC. Or something else?

Transactions explicitly refer to which UTXOs they are spending.

You can construct a transaction which only spends one of the two 5-BTC UTXOs, and sends 2 BTC to the destination and 3 BTC to a (possibly new) address of yourself.

You can also construct a transaction which spends both, and sends 8 BTC back to yourself. Or it could have multiple outputs that send funds back to yourself, summing up to 8 BTC.

In short: there is nothing special about the two UTXOs that share an address, apart from the fact that the same key can sign for both - but it doesn't have to.


Why will anyone still play SatoshiDice? There seems to be a new SatoshiDice clone called BetCoinDice.

Everything is the same, except the expected return for the player is higher since the house percent is lower.

If this is the case, is it true that it doesn't make sense to use SatoshiDice any more?

Gamblers will pay a premium to play on a trusted, reputable site that has a long history of not defrauding its customers.

As noted by LocalBitcoins, Betcoin is accused of shady behavior, including lying about their trademark, failing to correctly use a provably fair system, playing on their own site to inflate volume, and DDoSing competitors. Source: http://bitcoinmagazine.com/7659/betcoin-tm-allegedly-fraudulent-activity/


Risk of double spending Hi I sent $10 btc To an address now it’s saying that my account is at risk of double spending I don’t know what does that mean or what to do. Any help would work thanks

A double spend occurs when someone sends a bitcoin tx, and then quickly sends another transaction using the same coins, but to a different receiving address. The network will ultimately only confirm one of the two transactions by adding it into a new block, so one of the receivers of a double-spent transactoin is at risk of not having their payment confirmed.

Some wallet software will watch for potential double spends, and issue a warning if one is detected. If you sent this transaction and know you did not double spend, then its probably just a false positive from the software, and you have nothing to worry about.

If you are the receiver of this transaction, do not release whatever goods/services you are trading the btc for until after this transaction has enough confirmations. Usually, 6 blocks is safe, but this number varies with the total value transacted (it is smart to wait longer for large transactions. Each block after the transaction has been mined is considered '1 confirmation').


How do I compute merkle root for genesis block? I wanted to help out the community and create a pure C application independent of the reference client, that given a timestamp and a public key, will produce a merkle root for creation of a genesis block.

My knowledge of C++ is very little to none. After looking at the source code, this is the relevant code

    const char* pszTimestamp = "The Times 03/Jan/2009 Chancellor on brink of second bailout for banks";
    CTransaction txNew;
    txNew.vin.resize(1);
    txNew.vout.resize(1);
    txNew.vin[0].scriptSig = CScript() << 486604799 << CBigNum(4) << vector<unsigned char>((const unsigned char*)pszTimestamp, (const unsigned char*)pszTimestamp + strlen(pszTimestamp));
    txNew.vout[0].nValue = 50 * COIN;
    txNew.vout[0].scriptPubKey = CScript() << ParseHex("04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f") << OP_CHECKSIG;

Which produces this merkle hash

 4a5e1e4baab89f3a32518a88c31bc87f618f76673e2cc77ab2127b7afdeda33b

I am not sure whether CScript() << 486604799 << CBigNum(4) <<... is bitshifting all of this, or simply writing it out to .scriptSig.
And I am going to assume that CScript() is the constructor that initializes .scriptSig.

As I delved into the source code and following what BuildMerkleTree calls I ended up in

template<typename T>
uint256 SerializeHash(const T& obj, int nType=SER_GETHASH, int     nVersion=PROTOCOL_VERSION)
{
    CHashWriter ss(nType, nVersion);
    ss << obj;
    return ss.GetHash();
}

So I started following ChashWriter, and ended up in

template<typename T>
CHashWriter& operator<<(const T& obj) {
    // Serialize to this stream
    ::Serialize(*this, obj, nType, nVersion);
    return (*this);
}

And I got lost there. But the closest I got was double SHA256-ing this

04ffff001d0104455468652054696d65732030332f4a616e2f32303039204368616e63656c6c6f72206f6e206272696e6b206f66207365636f6e64206261696c6f757420666f722062616e6b73 5000000000 04678afdb0fe5548271967f1a67130b7105cd6a828e03909a67962e0ea1f61deb649f6bc3f4cef38c4f35504e51ec112de5c384df7ba0b8d578a4c702b6bf11d5f OP_CHECKSIG after supposedly converting to a byte array.

And I was obviously wrong about it, as the result was not correct.

Apparently, Bitcoin uses something known as Serialization to serialize the object's variables, perhaps concatenate them, but unfortunately due to my inexperience with C++ I could not understand which variables, in what order and so on. Basically, the Bitcoin source code was more complex than I had imagined.

So my question is how I may produce a merkle hash for a genesis block, without using serialization and in C?

Instead of looking at the source code, take a look at the relevant wiki page.

As blockexplorer will reveal, the merkle root of the genesis block is equal to the hash of the transaction in it. This is because building a hash tree of one transaction will simply result in that one transaction, and the hash of that tree will be the same as the hash of that one transaction.

When dealing with more transactions, simply put them in a tree and hash them from bottom to top, as the wiki page mentions.


Need help about Mining and Difficulty levels! I am new to these mining things and i want to know that, "What if the difficulty level increase?, would i make a loss with mining? I am mining $1 USD with 5MH/s server with the current difficulty."

Can someone shed some light on this matter? I will be very thankful to him

Generally speaking, as the difficulty goes up, and you keep the same hardware, your earnings will go down. If they drop below the cost of mining (including electricity, etc), then yes, you will have a loss.


Why does Bitstamp allow trading of currencies that it won't return a balance for? According to https://www.bitstamp.net/api/ section "Buy Limit Order" Bitstamp allows users to buy LTC coins using the currency pair "ltcusd". But, looking at the "Account Balance" section, there is no way to get a user's LTC balance.

What happens when a user buys "ltcusd"? Where does the LTC balance go?

Contrary to the documentation, the server actually returns a balance for LTC, BCH and ETH coins using fields ltc_available, bch_available and eth_available, respectively.


HD wallets with an exposed child private key HD wallets as described here are built based on a master seed and a master public key as follows:

PK.b = PK.a + sG
SK.b = SK.a + s

I just got a little confused about this. Is s the mnemonic seed that
user knows? which generates the private keys.
Secondly a service
provider only needs to know sG to calculate the user's next address.
Am I right?
And lastly more importantly I am just wondering whether it is possible to
calculate the master private key (seed) if an attacker or service provider gets one child's private key address?

I don't know where you found this formula, here is the code to derivate a childkey, the BIP is here, it does not look like your formula, but I'll try to respond to some of your questions.

I just got a little confused about this. Is s the mnemonic seed that user knows? which generates the private keys.

A mnemonic seed is just a sentence that permit you to get the master key with (optionally) a password. A master key is the real important piece of information, a mnemonic is only a way to generate one that can be write it down in words.

Secondly a service provider only needs to know sG to calculate the user's next address. Am I right?

Your formula does not look like what is in the BIP, so I can't really comment on that.

And lastly more importantly I am just wondering whether it is possible to calculate the master private key (seed) if an attacker or service provider gets one child's private key address?

Yes, if all the children in the path to the leaked private are non-hardened keys AND the root HD PubKey leaked. I explain that P 35 of my book.

A non-hardened key can “climb” the hierarchy.
Non-hardened key should only be used for categorizing accounts that belongs to a single control.


Is there a list of news articles related to bitcoin? What articles if any have been in the mainstream media about bitcoin?

The most up-to-date list is the Bitcoin press hits thread. However, if you want a shorter list with more quality content, I recommend Press page on wiki.


First confirmation time vs miners fee's After submitting a transaction to the blockchain..

1) If I pay a higher transaction fee will first confirmation happen faster?

2) I found today that a 250B transaction with 1000 Satoshi fee took just under 2 hours is this normal?

3) Does the network I submit the transaction to make any difference to the fee and the time to first confirmation, as indicated here... http://p2sh.info/dashboard/db/fee-estimation

4) I hear that some miners prefer to mine transactions with no fee as it gives them some kind of advantage? Any information on this would be great

1) Yes. You can see some statistics here: http://bitcointicker.co/networkstats/

2) "Normal" will depend on network usage and how much others are paying. So can't give a definite answer there. Let's just say your fee should be competitive if you want your transaction included in reasonable time.

3) Shouldn't matter as all transactions are distributed around the entire network. Most of the miners should "see" your transaction very fast, so the time will depend on whether all the miners or just some of them decided to include your transaction in the block they're working on. Miners are free to have whatever policy they want on what transaction they want to include. Usually it's the highest fee that gets in. If the miner who included yours "wins" the block, your transaction will most likely stick on the blockchain, and after a few more confirmations, definetely.

4) Not exactly sure on this one, but it doesn't make much sense to me. I know miners sometimes decide to mine an empty block. Not sure what is the benefit though, could have something to do with network propagation. Maybe someone else could shine some light on this.


How to find a list of all nodes in a p2pool network? I'm running a p2pool node for cachecoin and see there are more users and hashrate in the overall p2pool network than from the known nodes.

Is there a way to get a list of the connected nodes somehow, maybe by IP?

All I see currently is the web frontend and the stdout buffer.

The answer is p2pool-scanner.

A little piece of javascript with minimal webserver (NodeJS) which keeps scanning your local p2pool-data directory for node ips and scans all nodes for public html frontend. If it finds a public accessable frontend, it will add it to a list of public nodes and displays the results sorted by uptime.

Its easy modified (scanner.cfg) to work with any *coins p2pool network.

Here is an example node scanner for vertcoin: http://q30.qhor.net:9172/


I sent bitcoin from electrum but never received it , has been confirmed but I can’t tell what’s happened to the btc. Can anyone help me out? Should be a picture included if information !

Looks like you downloaded a malware version of Electrum and sent bitcoin using that. The output address in that transaction starts with bc1. I'm guessing that's not the address you intended to send the coins to? The malware replaced the address with its own. There is nothing you can do about it now. If you want to use cryptocurrency on the same system you should do an OS reinstall first in case there were secondary infections from the malware. Sorry for your loss.


Why would Bitcoin Core freeze my computer when syncing? And is it supposed to take this long? 24 hours ago, I finally bit the bullet and dug up my old computer, set it up physically, installed Linux Mint (with full disk encryption), installed Bitcoin Core through its software manager, started it, immediately selected "pruned mode" in the settings (kept it at default 2 GB since I have no idea if it's good or bad to increase/decrease it), closed it and started it again, to let it sync from scratch to 100%...
When I went to bed, it seemed awfully unresponsive, with mouse movements taking several seconds before they showed up on the screen.
When I woke up just now and looked at the progress, it was still at 21%, with "10 weeks left". It now would not at all react to any attempts to close it or click on anything. I had to "hard-cut" the power to the machine and restart it. Now I'm again running Bitcoin Core and so far, it seems very responsive and says "10 days".
It's connected directly to 100/100 Mb/s fiber, and the hardware is 3 GB RAM and a 2011-era Dell CPU. Dual core something. The HDD is 250 GB and mechanical. (Which is why it was not a choice to store the entire blockchain and I had to use pruned mode right away.)
I don't know what to make of this. My guess is that it was not actually doing any work during the entire night, instead having somehow "hung". I sure hope it's not some hardware issue or something, because that machine is the only practical means for me to have a decent chance of setting up a secure new wallet for cold storage.
Others online seem to be talking about "hours" to sync, but this seems like it at best will take at least four days, if everything goes perfectly and progresses exactly like it has so far, minus the hanging. And again, the program itself is talking about "10 days"... nope. Now it says "6 days". I just looked over at the screen.
Basically, I have no idea what's going on.

If your computer has some problem during the night, maybe the download never started, but it is normal that your bitcoin core is not in complete sync at the moment because the velocity of Sync doesn't depend on type connection (well it is part of the truth, if you have a slow connection, it is a problem).
In addition, I run a pruned sync on this days on my Linode node and I can share the data.
Before doing that I run the bitcoin node on a Linode server of 5$ and it runs without problem.
The space on the machine is 25Gb (Wow :-P) and it use only around 2/4 Gb I don't know well this data.
To prove that the connection is not important for the upper bound limit of velocity I can the Linode data where the VM works to sync the Bitcoin Network.

In addition, your bottleneck can be the disk, I know that in an HDD the synchronization is a little slower and it is also possible that you have a delay on the Bitcoin core answer. For instance when you run a command like getblockchaininfo. But this really depends on your Computer conf and HDD quality. In addition, I don't know if your disk encryption, can make things slower, I don't know this because I never use disk encryption (I like privacy but I like to pull my data if my Linux has some kernel panic :-) ).


Where do bitcoins come from and what gives them their value? Where do bitcoins come from?  From the WeUseCoins.com video it appears they are just being produced by "miners" and sold to people.  So who backs Bitcoin or gives it its value?

Although individual bitcoins enter the Bitcoin economy as miners are rewarded for processing transactions, it's much more helpful to think of all 21 million bitcoins as having been created when Satoshi Nakamoto defined the Bitcoin protocol and launched the Bitcoin network in 2009.

The reason for this is that the Bitcoin protocol specifically defines and controls when and how a limited total number of coins are rewarded to miners for the job of securing the Bitcoin network.  These "bitcoins" are really just mathematical tokens which are very carefully controlled by the network protocol to prevent counterfeiting, theft, etc.

By agreeing to use these mathematical tokens as money, the larger Bitcoin community is essentially "backing" their value and turning them into a currency in the same way traditional African and Asian societies used the money cowry despite the absence of any central bank.  Unlike the money cowry:

there will never be more bitcoins
they are impossible to counterfeit
they can be divided into as small of pieces as you want
and they can be transferred instantly across great distances via a digital
connection such as the internet.

Presumably, the members of the Bitcoin community who choose to accept them as money consider these features to be worth something, and value the bitcoin accordingly based on supply and demand on open currency exchanges.

Because bitcoins are given their value by the community, they don't need to be accepted by anyone else or backed by any authority to succeed.  They are like a local currency except much, much more effective and local to the whole world.

So to sum up, bitcoins come from the Bitcoin community's agreement to follow a set protocol, and are backed by everyone who uses them as money.


The asm strands for assembly, which is the symbolic representation of the Bitcoin's Script language op-codes.

In this particular case we have 2 pieces of data that go to the execution stack.

The transaction signature:

304502201fd8abb11443f8b1b9a04e0495e0543d05611473a790c8939f089d073f90509a022100f4677825136605d732e2126d09a2d38c20c75946cd9fc239c0497e84c634e3dd01

And the public key of the input's address:

03301a8259a12e35694cc22ebc45fee635f4993064190f6ce96e7fb19a03bb6be2

Notice that the hex and the asm are almost the same except the 48 in the beginning and 21 towards the end. These are op-codes that tell the interpreter to put a  specific amount of bytes to the stack. So in the case of the signature it tells to put 72 bytes (0x48) to the stack and 33 bytes (0x21) for the public key. Check here for more info https://en.bitcoin.it/wiki/Script#Constants


Txindex=1: how to recognise the blockchain with this option? This might be a dumb question: I started the Bitcoin daemon for an initial blockchain download. It immediately started downloading, I edited the Bitcoin.conf file with txindex=1. Stopped and restarted the daemon. How can I be sure the blockchain has txindex=1 correctly set? Should I reminded with the command line Bitcoind -reindex

How can I understand “looking” at a blockchain (day I downloaded from a torrent) that has txindex=1? Thanks

You can check the debug logs (might require -debug flag) and see if it is indexing transactions:

$ tail -f ~/.bitcoin/debug.log

You can also try to get a transaction by txid, and if it returns transaction data, then the blockchain has been indexed for transactions (might have to wait for sync to complete):

$ bitcoin-cli getrawtransaction {txid}


Eclipse attack vs. Sybil attack I came across this paper Eclipse Attacks on Bitcoin’s Peer-to-Peer Network ∗ that sounds very similar to the Sybil attack.

Can someone point out the difference between both attacks.

An eclipse attack is when most (if not all) of your peers are malicious and they basically prevent you from being well-connected to the network to obtain information about transactions you're interested in. An eclipse attack is particular useful when a payer has sent some bitcoins to you in some transaction, then decides to also doublespend the same bitcoins. The doublespender (or payer) will use the eclipse attack to prevent you from knowing that there is also a doublespend transaction out in the open, so you get misled into believing that there's only the original transaction.

A sybil attack on the other hand is where a malicious actor is trying to spam the network with nodes that they control attempting to subvert the network's reputation system. For example, false signalling of support using version bits.

To summarise, an eclipse attack is targeted at a single party; whereas a sybil attack is network targeted. In the context of bitcoin, a sybil attack is not particularly harmful since all nodes operate based on consensus rules and any deviation will lead to said node getting DoS banned.


What is the meaning of 'change' and 'reserve' in a Bitcoin Core wallet dump? I'm using libwally to derive addresses from an extended private key. I shared the seed with Bitcoin Core (loaded it in a blank wallet with sethdseed), and noticed that there are 2 addresses in the dump of the wallet file under the same derivation path, one is labeled reserve=1 and is the same that I derive with libwally, the other is labeled change=1 and is different.
I have a few questions about this:

what is exactly the meaning of reserve and change? My guess is that reserve are normal reception addresses and change are, well, change, but I'm still wondering if there's some meaning more specific to Bitcoin Core.
I thought that change addresses were derived with a different path, like the reception addresses all end with ../0/{index} and change with ../1/{index}, or is Bitcoin Core doing things differently of say Electrum?
Besides I wonder how to generate 2 different key pairs with the same master key and path, could I have generate the change address with libwally too?

[EDIT] After doing it one more time I only have one address with the same path in the dump file of Bitcoin Core, so I guess I made a mistake last time, I'll explain it here in case it helps:
To create a wallet with a seed you choose yourself you need 2 commands, createwallet and sethdseed. Besides the required wallet_name, createwallet also takes an optional blank argument. By default it is false, and the command will use a random seed to generate a key pool. But since we want to use our own seed, we need to set it to true. If you dump the newly created wallet, it will be blank, no master key, no key pool, nothing. Then only you can sethdseed with a 32B seed encoded in wif format.
I was having 2 keys under the same derivation path because I first created a wallet with a random seed, and then added my own with sethdseed, so I was having 2 key pools in my dump file. As Andrew said in the answer, it is impossible to have 2 different key pairs with the same master key and path.

what is exactly the meaning of reserve and change? My guess is that reserve are normal reception addresses and change are, well, change, but I'm still wondering if there's some meaning more specific to Bitcoin Core.

reserve means that the key is in the keypool and has not been used yet. This is used for both change and receiving addresses as there are keypools for both.
change means that the key is used for change addresses.

I thought that change addresses were derived with a different path, like the reception addresses all end with ../0/{index} and change with ../1/{index}, or is Bitcoin Core doing things differently of say Electrum?

They are. Bitcoin Core uses m/0'/0'/i' for receiving addresses and m/0'/1'/i' for change. However if you have an older Bitcoin Core wallet, this split doesn't exist and there's only one keypool. But if you are using sethdseed, that shouldn't effect you.

Besides I wonder how to generate 2 different key pairs with the same master key and path, could I have generate the change address with libwally too?

There aren't 2 different key pairs with the same master key and path. Bitcoin Core doesn't do this, and that is not possible with BIP 32 (or any BIP).


How can you find out what is the latest block number? When running a fresh client, or after not being connected for a while, the client takes some time downloading new blocks. How can you find out what is the target block number (the id of the newest publicly available block)?

All these sites display the total block count:

http://blockexplorer.com/
http://bitcoincharts.com/
http://bitcoinwatch.com/

BlockExplorer also has an API that among other things lets you get the latest block count.


Determining sender/receiver address in transaction Suppose that I were given a wallet address, i can retrieve all the transactions for the particular address.

My question is:

1) Assuming the wallet address is sender, how could it determine the receiver of the address? Vice versa if the wallet address is receiver, how could it determine the sender address from transaction detail? I have seen few transactions but couldn't think a full proof solution to it.

Taking this transaction as example, how could i know which address actually initiate send bitcoin transaction to the wallet address mz95VxTekXHVZCPVjtK7pF2dMa7yF8QMkM.

2) Using the same transaction id, how could i know the miner fee paid by a particular sender? I know that the both sender address pay a total of 0.000035 BTC fee, but how do I know how much each of them paid initially (the miner fee each of them set before sending transaction)?

There is no 1-to-1 mapping between senders and recipients. That's why things like CoinJoin is possible. Transactions are split in two parts: inputs (that redeem previously unspent outputs) and outputs (that send the coins). The redeemed coins are essentially pooled together before being sent so at this point there is no notion of which coin is which.

The transaction fee are also paid by this pool so no one specifically paid for the transaction but the sum of the inputs.


How do I recover newly created bitcoin addresses from an older wallet.dat? I had a bitcoin wallet and several other coins' wallets on my laptop and did a backup for my wallets several months before the laptop died.  Between that time, I had created several new bitcoin addresses.  After running several disk recovery tools, and they all told me that the wallet.dat files on my crashed hard drive were unrecoverable.

When I run bitcoin cliet using the older wallet.dat files, my newer addresses don't show up and my balance is incorrect.

Is there any way to fully recover addresses that were create AFTER the most recent walled.dat backup was created?  This can pose quite a problem since I have no access to the coins associated with the newly created addresses.

Any insight would be greatly appreciated.

Unfortunately, this is not possible. One of the disadvantages of non-deterministic wallets is that when new keys are needed and the key pool is empty, they are generated randomly. If the new wallet is lost, there is no way to extract those keys from an older wallet.


Why is JSON not used in the Bitcoin P2P protocol? The Bitcoin P2P protocol uses its own serialisation format for the transferred data.
Is this serialisation considered as more secure against DoS attacks than JSON?

I do not know if there are any comparisons of the security difference between Bitcoin's P2P messages and JSON, but the binary format is certainly more compact than JSON.
I think it would be reasonable to assume that there are security implications, but security likely was not the major concern when the P2P format was initially defined. Rather ease of implementation and message size were the likely concerns.
A binary format is simply smaller and more compact than JSON strings. Strings take up a lot of space, especially strings for data that represent bytes. Furthermore, it takes more logic and time to convert binary data to a string, then convert it back from a string once received. Any string encoding for binary data is not going to be as efficient as the binary itself. For data that the user is never going to see, and with a protocol that isn't text based, using JSON is not reasonable.
Lastly, while security concerns likely were not behind this decision, there certainly are security implications for choosing a binary format over JSON. Variable length string parsing has traditionally been a source of security problems in many different software. As JSON is string based, there is the potential for anyone implementing something that uses JSON to make a mistake that introduces a serious vulnerability in their string parsing. So a binary format would be better in that regard.


Bittrex websockets: How to get the order history? Using the Bittrex websockets API I am able to get the summary updates for all markets and also the exchange updates for specific markets.

However, I am not able to receive the order history (as opposed to updates).

The market exchange updates are regularly received after invoking the hub method: "SubscribeToExchangeDeltas".

I am trying to get the order history via invoking the hub method: "QueryExchangeState".

But this does not seem to work and I don't get an error either ... ?

Does anyone have experience with this or has the same problem or knows a nifty trick, please let me know!

The code I am using is like so:

import pprint
from requests import Session  # pip install requests
from signalr import Connection  # pip install signalr-client

def handle_received(*args, **kwargs):

    print('\nreceived')
    print('\nargs:')
    pprint.pprint(args)
    print('\nkwargs:')
    pprint.pprint(kwargs)

def print_error(error):
    print('error: ', error)

def main():
    with Session() as session:
        connection = Connection("https://www.bittrex.com/signalR/", session)
        chat = connection.register_hub('corehub')
        connection.start()

        connection.received += handle_received
        connection.error += print_error

        for market in ["BTC-MEME"]:
            chat.server.invoke('SubscribeToExchangeDeltas', market)
            chat.server.invoke('QueryExchangeState', market)
            pass

        while True:
            connection.wait(1)

if __name__ == "__main__":
    main()

So ...it turns out from correspondence with a Bittrex developer that it is currently not possible to get the order history via websockets.

One has to revert to the "normal" public API for this: https://bittrex.com/home/api


What can blockchain do that normal databases systems won't? Aside from cryptocurrencies, what advantages may blockchain(either public or private) have and real life use cases that can be more useful implemented in blockchain over traditional databases based systems ?

Blockchains are data structures, whose only advantage is that storing data in that structure allows you to achieve decentralization under certain conditions.

So your question reduces to "how is decentralization important"?
Decentralized systems tend to have the following favorable attributes:

Open (anyone can participate; not permissioned)
Borderless (as long as you can reach one other connected node, country/regional borders don't matter)
Neutral (the system doesn't care what you use it for)
Censorship Resistance (transactions/data entry is unstoppable)
Trustless (falsified data is easily detectable by verifying across multiple nodes)
Immutability (data cannot be removed or altered)
Public


Multi-sig signature computation I don't understand, how multi-sig signatures are generated.

I've seen that inputs redeeming a multi-sig output, can be signed and signed over repeatedly, with different private keys using bitcoind's signrawtransaction, as it is done here.

But like this, the more and more signed transaction would need to be passed around among the different parties of the multisig.

Isn't it also possible to let the different parties of the multi-sig, individually produce their signatures, send them to one place, where they then are assembled to a scriptSig redeeming the multi-sig output?

Yes you are correct. The signatures are produced separately, by each signer and then combined into the final input script. When an individual is signing, he/she is not signing the a transaction with the signature of others, only the transaction sighash, where no signatures are committed yet.


Is new cryptocurrency that runs only in raspberry pi possible? Is it possible to create a cryptocurrency software that can run efficiently on a raspberryPi and has a mechanism to detect (based on maximum coin production?) if a node is using a better computer so the swarm rejects it's coins?

It possible to inject hardware detecting code into code of your mining software, but to protect the mechanism you cannot publish it as an open-source. That will make your currency not so popular as others. Even if you will be succesful there are people that will change the Raspberry Pi CPU and pass-by your mechanism.


What a completely-decentralized cryptocurrency might look like It occurred to me that a more useful cryptocurrency would be one which didn't require a network to validate transactions. It would consist of some kind of (self-mined?) token that can be proven to be unique and to be "owned" only by the holder and likely be associated with a wallet. Spending it would simply change the token so that it's associated with a different wallet. Something like this might be even more fungible than a fiat note having a serial number.
Has a white paper been released describing a token which precludes doublespending without needing a network, at least after it is initially created?

Sounds nice, but may pose some challenges.
HashCash, bit gold, and b-money all tried to use self-mined proof of work as cash directly. Those projects were unable to solve the doublespending problem as they did not feature a global consensus system. DigiCash on the other hand was able to solve doublespending but required a central operator to clear payments and issue new tokens—shutting down the operator meant that the currency stopped existing.
Bitcoin's great breakthrough was that it provided a practical solution to the doublespending problem without a single point of failure. It combines the strengths of the above two approaches into a system where network participants both issue coins and decentrally author the global state. The latter removed the need for a central operator, while still providing the referee function which enabled every participant to locally resolve the doublespending problem.
What you describe as

"some kind of (self-mined?) token that can be proven to be unique and to be "owned" only by the holder"

is essentially a description of the doublespending problem: how do you guarantee that a digital good cannot be transferred multiple times?
So, your proposal boils down to a suggestion that we would "only need to find another, even better way of solving the doublespending problem" and then we'd be able to create an even better cryptocurrency. Sounds about right, but might be a bit optimistic since this solution already took a few decades to emerge, and the requirements you describe sound a lot more challenging.


Different candle positions in coins with same OCHL values Why do candles sometimes have different positions and sizes even when the open-close-high-low are all of the same value?

For instance in one coin I saw: DigitalNote(XDN) the price has been consistent at 0.00000030 for a while, yet the candles are of different sizes.

In this image, the last two candles both have O=0.00000030 C=0.0000030 H=0.0000030 L=0.0000030

Yet somehow the candles are of different sizes.

What's going on?

Keep in mind exchange data might not be reliable in all instances due to the way they have it implemented. Your best bet is to see if the exchange can provide a data field of historic prices and then plot it yourself using excel.


Question about UTXO and indivisibility I'm reading about the concept of UTXO. Everywhere I read, it says that a UTXO in an account is indivisible. One analogy said: "It's as if you wanted to make a $5 purchase with a $10 bill. You wouldn't tear the bill in half."

Let's say I have 0.1 BTC as one coin in my wallet and I want to send 0.05 to someone. What I'd do (minus the fees) is send 0.05 to the person and 0.05 coin back to myself, right? That is, it will be marked in the coin's ledger that I and they respectively are assigned that fraction of it. At the moment of the transaction, wouldn't the coin be split?

Also, at the moment of original mining, aren't all new coins worth 1 BTC? If that is that case, they must be split in some way at some point. Otherwise, the amount of bitcoin that people own in the world would all be integers.

A Satoshi is the smallest unit of account within the Bitcoin network that can be transacted. One BTC equals 100,000,000 Satoshis.

The 0.1 BTC in your example is 10,000,000 Satoshis. 5,000,000 Satoshis are applied the that special person in its own UTXO, and 5,000,000 Satoshis minus mining fees are sent back to yourself to another address, and is recorded as another unspent transaction output (UTXO).

A UTXO is defined by a transaction's ID and the output index of that transaction.  For each successful transaction whose outputs are unspent, each output is a UTXO. An additional point is UTXOs are atomic in the sense all of a UTXO's balance is spent or none of a UTXO gets spent in a transaction.

FYSA - In the future, we might see the term UTXO deprecated with the term called payment.


When closing the channel for LN - how to calculate the fee for the blockchain transaction? To be clear: Following is not about fees in Lightning Network. Following is about fees on blockchain for transaction which closes the channel in LN.

Channel closing transaction can be created months before broadcasting to blockchain network. How the fee for the blockchain transaction is calculated without knowing the (far) future situation in mempool?

Is replace-by-fee possible for LN's closing transaction? There are different types of closing transaction — maybe answer is different for each type of closing transaction.

Is the fee calculation related to current situation in mempool? I found some calculations here, but I didn't found any relation to dynamically changing situation in mempool.

If worried about the original closing transaction having too high of fees:

The signed closing transaction that you're worried about (with too high of fees) has not yet been broadcast to the network, so no harm no foul (yet).

If the two parties are cooperative, they can just agree to sign a new transaction with lower fees and broadcast that to close out the payment channel (this should be advantageous for both of them anyway).

If the two parties are NOT cooperative, it might be best to just broadcast the original closing transaction and eat the fees.

  Is replace-by-fee possible for LN's closing transaction?

Replace-by-fee only applies to transactions that have already been broadcast to the network. Also, they only help if you're increasing fees, not decreasing them, so it doesn't apply to this situation.

If worried about the original closing transaction having too low of fees:

If the two parties are cooperative, you can just sign a new closing transaction with higher fees and broadcast that.

If the two parties are NOT cooperative, just broadcast the original closing transaction and hope that the transaction does not get stuck in the mempool. Also make sure that the original closing transaction has a high enough fee that there is little worry about it getting stuck in the mempool. Even somewhat non-cooperative parties should be willing to re-sign and lower the fees to close out the payment channel. Overall, this is the trickier scenario to predict.

  Is replace-by-fee possible for LN's closing transaction?

Again, replace-by-fee only applies to transactions that have already been broadcast to the network. Also, this would require a cooperative party.


On the feasibility of fees According to https://bitcoinfees.21.co/, "For the median transaction size of 226 bytes, this results in a fee of 0.678 mBTC."

At the time of writing this equates to approximately $1.53US.

This means that many bitcoin transactions are infeasible (e.g. buying a cup of coffee).

As a result I have a few questions:

Is it possible to anticipate what fees will be in the future (i.e. are they likely to increase, decrease or is it unknown?)
Can changes be made to the bitcoin system to encourage a reduction in transaction fees?

In my limited understanding, I cannot see how this currency has a future when the transaction costs are so high, so I'm interested in whether there is a solution to this, or if it is simply an inevitable part of the bitcoin system?

1) Bitcoin is a gossip network in which each (full) participant checks all activity of all other (full) participants. Such systems scale notoriously badly as the cost for each network event scales quadratically. Simple example:

Three participants creating three transactions leads to six transaction relays and verifications.
Six participants creating six transactions leads to thirty transaction relays and verifications.
Twelve participants creating twelve transactions leads to 132 transaction relays and verifications.

As you can see this obviously becomes unsustainable as more people adopt the network. Thus, a limit is needed to keep the workload manageable which is currently expressed in a consensus rule that limits the number of bytes per block to 1,000,000.

2) If we cannot process an unlimited number of transactions, there must be some sort of prioritization for transactions to get selected. At first Bitcoin transactions were confirmed by prioritizing larger and older transaction inputs, ensuring that everybody would get their turn. At some point block space demand was large enough that many blocks filled up and not every transaction would be confirmed within a few blocks. The miners gradually switched to a more efficient mechanism: Instead of prioritizing old inputs, they selected those transactions that maximized their revenue per block. Thus, transactions were sorted by largest fee rate, and an efficient fee market was established.

3) We've now reached the point where fees don't even drop significantly in traditionally low-demand times such as the weekend. Since transactions are selected by the fee rate per data size, transactions that transfer more value can naturally bid a higher fee than transactions of lower economic value. (Note that the amount of value transferred is decoupled from the data size of a transaction.) As transactions transferring thousands of dollars worth of money can easily pay several dollars and remain competitive with other payment services, it's obvious that low-value use-cases will be the first to get pushed out of the blockchain.

4) Strategic thought: The latter will occur inevitably, as even if we could sustain blocks of 1,000GB, only ~3,000 transactions per second would be possible—way too little for all sorts of microtransactions to remain feasible. If we had kicked down the can the road several times already as fee pressures started to peak, we'd eventually be in the situation where we'd have a community and industry accustomed to not having to deal with fee pressures, with wallets not having code to handle fee estimation, services not having logic to deal with unconfirmed transactions, and large business use-cases built around the availability of cheap blockspace—an utterly unsustainable expectation.

5) Personal opinion: It is thus important for the longterm development of the Bitcoin system to keep some fee pressure sustained in order to create the anticipation of the eventual exodus of micropayments as it will in the longterm be impossible for these payments to be on the blockchain. After seeing 530 satoshi/byte last week, we are overshooting at this point, and it's high-time to increase the capacity of the Bitcoin system. As I'm convinced that any hard-fork attempt will lead to two persistent forks of the Bitcoin blockchain, my preferred approach is to activate SegWit which has been tested for more than a year, and is active on multiple altcoin networks. Besides gradually providing more capacity as the network adopts the new segwit transaction format, it has better scalability properties for transaction verification, and provides the foundation for additional capacity and scalability improvements such as Lightning Network, Schnorr signatures, and signature aggregation.


Why didn't the difficulty adjust for the first 30,240 blocks? I'm working on showing the difficulty adjustments over time, and I've noticed that the first difficulty adjustment did not take place until block 32,256:

http://learnmeabitcoin.com/explorer/node/difficulty/

Why is this?

Because blocks were not being mined in less than 10 minutes on average during this time (so the difficulty would only decrease and not increase), and the difficulty cannot go lower than 1.


Sent bitcoin with no history of transactions I sent 0.029044 bitcoins a few hours ago to this address 16CCgdxQ1qc89Yp2rZwzBx4Pfw83DtCyrP but don't see them yet. My account balance has become zero with no history of transactions. What should I do? Can I return the bitcoins? How to see a transaction if it is not in the history?

Everything is fine, the bitcoins are back.
With some peculiarity:)


In the case that I have free electricity, is mining worth it? As the title indicates, I have three options that are gonna make me free of charge in terms are electricity, which I describe below:

I have free access to electricity. I can have as much as I want power, to turn on even 10 computers simultaneously.
I do have free access to AWS / Azure servers with a good condition of ram and CPU.
I have huge clients on my website, so I can run some JavaScript's that are mining in their computers, or even implement the code inside a game.

In many places, I have read that mining using a PC doesn't worth the electricity. What about my case? Is it worth to do it? Do you recommend that I buy physical device for mining, or I can use a normal computer?

I have to tell that my Internet is 4G network for free electricity and not a lot of bandwidth.

First, mining does not require a lot of bandwidth. Whatever you have is likely enough.

Second, mining profits (in bitcoin, not some currency after exchange) is determined by difficulty. Difficulty is like a level number. The higher it is, the harder it is for mining computers to hash (the under-the-hood work).

Calculating mining profits only needs the current difficulty and your hash rate. Google search "Bitcoin mining calculator" to use one of the many good ones available.

Regardless of electricity costs, mining on:

computer processors or graphics cards is going to yield a very low profit. Probably not worth your time.
AWS has probably been discussed before, but again will likely be far too low hashing power to be worth it, plus you'd have the service fees.
other's computers with JavaScript is a relatively new and interesting idea, but again is such a low hash rate that it's only worth it if you have thousands of clients running your script. There's also the dubious nature of the proposal (do you have permission?).

Mining on specialised hardware, called ASICs, is very profitable if you don't consider electricity. But current models consume much, over 1000W all of them, and are very noisy and push out a lot of heat.


How to verify Wrapped Bitcoin (WBTC) issuance I'm trying to understand how Wrapped Bitcoin (WBTC) issuance can be verified.
The WBTC custodian, BitGo, published the following material:
https://wbtc.network/dashboard/audit
This is a list of Bitcoin addresses linked to Blockstream explorer where you can verify the UTXOs each address has access to (wallet balances, if you will). The sum total of these balances is equal to the amount of WBTC minted by BitGo.
However, how do I know that BitGo has the private keys for those UTXOs? Am I supposed to just accept the bonafides of BitGo and their audits, or is the a technical way to remove that trust?

However, how do I know that BitGo has the private keys for those UTXOs?

You need to trust Bitgo that they have the keys.

Am I supposed to just accept the bonafides of BitGo and their audits, or is the a technical way to remove that trust?

Those transactions and UTXOs are only helpful in transparency to some extent and keep track of things. You still need to trust BitGo for everything involving WBTC token.
Also there can be other issues with such tokens: https://twitter.com/jchervinsky/status/1344385524086161408
Anyone can create such tokens and publish some data on their website for random transactions. Example: I can create a token on a network which has nothing to do with Bitcoin. Use the symbol "PBTC" for it. Do some transactions, share some UTXOs on website and the marketing team promotes it as "PBTC scales Bitcoin and is better than Bitcoin". People who use this token will have to trust me, use the network that it was created for and imagine it is same as BTC because symbol "PBTC".


To generate private key How can I generate a private key to spend the bitcoin of a watch only addresses that is in the imported addresses of blockchain.info?

One cannot "get" the private key from a watch only address. There is ECDSA logic and several hashing functions, that (as per today's knowledge) prevent this.

The priv key is generated in the wallet, via ECDSA you come to the public key, which is hashed and checksum'd and base58encoded into a bitcoin address. These hashing functions are a one way logic...

The answers here are fairly generic, and deserves probably a whole chapter of a book: Andreas' has it already explained in his book "Mastering Bitcoin". It is an amazing book that'll definitely get you to go. It's freely available online here. Look into chapters 4 and 5, that will explain ECDSA and wallets setup, followed by chapters on keys.


How many addresses can an Electrum Seed generate? If I generate too many, they go red for some reason. So what is the maximum amount of addresses that a seed can make?

You don't need to worry about red addresses. Just remember roughly how many of those there were if you ever send money to one of them.

There is no practical limit of how many addresses Electrum can generate from a seed. To figure out, how much money you have in your wallet, Electrum needs to sum up the funds in your addresses sequence – of which I just said that it doesn't have a practical limit in the number of its elements. This causes a problem: When should Electrum stop checking for more money further down the address sequence? The solution is to introduce a gap limit g.

When Electrum sums up the money in the addresses, it has a counter c which is incremented every time an address has no recorded transactions and set to 0 every time it does. If c > g, Electrum stops.

By default, g is set to 20 since Electrum 2.0. Addresses beyond the gap limit are red. If money is sent to one of them but never to the g addresses before them, Electrum will not look for it.

The gap limit also determines how many unused addresses you're shown if you don't generate new ones.


Will the lightning network reduce BTC Liquidity due to "locking-up" funds in channels? How will people be able to buy and sell their BTC if all of it is locked inside Lightning channels?

Lightning Network payment channels are not really "locking up funds". Your funds are not locked, you can still send money to people and transact over the Lightning Network, even if you don't have a direct payment channel with those people. LN lets you route payments through others. So if you wanted to sell some Bitcoin and you have an open LN channel, then you can route your money to an exchange that supports LN and thereby deposit your coins. Then you can sell them. In your LN channel, you would have 0 Bitcoin, so you have actually sent your Bitcoin elsewhere.


BTC stuck with zero confirmations I sent BTC from my blockchain.info wallet to my other wallet 6 hours ago. It is still at 0 confirmations.

Further Detail:

the network  propagation is very low at 0-1%
I used the recommended fees setting(the middle setting)
I sent a couple cents from the same wallet to the same receiving wallet and it went through to 3 confirms after about an hour or so.
my wallet is :
and the hash is:

So, now I'm stuck and can't find any info online that I understand to help me with this.  Any help will be very greatly appreciated.

When you look at blockchain you will see that your transaction contains 0.0001 BTC which is not zero fee, so it is very likely that your transaction will be confirmed.

You have various options if the transaction doesn't get confirmation:

Reset your blockchain and wait until it's up to date again (keep your device on power and connected to internet). After the rescan, stuck transactions should be gone and your BTC free to spend again.

OR

Relay stuck transactions to a miner that accepts non-standard fees. You can use the trusted peer option for this, just remember to clear that option after your problem is resolved. Also see https://en.bitcoin.it/wiki/Free_transaction_relay_policy.

From: UnstickLowFeeTransactions

Note: There is certain time after blockchain.info clears the transaction if it isn't taken by any miner +- 72 hours. I would recommend you wait this time.

OR

Download electrum or any bitcoin client
Dump your private keys from blockchain.inf and import them. Use Pywallet to delete that transaction from your wallet.
Create whole new bitcoin wallet at blockchain.info and sent entire transacion again. (Wallet mustn't be created under same account).
send your transaction again.

Conditions for confirmation of zero transactions:

Transaction is smaller than 10 thousand bytes.
All outputs are 0.01 BTC or larger.
Its priority is large enough (see the Technical Info section below)

https://en.bitcoin.it/wiki/Transaction_fees

Source of my post:

https://bitcointalk.org/index.php?topic=274185.0

https://bitcoinarmory.com/download/troubleshooting/


RPCPORT and --rpcport not working in Latest version: 0.18.0 We are using bitcoin core RPC Endpoint to broadcast transaction over network, It was working perfectly till version 0.17.0 but in latest version 0.18.0 RPCPORT and --rpcport is not working.

Please let us know is there any way to start RPC port on version 0.18.0

See the 0.18 release notes (https://bitcoin.org/en/release/v0.18.0#configuration-option-changes):

  The rpcallowip option can no longer be used to automatically listen on all network interfaces. Instead, the rpcbind parameter must be used to specify the IP addresses to listen on. Listening for RPC commands over a public network connection is insecure and should be disabled, so a warning is now printed if a user selects such a configuration.


Is the Mycelium HD wallet private key stored encrypted on the device? haven't found details on that in the net.

My concern is that I'm using a corporate (bring you own device) phone. We have to install a "security" app running with administrator rights.

IMHO this app can read EVERYTHING what is on the device. I'm pretty sure. Therefore, is the private key of the Mycelium HD wallet encrypted (with the PIN hopefully) when stored the device?

Any thoughts?

Yes, Mycelium stores an encrypted copy of your key, protected by your PIN (if applicable) on the device. This includes any individual private key accounts you import.

In general, I would advise against storing crypto keys (or any private keys or confidential information, really) on a corporate device (laptops, phones, desktops, email accounts), or even a device others can access regularly.


You should create a P2SH address containing the hash of that script, and when you want to spend, you can spend from that P2SH address. This'll make your transactions standard.


Is the dust output limit the same for p2wpkh and p2wsh? I've seen mentioned in a few places that the dust limit for an output to be considered standard is minRelayTxFee*3. Based on this, I would expect the dust limit for a p2wsh output to be larger than for a p2wpkh, since CTxOut for p2wsh is larger (43 bytes versus 31 bytes).

However, when I look at the code in policy.cpp, it seems to only care about whether the output follows a witness program, and not whether it is p2wpkh or p2wsh. So does that mean the dust limit for a p2wsh output is also 294 satoshis?

I just realized that there are in fact these two lines which takes into account the size of CTxOut:

size_t nSize = GetSerializeSize(txout);
...
...
nSize += (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4);

so based on this, a p2wsh output (43 bytes) would have a dust limit of:

= 43 + (32 + 4 + 1 + (107 / WITNESS_SCALE_FACTOR) + 4)
= 110 bytes

then using the current dust_relay_tx_fee of 3000 sat/kilobyte (or 3 sat/byte),

110 bytes * 3 sat/byte = 330 satoshis

Therefore, p2wsh outputs with less than 330 satoshis will be considered non-standard and will be rejected.


MtGox websockets api returning "400 Bad Request" I want to get started with the Mt. Gox websockets API, but I can't seem to get a good response from the server.

I'm sending the following (captured with Wireshark):

GET /mtgox HTTP/1.1
User-Agent: websocket-sharp/1.0
Upgrade: websocket
Connection: Upgrade
Host: websocket.mtgox.com
Sec-WebSocket-Key: LtH+YFgnW1N8KDLDbocsUQ==
Sec-WebSocket-Version: 13

and the server responds:

HTTP/1.1 400 Bad Request

I've tried sending the handshake via telnet and with this C# code and I still get a 400 Bad Request error:

class Program
{
    static void Main(string[] args)
    {
        ClientWebSocket ws = new ClientWebSocket();
        Task connectionTask = ws.ConnectAsync(new Uri("ws://websocket.mtgox.com/mtgox"), CancellationToken.None);
        Console.Write("Connecting");
        while (!connectionTask.IsCompleted)
        {
            Console.Write(".");
            Thread.Sleep(100);
        }
        Console.WriteLine(ws.State);
    }
}

(The last line printed is "Closed" and when I inspect the handshake with Wireshark I see the same 400 Bad Request)

Any ideas what I'm doing wrong? I can't see much documentation or samples using the websockets API so I don't really have anything to compare to :(

In response to sta's suggestion, I tried this (using WebsocketSharp):

static void Main(string[] args)
{
    WebSocket ws = new WebSocket("ws://websocket.mtgox.com/mtgox");
    ws.Origin = "http://websocket.mtgox.com";
    ws.Connect();
    ws.OnMessage += (sender, e) =>
    {
        if (!String.IsNullOrEmpty(e.Data))
        {
            Console.WriteLine("{0}", e.Data);
        }
    };
    Console.WriteLine("{0}", ws.IsAlive);
    Console.ReadLine();
}

This displays FALSE so there's still something I'm doing wrong :/ I haven't had a chance to dig into WebSocketSharp yet though

Update:
With WebsocketSharp setting the Origin header correctly, Wireshark shows the mtgox server accepting the websocket upgrade:

HTTP/1.1 101 Switching Protocols\r\n
Upgrade: websocket\r\n
Connection: Upgrade\r\n
Sec-WebSocket-Accept: 2+1ghzJ/Itt6w1aBdUteghcsJHk=\r\n
\r\n

But WebSocketSharp still reports the connection as closed :(

It seems that the client should send the Origin header in opening handshake to the MtGox server.

If you use current websocket-sharp, you should do like the following before connecting.

ws.Origin = "http://websocket.mtgox.com";

Could you try?

Update:

Could you try again the following code?

static void Main(string[] args)
{
    var ws = new WebSocket("ws://websocket.mtgox.com/mtgox?Currency=USD");
    ws.Origin = "http://websocket.mtgox.com";
    ws.OnOpen += (sender, e) =>
    {
      ws.Send(
@"{
    ""op"": ""unsubscribe"",
    ""channel"": ""d5f06780-30a8-4a48-a2f8-7ed181b4a13f""
}"
      );
    };
    ws.OnMessage += (sender, e) =>
    {
        if (!String.IsNullOrEmpty(e.Data))
        {
            Console.WriteLine("{0}", e.Data);
        }
    };
    ws.Connect();
    Console.ReadLine();
    ws.Close();
}

It seems that an exception has occurred when the client is receiving ticker type data in a while.

I'll investigate a little further.

Update:

I've found out the cause of the exception, and fixed websocket-sharp.

Could you try your code with current websocket-sharp?


For a non-technical person, how do I generate a ECDSA key pair easily? I want to know because I would like to generate a vanity address at Vanity Pool.

Install OpenSSL. When the executable in your path, enter this command to generate a private key:

openssl ecparam -genkey -name secp256k1 -noout -out myprivatekey.pem

To create the corresponding public key, do this:

openssl ec -in myprivatekey.pem -pubout -out mypubkey.pem

This will give you both keys in PEM format. I'm not sure what format the web page wants, but it shouldn't be difficult to convert. You can use variants of the last command to output other formats. Remove -pubout if you want the private key, leave it if you want the public key. And you can use -outform DER to get DER format. You can use -text to get hexadecimal.

Do not give any form of your private key to anyone else.


Bitcoin public key — why do we have a compressed and uncompressed version? My understanding is that the public key can start with 04 if it's uncompressed, or 02 or 03 if it's compressed.
What's the purpose of this?
It appears that you'd have greater entropy if it's uncompressed.
And if this is indeed the case, why would you want a compressed public key?
Wouldn't it be safer to use the larger one?

My understanding is that the public key can start with 04 if it's uncompressed, or 02(x-coor) or 03(y-coor) if it's compressed.

That's not exactly right. There are two encodings:

Uncompressed encoding: (0x04, X coordinate, Y coordinate)
Compressed encoding:

(0x02, X coordinate) if Y is even
(0x03, X coordinate) if Y is odd

What's the purpose of this?

And if this is indeed the case, why would you want a compressed public key?

If you're asking about intent, you need to be aware that these standards for encoding aren't specific to Bitcoin. They're defined by SEC1, and adopted by many other systems. Presumably their goal for having both is:

Compressed encoding is smaller, and thus desirable when space/bandwidth considerations matter more.
Uncompressed encoding is slightly more efficient to work with, so if space/bandwidth isn't a concern it's faster to choose this.

If Bitcoin was designed today, it would probably only have compressed keys.

Greater entropy as we can have a larger public key if it's uncompressed?

Wouldn't it be safer to use the larger one?

No, there is a one-to-one conversion between compressed and uncompressed keys, in both direction. There is no difference in entropy (both have 256 bits of entropy) and thus equally secure.


What motherboard should I use for alt coins mining? I want motherboard with 6 PCI-e slot.

Where can I get that?

I suggest you use this motherboard: http://www.asrock.com/mb/intel/h81%20pro%20btc/

Its one of the most used for mining rigs, since it can hold a lot of gpu's


After Segwit Activation, what is the largest block size possible? The code says MAX_BLOCK_SERIALIZED_SIZE = 4000000, but that is actually not a actually consensus rule as stated here:

https://github.com/bitcoin/bitcoin/issues/10289

The actual consensus rule is based on MAX_BLOCK_WEIGHT, which is also 4000000. It's unclear to me what the minimum weight a p2wpk or p2wsh transaction can have. Specifically, what's the best witness-serialized size/weight ratio that a transaction can have post-segwit activation?

That should answer the question of what is the largest block size possible post-segwit activation.

The maximum block size is 4,000,000 bytes (4 MB). This is because the block weight calculation is base size (in MB) * 3 + total size (in MB) = block weight (see BIP 141). Since the only units are MB, the block weight's only units are also MB, thus the maximum block size is the same as the block weight.

The best possible size to weight ratio I can think of is a transaction which also spends a P2WSH output that has a ridiculous redeemscript. And then there's also the coinbase transaction and block header. The witness would be 4000000 - 240 * 3 - 240 = 3999040. So there is 3999040 bytes in the witness. The total block size is then 3999040 + 240 = 3999280 bytes.


Probability an honest node finds the next block vs. probability the attacker finds the next block I am trying to understand Satoshi's paper [1]. On page 6 of the paper, he calculates the probability that someone can attack the blockchain from z blocks behind. He begins by defining:

My question: The mining of a block i.e., solving the hash puzzle is a completely brute-force trial-and-error process in which one keeps trying a random nonce until one gets a hit. No one has an upper hand in this process. So shouldn't p and q be equal to each other?

EDIT: since comment would have been very long. Responding to the comments, in that case it gets even worse. q can be greater than p. Let the Bitcoin network be composed of M mining pools with their compute power be given by p_i. Then all an attacker needs to do is to form a pool whose compute power is greater than max(p_i). Am I missing something? In other words, the pool with max compute power can attack the blockchain already.

In an ideal design, if I want to attack the blockchain, I should be pitted against the sum of p_i not the max of p_i.

No one has an upper hand in this process. So shouldn't p and q be equal to each other?

The chances of finding a valid block header that meets the target requirement increases proportionally to the number of tries. This means that it is proportional to the hash power that you have. Even if there are two miners, one could be using a huge datacenter (the size of United States), while the other might be mining on his 10 year old laptop. Their hash power would not be the same, and hence p and q will also not be equal to one another. Hash rate is the metric to be used to find out the probability of a miner finding the next block.

  Then all an attacker needs to do is to form a pool whose compute power is greater than max(p_i). Am I missing something? In other words, the pool with max compute power can attack the blockchain already.

What you are describing is a 51% attack. With the current hashrate of the Bitcoin network, it would require HUGE investments (billions of dollars) from the entity who is planning to do such attacks. At that investment level, the economic incentive to launch such attacks may be tiny, unless it's a state actor who is trying to annihilate the confidence of the network. Even if a fraudulent miner amasses >50% of the hash rate of the network, full nodes MAY try to patch themselves to reject such blocks (for example: if that attacker tries to broadcast a longest chain that is > 6 blocks different than the original chain, to prevent double spends).


What is G on Marketcap I have checked the bitcoin marketcap charts on coinmarketcap.com. Looking at the charts I see time on the horizontal line and k, M and G on the vertical line.

What does G stand for?

Standard SI prefixes. Kilo, Mega and G is for Giga, obviously. Just multiply the value with 10^9 to get the base value.


Set the number of keys/addresses in a wallet Is there a way to configure the number of keypairs (or addresses) created by bitcoind or bitcoin-qt?

I've looked at the sample bitcoin.conf file, but failed to find the relevant parameter.

Finally found it:

# Pre-generate this many public/private key pairs, so wallet backups will be valid for
# both prior transactions and several dozen future transactions.
#keypool=100


Embedding P2Pool technology in Bitcoin Core As far as I understand, P2Pool is a way to decentralize mining. I don't know all the details, but it allows to distribute the mining rewards by the parties involved, fairly and without a centralized pool.

One major problem with P2Pool is that it requires each participant miner to keep record of the full blockchain. In contrast, participating to centralized pools doesn't require you to download the full chain.

However, as far as I understand, new versions of Bitcoin will soon provide pruning capabilities, therefore allowing miners to only keep unspent outputs (without the entire chain) up to certain blocks, which drastically reduces the amount of space needed to verify transactions.

With all these new developments, wouldn't it make sense to embed P2Pool sort of technology inside Bitcoin Core itself, or are there bigger limitations that I'm not aware of?

However, as far as I understand, new versions of Bitcoin will soon provide pruning capabilities, therefore allowing miners to only keep unspent outputs (without the entire chain) up to certain blocks, which drastically reduces the amount of space needed to verify transactions.

This has been the case since 0.8.0. The new addition is just to remove the requirement to keep block files around, which were only ever used for serving to other peers and for wallet rescans anyway. Incidentally the pruning function is incompatible with the current wallet, which would make P2Pool operation a bit difficult until it has been patched for operation with its own wallet system.

  With all these new developments, wouldn't it make sense to embed P2Pool sort of technology inside Bitcoin Core itself, or are there bigger limitations that I'm not aware of?

It would have made sense in 2010, less so now. P2Pool has extremely high share difficulty which frustrates small miners, and it has all but lost all of the momentum it might have had a few years ago. Unfortunately it is also written in Python, which makes it a little lethargic and not suited for inclusion without a complete rewrite.

The mining landscape is also a lot different to even a year ago. Home mining is all but non existent, and most of the hashpower is concentrated under the control of as many people as would fit in a small elevator car. Those with miners will often have brands who have released hardware that actively damages P2Pool by discarding valid blocks (a sort of unintentional block withholding attack). Most mining hardware include small single board computers of some description which are underpowered even for stratum mining, which means the person needs to keep another full sized computer around to run a node on, which is apparently undesirable.

The budget for P2Pool development is almost zero as a result of the combination of all these factors. It would have been nice if this was a core part of Bitcoin to begin with, or something similar. Perhaps things would be different now if it had.


Is "fee higher than block reward" attack possible? Imagine the following scenario:

I send you 1000 BTC.
After 6 confirmations, you give me what I bought.
I create another transaction with 900 BTC to my own wallet and 100 BTC as transaction fee, using the same input as the previous transaction. (double spend)
The mining pools find that 100 BTC is higher than 6 block rewards which is 12.5 * 6 = 75 BTC, so they start to mine on the last block which doesn't contain my first transaction.
Those 6 confirmations are orphaned and the pools earned more money.
My double spending succeeded.

I know that this mining strategy is not implemented in most pools today, but nothing is preventing pools from doing this in the future.

100 BTC is a large amount of money. But after many years the block reward will be very low, so this attack may not require so much money to perform in the future.

I googled and didn't find any related questions.

I want to know whether this kind of attack is possible in practice and what we can do to prevent this.

An attack like this is possible, it is just a way to profit off a 51% attack. However you must remember several things:

if a miner controls less than 51% of the hashpower, then chances are they will not be able to catch back up to the network after mining the malicious tx, so the honest network will prevail as the longest chain
if a miner tries the attack but fails to succeed, they will have wasted a lot of resources in doing so (opportunity cost). Compare this to a more guaranteed profit of not being malicious
if an attack like this succeeded and users noticed, it would hurt the security of the network, and thus coin prices should be expected to fall. So the miner has undermined their own investment.

If you hunt around online, I have seen a simple formula for determining the value of transaction vs the number of block confirmations to wait for before considering the tx ‘final’. Your line of reasoning is correct: for larger transfers of value, the wait period should be longer, so that the potential reward of malicious behaviour is outweighed by the reward of honest mining.


Ownership of private keys in the Lightning Network My question refers to the technical side:

who is holding the private keys if a third party is using my lightning node to participate in the Lightning Network payment channel ?

Thank you

If the third party is routing a payment through your node, only your node and its peers along the payment route need to sign, and therefore only the respective private keys are required. The third party node only signs with its private keys for channel states in its own channel it is routing through (the first hop in the payment route).

If the third party is accessing your node through the server API, then it is necessarily using your node wallet, so it is the private keys hosted on your node which are being used for channel state signing.

Private keys must generally be hosted on an active lightning node, as channel states are updated continuously by the implementation, without user intervention.


Is there a rationale for the compact representation of the target? In Bitcoin, the target is a 256-bit unsigned integer stored using a compact representation similar to a 32-bit floating-point with the following parameters:

1 sign bit (is there any use?)
8-bit exponent with offset binary 3 (why?)
base 256 (by using this base, couldn't the exponent be 5-bit long? By definition, the maximum target is set to 2^224 - 1 = 256^28 - 1)

It looks like the format was designed for other purposes than Bitcoin's target, and used unmodified in the code.

If you want a rationale for why a compact representation in the first place: not to waste space in block headers, presumably. We now know that there is little need for having the target stored in block headers at all (header-first sync does not need it), but before that, it was needed for certain DoS protections.

The particular choice indeed seems a bit odd; the sign bit is certainly unnecessary, and the ranges seem a bit off. However, it's not a terrible choice for a simple generic 32-bit floating point number.


Does it take longer to generate an address when I stop and restart vanitygen? I want to generate a bitcoin address.
 I start vanitygen, but a power loss occurs.
 Now I restart vanitygen.
How does this affect the time to generate the address?

tl;dr If you stop vanitygen for 5 minutes, on average you've added 5 minutes to the time it will take to complete.

While it is running, vanitygen tells you how much longer it will take until you have a 50% chance of finding a suitable address.  About half the time, that countdown will reach zero, and then the countdown starts again, but this time showing the time until you have a 75% chance.  And so on.

This gives the impression that it is making "progress" towards finding a suitable address, but that is misleading.  Every second that vanitygen is running is has a certain chance of finding an address.  There's no progress being made, in the same way that you don't "make progress" towards winning the lottery if you play it every week.  Just eventually if you play enough times, you win.

So if you stop the program running and start it again, you've lost nothing other than that you've wasted the time between stopping and restarting when it could have found a solution.


Do you really need more than 50% mining power in order to attack Bitcoin blockchain? My question is about concept, so code is not related, however, do you really need 51% of the mining power in order to attack/replace the real bitcoin Blockchain?

For example, a blockchain has a length of 8, A, B, C, D, E each represent a individual with 20% of the total mining power, let's say person A and B decide to work together, but that's only 40% of the total mining power (less than 51%), for illustration purpose, miner C, D, E will always mine alone, so by the time miner C, D, E each finished mining the 9th block, A and B have already mined the 11th block (assuming they mine faster, since they work together and have a total mining power of 40%), so longest chain wins right? and now the 9th block that miner C, D, E just mined becomes invalid and their chain will be replaced to the longer blockchain, does this mean A and B might have the power to control and manipulate the entire bitcoin Blockchain with only 40% of the mining power as long as the rest of the network don't work together? if so, then bitcoin is not really safe, because most of the time there is no way for small individuals to work together, it's like owning a company, you don't have to be holding 51% shares in order to be in charge of the company, you can do it with just 2% as long as the rest of share holders each hold less than 2% and don't work together against you,

So my ultimate question is, does bitcoin network have a way to force the rest of the share holders to join forces? Therefore you need a true 51% to control/manipulate it or is it like a company?

A majority attack (51% attack) was given this name for a reason: in order for the attack to succeed on average, the attacker needs 51% of the hashpower.

Reading your question, I can see a misunderstanding of how mining works, in that you postulate two miners working together with 40% of the hashpower will outcompete 3 miners with 20% of the hashpower each (ie, 40% > 20%). This is false.

Bitcoin mining is a memory-less process. This means that any single block header a miner creates has an equal chance of creating a valid hash - there is no advantage to having more hashpower, other than being able to make more guesses per second. A miner does not 'make progress' towards finding a new block, each hash is either valid, or not.

An example using dice

As an example of a memory-less process, consider the act of rolling some dice.

Lets consider a situation in which each di has 100 sides, and only 1 of those sides is considered a 'valid roll'. If there are 100 such dice in existence, and each of them is rolled once per second, then probability leads us to expect one valid roll per second.

Now, lets consider your situation, in which 5 people each have 20 of the dice. We can see that, even if two people 'roll together', they will still only roll a 'valid roll' 40% of the time, whereas the other three people will roll a 'valid roll' 60% of the time, regardless of whether or not they are 'working together'.

Likewise, in your example we can see that the three miners with 60% of the hashpower will, on average, find more blocks than the two miners with 40% of the hashpower. This is simply because (20 + 20 + 20) > 40.

This may lead you to the question "then why would miners work together?" The answer is that by working together (using a 'mining pool'), a miner can expect less variance in their payout. See this answer for more info, and this answer is relevant as well.


Does my node rebroadcast its mempool transactions on startup? Say my node has transactions in its mempool and then gets shut down and restarted.

Does it save the mempool to disk and reload this mempool when it starts back up, or does its mempool get lost on shutdown?

If the mempool gets saved and loaded on restart, does my node rebroadcast these transactions out to the network once it starts back up?

When a node shuts down cleanly, it does flush the mempool to disk and reloads it upon startup. It will not rebroadcast the transactions.
A node will only relay transactions once, when it first learns about them. Your wallet will cause its own transactions to be rebroadcast. There is currently no mempool-based mechanism that rebroadcasts any foreign transactions after the initial relay.
Especially due to the privacy implications of this behavior (which makes rebroadcasts an obvious tell that the source is the sender), there is on-going work to change node behavior such that it will generally rebroadcast all transactions that should have been included in the previous block: [p2p] Introduce node rebroadcast module #21061


BlockChain.info testnet wallet and API Does blockchain.info provide wallets and API service for testnet? This information is quite hard to find from their site.

It may be a bit late, but for others coming to this question, Blocktrail have a data and wallet API that supports both Bitcoin mainnet and testnet.

The API provides HD wallets with multi-signature transactions (allowing for full control over your coins should anything ever happen to Blocktrail), and there are currently SDKs for PHP, NodeJS and Python, with more coming soon.

There are also simple examples included in the SDKs to help you get started, a comprehensive API documentation, and a couple of working example projects:
 1. Simple Bitcoin Wallet App
 2. Simple Block Explorer

Disclaimer
I am currently one of the core developers for this API


Retrieving Old Transaction in Bitcoin Core's console -getrawtransactions returns "no such mempool transaction" error I'm new to running a full bitcoin node. After almost a week I could download the entire blockchain. My computer is running 24/7 to support the cause.
When I tried to verify some old transactions that I have in the Bitcoin Core's console (version 0.20.1) I receive some error that I don't understand and my searches didn't help me resolve this issue.
I run this code in the console:
getrawtransaction transaction ID true
I paste the IDs for my past transactions
This code returns an error message saying:
No such mempool transaction. Use -txindex or provide a block hash to enable blockchain transaction queries. Use gettransaction for wallet transactions. (code -5)
It is worth mentioning that I don't use Bitcoin Core's wallet.I use a third-party wallet.
I created the bitcoin.conf file as follows (placed in ~/.bitcoin/bitcoin.conf) :
txindex=1
When I ran the bitcoin-qt I got the error message:
Error: Prune mode is incompatible with -txindex.
I was wondering if someone could help me resolve this issue?
Thanks

You're trying to use an optional feature of Bitcoin Core: the ability to query for old transactions.
This functionality needs:

(a) the full blockchain (where else would it get the transaction from)
(b) an index by txid so it doesn't need to read through 270 GB to find what you're looking for.

The error message you get is telling you that this (b) index is not enabled. When you try to enable it, it fails because you don't actually have the blockchain (a) in the first place (it's pruned), so it can't be indexed.
If you really need this functionality, you'll need to disable pruning, start syncing from scratch (as it'll need to download the blockchain again), and enable indexing.
However, you saying "tried to verify" perhaps highlights a misconception you have: getrawtransaction doesn't verify anything, it just retrieves the transaction in your local copy of the blockchain. Everything is already verified, even when it's not kept on disk. Generally when you care about a particular transaction, it's because it directly or indirectly affects your own funds, and the recommended solution for that is simply using good wallet software - it will only show you transactions that are verified and whose entire history is verified.


Will the amount of electricity used for mining be huge if Bitcoin is widely adopted? A quick and very rough estimation: If the USD/BTC exchange rate grows to $1000/BTC (not that far-fetched if Bitcoin is actually widely adopted) bitcoins for a value of $300000 would be produced every hour, given the current rate of 50BTC each 10 minutes. This should mean that the amount of money spent on mining is roughly the same, $300000/hour.

Given an electricy price of $0.01/kWh that means that 3GW, i.e. a rather large power plant, would be used solely for mining.

Is there anything fundamentally wrong about the above calculation? Is it a problem?

This is a very difficult prediction to make, but there is one factor often left out of mining cost estimations: cost of hardware. When amortized over their expected lifespans, the costs of various pieces of equipment can become a meaningfully large factor in Bitcoin mining costs. In the days to come, it seems likely that FPGA or ASIC miners will become more common since they offer tremendous power efficiency gains over GPUs. The "downside" to FPGA and ASIC mining is that it is also extremely expensive to obtain the initial equipment, which means that the cost of equipment amortized over its expected lifespan is higher than with GPU mining.

We're now seeing the first commercially available FPGA mining rigs become available, costing about $440 for a 100 MH/s rig consuming 6.8 watts of electricity. Here at my home in Las Vegas, NV it would cost about 55 cents per month to run one of these FPGA boards, and even if the device survived 10 years of operation before its death, amortized hardware cost would be $3.67 per month, absolutely dwarfing energy costs. The ATI Radeon HD 5830 based rigs I currently run cost about $6.58 per 100 MH/s in electricity alone, but a 10-year amortization only adds $0.96 per month per 100 MH/s to that cost. This means the buy-in for GPU mining is low but so is the profit and sustainability.

This puts my cost per coin for FPGAs at $2.45 and for GPUs at $7.54, though there is certainly room for improvement in those numbers and your mileage WILL vary. The important bit, however, is that FPGA mining is far more profitable regardless of hardware cost and is likely to be the next big thing, which does a lot for Bitcoin's overall energy footprint since FPGA mining consumes about 8% of the electricity GPU mining currently consumes. If FPGA mining took over right now, the Bitcoin network could grow to 12 times its current hash rate without seeing a net increase in energy consumption.

In short, Bitcoin is in its infancy still and so is mining. Just as most technologies begin at low efficiency and high cost and grow towards high efficiency and low costs, so too is Bitcoin mining. You are correct in your assumption that electricity use will likely grow with Bitcoin adoption, but the missing factor in that equation is the increasing energy efficiency of mining hardware.


Why does my client not show funds that were sent to me? Quick question regarding a transaction that I am having an issue with, about a week ago I bought some BTC with MtGox, however when I withdrew the BTC I opted not to pay the fee. One week later I am still waiting for the BTC, can I pay a fee myself to process the transaction quicker, post original transaction?

Your client will immediately show a payment that was sent to you however it will only show as "0/unconfirmed" until the transaction has confirmations and also your client must be synchronized (has downloaded the needed remaining blocks).

If the transaction was broadcast to the network (e.g., shows up in Blockchain.info) but your client doesn't show any payment whatsoever then the problem is likely to be either that your client isn't connecting to the network or somehow the address you think is in your wallet really isn't.

If you manually imported private keys into the client's wallet, then possibly the client needs to have the client launched from the command line with the "-rescan" option to get the imported private key and its bitcoin address to be properly recognized.  That option can be run at any time (i.e., isn't harmful to run, even if not needed) so if you are expecting results that aren't occurring, this is one step you can take to eliminate any question.

Of course, make sure you have a backup (multiples, actually) of your wallet.dat at all times, including before doing a -rescan or at any time there appears to be trouble.


bitcoins not arrived to the receiver Please help me i don't know what do to.
My friend installed the app and i sent him a payment using the address given by the app without knowing the address is changeable. I sent the bitcoins to this address: 1LtVLn1iGrem6W7vVRz8H48HbJZrbWzFCK. The date was: March 7, 2017. The amount was 0.23985547.  The bitcoins was not transferred to him.

Please help me as soon as you can,
Thanks in advance.

The transaction was already confirmed on Match 7th. Your friend is either lying or has a synchronization problem with their wallet software.


Why do I have more unconfirmed tx than getmempool info reports? I presently have 39 unconfirmed tx that I've sent according to my local bitcoind:

$ bitcoin-cli listunspent 0 0  | grep account | wc -l
39

(note: the above command gives the correct answer because the tx were sent to the same bitcoind wallet.)

I made a script to watch the mempool size via getmempoolinfo and record the high and low amounts.  Here is output:

  size: 9359
  bytes: 9165998

  size_low: 16
  size_low_when: 2017-08-22T14:29:49-07:00

  size_hi: 71196
  size_hi_when: 2017-08-22T13:46:14-07:00

  bytes_low: 3063
  bytes_low_when: 2017-08-22T14:29:49-07:00

  bytes_hi: 53361196
  bytes_hi_when: 2017-08-22T13:46:14-07:00

  last_block_found: 2017-08-23T01:13:02-07:00

Notice that the smallest size that has been seen is 16.  This comes from the "size" output of getmempool info, which according to the help docs indicates the number of tx in the mempool.

Seemingly then, getmempoolinfo was (for a brief time at least) reporting fewer tx in the mempool than the number of my own sent tx that are still unconfirmed.

How is that possible?   Is this a bitcoind bug, or am I misunderstanding something?

$ bitcoin-cli help getmempoolinfo
getmempoolinfo

Returns details on the active state of the TX memory pool.

Result:
{
  "size": xxxxx                (numeric) Current tx count
  "bytes": xxxxx               (numeric) Sum of all tx sizes
}

You are misunderstanding how listunspent and getmempoolinfo works. listunspent is for your wallet only and is a wallet only RPC command. It will only show things that pertain to your wallet. However getmempoolinfo is a node RPC. It will show what your node sees, which is almost always going to be more than just the things in your wallet. These two commands are completely unrelated and work independent of each other. There is no relation between these two commands.


Exploring a local copy of the Bitcoin blockchain without running a full node? I've been hitting the rate limit for API calls for different services and have decided that it would be easier to have a local copy of the blockchain and query that instead. See my previous question:

Get fees for each transaction in a block without too many API calls

Is there a way to keep a continually updated copy of the blockchain locally?

Any suggestions for block explorers that would work in this manner?

This sounds like you'd like to run a full node, which does exactly what you are requesting. You can run a Bitcoin Core full node with wallet services disabled if you want to use it just for blockchain analysis. I'd suggest following along the bitcoin.org guide to running a full node, and take a look at the Bitcoin Core Config Generator for all the different configuration options. You'll need at least 180GB of free HD space, especially if you are going to run the node with the Transaction Index turned on, which you will want for doing fee analysis.


Is - a valid bitcoin address character I came across address like this s-272edf45031dd498e7b3ae89e11ff21b
In the Address with Balance List
Is the '-' a valid character?

No, "-" is neither part of the base58 character set 123456789ABCDEFGHJKLMNPQRSTUVWXYZabcdefghijkmnopqrstuvwxyz used to encode non-segwit addresses, nor the bech32 character set 023456789acdefghjklmnpqrstuvwxyz used for native segwit addresses.
This "address" appears to be Blockchair's representation of a malformed output script that received ₿2,609 in a series of transactions on 2011-10-28.

Bitcoin Talk user genjix explains that the output script 76a90088ac corresponds to a malformed standard P2PKH script which gave the address as 0.
A P2PKH output script 76a914<pkhash>88ac is composed of the following instructions:
OP_DUP (0x76), OP_HASH160 (0xa9), 0x14 (20 in hexadecimal, indicating a 20 byte push), <pubkey hash> (20 bytes), OP_EQUALVERIFY (0x88), OP_CHECKSIG (0xac)

whereas this malformed script uses an OP_0 instead of the pubkey hash:

OP_DUP (0x76), OP_HASH160 (0xa9), OP_0 (0x00), OP_EQUALVERIFY (0x88), OP_CHECKSIG (0xac)

Colloquially, these funds have been burnt by sending them to the address 0, which is of course not a valid address. (Since OP_HASH160 will always produce a 20-byte value, and that will never match 0, OP_EQUALVERIFY will resolve to false for any pubkey and the funds are unspendable.)


Is it possible to reject a bitcoin payment? Say someone sends bitcoin to an address. It is later determined that those incoming funds are tainted and the recipient wants no association. What is their recourse?

The protocol doesn't include a way to reject transactions, for a variety of reasons (the protocol doesn't know which output is real and which is change; blocks can't be changed after being mined; etc) but it is possible to do something similar.

Accept payment, then return it

Pick one of the funding addresses at random, then send the coins back to that address.
Accept payment, then destroy it

Send the coins to an address that doesn't have a private key associated with it, like 1BitcoinEaterAddressDontSendf59kuE.

Implementations

To my knowledge, no client implements an easy way to do either of these things. The best way would be use coin control to select the offending output, then make a transaction that returned/destroyed it.


Who give initial value to Bitcoin? I know how the process of changing BTC price occur, but I curious as to what gave the  initial value to BTC and whether the price of another cryptocurrency refers to the BTC?

How would I replicate this process using an API or any algorithm?

฿ price comes from whichever API you use. I prefer Coindesk because it does a weighted average, but Blockchain.info is another good option, as is Bitstamp or Coindesk.

From there you can use Bittrex API or Cryptsy or Poloniex.

There's also specialist API like gem.io or blockcypher.com


Connecting two local nodes in RegTest I am trying to connect two local regtest nodes together. I am able to run one regtest node without any issues, and am also able to run the bitcoin-cli commands such as generate to create my own chain, however when I try to start a new node, I'm not able to connect them. This is what I do (sorry if there is a clear mistake).

Run node 1
./src/bitcoind -regtest -port=8333 -rpcport=8332 -datadir=/Documents/node1data -conf=Bitcoin/bitcoin.conf

Run node 2
./src/bitcoind -regtest -port=8330 -rpcport=8331 -datadir=/Documents/node2data -conf=/Bitcoin/bitcoin.conf

By now I seem to have two different chains, generating blocks on one node doesn't change the number of blocks in the other node. I would like to have these two nodes share a chain so that mining a block in one of the nodes updates the chain on both of them. However when I try to connect them using the following command:

./src/bitcoin-cli -regtest -port=8333 -rpcport=8332 -rpcuser=user -rpcpassword=password addnode "http://127.0.0.1:18332" "add"

The rpc call to addnode displays no errors and if I run it again I get: "Error: Node already added"

After this call, the command

./src/bitcoin-cli -regtest -port=8333 -rpcport=8332 -rpcuser=user -rpcpassword=password getconnectioncount

returns 0...

So, I see a lot of people using software such as dockers, etc. Why is this not working? Am I completely mistaken to think this could work, if so I would love to know where I'm failing. Ultimately, how can I achieve to have two or three nodes connected to each other?

Thanks in advance to anyone who reads my question.

It seems to me that the ports aren't matching:

You've set your first node to port=8333 and your second node to port=8330. However, you've called addnode with …18332. Maybe that's it?