How did Nakamoto untraceably pay for registering bitcoin.org? Wikipedia says "Nakamoto created a website with the domain name bitcoin.org" and "transferred several related domains", while bitcoin.org says it was "originally registered and owned by Bitcoin's first two developers, Satoshi Nakamoto and Martti Malmi".  A 2014 businessinsider.com article says bitcoin.org was first registered in 2008 via anonymousspeech.com, and that Malmi stated bitcoin.org was "originally created by Satoshi", and Malmi's first contact with Nakamoto was in 2011 when bitcoin.org was transferred to Malmi.
The article also says anonymousspeech.com accepted cash and E-gold.  Did Nakamoto pay for the original bitcoin.org registration, and used cash or E-gold (paid for with cash) to do that and keep his origins untraceable?  Or is it possible that somewhere in history is a non-anonymous payment of some kind that would finger Nakamoto?  For example, archive.org shows bitcoin.org was an actual hosted site at least by January 31, 2009.  Where was it hosted, and how and to whom was that hosting paid for?

How did Nakamoto untraceably pay for registering bitcoin.org?

Nobody knows for certain apart from Nakamoto and the businesses involved.
Nakamoto was (and remains) notably secretive and their true identity is not reliably known† and they no longer communicate with the world using that name in any verifiable manner.
All the businesses involved in the alleged registration process protect the identity and other confidential information associated with their customers. As they should. Therefore the details sought are not public knowledge.

first registered in 2008 ...

That certainly appears to be the case.
The domain registry information currently includes the following information:
Domain Name: BITCOIN.ORG
Registry Domain ID: D153621148-LROR
Registrar WHOIS Server: whois.namecheap.com
Registrar URL: http://www.namecheap.com
Creation Date: 2008-08-18T13:19:55Z
Registrar: NameCheap, Inc.

...via anonymousspeech.com,

The website of AnonymousSpeech.org says

Any inquiries  regarding the identity of our subscribers are ignored. We do not respond to any of them.

We are committed to the privacy of our users, and will absolutely not release any kind of data to any foreign governments.

archive.org shows bitcoin.org was an actual hosted site at least by January 31, 2009. Where was it hosted, and how and to whom was that hosting paid for?

That information is not available.
We know a couple of important things about Nakamoto:

They were extremely protective of the secrecy of their identity.
Though their work was not without flaws, they were competent in the field of online privacy and encryption.

We should therefore not expect to easily find any information they specifically sought to hide from the public.
Nakamoto's main aim was to create a cash system that did not rely on trusting third parties - their aim was not to teach us how to anonymously register DNS domains. This should shape our expectations of available information.

Footnotes
† So far as I know, the people claiming to be Nakamoto have failed to provide proof or have provided evidence subsequently shown to be false. We cannot ask Nakamoto and if we could, they would not an answer if their behaviour is consistent with their past behaviour.


Coinjoin API server possible? Is there a protocol limitation (I suspect there is) that does not enable transactions across different platforms to access a 3rd party remote server (Chaumian server?) through API and create a coinjoin every let's say 2 minutes or 100 users from all platforms/wallets? If someone implemented such a server, this would highly increase coinjoin liquidity and privacy.

There is nothing in particular stopping exchanges from using CoinJoin to construct transactions with other exchanges, but rather there does not appear to be any demand for this.  For example both JoinMarket and Wasabi1 have APIs that could be used.

In the future this situation could change if something like Schnorr signature aggregation capabilities are adopted by Bitcoin. In that situation, CoinJoin transactions could be noticeably smaller (and therefore cheaper) than many separate single-output transactions.  This still seems very unlikely though as the exchanges are more likely to simply batch their own transactions rather than working with other exchanges.

Until a significant percentage of users demand privacy, exchanges are unlikely to change anything.  There may also be regulatory issues with them providing such an option.


How to upgrade Bitcoin Core Version on Raspberry PI? I want to upgrade my Bitcoin core version to latest release 0.16.1. The release docs say just copy over bitcoind/bitcoin-qt (on Linux). What does that mean? what to copy? Copying from where to where?

https://github.com/bitcoin/bitcoin/blob/master/doc/release-notes/release-notes-0.16.1.md#how-to-upgrade

They are referring to executable binary files, either the bitcoind daemon or the bitcoin-qt GUI app.

The page with download links is https://bitcoincore.org/bin/bitcoin-core-0.16.1/

The only link for ARM (Raspberry Pi processor) is https://bitcoincore.org/bin/bitcoin-core-0.16.1/bitcoin-0.16.1-arm-linux-gnueabihf.tar.gz and expanding it

$ tar -xf bitcoin-0.16.1-arm-linux-gnueabihf.tar.gz

I find these directories:

~/bitcoin-0.16.1$ ll
bin/
include/
lib/
share/

~/bitcoin-0.16.1$ cd bin
~/bitcoin-0.16.1/bin$ ll

bitcoin-cli*
bitcoind*
bitcoin-tx*
test_bitcoin*

I don't find a bitcoin-qt GUI version; perhaps they have not compiled one yet. But you can certainly use the command-line versions, bitcoind, bitcoin-cli and bitcoin-tx.

The place to put them is where they will be found from anywhere, for example, /usr/local/bin   or /usr/bin.


How to use Electrum with a local regtest network? The problem

I have a regtest network running in 127.0.0.1:18443.
I can access to regtest with user:123.
I would like to use Electrum (v4.0.2) with my local regtest but I cannot realize how to do that.

What I tried
When I run:
electrum --regtest

The Electrum console opens as expected but the status is not connected:

My ~/.electrum/regtest contains:
{
    "auto_connect": false,
    "blockchain_preferred_block": {
        "hash": "0f9188f13cb7b2c71f2a335e3a4...........a11466e2206",
        "height": 0
    },
    "check_updates": false,
    "config_version": 3,
    "dont_show_testnet_warning": true,
    "gui_last_wallet": "/home/xxx/.electrum/regtest/wallets/default_wallet",
    "is_maximized": false,
    "oneserver": false,
    "recently_open": [
        "/home/xxx/.electrum/regtest/wallets/default_wallet"
    ],
    "rpcpassword": "123",
    "rpcuser": "user",
    "server": "127.0.0.1:18443:s",
    "show_addresses_tab": true
}

I changed rpcpassword and rpcuser with the user:pass of my local regtest, but I'm still unable to connect Electrum with my local network.
My questions

What am I doing wrong?
What does the "s" mean in 127.0.0.1:18443:s?
What's running in 127.0.0.1:51002?

Electrum doesn't connect directly to Bitcoin nodes. Instead it connects to Electrum servers using the Electrum protocol. These servers run Bitcoin nodes and additional Electrum server software in order to provide the data that Electrum actually needs to operate. So you need to be running an Electrum server software that connects to your node and then connect Electrum to that Electrum server.
Some Electrum server software:

Electrum Personal Server: EPS is designed for use with a single Electrum wallet and is probably the easiest to get an Electrum wallet connected to a full node
Bitcoin Wallet Tracker with Electrum plugin: BWT is like EPS but does more stuff and isn't just limited to Electrum
ElectrumX: ElectrumX is the official Electrum server software. It is a full fledged Electrum server software that is intended to be used by any connecting Electrum wallet. As such, it indexes the entire blockchain. If you want to do experimentation with the Electrum protocol, you may want to use this.
Electrs: Like ElectrumX but written in Rust.


How to generate a new extended public key (xpub)? I have a need to generate a new extended public key (xpub).

Examples:

xpub6CUGRUonZSQ4TWtTMmzXdrXDtypWKiKrhko4egpiMZbpiaQL2jkwSB1icqYh2cfDfVxdx4df189oLKnC5fSwqPfgyP3hooxujYzAu3fDVmz

tpubD6NzVbkrYhZ4WLczPJWReQycCJdd6YVWXubbVUFnJ5KgU5MDQrD998ZJLNGbhd2pq7ZtDiPYTfJ7iBenLVQpYgSQqPjUsQeJXH8VQ8xA67D

How can I do this?

I would like to do it inside json rpc, because that would help automate testing, but I ultimately don't care how I get them. They are for testing.

You can do that, but each HD seed needs to be inside its own wallet file which is loaded by the server. Running bitcoind with multiple -wallet arguments will achieve what you are aiming for. Currently it is not supported to dynamically load and unload wallets at runtime, but support for that is being added and will be available in a future release.


Bitcoin-qt falls behind on blockchain, how to replace? On Apple Mac, bitcoin-qt is 14 days behind. Never approaches current time. Have downloaded current blockchain from trusted source. Where to install? What procedure?

I know that there is a torrent where you can download the blockchain to jumpstart your fresh installation. This should also help to update your local wallet. In order to download and import the blockchain manually have a look at the instructions and the download link in this bitcointalk thread:

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


How does lending / leasing in NXT work? What are some use case scenarios? Since you can lend / lease you nxt to another account.

What are the pros/cons of this nxt lending feature?

What are some use case scenarios?

Leasing gives the other account your forging power, without giving them the ability to spend your coins. The two main use cases are:

To lease to a forging pool run by someone else. This avoids the need for you to run a server 24/7, and the pool should forge more often, smoothing out the peaks and troughs in forging income.
To lease to a forging node run by yourself, but on a machine you don't trust; for example a cloud service. You keep your balance on a secure machine and lease it to the insecure one.


If a user recovered data directory of LN node software with an old backup, what would happen? Would cooperative channel closing be possible? As far as I know, the "Data Loss Protection" feature would just request the counterparty to unilaterally close the channel. I wonder if mutual closing is still possible, with old channel states?

By the way, I roughly remember that I once seen a comment like this:

Before the "Static Channel Backup" feature was introduced, there was once a bad situation that the funds could be permanently lost, even if the channel counterparty unilaterally closed the channel. However, this bad situation was a trade-off in exchange for better (or easier) watchtower implementation.

No, a mutual close is not possible. For signing a mutual close, both the parties should be aware as to what the current state of the channel is at. Since one of the party has fallen behind, it does not know how much it is owed (or more correctly cannot prove to the other party how much it is owed). Moreover, if the last signed commitment transaction included adding of HTLCs, it is impossible for the fallen behind node to know what those HTLCs are, if the pre-images were sent, or if the HTLCs have timed out.

