Bitcoin Forum
October 16, 2017, 10:48:01 PM *
News: Latest stable version of Bitcoin Core: 0.15.0.1  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Poll
Question: Where should BIP manifest first?
Code should be embedded into the Bitcoin's Official Wallet: Bitcoin-QT - 4 (13.8%)
A separate program that uses API to talk to Bitcoin-QT - 12 (41.4%)
BIP by its current plan should not manifest at all - 5 (17.2%)
I don't care - 3 (10.3%)
Bitcoin-QT should have plugins system for such features - 5 (17.2%)
Total Voters: 29

Pages: [1]
  Print  
Author Topic: Bitcoin Payment Protocol discussion continued  (Read 1293 times)
Hyena
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
October 09, 2013, 10:17:43 AM
 #1

I created this topic because the original Payment Protocol FAQ (https://bitcointalk.org/index.php?topic=300809.0) was locked and people were asking for a poll anyway.

The major concerns seem to be:
* Man In The Middle attacks
* The fact that Certificate Authorities in their current form and function are not cool
* Bitcoin's Official client should be neutral to any commercial uses and entities

Discuss... I start:

Fact 1: MITM attacks happen rarely.
Fact 2: MITM attacks are pretty much useless when the victim sees it happening.
------------------------------------
What's the worst thing that could happen when getting MITM attacked during BTC tx?
- You send your coins to a wrong address.

What is bitcoin best for?
- Making small transactions.

Conclusion:
Don't send a large sum of money in a single transaction. Instead, make many small transactions that you can afford to lose in case of this rarely occurring MITM attack. When the other party receives this small transaction, it should somehow communicate to you "Keep going, you're sending to the right address". The communication part should obviously use another channel based on some existing trust. If you know you can trust blockchain.info then you can just check the receiver on that site, trusting the CA used by blockchain.info.

But here's another idea:
How to memorize a bitcoin address if it is not a vanity address and contains random characters? Extract the address into the format of common words similarly to what brain wallets do. The computer should then draw a deterministic picture of the address, so that all the used common words would be drawn on the picture.

Hypothesis: if you memorize the picture you are likely to notice if suddenly there is an ELEPHANT instead of a HORSE on that picture. When you see such thing you know that you're sending your money to someone else. Vanity key mining would then become a whole new thing: for example one wants to have a picture of its public key that has 7 loads of gold on it Cheesy

1508194081
Hero Member
*
Offline Offline

Posts: 1508194081

View Profile Personal Message (Offline)

Ignore
1508194081
Reply with quote  #2

1508194081
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
Herbert
Hero Member
*****
Offline Offline

Activity: 488



View Profile WWW
October 09, 2013, 11:10:24 AM
 #2

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

www.bitcoinmonitor.net - Free payment notification via email, newsfeed, xpmm/jabber, url callback and full API access!
Send SMS with www.txt4coins.net! No registration, pay-per-use, full API access, bulk messages - All inclusive!
Hyena
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
October 09, 2013, 11:53:21 AM
 #3

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

Explaining something is one thing, discussing it as a community where people other than devs have right to say a word is another.

TradeFortress
VIP
Legendary
*
Offline Offline

Activity: 910


View Profile
October 09, 2013, 11:58:59 AM
 #4

Conclusion:
Don't send a large sum of money in a single transaction. Instead, make many small transactions that you can afford to lose in case of this rarely occurring MITM attack. When the other party receives this small transaction, it should somehow communicate to you "Keep going, you're sending to the right address". The communication part should obviously use another channel based on some existing trust. If you know you can trust blockchain.info then you can just check the receiver on that site, trusting the CA used by blockchain.info.

That's silly. Assume a CA is rogue, they are able to generate a cert for blockchain.info and MITM. I'm not sure how checking Blockchain.info will help because that will just tell you if a transaction was received or not.
Hyena
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
October 09, 2013, 01:25:55 PM
 #5

Conclusion:
Don't send a large sum of money in a single transaction. Instead, make many small transactions that you can afford to lose in case of this rarely occurring MITM attack. When the other party receives this small transaction, it should somehow communicate to you "Keep going, you're sending to the right address". The communication part should obviously use another channel based on some existing trust. If you know you can trust blockchain.info then you can just check the receiver on that site, trusting the CA used by blockchain.info.

That's silly. Assume a CA is rogue, they are able to generate a cert for blockchain.info and MITM. I'm not sure how checking Blockchain.info will help because that will just tell you if a transaction was received or not.

It was just an example. If you can't think for yourself then here's another one: go behind the bushes with the receiver, exchange your public keys and everything will be fine. Then when the receiver gets your transaction he or she will send you a message "Thanks dude, I got your initial coins, now send the bulk." (signed by the owner of the public key that you got from behind the bushes).

And now, don't come saying "that's silly, what if someone else wearing your receiver's mask comes to give you the public key behind the bushes". So, it's not silly. Obviously if I was to send 1 000 000 bitcoins then I wouldn't trust blockchain.info but if I had to send 1 bitcoin, it wouldn't be a problem.

Mike Hearn
Legendary
*
Offline Offline

Activity: 1526


View Profile
October 09, 2013, 02:13:09 PM
 #6

The idea of sending very small payments and then making sure you got what you wanted via some other mechanism is not a bad idea, in fact, it's a great idea, which is why I am working on implementing it.

The idea of sending small payments makes a lot of sense for things that can be micro-billed, for instance, imagine a file server that will serve up a 50kb chunk of a file in return for a micropayment. Now MITM attacks don't matter any more because (assuming you can verify you're downloading what you expected) you pay, and either you get the service or you don't. If you don't, you stop paying and your maximum loss is really tiny.

