Bitcoin Forum
May 21, 2019, 08:09:34 AM *
News: Latest Bitcoin Core release: 0.18.0 [Torrent] (New!)
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: BIP-able idea suggestion: Secure IP Transactions  (Read 140 times)
Emilstud
Newbie
*
Offline Offline

Activity: 23
Merit: 16


View Profile
January 09, 2019, 06:19:31 PM
Last edit: January 09, 2019, 06:48:29 PM by Emilstud
Merited by vapourminer (1), ETFbitcoin (1), pooya87 (1), bones261 (1), LoyceV (1), Jating (1), o_e_l_e_o (1)
 #1

Hello Bitcoin Community,
a long time ago there was a feature called ip transactions.

It worked like this:
1. You enter the IP-address of a recipient
2. A node which used this IP created a new address and informed the sending node about this address.

It has been removed in version v0.8 due to a lack of security.
The main key parts because it was removed were that it was very insecure because of Man-in-the-Middle attacks.

I thought that it would be really cool if you could send Bitcoins to donate.example.com.

The secure way would go through SSL.
For example:
If you enter an IP-Address/Domain it would send a SSL/TLS request to the IP-Address (I will call it server by now).
The server responds with a new generated address.
During this process SSL/TLS will be used to verify authenticity.

After the user clicked send, a message box will popup with the public key of the certificate. The user then can verify if this public key truly belongs to the owner of the IP-Address (For example if the owner provides the ssl pubkey on his website) and then confirms the transaction.

Additionally this can also be implemented in the bitcoin uri scheme:
bitcoin:donate.example.com?amount=1&sslpubkey=9A:62:5E:8B:53:D9:B0:74:10:FC:D5:6B:0F:D5:9B:3B:D9:71:4A:82
please execuse me if this URL is malformed, was too lazy to do url encoding.

Then the SSL fingerprint would be verified automatically.
Would be nice for donation receivers who want a new address for every transaction I will go onto this later.

Another big advantage is that every time someone wants to send Bitcoins to an IP-Address a new Bitcoin address is being generated.
This is really nice for people who want to use a new address for every incoming transaction.
I know it is also possible with today's methods but this would be much easier.
I see lots of sites using static Bitcoin addresses for donations. This is good for transparency but not as good as a new address when it comes to privacy.
Also very nice for only shops who want to protect their customers.

What do you think about my idea?
1558426174
Hero Member
*
Offline Offline

Posts: 1558426174

View Profile Personal Message (Offline)

Ignore
1558426174
Reply with quote  #2

1558426174
Report to moderator
1558426174
Hero Member
*
Offline Offline

Posts: 1558426174

View Profile Personal Message (Offline)

Ignore
1558426174
Reply with quote  #2

1558426174
Report to moderator
Get alert of price pumps/dumps beforehand 74% average Win Rate
reported by our users
TRY NOW!
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1558426174
Hero Member
*
Offline Offline

Posts: 1558426174

View Profile Personal Message (Offline)

Ignore
1558426174
Reply with quote  #2

1558426174
Report to moderator
darosior
Full Member
***
Offline Offline

Activity: 170
Merit: 177



View Profile WWW
January 09, 2019, 07:11:57 PM
Merited by vapourminer (1), ETFbitcoin (1)
 #2

Hi,

I think it could be nice but I don't know if it would be very secure. However I don't think this should be a BIP as it doesn't need to be in the reference implementation, it could also be used by some wallets.

Cons : https://bitcointalk.org/index.php?topic=9334.0 (or why it has been removed)
Pros :
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.

Incidentally, for this DNS have custom-built records SRV. Theese records for Kerberos, for example:


$ dig _kerberos._tcp.host.com srv

;; QUESTION SECTION:
;_kerberos._tcp.host.com.   IN   SRV

;; ANSWER SECTION:
_kerberos._tcp.host.com. 3550 IN   SRV   10 10 88 kerberos.host.com.


Requesting for any DNS-name SRV-record in this format, you can find the address of Kerberos-server for this domain. Similarly, we can do for Bitcoin by queryng about: "_bitcoin._tcp.host.com" or something.

All this is done covertly, human sees only the right part of the name: host.com

And for domain names with sub-domains Kerberos using TXT records to enable the customer to understand what realm it belongs to:


$ dig _kerberos.grid.host.com txt

;; QUESTION SECTION:
;_kerberos.grid.host.com.   IN   TXT

;; ANSWER SECTION:
_kerberos.grid.host.com. 3587 IN   TXT   "HOST.COM"


Bitcoin can use this for subdomains like www:

_bitcoin.www.host.com. 3587 IN   TXT   "HOST.COM"

i.e., human can send bitcoin to www.host.com, bitcoin client check TXT _bitcoin.www.host.com for DNS-name of bitcoin "realm", than check SRV _bitcoin._tcp.host.com and, finally, sends bitcoins to IP, specified by this SRV-record.

This scheme is really a part of Kerberos standart and used, I think, more than 15 years.

And this DNS trick will be usable in Tor's .onion network

Github profile ~ Crypto Lyon (french community)  ~ GPG key fingerprint : E13F C145 CD3F 430 ~ LN public key : 03678b4f041fbfbeebcafc076469df75decf81da20a53bd490172e83ce532df1fa
Tutorials/posts : Address from private keyBitcoin smart contracts ~ Setup a Bitcoin node ~ Raw P2PKH transaction in Python ~ P2SH ~ 51% attack
achow101
Moderator
Legendary
*
expert
Offline Offline

