BitcoinFX (OP)
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2019, 08:42:11 PM Last edit: February 17, 2019, 12:05:18 PM by BitcoinFX Merited by Steamtyme (2), dothebeats (1), qwk (1) |
|
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#msg227Surely '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 ...
![Cool](https://bitcointalk.org/Smileys/default/cool.gif)
|
|
|
|
qwk
Donator
Legendary
Offline
Activity: 3542
Merit: 3413
Shitcoin Minimalist
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2019, 09:03:32 PM |
|
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
|
Yeah, well, I'm gonna go build my own blockchain. With blackjack and hookers! In fact forget the blockchain.
|
|
|
rdbase
Legendary
Offline
Activity: 2996
Merit: 1559
Join the world-leading crypto sportsbook NOW!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2019, 09:08:08 PM |
|
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 (OP)
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2019, 09:40:32 PM |
|
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 (OP)
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2019, 09:43:08 PM |
|
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 ... ![Undecided](https://bitcointalk.org/Smileys/default/undecided.gif)
|
|
|
|
poptok1
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2019, 10:07:09 PM |
|
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 ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) But its still possible to be "turned on" so I guess it isn't lost forever.
|
|
|
|
franky1
Legendary
Offline
Activity: 4340
Merit: 4676
|
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
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
BitcoinFX (OP)
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 11, 2019, 11:30:08 PM |
|
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
Legendary
Offline
Activity: 1652
Merit: 1483
|
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
Legendary
Offline
Activity: 3570
Merit: 10845
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2019, 03:28:39 AM |
|
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 (OP)
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2019, 01:48:36 PM |
|
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" ![Roll Eyes](https://bitcointalk.org/Smileys/default/rolleyes.gif)
|
|
|
|
monsanto
Legendary
Offline
Activity: 1241
Merit: 1005
..like bright metal on a sullen ground.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 12, 2019, 10:40:46 PM |
|
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/1087013943330172930Satoshi 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
Legendary
Offline
Activity: 4340
Merit: 4676
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2019, 02:20:03 AM |
|
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/1087013943330172930Satoshi 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"
|
I DO NOT TRADE OR ACT AS ESCROW ON THIS FORUM EVER. Please do your own research & respect what is written here as both opinion & information gleaned from experience. many people replying with insults but no on-topic content substance, automatically are 'facepalmed' and yawned at
|
|
|
alonelyorange
Member
![*](https://bitcointalk.org/Themes/custom1/images/star.gif)
Offline
Activity: 532
Merit: 10
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2019, 03:45:32 AM |
|
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 (OP)
Legendary
Offline
Activity: 2646
Merit: 1722
https://youtu.be/DsAVx0u9Cw4 ... Dr. WHO < KLF
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 13, 2019, 02:20:11 PM Last edit: February 13, 2019, 04:31:44 PM by 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/1087013943330172930Satoshi 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.0As 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! ![Cool](https://bitcointalk.org/Smileys/default/cool.gif)
|
|
|
|
|
rdbase
Legendary
Offline
Activity: 2996
Merit: 1559
Join the world-leading crypto sportsbook NOW!
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
February 16, 2019, 02:03:12 PM |
|
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. ![Lips sealed](https://bitcointalk.org/Smileys/default/lipsrsealed.gif)
|
|
|
|
|
|