P2P and returning IP and domain-based transfers
Bitcoin was designed to be used as peer-to-peer cash. When the original paper and node software were released, the system was created with two ways to send money.
There are two ways to send money. If the recipient is online, you
can enter their IP address and it will connect, get a new public
key and send the transaction with comments. If the recipient is
not online, it is possible to send to their Bitcoin address, which
is a hash of their public key that they give you. They'll receive
the transaction the next time they connect and get the block it's
in. This method has the disadvantage that no comment information
is sent, and a bit of privacy may be lost if the address is used
multiple times, but it is a useful alternative if both users can't
be online at the same time or the recipient can't receive incoming
connections.We see the later now as the only real option. This forms an expectation that you need to send to the network, that has come about through the myth of nodes not being miners; I demonstrated this was wrong a while back.
The original code needed a lot of work. The following method of connecting to and exchanging details without users was frankly horrible, but the concept was good if the execution was off:
Enter the recipient’s IP address (e.g. 123.45.6.7) for online transfer with comments and confirmation, or bitcoin address (e.g. 1NS17iag9jJgTHD1VXjvLCEnZuQ3rJED9L) if recipient is not online.
The original version of IP-to-IP sending was rather insecure. The messaging was completed in clear text, and the clients did nothing to validate each other. It was open to MiTM (Man in the Middle) attacks and snooping. Unfortunately, with the erroneous blind siding and blinker of thinking that Bitcoin was about all the people globally having to run a node, Core removed the feature, and worse, could not even comprehend a use for it.
Unfortunately, the inability of a few people, with an idea of what Bitcoin should be that was not what it is, led to the removal of an important part of the system and the lack of development of SPV wallets.
There are ways to have constructed this correctly. One is to have used a secure domain identifier and DNSSec. With secured domains, the use of certificates would allow a merchant and client to communicate and exchange data. It was never finished, and it seems nobody wanted to work on it, but I never gave up hope on this, and nChain has been busy. This was always supposed to be fixed.
One aspect of IP-2-IP included sending messages out-of-band.
This allowed users and merchants to connect when needed and exchange information, invoices, and more.
We intend to see this re-introduced into Bitcoin in a secure manner.
In the Bitcoin SV node software, we plan to start allowing the reintroduction of the various aspects of Bitcoin that have been removed due to others not understanding these. We seek to push for more SPV wallets and to allow these to communicate and send between each other.