The one way that can be though of is that when the other party detects that its peer has fallen behind, it sends its peer the last signed serialized commitment transaction (without signatures) that it holds and the signature that the fallen behind peer sent it. They can then negotiate the closing condition including the fees. However, the protocol allows only messages that are not more than 65535 bytes long. Commitment transactions can be as much as 400,000 WU (>100,000 bytes) so it would not fit in a single Lightning message. May be the protocol can use the new TLV format to indicate multiple messages to follow, but as is, the current specs do not allow it.


Implement HTLC manually by writing scripts Is there any way to implement HTLC manually for locking funds in the channels in lightning network for a period of time (by setting intervals) and releasing the funds after the time lock expired using bitcoin regtest mode?

Yes...

... But it is going to be a lot of work.

First you should look at BIP 199 which defines htlc scripts. However that alone will only tell you how to create a htlc output.

But with the transaction itself it is not done. You need to use the right channel state and keys so you could read BOLT 02, 03 and 05 to learn about the peer protocol and messages you need to exchange with your channel partner (for such you will actually also need  BOLT 08 and 01 covering setting up a transport session and the message format), the key derivation and the exact onchain specs for htlc output and witeness  scripts. You will find all the BOLTs at https://github.com/lightningnetwork/lightning-rfc?files=1

All of this can be done in regtest. If you want to use a regular lightning implementation you can also run them in regtest mode by changing the corresponding entry in the config file.


Would first-seen prevent a double spend attack? It takes approx. 8 seconds for a transaction to propagate through the entire Bitcoin network. If we got rid of the concept of replace-by-fee and replaced it (no pun intended) with a first-seen approach wouldn't this significantly reduce the likelihood of a double spend?
Even if an attacker is running another wallet on the other end of the planet and broadcasts an identical transaction right near the winning mining node, such a double spend transaction would still reach the merchant within < 16 seconds.
Would a merchant be able to simply listen out for a double spend transaction and conclude with a reasonably high level of confidence that it is very unlikely for a double spend to occur in this case?
Note: This SE question does not address my particular concern as a merchant would be waiting 16 seconds to rule out a simultaneous transaction.

First of all, what is the goal? The Bitcoin consensus rules already completely eliminate the possibility of an "double spend" within any individual version of history ("chain"). The concern is about individual wallets accepting a transaction as a fullfilled payment, before it is certain that that transaction will end up in the winning chain. So when we speak about problematic "double spends", the term is confusing - no coin is actually spent twice - instead, it is the confusing name we give to "being convinced you were paid while in reality you aren't".
And there is an easy solution for this: waiting until the transaction is sufficiently confirmed before treating it as accepted. This approach is suggested in the Bitcoin whitepaper, together with an analysis that shows how risk of reorganization falls with increasing confirmations, assuming no attacker with a majority of the hashrate exists.
So the whole concern is about being able to accept transactions before they gather sufficient confirmations. And the answer is simply: if you want to be sure, you simply cannot. This is a fundamental problem: global consensus among untrusted participants is hard, and in Bitcoin's case, which relies on economic incentives to see that concensus emerge, you need proof-of-work to build up any guarantee, and that takes time - multiple blocks' worth of time.
If you're thinking of a rule where nodes reject blocks that contain transactions that they believe are fraudulent/doublespends, you're just introducing a recipe for the network to fork. We need a way to make all nodes agree on what transactions are valid, and if we had any other way of doing so without using slow and costly proof-of-work, we would.

It takes approx. 8 seconds for a transaction to propagate through the entire Bitcoin network. If we got rid of the concept of replace-by-fee and replaced it (no pun intended) with first-seen approach wouldn't this significantly reduce the likelihood of a double spend?

That's how things worked before the introduced of opt-in RBF (BIP 125), and still how it does work for transactions that don't signal RBF. However, its promises are widely understood to be an illusion: there were (and are) known ways to construct transactions that propagate slower than others through the network. All an attacker needs to do is create a slow-to-propagate transaction that pays you and broadcast it "close" to you in the network, while broadcasting a fast-to-propagate transaction that pays himself and publish it in many other places on the network at the same time. Most miners will see the second one first, and that transaction will have a higher chance of winning.
And if you look at incentives, you don't even need that. Miners have an incentive to accept the highest-fee transaction, regardless of when they see it. Even if the network doesn't relay it, nothing prevents an attacker from sending a higher-free transaction directly to a miner. They'd be stupid to reject it. Bitcoin software initially (and still, for non-BIP125 transactions) was written to reject such replacements, but as profit margins for miners shrink and the industry becomes more competitive, it seems very unlikely to me that miners will not eventually just accept whatever maximizes their income.

Even if an attacker is running another wallet on the other end of the planet and broadcasts an identical transaction right near the winning mining node, such a double spend transaction would still reach the merchant within < 16 seconds.

That's assuming that the network provides a reasonable guarantee at relaying conflicts. It doesn't. Nodes only relay the transactions they themselves accept. Relaying conflicting transactions so the rest of the network can learn about conflicts has many problems:

It doesn't necessarily work. If the attacker hands the conflicting transaction directly to a miner, they may not have any incentive to reveal it to the rest of the world before it is mined.
Done naively, it is a trivial DoS attack: an attacker simply creating a myriad of conflicting transactions would result in the network relaying all of them, at no cost to the attacker except the fee of the one variant that eventually gets mined.
Done less naively, with precautions in place to prevent said DoS attack (e.g. through rate limiting that kicks in at some point), it becomes trivial to bypass: first produce enough transactions to trigger the rate-limit, and only then perform the attack now the network has decided they've had enough of your conflicts.
It helps the attacker. If the conflicting transaction pays more, the network relaying it will make it easier for economically rational miners to pick it up.

In fact, there is barely any guarantee that even honest transactions propagate well in adverserial setting. It is even less the case for conflicts.

Would a merchant be able to simply listen out for a double spend transaction and conclude with a reasonable high confidence level that it is very likelihood for a double spend to happen in this case?

It is certainly possible to use heuristics to try to analyze the probability of conflicts, and for sufficiently low-value transactions, it may be fine to treat the occasional risk of a reversed transaction as a cost of doing business. But remember that past performance is not a promise of future success. Just because nobody attacks you doesn't mean it isn't trivial to do so; it may just be that it wasn't ever worthwhile to try.
TL;DR: if you want to be sure about a payment, wait for confirmations


Can 2 blocks have the same previous hash? Can two blocks have the same Previous hash after being created.

2 blocks totally different from each other but with the same previous hash

Can two blocks have the same Previous hash after being created.

Yes, two otherwise valid blocks could be created that both link to the same parent block, but importantly: only one of those two blocks will become a part of the valid chain. So ultimately, only one of them will be valid, and the winner will be the block that miners build on top of first (and thus it becomes a part of the longer chain).

The other block will become what is called an 'orphan block' (though some people prefer the more exact term, 'extinct block').

You can look through the orhpaned-blocks tag for more info.


What's the deal with OP_RETURN and length? It seems like most OP_RETURN transactions include length as the first byte after the OP_RETURN code. Is this specified anywhere?

Also, the length is sometimes the entire length of the rest of the output, and other times, such as with memo.cash, it is only 2, but there are many more bytes than that.  What is it supposed to be?

The length (amount of data to be pushed into the stack) typically comes directly after the OP_ code.

If the byte after OP_RETURN (0x6A) is between 0x01 and 0x4B, that is signaling the amount of data to push into the stack. This is defined in the Script language; a chart can be found here.

For example:

6A24AA21A9EDA45B20BAE4C0D9C747D7C17074D0606AF70FABA1394FC75E5DA6ABDA0426232E

The first byte 0x6A decodes to OP_RETURN and the next byte is 0x24 signaling
to push 36 bytes of data to the stack. (0x24 hexadecimal is 36 in decimal)

Our example therefore decodes to:

OP_RETURN PUSHDATA(36) AA21A9EDA45B20BAE4C0D9C747D7C17074D0606AF70FABA1394FC75E5DA6ABDA0426232E

If there was any more data after the 36 bytes it would be interpreted in coordination with the proper OP_code.


How does the Electrum wallet encryption work? Nube bitcoin question...  I created an electrum wallet, and can find it under appdata on my windows machine.  When creating it I set up a pass phrase and password.  I sent a small transaction into one of the addresses.

I read in https://en.bitcoin.it/wiki/Electrum/Documentation that this procedure should encrypt the wallet.dat file.  Looking at the wallet.dat in a text editor before restarting electum, it does not appear encrypted in it's entirety, and to me it is not obvious what in there is encrypted.  Perhaps only the private keys are encrypted?  Also when I start up electrum, there is no prompt for a password to decrypt anything.

Is it explained anywhere how I can see evidence that encryption is in place?  Perhaps I should take that small amount of bitcoin now in my wallet and figure out how to send it somewhere else, and it will all become clear?

Looks like only the private keys are encrypted. Your addresses are stored unencrypted, so the software can show your balance without requiring a password.


Is it chain of headers rather than a chain of blocks? We know widely used explanation of the blockchain:
"Every block contains a hash of the previous block". The sentence above implies that since every block contains a hash of the previous block, therefore every block should have a knowledge about transactions included into the previous block because every block has a following structure:

Block:

Magic No
Block Size
Block Header
Transaction counter
Transactions

Block Header:

Version
hashPrevBlock
hashMerkleRoot
Time
Bits
Nonce

However, every block does not have knowledge about transactions incuded into previous block correct???

As fas as I understand there are two chains in the Bitcoin:

a chain of blocks headers (a block chain)
a chain of transactions (Prev Tx Hash)

Hence just to clarify, rather than saying: "every block contains a hash of the previous block", would not it be correct to say: "header of every block contains a hash of header of the previous block"?

Please correct my assumptions if I am wrong. Thanks.

Blocks contain a header, and headers are chained, so blocks are chained also.  Note the merkle root from your question: this attaches the transactions in the block to the header, making them a logical combined unit:

