The first Bitcoin (BTC) transaction received to an IP address ?

[BitcoinFX]

On February 04, 2010 I made a forum post requesting that someone might try to send a Bitcoin transaction to my static IP address in the UK.

I had two windows terminals running Bitcoin and MT4 software and I wanted to see if the lowest subnet IP machine would receive the transaction.

Here is the original request and the response from the sender of the transaction(s) bitcointalk forum member 'SmokesTooMuch' (account 13).

- https://bitcointalk.org/index.php?topic=34.msg227#msg227

Surely 'Satoshi' had already tested this functionality !? However, as far as I know this is/was the first Bitcoin (BTC) transaction received to an IP address ?

Port forwarding forwards a port to one computer.  It tells the router which computer handles connections to that port.  So that's the computer receiving.

If you didn't set up port forwarding, then incoming connections won't go to any computer, and attempts to send to that IP would just say it couldn't connect to the recipient and nothing is sent.  When sending by IP, you still send to a bitcoin address, but your computer connects to that IP, gets a new bitcoin address from it, gives the transaction directly to the them and confirms that it was received and accepted.

Someone should post their static IP so people can try out sending by IP and also give that user free money.

There's a 32-bit checksum in bitcoin addresses so you can't accidentally type an invalid address.

If 4) you send to a recipient who has abandoned or lost their wallet.dat, then the money is lost.  A subtle point can be made that since there is then less total money in circulation, everyone's remaining money is worth slightly more, aka "natural deflation".

... snip ...

EDIT: As per. my OP question my received transaction is not 'The first Bitcoin (BTC) transaction received to an IP address', although it would appear to be the first 'public' / forum request to be actioned with regards to Satoshi's posted request(s).

... snip ...

[1714050860]

1714050860

[1714050860]

1714050860

[1714050860]

1714050860

[qwk]

I wonder how many times that feature was used anyway.
It was obviously removed as a "dead feature" in 0.8.0.
https://bitcointalk.org/index.php?topic=9334.msg2154396#msg2154396

[rdbase]

So what does this exactly mean?
Are we able to send a transaction without a miners fee?
Never the less it is a nice feature of the blockchain if correctly implemented.

[BitcoinFX]

I wonder how many times that feature was used anyway.
It was obviously removed as a "dead feature" in 0.8.0.
https://bitcointalk.org/index.php?topic=9334.msg2154396#msg2154396

Indeed. No way to know really, I guess.

CSW / nchain are looking to put this 'feature' back into BSV.

What might we ascertain from the transaction data etc.,

[BitcoinFX]

So what does this exactly mean?
Are we able to send a transaction without a miners fee?
Never the less it is a nice feature of the blockchain if correctly implemented.

As-is/was the miners fee would still apply to the transaction, so ... 

[poptok1]

Funny, I was thinking about it yesterday but instead my mind went in to NFC option research with little to no effect.
Could appreciate some help here if anyone cares.
That's lame they ditched this feature, explanation for it feels a little... lazy?
Less code less bugs... logical but lazy nevertheless But its still possible to be "turned on" so I guess it isn't lost forever.
 

[franky1]

instead of a user having to gain a bitcoin address from a user via a website, a forum, a chat, a business card or a display at a merchant and having to enter it in at GUI level via copy/paste/qr scanning

a user could be connected to a services IP address..
the user sends a message to the IP address requesting a public key.. and the IP address (Service) gives back a bitcoin address.
the user then makes a transaction using that given address..

in short it was just a different way of getting an address that didnt rely on copy/paste. QR code scanning. manually at GUI level. but instead direct IP contact with a service the user wanted to give funds to, to get a public key without GUI manual methods

it was never about making a transaction where the recipient output was an IP address.
just a way to obtain a valid public key from a recipient via direct communication as oppose to GUI level copy/paste/QR code scanning

once the transaction is made. it still needs to then be relayed to pools and confirmed.
again its nothing about the output destination of a transaction being an IP address.
again its nothing about avoiding pools to get confirmed funds.

its just a different way to obtain a proper public key, but without using the GUI/manual way

[BitcoinFX]

