Topic: The first Bitcoin (BTC) transaction received to an IP address ? (Read 431 times)

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?

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

Re: Blockstream's Bitcoin Satelite
- https://bitcointalksearch.org/topic/m.49574549

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

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.
 

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

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

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.

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


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)

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

Indeed. No way to know really, I guess.

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

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

--------------------
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)?

> 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=

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.

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.

I wonder how many times that feature was used anyway.
It was obviously removed as a "dead feature" in 0.8.0.
https://bitcointalksearch.org/topic/m.2154396

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 ...