That is, you can't attach an arbitrary block to an arbitrary header---each header only attaches to one set of transactions.
You are correct that this expression is wrong: "every [valid] block contains a hash of the previous block".  That phrasing may be useful for non-techies, but if you find it in any editable technical documentation, you should probably change it.


Is it possible that someone forks the chain? I'm not sure I understood everything but all the clients always keep the longest chain, ok.
So, what happens if an evil person injects bad transactions in a block and successfully mine it (given the difficulty, the probability is extremely low, but let's imagine), how is the network gonna answer?

The rule is that the longest* valid chain is considered the active one. If you build a forking branch with invalid transactions in it, the network (in particular, all full nodes - including miners) will simply ignore it. If it's invalid, it does not exist. Blocks are not relayed to peers before validating them entirely.

You may be able to temporarily fool lightweight clients that don't do full validation, but to build a chain with sufficient length to "confirm" these invalid transactions requires sustained high hashrate, assumed to be impossible without significant (close to or above 50%) mining power.

longest* = it's actually the branch with the highest estimated total number of hashes that is considered the active one (as a tie breaker), not the longest one. This only very occasionally makes a difference (in particular, when the fork crosses a retarget).


Using Bitcoin for Travel Purchases BitCoin is (arguably) the world's best chance thus far at a virtual currency (although it's very unstable).  Even though it's a high risk, it is able to be converted to regular dollars, and some shops and online sites accept payment in Bitcoins.

Is there a way to convert BitCoins to regular currency online, or is there a world-wide travel website that you can use BitCoins to purchase flights, tickets, etc with?

+1 for fun question. Places where you can sell bitcoins are a plenty. You are a bit late though since the exchange rate was much higher earlier this year. Purchasing stuff with bitcoins isn't that widespread. bitcoin.travel lists about 10 travel releated places in the entire world that accepts bitcoins. bitcoin.it also has a list of travelling related vendors accepting bitcoins. All this may change quickly in either direction so watch these sites for updates.


Bitcoin Source Code genesisOutputScript I am checking bitcoin source code to learn forking a coin better,

in this link

https://github.com/bitcoin/bitcoin/blob/master/src/chainparams.cpp

Line 52 has scratched my mind, what is that for? Should that be changed while forking a coin?

I know lines 124 and 125 are set after the first genesis block is mined, can someone explain me what line 52 does, and how it affects the blockchain?

You can use this code for genesis block:
https://github.com/nasa8x/genesis-block


How do bitcoin qt sign signature/messages work? In bitcoinQT what is the sign message for? I'm not exactly sure what I can use this for.

can someone give an example of how this would be used in a layman way? nothing too technical please.
also those this message only reside on your computer or your wallet file?
so it doesnt go into the blockchain?

What you have come across is the yet to be fully explored world of cryptographic signatures - and this is only the beginning my friend.

A cryptographic signature in a very simplistic way, allows you to electronically sign something, usually a string of text. That signature can then be used to prove that the text that you signed has not been tampered with. If you were to even add a comma or a space to the text, the outcome of your signature would be different, and therefore you could prove that the text and your signature were not the same.

Unless you did not know, almost anything digital is at one level a string of text (sometimes human readable, sometimes not) so anything digital can be cryptographically signed in one way or another.

This has absolutely nothing to do with the block-chain or bitcoin per se, but is a side-benefit of bitcoin employing crytographic signatures to allow you to send bitcoins. You do not have to spend bitcoins to sign something.

In short, the mechanism is being used to allow you to crytpographically sign ANYTHING. It is almost too broad a subject to answer fully here, but for example, imagine that you are buying a house, and that you copy paste the contract into the message box and sign it, and then the seller does the same with the result of your signature.

What you would get is a cryptographically signed contract that absolutely could not be tampered with, that proves that both of you agreed to the terms in the contract, and an independent third-party could prove this to be the case.

This opens up a whole new world potentially without lawyers (think of how wondeful that might be) because you would only agree to (and sign) things that you agreed 100% with and understood. You could not be forced to sign anything that you did not agree with.

In the future where cryptographic signatures are used for everything people and companies will be forced to behave fairly in order to get anywhere at all.


Connecting to Regtest I want to connect to a local node that I have set up in regtest mode using bitcoind. The node I am connection from is non bitcoind and I need to set the port that I want the peer discovery to take place from. What parameters do I need to set in my bitcoin.conf for bitcoind?

The default port for bitcoin regtest is 18444. You can set a custom port with port=<port> in your bitcoin.conf or by passing -port=<port> as argument.


Can I force my wallet to only have news keys, post-encryption? Now that v0.4 of the bitcoin client has encryption I've gone ahead and encrypted the keys in my wallet.  But I had previously made backups of my (unencrypted) wallet and those keys are the same keys that are now encrypted.

This gives me a false sense of security.

Is there any way after I've upgraded to v0.4 and encrypted to force all my existing keys to become invalid and then to spend to a new (encrypted) key so that even if an attacker gets ahold of my backup that my coins are safe?

Seems to me that the easiest way would be to create a brand new, encrypted wallet using the new client, then send all your coins to that one and forget about the old one.

(You can force a new wallet by simply deleting wallet.dat before launching the client)


Who decided that segwit2x isn't going to happen? I have read this article:

https://lists.linuxfoundation.org/pipermail/bitcoin-segwit2x/2017-November/000685.html

Since bitcoin is a decentralized system, who's decided that segwit2x isn't going to be deployed?

Key proponents of the New York Agreement have rescinded their support after large parts of the community opposed their initiative for months. Theoretically, a miner could still activate the fork unilaterally, but the expected value of the Segwit2x network dropped significantly with the exit of said key proponents.


How can I find a Bitcoin address from the transaction time and amount? If I know the time of the transaction down to the minute and the amount of Bitcoin, how can I find the transaction id (or transaction ids, assuming there is more than one)?

Is there an online blockchain query tool that will let me do this? I really don't want to have to download the whole blockchain and run code against that.

What would be the easiest way for me to get this info?

I think what you're looking for is something like this: https://goochain.net/

It has options for date range and amount range.


OP_Return in transactions at json_rpc_api at blockchain.info I am writing a project in Ruby using JSON-RPC to communicate with blockchain.info. The API is available here: https://blockchain.info/api/json_rpc_api

Is it possible to create a op_return txout using the given JSON-RPC API ?

Blockchain.info and bitoind/qt out of the box doesn't support pushing transaction out with the OP_RETURN op code. They will mark the transaction as invalid and refuse to broadcast it.

I have an open source project with a program that will push out transactions to the network directly at https://github.com/kaykurokawa/pushtx.  It doesn't do any error checking on the transaction so transactions with OP_RETURN will get relayed.

I've successfully used this in combination with pybitcointools for crafting a transaction with OP_RETURN in it.


How do I fit a normal PCI-E x16 video card into a PCI-E x1 slot? What hardware would I need to buy to fit a normal PCI-E x16 card (In my case, a R9 280x) into a normal PCI-E x1 slot?

You need a PCI Express (PCI-e) x1 to x16 Riser adaptor cable like this one:
http://www.trademe.co.nz/computers/cables-adaptors/other/auction-670675802.htm

Bear in mind that some graphics cards draw a lot of power, and I've seen photos of cables that have overheated because they couldn't handle the load. The linked one above may have solved this issue by providing a separate power cable.


What would happen if a mining pool admins having majority of hash power turns evil? This question interest me mostly in the context of the Ethereum, but it might be interesting to see how this problem is solved by the other cryptos as well.

I understand that the consensus about what is included in the ledger of the next block is established by the game-theoretic disadvantage of the miners who mine a block that includes ledger entries which are likely to be disputed by majority of the other miners.

But as a mining pools get bigger and sometimes advocate using their own software to mine the coins, once their hash rate exceeds 50% they will have a power to form their own consensus, based on the whim of the admins of the mining software.

With that power they will be able to block certain transactions to get into the chain, effectively freezing assets on any accounts they don't like and disturbing the execution of the smart contracts.

This situation can happen even more easily, when the ETH would switch to the proof-of-stake, since it is easier to accumulate a capital rather than to accumulate the hardware.

What are (if any) provisions in ETH and other crypto currencies against such scenario?

I find it is strange and somewhat disturbing, that such a fundamental question did not got answered. AFAIK the situation I described is very real concern for the bitcoin: https://www.cs.cornell.edu/%7Eie53/publications/btcProcFC.pdf . How does the Ethereum fare?

After reading two papers: https://blog.ethereum.org/2015/01/28/p-epsilon-attack/ and https://www.cs.cornell.edu/%7Eie53/publications/btcProcFC.pdf I conclude, that the neither ETH nor BTC (and most if not all any other crypto currencies) are secure against such attacks. It is also not secure against a so-called Schelling scheme, i.e. attack made not by the party that controls a big pool of miners, but simply a party that has enough coins to bribe miners into mining his own double-spending block. If the attacker is able to bribe majority of the miners, such an attack can be zero-cost for the attacker.

Specifically, "The P + epsilon Attack" paper concludes:

  Of course, in practice, proof of work has survived despite this flaw,
  and indeed it may continue to survive for a long time still; it may
  just be the case that there’s a high enough degree of altruism that
  attackers are not actually 100% convinced that they will succeed – but
  then, if we are allowed to rely on altruism, naive proof of stake
  works fine too. Hence, Schelling schemes too may well simply end up
  working in practice, even if they are not perfectly sound in theory.

I hate to be a bearer of bad news, but the world with affordable, decentralized and deregulated finance services Ethereum and other cryptcurrencies bring might not be as secure, as we might want think.

Another sad update in this article: Decentralization in Bitcoin and Ethereum Networks, 11 Jan 2018


Which address should be used to send the money as target? We operate a market, there are sellers and buyers. Seller has Hierarchical Deterministic Wallets.  Seller give us the Xpub. Which address should be used as destination, when buyer wants to send money to seller?
I thought I should find the first address that has 0 balance. Do you agree with this strategy?