Thanks for that (franky1) ... brain overload ...

--------------------
bitcoinbitcoin:
How anonymous are bitcoins?

Can nodes on the network tell from which and or to which bitcoin address coins are being sent? Do blocks contain a history of where bitcoins have been transfered to and from? Can nodes tell which bitcoin addresses belong to which IP addresses? Is there a command line option to enable the sock proxy the first time that bitcoin starts? What happens if you send bitcoins to an IP address that has multiple clients connected through network address translation (NAT)?

and

> Can nodes on the network tell from which and or to which bitcoin
> address coins are being sent? Do blocks contain a history of where
> bitcoins have been transfered to and from?

Bitcoins are sent to and from bitcoin addresses, which are essentially random numbers with no identifying information.

When you send to an IP address, the transaction is still written to a bitcoin address.  The IP address is only used to connect to the recipient's computer to request a fresh bitcoin address, give the transaction directly to the recipient and get a confirmation.

Blocks contain a history of the bitcoin addresses that a coin has been transferred to.  If the identities of the people using the bitcoin addresses are not known and each address is used only once, then this information only reveals that some unknown person transferred some amount to someone else.

The possibility to be anonymous or pseudonymous relies on you not revealing any identifying information about yourself in connection with the bitcoin addresses you use.  If you post your bitcoin address on the web, then you're associating that address and any transactions with it with the name you posted under.  If you posted under a handle that you haven't associated with your real identity, then you're still pseudonymous.

For greater privacy, it's best to use bitcoin addresses only once.  You can change addresses as often as you want using Options->Change Your Address.  Transfers by IP address automatically use a new bitcoin address each time.

> Can nodes tell which bitcoin addresses belong to which IP addresses?

No.

> Is there a command line option to enable the sock proxy the first
> time that bitcoin starts?

In the next release (version 0.2), the command line to run it through a proxy from the first time is:
bitcoin -proxy=127.0.0.1:9050

The problem for TOR is that the IRC server which Bitcoin uses to initially discover other nodes bans the TOR exit nodes, as all IRC servers do.  If you've already connected once before then you're already seeded, but for the first time, you'd need to provide the address of a node as such:
bitcoin -proxy=127.0.0.1:9050 -addnode=<someipaddress>

If someone running a node with a static IP address that can accept incoming connections could post their IP to use for -addnode, that would be great.

> What happens if you send bitcoins to an IP address that has multiple
> clients connected through network address translation (NAT)?

Whichever one you've set your NAT to forward port 8333 to will receive it.  If your router can change the port number when it forwards, you could allow more than one client to receive.  For instance, if port 8334 forwards to a computer's port 8333, then senders could send to "x.x.x.x:8334"

If your NAT can't translate port numbers, there currently isn't a command line option to change the incoming port that bitcoin binds to, but I'll look into it.

[figmentofmyass]

I wonder how many times that feature was used anyway.
It was obviously removed as a "dead feature" in 0.8.0.
https://bitcointalk.org/index.php?topic=9334.msg2154396#msg2154396

Indeed. No way to know really, I guess.

CSW / nchain are looking to put this 'feature' back into BSV.

is that so? i wonder what their approach to MITM attacks is. i assume they're not just implementing the original bitcoin feature.

its just a different way to obtain a proper public key, but without using the GUI/manual way

it depends on the definition of "proper" since there was never any sort of authentication of the messages. BIP70 was a better approach since it had a mechanism for authenticating payment requests. (X.509 certificates)

[pooya87]

CSW / nchain are looking to put this 'feature' back into BSV.

that's what happens when people without knowledge about bitcoin and the technology start creating new coins. they take the routs that was already taken and was proven to be flawed and put people who use their token at risk.
although since altcoins are rarely used, i wonder if anybody would bother performing an attack on this?

[BitcoinFX]

I wonder how many times that feature was used anyway.
It was obviously removed as a "dead feature" in 0.8.0.
https://bitcointalk.org/index.php?topic=9334.msg2154396#msg2154396

Indeed. No way to know really, I guess.

CSW / nchain are looking to put this 'feature' back into BSV.