Activity: 1764
Merit: 2377


bc1qshxkrpe4arppq89fpzm6c0tpdvx5cfkve2c8kl


View Profile WWW
January 09, 2019, 07:47:31 PM
Merited by bones261 (1), darosior (1)
 #3

There is already work on an idea similar to this that is called Pay to Endpoint (P2EP).

Emilstud
Newbie
*
Offline Offline

Activity: 23
Merit: 16


View Profile
January 09, 2019, 07:50:06 PM
 #4

@darosior
The Bitcoin wallet can also sign the cert on it's own.
My idea was to use SSL certificates just for the fingerprints to avoid fakers by DNS spoofs and Man-in-the-Middle attacks.
SSL is the solution for probably all cons on the list.

@achow101
Thank you, I will take a look at it Smiley
pooya87
Legendary
*
Offline Offline

Activity: 1638
Merit: 1644



View Profile
January 10, 2019, 04:20:13 AM
Merited by darosior (2)
 #5

However I don't think this should be a BIP as it doesn't need to be in the reference implementation,

a BIP is a "bitcoin" improvement protocol not "bitcoin core" improvement protocol. in other words they don't have to be in reference implementation (bitcoin core) to become a BIP. for example there are BIPs that aren't in it or even anywhere else for that matter. example: BIP178 which is a versioned WIF proposal which isn't used by any wallet. or BIP39 which is mnemonic code (generating a seed phrase part) is not used by bitcoin core.

KingZee
Sr. Member
****
Offline Offline

Activity: 574
Merit: 413


Check your coin privilege


View Profile
January 10, 2019, 05:19:58 AM
Merited by vapourminer (1), ETFbitcoin (1)
 #6

This is a decent idea but there are a few caveats :

Wouldnt the receiver IP need to be online 24/7? If the server is down for some reason then I guess you need to implement some sort of fallback or it wont go through...

Man in the middle is awfully scary too, especially if you're relying on a server rsponse to send your coins. You havve to worry not only if you're the receiver but also the sender. There are a lot of attack vectors that you need to proof against, with SSL mentioned by satoshi above being just a small part of it..

People will be a lot more tempted to compromise servers. You cant fake a btc addresss or claim it unless you have the privkey, but you can definitely hack servers, the damage would be massive compared to just a single compromised address.. Same goes for clientside, you can use SSL to encrypt your requests, but what about before the request goes out? I know very little about networking and the dumbest idea I can come up with would be to just fuck with your hosts file and simply redirect all your requests from someexchange.com to mywebsite.hack..

If there is something like this in the works Im sure they're all beating the idea to death in order to avoid/minimize issues like these. Just see how cryptography has very little human factor involved and yet we still see people lose their keys. If you open up a door like this imo the benefits are minimal compared to how much more room there will be for human error.

Emilstud
Newbie
*
Offline Offline

Activity: 23
Merit: 16


View Profile
January 11, 2019, 06:32:52 PM
 #7

This is a decent idea but there are a few caveats :

Wouldnt the receiver IP need to be online 24/7? If the server is down for some reason then I guess you need to implement some sort of fallback or it wont go through...

Man in the middle is awfully scary too, especially if you're relying on a server rsponse to send your coins. You havve to worry not only if you're the receiver but also the sender. There are a lot of attack vectors that you need to proof against, with SSL mentioned by satoshi above being just a small part of it..

People will be a lot more tempted to compromise servers. You cant fake a btc addresss or claim it unless you have the privkey, but you can definitely hack servers, the damage would be massive compared to just a single compromised address.. Same goes for clientside, you can use SSL to encrypt your requests, but what about before the request goes out? I know very little about networking and the dumbest idea I can come up with would be to just fuck with your hosts file and simply redirect all your requests from someexchange.com to mywebsite.hack..

If there is something like this in the works Im sure they're all beating the idea to death in order to avoid/minimize issues like these. Just see how cryptography has very little human factor involved and yet we still see people lose their keys. If you open up a door like this imo the benefits are minimal compared to how much more room there will be for human error.

According to your hosts file tweak.
This would be impossible with SSL.
The SSL certificate is unqiue. It cannot be tampered unless you have the private keys.
My idea was if you send a transaction, a confirm dialog will pop-up with the public key of the fetched SSL cert. The author of the website should put his SSL pubkey onto his website so users can verify it with the popped up private key.
Emilstud
Newbie
*
Offline Offline

Activity: 23
Merit: 16


View Profile
January 11, 2019, 06:34:31 PM
 #8

However I don't think this should be a BIP as it doesn't need to be in the reference implementation,

a BIP is a "bitcoin" improvement protocol not "bitcoin core" improvement protocol. in other words they don't have to be in reference implementation (bitcoin core) to become a BIP. for example there are BIPs that aren't in it or even anywhere else for that matter. example: BIP178 which is a versioned WIF proposal which isn't used by any wallet. or BIP39 which is mnemonic code (generating a seed phrase part) is not used by bitcoin core.
I know but to standardize it (which is my plan) it needs to specified somehow.
Pages: [1]
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!