I think these is only one answer to this question: ask whomever gave you the xpub.
Xpubs define series of keys, but there isn't any implicit contract or understanding about how that should be converted into addresses. The specific index positions to use is one question, but there are others, like what type of address/script to use (P2PKH, P2WPKH, ...). All of these are things you should ask the receiver, as it is ultimately up to them to determine what kinds of transactions they would consider a valid payment.
To make a analogy: the receiver told you where they live, and you owe them money, but they haven't told you anything else. Do they want you to pay to their bank account? Do they want you to put an envelope with cash in the mail? Do they want you to bury a treasury chest with jewels under their lawn at night? All of these are in some shape or form ways that value can be transferred, but arguably you wouldn't go bury a treasury chest in their lawn without even talking to them, and expect them to treat that as a payment.


Get address balance in Java I'm a merchant that is currently developing program that I will use for receiving transactions for my business.

I would like my program to be able to check how much Bitcoin the address sending to me has. I have the entire blockchain downloaded to the computer.

Ideally I'd like something that works like this:

String address = "1PSxTeWTVgomscit2BoViZYKSc4QoyrmAk";
Double balance = blockChain.getBalance(address);

Is this possible? I am having a difficult time finding a way to do this using the blockchain stored on my computer. It seems like it would be fairly easy to do this just using blockchain.info's API, but I would like to keep the process contained on my computer.

Thanks in advance.

If the address is not in your wallet that is not possible with the current bitcoind RPC API. You have to either go through the blockchain calculating the balance of the address yourself (i.e. find the last transaction from that address or sum the payouts to the address) or use an online tool like blockchain.info as you mentioned.


CHECKSEQUENCEVERIFY After x time of last transaction Is there a way where i can have a multi-sig address which will allow one of the signers to use only their single key after a set amount of time after each transaction/update on the address?

I want to have an address that requires 2 people to sign for outgoing transactions. But if after 30 days nothing has been done with the address at all a single signer can sign a transaction. But if there is ever anything such as an incoming or outgoing transaction the 30 days is reset.

Whereas it seems, that this is not directly possible, cause bitcoin script does not allow to reference a transaction "within last 30 days", one could think about a "workaround" with a business logic watching the P2SH address. An approach could be the nested "if", which is allowed in bitcoin script. If ever within last 30 days there was a payment, the 30 days need to get "reset" - maybe you would need to play with two P2SH addresses, and shift the funds to a second addresses (and vice versa). If your business logic discovers a transaction in the last 30 days, the funds are transferred to a second address, and then again to the first address. For this second address you'd have the same set of rules, just the tx output script (for it's address) changes. The business logic could have a "known secret", that noone else knows, and then shift the funds between the addresses, just as an idea, like this:

IF
  OP_HASH160  <length 0x14> <SECRET> OP_EQUAL
  <business pubkey> CHECKSIG
ELSE
  IF
    2 <Alice's pubkey> <Bob's pubkey> <Escrow's pubkey> 3 CHECKMULTISIG
  ELSE
    30d CHECKSEQUENCEVERIFY DROP
    <Alice's pubkey> CHECKSIG
  ENDIF
ENDIF

Obviously it becomes clear, that there are fees involved in such a scenario. It depends on the frequency of transactions within last 30 days, and the value of the funds, that are shifted around. The fees should not eat up your funds... And then again, maybe one might look into using Lightning as "transport mechanism" to shift values around?


If I am on a fork, can the reindex parameter fix this? I've been reading confusing information online about what the --reindex startup parameter does.

This link is not clear to me.

https://github.com/bitcoin/bitcoin/blob/631df3ee87ec93e1fc748715671cdb5cff7308e6/src/init.cpp#L388

  gArgs.AddArg("-reindex", "Rebuild chain state and block index from the
  blk*.dat files on disk", ArgsManager::ALLOW_ANY,
  OptionsCategory::OPTIONS);

So, if I am on a fork because a mandatory upgrade occurred, I did not know about it, and I am no longer on the main chain, would a --reindex fix this?

No, it would not. --reindex only handles the data that is stored on disk. Blocks are stored in the order that they are received, which is what brought you to your current view of the blockchain. So all that would happen is that you end up at that same state.

Switching to another blockchain fork requires your node to be aware of it, so you need to have received those blocks from another node and they will be on your disk. If that chain is truly valid and has more work, then your node will have switched to it without a reindex.


Why is MTGOX's Price/Bitcoin higher than most other exchanges? I've been watching BitCoins for the last few months, and noticed that MTGOX's price per bitcoin is always higher than the price per bitcoin of similar exchanges, (eg cavirtex.com, and bitstamp.com).

Why is this? And why wouldn't people just buy them at another exchange, send their bitcoin to MTGOX, and cash out for an automatic (from what I've seen) 10-15% increase in what they invested?

I know they were the most popular/liquid site for bitcoin's until just recently, but I've heard that BitStamp has surpassed them.

It is because it is more expensive and has delays longer and more unpredictable to get $USD out of MtGox, and because they are facing regulatory and lawsuit problems.  US branch of MtGox, known as Mutuum Sigillum, may bankrupt or get more assets seized. Simply put, a dollar at MtGox is not worth as much as a dollar elsewhere.  MtGox is more accessible/less risky in markets outside US where demand is greater.

There is "friction" moving money between bitcoin dealers; delays, charges, fees, etc.  Arbitragers keep price differences for bitcoin fairly close to the sum of fees, but don't move until they are sure of a profit -- and the price is volatile, so they must account for risk due to the delay between selling in one place and buying in the other.  Delays with MtGox are so unpredictable that arbitragers are very cautious.


What are the advantages and disadvantages of 24/7 Bitcoin trading? What are the advantages and disadvantages of 24/7 Bitcoin trading over traditional stock market which operates only 6 - 8 hours a day and 5 days a week? Any threats?

The 24/7/365 bitcoin trading market is pretty unique in financial markets. Here are the advantages and disadvantages as I see them.

Advantages:
- more convenient: bitcoin can be bought and sold at any time and on any day.
- truly international: bitcoin can be traded during business hours in every country and every timezone.
- increased profitability: more trades means a good trader can make more money.

Disadvantages:
- increased risk: important market movements can occur while you're sleeping, causing trading losses.


How can I use messengers for crypto transactions? Is it possible to use Signal or Telegram for crypto transactions?
I heard CryptoCat messenger is for such needs, but interested in using those two mentioned above.

You can communicate transaction details to your counterparty using the app, but afaik neither of the messenger apps you mentioned have a cryptocurrency transfer system built into them.

So you'll need a wallet app, but otherwise you can communicate with your counterparty through the messenger app (agree on the amount to be transacted, send a payment address, etc)


(Detailed) journey of a transaction I want to understand better the paths taken by a bitcoin transaction. Whereas familiar with the general setup (submitting a payment, validation using your private key, everyone in the network can verify that your transaction is correct using your public key, mining starts, someone finds a nonce, your transaction is included in the blockchain,...)
However, there are blocks missing:
Is it possible (ex-post) to back out the journey of my transaction through the network (node where it arrives and subsequent propagation among other nodes)? I am wondering just for some illustrative reasons to learn what has to happen until my transaction pops up in the raw mempool of, say, chainquery.

Each node on the network is connected to one or (hopefully) many more nodes. Anytime activity happens (a transaction is added, a new block is found, etc.), the node that it initiating that activity sends it to all of the nodes that it is connected to, and they do the same. Each node will run the transaction through validations to verify that it considers it to be a valid transaction. Most of those validations are hard and fast rules, but some of them are more flexible. For example the logic that a node uses to decide whether or not to add a transaction onto the current working block might depend on whether a transaction fee was included or not. For validations like that, a person could modify their code to change the rules as to whether or not they accept a transaction without causing their node to be considered a "bad" node that's breaking the rules.

Because of all this activity, and nodes sending to nodes sending to nodes, at any given time one node might not have exactly the same info that another node has, so your next question is probably how that is handled, and the answer is that it depends on what is different between the nodes, but here are a few examples:

Let's say that you found a new block (congrats!), and your node has 100 pending transactions on it. But there are 5 other transactions that other nodes have that have never made it to you (or that you rejected because they didn't pay a fee or whatever). In that case, what happens is simple: The 100 transactions that you did have would be recorded and become part of the chain, and the 5 that you didn't have would not (and will probably show up on the next block).

What about something more tricky, such as two nodes, A and B, solving a block at the same time? In that case, both A and B will send their solution out to their nodes, and for a (hopefully brief) period, there will be a split in the chain, with some nodes working on A+1 and some nodes working on B+1. Ultimately the network handles this just fine. One of the nodes is going to win, and the other is going to be lost. The winning node will become part of the permanent chain, and the losing node will be lost to eternity. This is exactly the reason that most sites don't consider a transaction to be complete until it is X levels deep in the block. As a transaction becomes older and older, it is less and less likely to be part of a chain that ends up getting dropped.

There's probably another dozen things that have different rules as to what happens as they move along the nodes, but I hope that gives you an idea of how it works for two of the primary types of activity that happen on the network.


What is "Emergent Consensus" as a Mining Pool Support proposal? I would regularly check coin.dance/blocks for updates on Segregated Witness and Bitcoin Unlimited popularity among miners. Another proposal called "Emergent Consensus" has appeared. Could someone explain this proposal? While we're at it, could you explain BIP100 and Extension blocks, too?

Emergent consensus

Emergent consensus is a protocol upgrade proposal championed by the Bitcoin Unlimited developers. The idea is for each node to broadcast its acceptable block size and to thusly establish a feedback mechanism by which the miners can determine the size of blocks to create. In parallel, rules governing block size would be largely lifted under the assumption that a free market would discover the correct block size. The proposal is marketed as a permanent solution to the block size debate and as a means to put the block size limit into the hands of the users.

However, this proposal has collected a fair share of criticism, such as:

It's expected that it'll end up putting the block size limit into the hands of the miners instead of the users, as the out-of-band feedback mechanism is in no way binding to the miners.
Larger miners might be able to abuse the mechanism to put smaller miners at a disadvantage, resulting in further incentives for hashrate to consolidate.
Incentives for larger blocks overwhelm reasons to restrain block size growth, e.g. costs of larger blocks mostly burden node operators, while miners mostly benefit.
Specific implementation issues with the mechanism of establishing bigger block sizes in the network.
The necessity of a hard fork to activate the proposal.