is that so? i wonder what their approach to MITM attacks is. i assume they're not just implementing the original bitcoin feature.

its just a different way to obtain a proper public key, but without using the GUI/manual way

it depends on the definition of "proper" since there was never any sort of authentication of the messages. BIP70 was a better approach since it had a mechanism for authenticating payment requests. (X.509 certificates)

- https://twitter.com/ProfFaustus/status/1095055575992414211

"Remember when wallets exchanged information? You know, messages concerning the exchange. Oh, that is right, Core screwed the pooch and took all that made Bitcoin out in a vain and STUPID attempt to make crime coin. BTC is a sham, it is NOT Bitcoin - read the whitepaper"

 

[monsanto]

Interesting discussion.

This reminded me of a tweet from Adam Back a few weeks ago, regarding the first BTC transaction to Hal Finney:

https://twitter.com/adam3us/status/1087013943330172930

curious what old TCPIP connection payments look like? the 1st #bitcoin transaction (from Satoshi to Hal Finney) was a p2pk, uncompressed pub key, for which no address format exists https://blockstream.info/tx/a16f3ce4dd5deb92d98ef5cf8afeaf0775ebca408f708b2146c4fb42b41e14be#expand,output:0,input:0 … a deprecated method, direct p2p payment

Satoshi talking about disabling receive by IP feature:

Probably best to disable receiving by IP unless you specifically intend to use it.  This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.  Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases.  If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.  If you use a privacy proxy, man-in-the-middle risk is unacceptably high.  If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

I uploaded this change to SVN rev 156.  The switch to enable is "-allowreceivebyip".

Senders with this version will get the error "Recipient is not accepting transactions sent by IP address".  Older version senders will get "Transfer was not accepted".

I used a different name for the switch because "-allowiptransactions" sounds like it includes sending.  If there's a better name for the switch, we can change it again.

[franky1]

Interesting discussion.

This reminded me of a tweet from Adam Back a few weeks ago, regarding the first BTC transaction to Hal Finney:

https://twitter.com/adam3us/status/1087013943330172930

curious what old TCPIP connection payments look like? the 1st #bitcoin transaction (from Satoshi to Hal Finney) was a p2pk, uncompressed pub key, for which no address format exists https://blockstream.info/tx/a16f3ce4dd5deb92d98ef5cf8afeaf0775ebca408f708b2146c4fb42b41e14be#expand,output:0,input:0 … a deprecated method, direct p2p payment

Satoshi talking about disabling receive by IP feature:

Probably best to disable receiving by IP unless you specifically intend to use it.  This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.  Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases.  If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.  If you use a privacy proxy, man-in-the-middle risk is unacceptably high.  If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

because the IP feature was just about a different way to get a bitcoin address from someone, it was not a big NEEDED thing. but opened up nodes to trojans, viruses hackers, man in middle, and ofcourse DDoS attacks so benefit vs problems.. weighed more into the problems direction. so was disabled

anyway moving onto to adam back...
dang.. seems like adamback has no clue
1. there actually was an address that satoshi sent the funds to hal
1Q2TWHE3GMdB6BZKafqwxXtWAWgFt5Jvm3

2. a TCPIP connection payment is just a standard bitcoin payment. seems he dosnt know the basics yet CEO's a company of dozens of developers..

then. in the replies section. he then reveals the issues of connecting to ip addresses to request data... and if you read it and then look at his companies invention known as LN . it, yep LN has that same fatal flaw.

https://twitter.com/adam3us/status/1087151635510583296
"It's not very good:
- recipient has to be online (vs send to address recipient offline)
- IP address could change (many ISPs dynamic IP)
- recipient could have firewall or NAT (unreachable)
- TCP hijack could send funds to someone else (intercept/reroute)
- as no authentication"

[alonelyorange]

What interested topic you created here, any news about ip address and what for using ip address when we are sending bitcoin payment to other account, we need support how to make bitcoin become more profitable investment at the future.

[BitcoinFX]

Interesting discussion.

This reminded me of a tweet from Adam Back a few weeks ago, regarding the first BTC transaction to Hal Finney:

https://twitter.com/adam3us/status/1087013943330172930

curious what old TCPIP connection payments look like? the 1st #bitcoin transaction (from Satoshi to Hal Finney) was a p2pk, uncompressed pub key, for which no address format exists https://blockstream.info/tx/a16f3ce4dd5deb92d98ef5cf8afeaf0775ebca408f708b2146c4fb42b41e14be#expand,output:0,input:0 … a deprecated method, direct p2p payment

Satoshi talking about disabling receive by IP feature:

Probably best to disable receiving by IP unless you specifically intend to use it.  This is a lot of surface area that nobody uses that doesn't need to be open by default.

In storefront cases, you would typically only want customers to send payments through your automated system that only hands out bitcoin addresses associated with particular orders and accounts.  Random unidentified payments volunteered to the server's IP address would be unhelpful.

In general, sending by IP has limited useful cases.  If connecting directly without a proxy, the man-in-the-middle risk may be tolerable, but no privacy.  If you use a privacy proxy, man-in-the-middle risk is unacceptably high.  If we went to all the work of implementing SSL, only large storefronts usually go to the trouble of getting a CA cert, but most of those cases would still be better off to use bitcoin addresses.

I uploaded this change to SVN rev 156.  The switch to enable is "-allowreceivebyip".

Senders with this version will get the error "Recipient is not accepting transactions sent by IP address".  Older version senders will get "Transfer was not accepted".

I used a different name for the switch because "-allowiptransactions" sounds like it includes sending.  If there's a better name for the switch, we can change it again.

Good find!

A simple solution might be to re-enable "-allowreceivebyip" in another wallet, for anyone that might require it then ?

...

Furthermore, folks might have noticed that these transactions do not appear in my 'old' Signed and Verified wallet ...

- https://bitcointalk.org/index.php?topic=4630066.0

As I have already said, I can go back even further on this one.

...

EDIT: As per. my OP question my received transaction is not 'The first Bitcoin (BTC) transaction received to an IP address', although it would appear to be the first 'public' / forum request to be actioned with regards to Satoshi's posted request(s).

Cool beans!  

[BitcoinFX]

Funny, I was thinking about it yesterday but instead my mind went in to NFC option research with little to no effect.
Could appreciate some help here if anyone cares.
That's lame they ditched this feature, explanation for it feels a little... lazy?
Less code less bugs... logical but lazy nevertheless But its still possible to be "turned on" so I guess it isn't lost forever.
 

Yes. People should care ... small ideas go BIG ...

Re: Blockstream's Bitcoin Satelite
- https://bitcointalk.org/index.php?topic=2091860.msg49574549#msg49574549

Completely Offline Bitcoin Transactions
- https://medium.com/@notgrubles/completely-offline-bitcoin-transactions-4e58324637bd

[rdbase]

Funny, I was thinking about it yesterday but instead my mind went in to NFC option research with little to no effect.
Could appreciate some help here if anyone cares.
That's lame they ditched this feature, explanation for it feels a little... lazy?
Less code less bugs... logical but lazy nevertheless But its still possible to be "turned on" so I guess it isn't lost forever.
 

Yes. People should care ... small ideas go BIG ...

Re: Blockstream's Bitcoin Satelite
- https://bitcointalk.org/index.php?topic=2091860.msg49574549#msg49574549

Completely Offline Bitcoin Transactions
- https://medium.com/@notgrubles/completely-offline-bitcoin-transactions-4e58324637bd

How about having those offline bitcoin transactions transmitted by high frequency radio internationally?
https://bitcoinist.com/bitcoin-sent-ham-radio/
This is when or if the internet ever goes down so you will be still able to send your bitcoin during an apocalypse.

[BitcoinFX]

"Yeah Man!" - SWIM

Asteroid negotiations - Hyperdrive - BBC comedy *Satire* 
- https://youtu.be/qZtXYnOCtjY

I can be serious to ...

Free the Network: Hackers Take Back the Web
- https://youtu.be/Fx93WJPCCGs

- Dead Drops 'How to' - NYC
https://youtu.be/hwohadcUv4A

P2P , P2IP , P2Peat