However, micropayments are a separate thing from the payment protocol. When you can use them, that's great, but for many purchases it's not appropriate (like something being delivered mail order). In that case you really need to send the money all at once.
Severian
Sr. Member
****
Offline Offline

Activity: 476



View Profile
October 09, 2013, 11:20:55 PM
 #7

So much for section 10 of the white paper.

Quote
10. Privacy

The traditional banking model achieves a level of privacy by limiting access to information to the
parties involved and the trusted third party. The necessity to announce all transactions publicly
precludes this method, but privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous.
The public can see that someone is sending
an amount to someone else, but without information linking the transaction to anyone. This is
similar to the level of information released by stock exchanges, where the time and size of
individual trades, the "tape", is made public, but without telling who the parties were.

As an additional firewall, a new key pair should be used for each transaction to keep them
from being linked to a common owner. Some linking is still unavoidable with multi-input
transactions, which necessarily reveal that their inputs were owned by the same owner. The risk
is that if the owner of a key is revealed, linking could reveal other transactions that belonged to
the same owner.

http://bitcoin.org/bitcoin.pdf

StarfishPrime
Sr. Member
****
Offline Offline

Activity: 359


View Profile
October 10, 2013, 04:55:44 AM
 #8

So much for section 10 of the white paper.

Quote
10. Privacy

The traditional banking model achieves a level of privacy by limiting access to information to the
parties involved and the trusted third party. The necessity to announce all transactions publicly
precludes this method, but privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous.
The public can see that someone is sending
an amount to someone else, but without information linking the transaction to anyone. This is
similar to the level of information released by stock exchanges, where the time and size of
individual trades, the "tape", is made public, but without telling who the parties were.

As an additional firewall, a new key pair should be used for each transaction to keep them
from being linked to a common owner. Some linking is still unavoidable with multi-input
transactions, which necessarily reveal that their inputs were owned by the same owner. The risk
is that if the owner of a key is revealed, linking could reveal other transactions that belonged to
the same owner.

http://bitcoin.org/bitcoin.pdf


^ +1
Introducing a trusted third party (eg. CA) into a system which was created explicitly to not require one seems intuitively wrong on many levels.

An API supporting external applications to handle this sort of tag-on feature would be a more elegant solution than shoe-horning them into the actual client. Same with Trezor support etc... They may be useful for some but they should not bloat the client unnecessarily.

BIP 38 is a good example of what should be included in the client. It's already in widespread use (for encrypted off-line storage, etc) and would actually be useful for most users.

                         
    ¦                     
  ¦    ¦¦¦               
¦¦  ¦¦¦¦                 
                             ¦¦  ¦¦¦¦
                          ¦ ¦¦ ¦¦¦¦                     
                         ¦¦¦¦¦¦¦¦
                        ¦¦¦¦¦¦¦
                        ¦¦¦¦¦¦
                  ¦¦¦  ¦¦¦¦¦¦
                   ¦ ¦¦¦¦¦¦

                    ¦¦  ¦ ¦¦¦¦
                    ¦¦    ¦¦¦¦
                    ¦¦  ¦ ¦¦¦¦
                   ¦¦¦  ¦ ¦¦¦¦¦
                ¦¦¦¦    ¦ ¦¦¦¦¦¦¦¦
             ¦¦¦¦¦    ¦ ¦¦ ¦¦¦¦¦¦¦¦¦¦
          ¦¦¦¦¦       ¦  ¦   ¦¦¦¦¦¦¦¦¦¦¦
        ¦¦¦¦         ¦        ¦¦¦¦¦¦¦¦¦¦¦¦
     ¦¦¦¦          ¦      ¦    ¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    ¦¦¦         ¦¦         ¦   ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
   ¦¦        ¦¦         ¦¦  ¦   ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
  ¦¦       ¦          ¦ ¦¦   ¦  ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
 ¦¦¦     ¦¦          ¦   ¦    ¦  ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