For a more comprehensive overview, I'd recommend that you read the excellent three part series by Aaron van Wirdum that explores the proposal in detail:

A Closer Look at Bitcoin Unlimited’s Configurable Block Size Proposal
How Bitcoin Unlimited Users May End Up on Different Blockchains
Why Bitcoin Unlimited’s “Emergent Consensus” Is a Gamble

BIP100

Is a block size voting mechanism proposed by Jeff Garzik in 2015. It would establish a dynamic block size per vote of the miners. Each block would cast a vote for a maximum blocksize, and from the votes of the past 12,000 blocks the current limit would be derived by discarding the lowest 20% of the votes and picking the remaining minimum.

The proposal puts block size under control of the miners and requires a hard fork to activate.

Aaron van Wirdum covered it here: A Closer Look at BIP100: The Block Size Proposal Bitcoin Miners are Rallying Behind

Extension block

Another proposal to improve capacity which suggests appending additional blockspace similarly to how segwit adds the space for the witness programs. Unupgraded nodes only see the stripped version of the block (just like in segwit). However, while segwit keeps all the transaction "instructions" in the stripped block and only partitions the one-time-use witness program, the extension block actually allows complete transactions in the added space. Unlike segwit, the extension block therefore establishes a second UTXO set only visible to upgraded nodes. While the proposal could be rolled out as a "softfork" due to the stripped blocks being backwards compatible, the partioning of the UTXO set would basically force everyone to upgrade immediately to the new version in order to be able to track all economic activity on the network. (Whereas with segwit even old nodes see all transactions, even though the nodes don't understand some restrictions that apply to the segwit formatted transactions.)


How to check if the block chain is up to date using bitcoind or json-rpc? I read the full api method list and did not seem to find one.

I suppose there is no command specifically for that purpose, so what is the general way of doing this?

I would consider checking the time stamp of the last generated block, but the getblock method is not really explained in much detail.

EDIT:

Some people answer that I should compare the block count with one of an online block chain monitor. That is not really a practical solution. The Bitcoin-Qt client has a way of knowing when syncing is done (the V-sign vs the syncing icon), so why doesn't bitcoind? How does the Bitcoin-Qt get this information?

I use a python script that grabs http://blockchain.info/q/getblockcount and compares it to the output of bitcoind getblockcount.

As others have said, there is no absolute way of telling if your blockchain is up to date.

Anyway, here is my script:

    import httplib2
    from bitcoinrpc.authproxy import AuthServiceProxy
    access = AuthServiceProxy('#########')
    try:
            blockCount = access.getblockcount()
    except Exception as e:
            print "Problems connecting to bitcoin wallet:"
    else:
            try:
                    response, trueBlockCount = httplib2.Http().request("http://blockexplorer.com/q/getblockcount/")
            except Exception as e:
                    print "Unable to get true blockcount from blockexplorer:"+str(e)
            else:
                    if (int(trueBlockCount) - 5) > blockCount :
                            print "blockchain not up to date: true block count is: "+str(trueBlockCount)+", while bitcoind is at: "+str(blockCount)


How can a single funded channel become bidirectional? Is it possible that funding transaction of Lightning Network channel has got just one input? And if yes will it be one-directional during whole period of channel existence? Or after some off-chain transactions into Lightning Network, channel will become bidirectional due to second participant will have some funds after this transactions?

The amount of inputs of the funding TX has nothing to do with the question if the channel is unidirectional or bi directional.

What is relevant to understand is how the commitment tx encodes the balance of the channel. (the difference between capacity and balance was discussed in this question

In the standard case the balance of the channel gives all the capacity to the party funding the channel. (currently only one party can fund a payment channel but this will change with dual funded channels which are supposed to come with the next protocol update aka BOLT 1.1). So in the beginning of the lifetime of the channel it seems unidirectional as only the funding party can send money by making a payment or routing a third party payment on this channel.

However once that has been done the commitment transaction is invalidated and a new one is negotiated which has a different distribution of the balance. Now the party funding the channel is able to receive Bitcoin on this Channel.

There is one tiny exception: every channel partner must keep 1% of the channel capacity as a reserve for the penalty if a channel brach happens. So if the party that funded the channel makes initially a payment of less than 1% of the channel capacity it still cannot receive on that channel.


How could LN mitigate NAT transversal problem? As we all know, IPv4 address space is already exhausted, many ISPs have deployed carrier grade NAT (CGN). So how could an LN node living behind NAT deal with NAT transversal problem? How could two NATed LN nodes communicate with each other?

first of all if your lightning node sits behind a NAT it can still connect to other lightning nodes and also open channels with them. once you have channels you don't need a public IP address but your node id is enough. your channel partner and nat will solve the rest.

The problem is that your node behind a NAT does not have a public IP address. therefor you need to configure port forwarding in your NAT.

edit:
Also you can run your lightning node behind a toronion to have a static address.


Error compile bitcoin mac OS I have straggle to compile bitcoin core on mac OS machine. it has an error as the following:
/usr/local/include/QtCore/qglobal.h:667:65: error: expected '>'
         typename = std::enable_if_t<std::is_arithmetic_v<T> && std::is_arithmetic_v<U> &&
                                                                ^
/usr/local/include/QtCore/qglobal.h:667:65: error: expected ',' or '>' in
      template-parameter-list
/usr/local/include/QtCore/qglobal.h:668:66: error: expected unqualified-id
                                     std::is_floating_point_v<T> == std::is_floating_po...
                                                                 ^
/usr/local/include/QtCore/qglobal.h:679:35: error: no type named 'Promoted' in namespace
      'QTypeTraits::detail'
using Promoted = typename detail::Promoted<T, U>::type;
                 ~~~~~~~~~~~~~~~~~^~~~~~~~
/usr/local/include/QtCore/qglobal.h:679:43: error: expected ';' after alias declaration
using Promoted = typename detail::Promoted<T, U>::type;
                                          ^
                                          ;
/usr/local/include/QtCore/qglobal.h:691:31: error: no template named 'Promoted' in namespace
      'QTypeTraits'
constexpr inline QTypeTraits::Promoted<T, U> qMin(const T &a, const U &b)
                 ~~~~~~~~~~~~~^
/usr/local/include/QtCore/qglobal.h:693:28: error: no template named 'Promoted' in namespace
      'QTypeTraits'
    using P = QTypeTraits::Promoted<T, U>;
              ~~~~~~~~~~~~~^
/usr/local/include/QtCore/qglobal.h:694:5: error: unknown type name 'P'
    P _a = a;
    ^
/usr/local/include/QtCore/qglobal.h:695:5: error: unknown type name 'P'
    P _b = b;
    ^
/usr/local/include/QtCore/qglobal.h:699:31: error: no template named 'Promoted' in namespace
      'QTypeTraits'
constexpr inline QTypeTraits::Promoted<T, U> qMax(const T &a, const U &b)
                 ~~~~~~~~~~~~~^
/usr/local/include/QtCore/qglobal.h:701:28: error: no template named 'Promoted' in namespace
      'QTypeTraits'
    using P = QTypeTraits::Promoted<T, U>;
              ~~~~~~~~~~~~~^
/usr/local/include/QtCore/qglobal.h:702:5: error: unknown type name 'P'
    P _a = a;
    ^
/usr/local/include/QtCore/qglobal.h:703:5: error: unknown type name 'P'
    P _b = b;
    ^
/usr/local/include/QtCore/qglobal.h:707:31: error: no template named 'Promoted' in namespace
      'QTypeTraits'
constexpr inline QTypeTraits::Promoted<T, U> qBound(const T &min, const U &val, const T &max)
                 ~~~~~~~~~~~~~^
/usr/local/include/QtCore/qglobal.h:710:31: error: no template named 'Promoted' in namespace
      'QTypeTraits'
constexpr inline QTypeTraits::Promoted<T, U> qBound(const T &min, const T &val, const U &max)
                 ~~~~~~~~~~~~~^
/usr/local/include/QtCore/qglobal.h:713:31: error: no template named 'Promoted' in namespace
      'QTypeTraits'
constexpr inline QTypeTraits::Promoted<T, U> qBound(const U &min, const T &val, const T &max)

Please advise.
i used command brew install qt5

I had the same issue, seems like the problem is that I had both qt5 and qt6 installed, and it used qt6. Try running:
brew uninstall qt
brew install qt5


Why is mining difficulty increasing? I have heard in many places that mining difficulty is increasing, meaning that the hardware used to mine new coins will need to be more and more powerful as time goes on.

What is pushing mining difficulty upward? Is it related the number of people mining (a supply and demand kind of thing), the size of the blockchain, an intentional system design?

I found two related questions 1 2, but they are not exactly the same. I am more interested in what factors affect the difficulty and how. For bonus points, include predictions about future conditions.

The mining difficulty directly reflects the amount of computing power that the Bitcoin network has. This is adjusted on a periodic basis so that the average block solution time is 10 minutes (Bitcoin clients recalculate the difficulty every 2016 blocks). The difficulty can go up or down depending on how much effort people are putting into mining.

More information about difficulty can be found on the Bitcoin wiki.


How do I add two secp256k1 keys together? I have two public/private keypairs, A and B. I want to add them together to get a new keypair AB.

I'd also like to be able to add the public keys of A and B to get the public key of AB.

How do I do this?

Most ecc libraries will have this function, but if you want to program it yourself, here's what you do:

First, compute the slope of the line containing the points A and B. Let A = (X_a, Y_a) and B = (X_b, Y_b). The equation for the slope is:

s = (Y_a - Y_b) / (X_a - X_b)

The resulting point, we'll call C = (X_c, Y_c) = A+B. Doing some math, you get:

X_c = s^2 - X_a - X_b
Y_c = Y_a + s (X_c - X_a) = Y_b + s(X_c - X_b)

If X_a == X_b, then it depends on Y_a and Y_b. If Y_a == Y_b, then A and B are the same, so really, you're just computing a point doubling (2*A). If Y_a == -Y_b (the only other possibility) then A+B = the point at infinity, or the identity. Usually, that's not a very interesting point for cryptography. Computing 2*A is a little trickier, but can be done. You're already doing that when you compute the public key from the private key with G anyway, so I'll assume you have access to something that lets you double a point.

Note all the operations are all field operations, so you have to mod by P for secp256k1 (FFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFFEFFFFFC2F in hex).


Does an Invalid Transaction persist in the mempool? My basic understanding is that a transaction will continue to exist in the MemPool until it can be completed, (or eventually gets evicted due to the size of the MemPool).

To me, this leads to a strange situation:

A Wallet tries to spend more BTC than it current has
Miners reject that transaction (or more properly, fail to confirm it). But the transaction remains in the mempool.
At some much later point, the Wallet gets more value.
The previously rejected transaction can suddenly be confirmed.

This is roughly equivalent to bouncing a check with your bank, and then having the check clear days, weeks, or months later when you eventually get the money!

Is this actually how BTC works?  Or is there point where a transaction can be officially and completely rejected, just as at it can be confirmed?

A Wallet tries to spend more BTC than it current has

Technically, that would only be possible, if you try to spend an input (coin) that you can't sign (a.k.a. that you don't own).

Your local mempool (if you run Bitcoin Core or a similar fullnode) would reject the transaction immediately.
The transaction would not be broadcasted over the p2p network, because all nodes do reject transactions that are trying to spend inputs with invalid signatures (or inputs that doesn't exists)

  At some much later point, the Wallet gets more value.

The transaction is already made. It won't auto-update. It was already rejected.

Now one expect your local wallet knows the ("old", invalid transaction).

The only thing you can do now is to recreate the transaction (now with the correct inputs) and have it send over the network (and have it mined).

  The previously rejected transaction can suddenly be confirmed.

Invalid transactions cannot be mined and will not be broadcasted (broadcasting would be possible but extremely unlikely).


What is the meaning of the term "full-node"? There seem to be some different interpretations of what the term "full-node" implies. E.g. there seems to be some disagreement whether a pruned node is still a full-node.

So: What characteristics must be fulfilled to label a Bitcoin client as a full-node?

Fully validating nodes ("full nodes") are clients that have validated the whole blockchain self-sufficiently and enforce all of the rules of Bitcoin on any data they receive. Therefore, they cannot be cheated by means of invalid blocks or transactions.
Running your own full node is the most secure, most private, and least trusting way to participate in the Bitcoin network. A full node is necessary to prevent invalid blocks when mining.

Common usage of the term does not require that the node keeps all blockchain data at hand. Although many full nodes have a complete copy of the blockchain, full nodes can also run in pruning mode.

Nodes that can serve the complete blockchain are referred to as Archival Nodes.

Sources:

The Bitcoin wiki explicitly describes pruning as an option for full nodes (see Wiki: Full Node).
Bitcoin.org: What is a full node?
Bitcoin Core developer Pieter Wuille announced the pruning feature thusly on Twitter:

  @orionwl just merged pruning support in #Bitcoin Core! Run a (no wallet) full node with 1.3 GB storage. Thanks to all who contributed.


Bitcoin mining, do you do the work or does the computer? Assuming you have the appropriate hardware and software, does mining involve the person mining to sit at the computer to mine or do you fire it up and just let the software run and check back later to see the results?

The extent of human involvement in mining is to get the software and hardware and then run the software on the hardware. No one actually has to sit at a computer and do anything in mining. They don't even have to come back and check on anything as all aspects of mining are automatic save for computer setup and maintenance.


Does bitcoind need to be up to date to serve blocks to other servers Using bitcoin-13.2. I have an app that connects through port 8333 and fetches blockchain blocks. Problem is that my app connects and exchanges some info with bitcoin-core but I never receive the requested block from the blockchain. This is an intermittent problem. It appears to happen only when bitcoin-core is not connected to the internet. I m trying to isolate what is causing this behavior.

So, is there anything in bitcoin-core that would prevent an out of sync bitcoin-core from answering a 8333 request?

Thanks

Bitcoin clients are perpetually in a state of "catching up with the network".  There is no definitive point at which they are completely caught up.

If you are requesting a block or transaction that the client has yet to see, it will not be able to respond with that block or transaction.  Make sure that what you are requesting is something that the client has already seen and verified.  If you are sure that the client is aware of the data being requested, then you should continue troubleshooting.


How do I run my own testnet? What's testnet-in-a-box? If I want better control of my test environment while developing a bitcoin-related application it seems useful to run my own testnet rather than use the public testnet. How can I do this?

What is testnet-in-a-box? Can I use that? What are the advantages and limitations, if any? Are there other options?

Checkout the updated Testnet in a box.  You will need bitcoind already installed in your system.

The "Testnet in a box" linked above is just like the world-wide bitcoin network except the only members are the 2 running on your computer. There should be no difference except that it's easier to generate coins.


Is this brainwallet approach safe enough? Let's suppose I derive a private-public keypair from a passphrase like this :

long_and_complex_enough_but_yet_easy_to_remember_passphrase

Now I wish to generate 100 more keypairs using same passphrase, so I append consecutive numbers :

long_and_complex_enough_but_yet_easy_to_remember_passphrase_001
long_and_complex_enough_but_yet_easy_to_remember_passphrase_002
long_and_complex_enough_but_yet_easy_to_remember_passphrase_003
...
long_and_complex_enough_but_yet_easy_to_remember_passphrase_100

Is this safe enough to do, as long as the initial passphrase is enough complex one, or maybe the consecutive numbers add any vulnerability ?

Appending numbers doesn't open you up to any particular vulnerability, but using any human derived private key is an extremely poor idea. Markov chains are extraordinarily good at attacking passphrases, which is counter intuitive when most people assume an exhaustive search character by character.


Unconfirmed balance in MultiBit HD plus unconfirmed transactions (failed bitpay orders) I've had a little bit of BTC in a MultibitHD 0.5.1 wallet for a while now. With the latest surge in price, I tried spend it at a place that uses bitpay. My first transaction probably had too little of a fee and is unconfirmed. I attempted to redo with a larger fee but it too told me was too small a fee and my attempt to buy from the store failed.

After some searching I found that Multibit is not good to use anymore / discontinued. I also came across something telling me to repair the wallet which I did but then the remaining balance became unconfirmed and not sure what to do next.

How could I get back the unconfirmed balance or confirm it? Is there anything I can do about my two unconfirmed transactions? Would it make sense to transfer everything to a new wallet software (can't when unconfirmed balance)?

Following this suggestion in the GitHub issues page solved the unconfirmed balance in MultiBit HD.

I performed the following in Windows 10:

Closed the MultiBit HD Application
Navigated to the wallet data in %AppData%\MultiBitHD\
Rename the folder mbhd-12345678-... to old-mbhd-12345678-...
Reopen the MultiBit HD Application.
Restored from wallet words (Requires words and datestamp).

Note: I did not have to close the application during synchronization like the GitHub comment suggested.
After synchronization, the unconfirmed balance was then confirmed. I was then able to transfer my balance to another address and software.

At the time it just appears to have been an over flooding of transactions making confirmation slow especially with my low fees (0.1 mbtc, 0.5 mbtc, 0.75 mbtc). Wallet balance transfer and the two unconfirmed transactions have been processed and confirmed.


Can we check if a miner has validated the solution? When a miner finds a solution for the block and broadcasts it to the other node, all the other nodes verify if it is a correct solution or not. The idea pops up a few questions in my head:

I read somewhere that if mining pools find a solution, then peer miners in that pool don't verify the solution and straight away go for the mining of next block on top of it. This is kinda unfair for the other miners. Do we have any system to check if a miner has validated the solution or not?
On the other side of it, not sure how often does this happen on the network but a pool of miners can share wrong solutions to keep the other miners busy and get an advantage. Does this happen on the network?

Thank you in advance! :)

Firstly, correct me if I'm wrong.

When a miner finds a solution for the block and broadcasts it to the other node, all the other nodes verify if it is a correct solution or not.

It's very trivial to validate the PoW, just hash the block header and then count how many "leading zeros" that hash contains (note that such description is theoretical. The actual implementation allowing "fractional leading zeros" is somewhat complex or even weird).
Validating the whole block is much more complex and "costy" than validating the header only. The CVE-2018-17144 inflation/DoS vulnerability was actually caused by improper optimization of the validation code in order to further improve block propagation.
However, theoretically no matter how many miners are in a pool, they are just one single full node (as the identity of the pool) in the Bitcoin P2P network.
It's the pool who constructs the block to be mined. Pooled miners using the stratum protocol don't download the full block data at all. They only download minimal data required (like the block header, coinbase transaction etc) to do the SHA256d mining. They therefore don't validate the block because it's not even downloaded at all.
So we can see, currently pooled miners (who do not run their own full nodes) blindly follows the pool, so that it's possible for an evil pool operator to abuse the hashpower provided by miners in that pool. Actually some miners are even happy with such situation, because some pools promotes features like "automated switching for maximum profit". We may see improvement/relief on this issue in the future if BetterHash/StratumV2 protocol could be widely adopted.
Besides, pooled miners can indeedly attack the pool (or other miners in the pool, depending on the pool's payout mode, PPS or something other) by withholding the solution, albeit it's very trivial for the pool to validate the solution (PoW).

Can we check if a miner has validated the solution?

To my knowledge it's currently not possible to know whether a miner (mining pool) had validated the whole block.
It's just the miners' own interest to fully validate the previous block once again on their own, so that they would be completely confident that they won't waste their hashpower/electricity costs on an invalid branch of blockchain.

I read somewhere that if mining pools find a solution, then peer miners in that pool don't verify the solution and straight away go for the mining of next block on top of it. This is kinda unfair for the other miners. Do we have any system to check if a miner has validated the solution or not?

You seem to describe a kind of validationless mining called "SPV mining".
However, it's not "peer miners in that pool", but other pools (or solo miners) can possibly do that.
It indeedly once caused problems, like the 2015 chain-fork incident related to BIP66.
Theoretically there's also a variant of selfish mining attack called "Blockchain Denial-of-Service (BDoS)", which aims to push victim miners under profitable line.
There's also a controversial argument that SegWit also has an issue similar to BDoS, because developers had once pointed out that SegWit allows the miner to mine atop previous block without downloading & validating the witness data (mostly digital signatures, only SegWit transactions have such data), so that that miner could then collect transaction fees with higher confidence (because, with the non-witness part of the previous block it's already enough to update the UTXO set, which is the "global account balance database" of Bitcoin maintained by each full node on its own).

On the other side of it, not sure how often does this happen on the network but a pool of miners can share wrong solutions to keep the other miners busy and get an advantage.

In selfish mining, it's not really a "wrong" solution to be shared, but stale branch of the blockchain which the victim "honest" miners have no choice but to mine atop it, because the longer branch is withheld by "selfish" miners.


Why is my withdrawal from the 50BTC pool not visible in the blockchain yet? I did a bitcoin transaction of 216 BTC from the 50BTC mining-pool to my wallet (Bitcoin-Qt).

It has been 3 days now and I have not received anything yet.

I've tried to search my address on blockchain.info and it doesn't come up.

50btc was hacked some time ago and the hacker completely messed up all account balances. If you actually have mined over 200 BTC there, I suggest you contact the administrators. But I assume you're just one of the people who woke up one day and saw that your 0.001 mining profit had been replaced with a completely arbitrary number of coins, in which case no, "your" Bitcoins were not lost since they never existed in the first place.


Is there a tutorial on how to set up a secure enviroment and use Electrum? Which OS to use? How to verify that the OS is secure?

How to download and install Electrum securely? There are many methods - binaries, git, homebrew, Ubuntu package, building from source.

Is there a tutorial that has step by step instructions on how to set up a secure environment for Electrum and use it securely?

Here is check http://secure-bitcoin.blogspot.ru/, please leave a comment if you find any mistakes


How I should pay tax if I buy Bitcoin from an overseas friend Assume I buy 1 bitcoin from an overseas friend which is USD$10 and I sell it in US for $11.

is it legal? I am afraid, it would be considered money laundry
I will not be able to have official receipt from my friend, do I pay tax as for the earning of $1 or sell price $11?

The $1 is a Capital Gain (it's not income except perhaps if you're a professional trader). So, if there's tax to be paid, it will be Capital Gains Tax, not Income Tax. When you declare your total Capital Gains and your total Capital Losses to your tax authority, they will tax you on any net gain over and above your personal allowance (which will depend on your personal circumstances). See https://www.irs.gov/taxtopics/tc409.html


How to Avoid Wallets Compromised by Android Vulnerability I'm interested in understanding Bitcoin better, and developing good habits with regard to cryptocurrency, even though I'm not using Bitcoin very much at the moment.

But based on my very limited activity with Bitcoin, I think I've found myself in a vulnerable position through mechanisms that I don't understand. Here's what I've done:

Months ago, I set up Bitcoin Wallet on my Android phone. And it, of course, assigned me a Bitcoin address (1L...).
I visited a couple of those sites where you view an advertisement and get a trivial amount of Bitcoin, just to see how the transactions flowed. This worked, and I then had Bitcoin holdings that were too small to spend. I left it all alone for a while.
I installed Multibit on my desktop and imported my private keys from Bitcoin Wallet.
Bitcoin Wallet posted a notice of an Android vulnerability that affected Bitcoin wallets, and suggested moving funds to a new address. The app created a new address for me (1M...). I imported the new private keys to Multibit, but my holdings were of course too small to be moveable.
Recently I saw that an app developer who makes a free app that I find highly useful was taking tips in Bitcoin. I thought this would be a nice chance to go a little deeper into the Bitcoin ecosystem. So I purchased enough to cover my tip (with a little left over) from Coinbase, and then transferred them to my new, presumably uncompromised, address: 1M...
I initiated my tip to the app developer in Multibit. That transfer went successfully, but when I examine the blockchain, I see that the transaction has emptied my new address (1M...) and put it all in the old address (1L...) that Bitcoin Wallet warned me not to use any more.

The amounts I'm dealing with are quite small, so I'm not in a panic about it -- but I don't understand what happened here. Specifically,

Why did the transaction clear out the funding address rather than just take what it needed from it?
Did I do something wrong? Or, alternately, is there something I could/should have done to manage the transactions with more detail?

As this bug has been fixed the best idea is to archive those addresses which have been generated before the update (not all wallet applications support this feature). The other is to completely remove the wallet and replace with a new updated version.

As far as im aware no wallet supports deletion of addresses (for obvious reasons).

As for creating transactions, on specific wallets some have more detailed sending abilities than others, its all about a balance of userfriendly vs features. If you look at blockchain.info wallet it has advanced features allowing specific send from and change addresses to be set, most mobile apps will probabaly lack such sophistcation due to being made for mobile.


How to open lightning network channel to a selected node in Electrum? Electrum (version 4.1.2) Open Channel dialog only contains a dropdown "Trampoline" with predefined entries. How a new channel can be opened to a specific node?

Go into Tools -> Preferences -> Lightning and disable the setting "Use Trampoline Routing (disable gossip)". If you now try to open a new channel you will see that you can put the full node id there in a generic text field, and the drop down is gone.


INPUT Script with no ScriptSig? Anyone knows what does it mean when there is no ScriptSig under INPUT SCRIPT for a TX?

See here:

https://i.imgur.com/TCHFUfV.jpg

Thanks!

It seems to be a witness transaction according to your screenshot (you can see the same missing scriptSig followed by witness here).

Segwit encodes the signature information slightly differently from the regular script sig, so it will not show up under that heading. A segwit transaction would still contain the information you would traditionally see in the scriptSig, but in the witness section instead.


Can transactions scale sufficiently to compensate the diminishing block reward by fees? Today, the bitcoin network is secured by massive computing power, which is expended in the process of mining. The miners are rewarded by newly mined bitcoins, plus transactions fees.

The security of the network relies on the computing power being so expensive, that no one group can afford to gain 51% share.

Eventually, the amount of newly mined bitcoins will diminish, and the mining  reward by itself would cause mining to become unprofitable.

Will the fees be able to pay the expenses for the huge expensive computing power?

I can see two extreme situations where it might work:

a) either the transaction fees will be astronomical
b) or there will have to be huge amount of transactions

