Bitcoin: Replace-By-Fee

My friends may have noticed a peculiar pattern in my emails, that have been exploring Bitcoin. I have partially been asking questions, and tentatively finding wrong answers to them, until such a time as I have found the correct answers.

The most recent question had to do, with why, after I had sent some Bitcoin-amount from my Bitcoin Core wallet, to my Electrum wallet, that amount appeared as 'Pending' within 10 minutes, but took up to an hour to be Confirmed. It was specifically the speed with which it appeared as Pending, not how slowly the transaction was confirmed, which struck me as a mystery, given that the way the network is supposed to function, only the mining pool which has been given the request to send my transaction, should be in the process of solving the hash, for a block, which it is mining, and given the fact that the rate of 1 block every 10 minutes, is being shared between mining pools.

My next hypothesis was, that all the mining pools could have been working to mine the same transaction-list, which was an alarming idea for some obvious reasons. And that idea was false.

As it happens, this is completely normal behavior. The reason the receiving wallet sees the transaction as Pending so fast, is the fact that on the receiving end, the wallet connects to numerous nodes, and any one of those nodes could be the same node, belonging to the mining pool that I asked the amount to be sent from. So the appearance of the transaction as Pending, does not mean that the transaction has been inserted into the block-chain yet, its status as Confirmed does.

To top it off, I had 'RBF' enabled on the sending wallet.

'RBF' stands for "Replace By Fee", and is a special feature offered by Bitcoin Core. What it means, is that A could be sending an amount to B, which B sees as an Unconfirmed amount almost immediately. And then B can send funds from that Unconfirmed amount to C, provided that both A and B are clients of Bitcoin Core, and that A offered this ability when sending the amount to B.

- Bitcoin-Core Clients -
A  ->(RBF-enabled)  B  ->(unconfirmed-input)  C

A pays a slightly higher fee for this.

The reason this can exist, is the fact that Bitcoin Core is a large operator, and has confidence in the transaction sent by A. It therefore authorizes B to spend it again, even though (A -> B) is not in the block-chain yet.

Enabling this feature, given that Electrum is a 3rd-party wallet, and that some of the nodes it connects to are also Bitcoin Core nodes, virtually guaranteed that B would see the transaction, even though it was Unconfirmed, almost immediately. And in my case, there was no Party C (yet).

Also, Bitcoin Core could be making this feature an argument, not to increase the block-size, because as long as everybody has a Bitcoin Core -compatible client-program, the visibility of (A -> B) to party B, can act as an assurance that payment has been sent, even though it might currently take over an hour, for that payment to be Confirmed.

And, Party B need only be connected to a Bitcoin Core node for verification purposes, without having to use Bitcoin Core for sending, in order to be able to see the Transaction (A -> B) .

Actually, there is a partial admission, that this could lead to a double-expenditure somewhere. But Bitcoin Core is additionally confident, that this risk is minimal.


Dirk

 

My P2P Bitcoin Core Client taking a vacation today.

Today is Friday, July 7, 2017. According to some weather reports, there is a risk of Thunderstorms today. As I’m writing this the time is only 14h30 or so, and the Thunderstorms are expected for maybe around 17h00 or so.

A Thunderstorm could knock out my power, and could cause my blog to go offline. But this is a relatively minor inconvenience, according to recent experiences, because eventually I’d be able to reboot the host-machine and thus make the blog available to readers again.

If I had a Bitcoin P2P-client running, a power-failure could have more serious consequences.

So just to be safe, I shut down my Bitcoin P2P-client program for the day, while my Web-server is still running. I figure that providing no service for the time being, is a better alternative, than providing service which has gotten corrupted in some way. And then there could also be the eventual risk, of my having to rebuild my local copy of the block-chain, if simply rebooting the host-machine fails to recover it.

Because there are no T-Storms forecast for Saturday, I expect just to restart my P2P-client on Saturday morning. Sorry for any inconvenience to Bitcoin users today.

(Edit : )

As of 20h30, I am back up. For the moment, the Thunderstorm that was forecast, did not seem to materialize.

Dirk

 

Bitcoin-Core P2P Client Has UPnP.

I use a Bitcoin client, which is called “Bitcoin Core“. This is a version of Bitcoin, based on Peer-To-Peer protocols. This version of the wallet-program should not be confused with the Android version, which some people have on their phones, and which is Not P2P.

Several people who use the P2P version of this wallet-program, which builds our local copy, of the global block-chain, on a zero-trust basis, have observed that they leave their client running 24/7, yet that they do not seem to be functioning as a full peer. As a full peer, their computer can act to facilitate Bitcoin transfers. Even when not being used as a full peer, this version of the program will connect with up to 8 other peers – using outbound connections – and will use these connections to keep its internal version of the block-chain – and therefore their wallet – synced with the rest of the network.