¦¦¦     ¦          ¦      ¦   ¦¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
¦¦¦    ¦        ¦¦         ¦¦  ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
¦¦¦   ¦¦     ¦¦         ¦   ¦  ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
¦¦¦   ¦     ¦¦         ¦¦¦   ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
 ¦¦   ¦¦    ¦        ¦    ¦  ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
 ¦¦    ¦   ¦        ¦¦    ¦  ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
  ¦¦    ¦  ¦¦       ¦     ¦  ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
   ¦¦    ¦  ¦      ¦      ¦  ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
    ¦¦¦   ¦ ¦¦     ¦¦     ¦  ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
     ¦¦¦   ¦ ¦¦     ¦¦    ¦ ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
       ¦¦¦¦  ¦ ¦¦    ¦  ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
          ¦¦¦¦¦¦  ¦¦  ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
             ¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦¦
                        ¦¦

.
TorCoin.....
¦
¦
¦
¦
  Fully Anonymous TOR-integrated Crypto
               ¦ Windows     ¦ Linux     ¦ GitHub     ¦ macOS
     ¦
     ¦
     ¦
     ¦
.
   ANN THREAD
     ¦
     ¦
     ¦
     ¦
[/center]
jgarzik
Legendary
*
Offline Offline

Activity: 1470


View Profile
October 10, 2013, 11:17:52 AM
 #9


Have any of these critics contacted bitcoin websites, asking them to stop using SSL w/ public CA?

No?

I thought not.

For, the payment protocol will be used where there is already a digitally secure relationship between customer and merchant.

Quote from: Severian
So much for section 10 of the white paper.
Quote
privacy can still be maintained by breaking the flow of information in
another place: by keeping public keys anonymous.

Nothing about that section changes.  Bitcoin-QT still tries to use a new key for each transaction, just like that section describes.  The payment recipient (merchant) still knows just that public key hash, but not about your other transactions.

Methinks there is some basic reading comprehension fail going on.


Jeff Garzik, bitcoin core dev team and BitPay engineer; opinions are my own, not my employer.
Donations / tip jar: 1BrufViLKnSWtuWGkryPsKsxonV2NQ7Tcj
Hyena
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
October 10, 2013, 03:43:14 PM
 #10

bla bla bla


still sounds more like a separate program / module / plugin rather than something hard-coded into bitcoin QT.

ineedit
Sr. Member
****
Offline Offline

Activity: 252


View Profile
October 10, 2013, 07:24:08 PM
 #11

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

Explaining something is one thing, discussing it as a community where people other than devs have right to say a word is another.

I agree, I seem to have missed somewhere the explanation of why the other thread was locked, where has that discussion moved onto if not here?

If I have been help then please show your thanks         BTC: 127PRogAVZiV3fEmpJERh9KemK3a3Ffh6G         LTC: LXghFL8mZffpTFkm2nRTesuDrV5DJQP3Js
Hyena
Legendary
*
Offline Offline

Activity: 1778



View Profile WWW
October 10, 2013, 08:24:10 PM
 #12

I think Mike did a great job by explaining everything related in the FAQ thread. Please don't spread FUD just because you personally disagree.

Explaining something is one thing, discussing it as a community where people other than devs have right to say a word is another.

I agree, I seem to have missed somewhere the explanation of why the other thread was locked, where has that discussion moved onto if not here?

here's the old topic: https://bitcointalk.org/index.php?topic=300809.0

ineedit
Sr. Member
****
Offline Offline

Activity: 252


View Profile
October 11, 2013, 07:10:03 AM
 #13


Thanks Hyena!

I now understand Mike's reasoning behind why he locked the topic. It might have turned into a technological spat on the merits of different methods but still quashes the discussion. I think that you were right to re-open as a poll.

My vote is for "A separate program that uses API to talk to Bitcoin-QT" as I see that is the closest match to "Bitcoin's Official client should be neutral to any commercial uses and entities"

If I have been help then please show your thanks         BTC: 127PRogAVZiV3fEmpJERh9KemK3a3Ffh6G         LTC: LXghFL8mZffpTFkm2nRTesuDrV5DJQP3Js
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!