option a) is clearly not viable, which leaves option b).

What would this mean for the bitcoin economy?

Will bitcoin need to become "high-velocity" money?
How could that be enforced? And how would we prevent the blockchain growing out of control?

Is my analysis correct?

Or a combination of both. It looks like things like the Lightning Network will be there for micro payments and smaller amounts so that only larger transactions will be directly on the blockchain. For larger (and aggregate) transactions a bit more fee shouldn't be a problem (a). Also at some point the block size will likely be raised allowing for more transactions per block as well (b).

Either way your title is wrong: there is no post-mining world.


Why would anyone use a payment network based on an imaginary currency? Almost everyone who encounters the idea for the first time (including me) has the same reaction, that can't possibly work. But so far the market has proved the skeptics wrong.

The currency you are most likely used to right now is fiat money or in other words "imaginary".

  DEFINITION OF 'FIAT MONEY'

  Currency that a government has declared to be legal tender, but is not
  backed by a physical commodity. The value of fiat money is derived
  from the relationship between supply and demand rather than the value
  of the material that the money is made of. Historically, most
  currencies were based on physical commodities such as gold or silver,
  but fiat money is based solely on faith. Fiat is the Latin word for
  "it shall be". http://www.investopedia.com/terms/f/fiatmoney.asp

So I would ask you, why do you use an imaginary currency?