So after some time, what people may simply ask is, ‘Why don’t I receive incoming connections, from other wallets, expecting me to help complete their transactions?’ This would be a reasonable question, yet gurus elsewhere have given a wrong answer.

In general, this P2P Node needs to listen on TCP Port 8333. Therefore, what some people expect, is that they need to establish a port-forwarding rule on their router, which forwards TCP Port 8333 to whichever machine on the LAN is running Bitcoin Core. The advice has sometimes been given, that if you forward this port, you will start receiving massive numbers of inbound connections, and will become useful to the network.

There’s a slight problem with this version of an explanation. Bitcoin Core has the ability to use ‘UPnP’, which is also known as “Universal Plug-And-Play”. What UPnP does, is allow individual clients of our LAN to open a required port on the WAN-side of the router, such as TCP Port 8333 if need be. Because some users believe that enabling UPnP on their routers, makes their routers ineffective as a firewall, they disable this feature. This would be, because those users cannot even trust their LAN-clients, in which case the LAN-clients could trivially request forwarding rules, which the operators of such a LAN did not authorize.

The problem I see, is that I, personally, have UPnP enabled on my router, because I believe my actual LAN-clients to be secure, so that according to me, if they want a WAN port number, they can have it. Also, I have UPnP enabled on my Bitcoin Core P2P / wallet-program. Therefore, the LAN-client in question is requesting this Port 8333, and is obtaining it. Yet, I still don’t see a wealth of inbound connections asking for my CPU time.

bitcoin-core-upnp_1

There could be several reasons for this, one of which might have been, that a software-firewall on the client-machine in question could be blocking Port 8333. But I, personally have checked my software-firewall. It tells me that it is allowing all connections to and from my Bitcoin Core client a-okay. Maybe the firewall of some other participant is not?

Answer: The Windows computer my Bitcoin Core client is running on, had the LAN connection set to Public. According to Windows firewall rules, access to this program on the host machine is only granted when the network would be Private. This is to allow quick access to Public networks, which are not trusted, without reconfiguring the computer, while setting up a more-liberal set of rules for Private networks. Changing the network-type to Private seems to have solved this problem.

With certainty, my Bitcoin Core client will not show me any transactions it has facilitated, because those transactions do not affect my wallet. Bitcoin is designed to be anonymous, so that I will only see transactions which affect my own balance.

Dirk

 

Bitcoin Basics

When a Bitcoin Wallet Program synchronizes its own list of Receiving Addresses, it broadcasts a query over the network, which names each Public Key / Address, and the network replies with an updated history, of whether that Address has Sent or Received any funds since the last sync, on the assumption that the same Bitcoin Wallet also stores the corresponding Private Keys. If the Wallet Program tries to Send any funds From one of its Addresses, it must Prove that it holds the Private Key, by Signing the request to do so, using Public Key Cryptography. This signature can be verified by anybody using only the Public Key.

If the stated Address has never received any funds, I believe that the query disappears from the network within some short amount of time.

It is common practice in Public Key Cryptography, additionally to encrypt any Private Keys using a Password which is not stored, and which the user must enter, every time he wants to use them, but not to encrypt the Public Keys. Since simply to receive an update for the Public Keys does not require the user enter his Password, it follows that the Wallet Program does not need to prove to the network, that it does have the Private Keys stored.

Otherwise, if the Wallet stores any Public Keys without the corresponding Private Key, by default, those are assumed to belong to other users, as potential Addresses to Send funds to. And this is about as much as a basic Bitcoin Wallet Program needs to be able to do.

However, most specific Wallet Programs have additional features and capabilities, specific to one Program. For example, some Wallet Programs allow for more than one Wallet to be created, and additionally allow for pure, Address-Watching Wallets to be created, which when synced, also query the network for a list of Addresses, but for which the Wallet in question does not store any Private Keys. These Wallets receive updates for the list of Addresses even though the Addresses in question are actually externally-owned, since the network never required any proof from the Program anyway, that it has the Private Keys.

I think the main disadvantage of this approach, is the fact that this separate Wallet does not get synced, unless the user specifically instructs his Program to Open that one.

But, since some programmers do not feel that their users need these advanced capabilities, certain Wallet Programs simply leave them out, especially in the case of Wallets meant for smart-phones. OTOH, smart-phone Wallets often have additional capabilities, related to being able to scan QR-codes, in order to acquire Addresses to Send To, or to acquire ‘Requests For Funds’, which in addition an Address, contain the Amount that should be Sent, within the same QR-code…

Dirk