When creating a block, who actually generates the 25 bitcoins that act as a reward? I realise that somebody who manages to find a new block in the blockchain gets 25 bitcoins as a "reward".

Where do these bitcoins actually come from? How are they minted? How are they actually generated? What's the "everyman's" explanation of what happens, in the blockchain, so that these "new" 25 bitcoins are actually created?

The 25 BTC are actually generated out of thin-air. Essentially every peer in the network knows to accept blocks where the first transaction in every block should be of maximum 25 BTC. If it's more, then the block is considered invalid. Note that these are the coins given to the miner since the miner is the one creating the block and can therefore set to which address these 25 BTC go to. Also note that 25 is not an hardcoded value, it changes with time. Again, there's another rule "programmed" into each peer where they can calculate the current reward. Currently the maximum allowed is 25, but every certain amounts of blocks, peers know that the value needs to be halved - it was originally 50 BTC, now it's 25, next it will be 12.5.

So to answer your question, peers collectively know that the rule is to generate coins out of thin air every so often, and the person that gets them is the person that mined the block. You might be asking: what if a dishonest peer changes the 25 BTC transaction to go to himself rather than the miner. They can't do this because they would need to re-mine that block (changing contents of a block also changes its hash).


Do Full Nodes perform Proof of Work to validate a Block? I do understand that Full Nodes validate all transactions twice based upon the public key of the users. Firstly, once a transaction is unconfirmed and secondly the transactions that have been mined in a block. My Question is do the Full Nodes also perform Proof of Work to confirm the validity of a Block or not?

Hashcash-style proof of work is a simple search process: Try lots of nonce values until you get an acceptable solution.  To verify a node simply just has to try one value, the one the miner provided.  So it uses the same test but does not search, as a result it does very little work.

The Bitcoin software hasn't really validated transactions twice since 2012. Caching is used to reuse the validation effort from the first time the transaction was seen, especially for the digital signature verification.

Very careful engineering has been required to make sure that the handling of unconfirmed transactions can't accidentally cause invalid blocks to pass. This is especially a concern because complications like locktimes and soft-forks can make the validity of a transaction some what conditional. But in the latest software really the only validation needed at block time of an already seen transaction is the locktimes and double spending checks.


How does the graph of money supply of PPCoin look like? We all know how the money supply graph in Bitcoin looks like - exponentially reaching 21,000,00 BTC.

How does the same graph behave for PPCoin (A fork that also involves Proof Of Stake)?

Here it is:

Note that this chart goes only up to March 2014. In the future, when proof of stake dominates, there will be a steady 1% inflation every year, but also 0.01 PPC will be destroyed every transaction. It is not known exactly what will happen, i.e. whether the 1% inflation or the destruction of coins every transaction will be a more significant factor.


ScriptSig raw hex to sign raw tx i have a p2sh address that is created using an uncompressed public key (from my ledger nano) and a compressed public key (bitcoincore wallet). It requires both signatures to send the funds. When i use my nano ledger to sign i get output:

3045022100b0c80ad5f5db6b790b75156186322b1fd6f9d1da61ff04e47f5a64ca8cdfaf6f02207bce077a537e215d9dd5ccaae72e8af1c4750e67722910c2af1d1f3b6e9357f2

I am using the ledgerjs library to get this and using the signP2SHTransaction function. Normally i just input my private key into bitcoin core's signrawtransaction function but I am pretty sure this is the scriptSig. I just don't know of any libraries that allow me to use this to sign the rawtx. (I looked at python-bitcoinlib but i saw no way to input rawtx information into a readable format.)

Any suggestions on a tool i can use to take this to sign the raw tx hex to the send on the wire?

You are correct, that is the scriptSig. I'm not sure if there exists a tool to add this to an unsigned tx, but you really just need to append it to the input you were signing. If you had multiple inputs, you need one of these for each input. Depending on your sighash flags, they may or may not be identical.


What percentage of altcoins are based on Bitcoin? What percentage of altcoins share the same codebase as Bitcoin?

Map of Coins is a great resource for this.

As of May 2016 they are tracking a total of 710 cryptocurrencies. Of those, 667 are based on Bitcoin's code, which is 94%!


Sync bitcoin transaction status to local database I am sending bitcoin transaction in node js via bitcore-lib and bitcore-explorers.

I realized that when i call the function .broadcast to send the transaction to network and returns value, it means that the transaction is broadcasted but not completed.

What I want to ensure that when the transaction is in bitcoin network , I will need to write the status into local database (pending, success or fail).

I am thinking of looping and keep calling the transaction detail by txid until it is completed only it write to database. But thinking that bitcoin network transaction will take up to 30 minutes it might not be a good approach because the node server might take up a lot of resources in keep querying the transaction detail.

Any idea on what's the best practice to ensure that local database transaction detail and status in sync with the bitcoin network?

And what function should i use to get transaction detail? I seems to not able to find query of transaction detail in bitcore library.

Since you aren't running your own node, the best way would be to simply check each new block for your transaction. Since transactions can only be mined if a new block is generated, you don't need to poll for a status chain between blocks.


Mining Fee for the blocks that are orphaned Suppose a miner mined a block and the block got added in the main chain of the block chain. He must have got his mining fee then. Now suppose that due to a fork sometimes later, the block that he mined is no longer a part of the main chain, i.e. that block is orphaned now. Then would he retain his mining fee or would it get deducted?

If the block he mined is no longer a part of the main chain, then his mining fee for that block would simply not exist on the chain. So the miner would not retain the fee, but it wouldn't technically be 'deducted' either. 'Deducted' implies that the system is reducing the value of the miner's account. Instead, the system just has a different UTXO set, which does not include those mining fees.


Can the lightning network be subject to DoS attacks due to message flooding? In the current implementations of the Lightning network protocol (c-lightning, eclair and lnd), is there any check that stops spamming/flooding of channel_announcement, mode_announcement or channel_update messages? Assume that these messages are valid and provable.

The protocol is purposefully built in such a way that DoS attacks are mitigated and reduced in impact. Each channel_announcement contains a reference to the funding transaction, and each node verifies that this funding transaction matches the information in the announcement. This makes the creation of a channel_announcement non-free, and binds some resources of a potential attacker, and a channel may only be announced once. channel_updates are only valid if they are preceded by a matching channel_announcement making them also non-free. The same is true for node_announcements which must be preceded by at least one channel_announcement announcing a channel for that node.

While channel_announcements are unique, this is not true for channel_updates and node_announcements, which can update the parameters of a channel/node. To mitigate a potential flood of updates the protocol specifies that a staggered broadcast must be used, which buffers incoming gossip messages and waits 60 seconds for in-memory replacements before forwarding them. This coalesces multiple updates for the same channel or node into a single message then being actually broadcast. So if you attempt to broadcast loads of updates they'll be aggregated at the first hop, and only the latest one will ever be forwarded.

This reduces the number of messages that a node may broadcast to 1 channel_announcement per channel, and 1 node_announcement per node per 60 seconds and 1 channel_update per channel per 60 seconds.

(Disclaimer: I am one of the spec authors and the author of the staggered broadcast proposal)


What is the program in Python that print information about the current block? What is the program in Python that print information about the current block the world try to mine (I mean Version, Previous Block, Merkle Root, Time, Bits) plus how many zeros we are looking for for the output of the hash!

To take the information of the bitcoin blockchain, you can use the bitcoin core RPC Framework, for use it, you must have all blockchain on your computer

Download Bitcoin core
aligns the bitcoin node
Configure rpc framework
Use the API to take the information, I prefer using this library with python, this is an example for using it

You can use this documentation for study API

also for a response to the last comment, you can use the API for call the Mining commands but is difficult understand your question "I can print information about the block they're mining now" because the mining is a war for the node and each node can have different information


In Proof-of-Stake, can a block creator fudge the block hash? In Proof-of-Work, a block hash is costly to manipulate (say, wanting the hash to be even, or have the hash of the hash smaller than some number) since there is a lot of computing power put into selecting the right header to produce a valid hash.

I'm wondering - are the block hashes in the various Proof-of-Stake implementations easier to manipulate since the hashes aren't bound by PoW mining? Could a PoS miner spend some computational time to generate many valid blocks and pick one to use, or are there some other constrains preventing block hash fudging?

Absolutely. ECDSA signatures at not unique, they can always be permuted by the signer at will by re-signing with a new nonce. The creator of the block can also choose to reorder or omit transactions to alter the block and then re-sign this to get a new block hash.


Are There Abbreviations/Acronyms/Codes for Cryptocurrency Exchanges? I wonder if there are any abbreviations/acronyms/codes for exchanges like Cryptsy, Kraken, and Ccex. Similar to abbreviations as seen for coins in Bitcoin = BTC and Litecoin = LTC.

No, there are not such codes for Exchanges, like there aren't any codes for different websites. The codes for the different currencies are just for shortening I believe. It's easier anyhow for trading pairs (NMC/BTC instead of Namecoin/Bitcoin)


For how long has a channel been inactive? I would like to close channels for which there is enough evidence that the remote node disappeared and won't come back.
So my idea was to check for how long a channel has been inactive, and if it is > two months to close that channel.

How could I find out for how long a channel has been inactive (in LND)? Finding out which channels are inactive is easy by queryinglncli listchannels --inactive_only, but the result does not show any indicator about how long that channel has been inactive.

You can look for "last_update" field in getchaninfo output.

Below I also submitted https://github.com/edouardparis/lntop console screenshot which does the same thing.


Could Bitcoin work as a world currency? We've seen the issues taking place with the Eurozone, notably that countries who share monetary union seem to ultimately need to share economic union, which tends to lead to political union.

Is there a plausible scenario whereby Bitcoin (or similar) could become a world currency, yet somehow different countries could avoid economic/political union and maintain sovereignty?

It all boils down to the amount of people who adopt it as a stanard as measurement of wealth. if around 10% of the country were to use it as a form of payment (requesting it for wages, using it in shops and so forth) the likelyhood of it taking of would be signifcantly higher, below this it would never happen.

[EDIT - Found it] http://pre.aps.org/abstract/PRE/v84/i1/e011130

The other issue is government buying into the idea of a currency they could not control, although this would be relevantly null if they were to hold a substantial amount of any given currency, there is little reason they couldnt "mint" their own chain and distribute the funds.

Both ideas are entirely possible with widespread adoption but until the magic 10% figure is hit it will never happen.


How do I find a renamed wallet whose name I can't remember? I bought BTC in 2011 and renamed my wallet.dat to something else that I cannot remember. How can I find my wallet file on my computer? I'm prepared to use the command line and scripting.

Place to start - use the linux "file" command, which will show the following for a bitcoin wallet (at least in the client I use)

wallet.dat: Berkeley DB (Btree, version 9, native byte-order)

So - you could run something like:

find / -type f exec file '{U}' \; | grep "Berkeley DB"

That would be a start!


SHA256 Implementation Gate Equivalent I needed help in understanding how to calculate the GE for a SHA256 implementation. I need to calculate the GE of individual functions in the SHA256 hashing algorithm.

Could anyone please direct me to an appropriate paper/book that explains this in detail?

Well, the answer to this question mostly depends on what kind of implementation you choose for your multiple-input 32-bit wide adders (there are several different solutions to this speed versus gate count trade-off). Usually, when using the term "gate equivalent," engineers are talking about FPGAs, where it is a cool marketing slogan that tries to persuade you that the FPGA is much more powerful that you'd think from its number of logical elements because some of them can implement complicated circuits that would need a high number of gates otherwise. In this case, you will almost certainly use whatever special provisions your FPGA chip has for wide additions (and your GE count will depend on whatever its manufacturer's marketting department believes to get away with for translating that into "typical" gate counts of comparable circuits).

If your goal is to estimate how much of SHA256 you can fit into a given FPGA, you may be even better off comparing with what others have achieved. This may take a bit of digging, but will give you good estimates. The FPGA section of this wiki page for mining hardware comparison could give you initial links. I don't have numbers at the ready, but I remember having concluded ca. 15 month ago that those FPGAs that were mature enough then to have single-unit bare chip retail prices around 100 $ (the most computing per money you could get then) tended to be just about big enough for a fully unrolled and fully pipelined double-SHA256 implementation.


Services paid in Bitcoin I am interested in what other internet and other communication services out there are accepting Bitcoins for payment.
I know of http://mullvad.net/ for VPN and a few others, http://www.chundle.com/bitcoin for Usenet.

I doubt there are any ISPs yet or cell services.

Bitcoin Torrents lets you use their uber-fast servers to download a torrent.  Then you can stream it from there at a consistent rate.  Very nice idea!