Nostr notes by

📅 Original date posted:2015-02-10 📝 Original ...

2023-06-07T15:30:01Z

In reply to nevent1q…kcz4
_________________________

📅 Original date posted:2015-02-10
📝 Original message:2015-02-10 12:12 GMT+01:00 Natanael <natanael.l at gmail.com>:
> Den 10 feb 2015 11:48 skrev "MⒶrtin HⒶboⓋštiak"
> <martin.habovstiak at gmail.com>:
>>
>> I still don't understand. The website can have this information
>> available. This is exactly what e-bay does - it displays shipping
>> information to my country before I do anything. What's the problem?
>>
>> Also with other stuff, website can do it and browser extension can do
>> it too without messing with Bitcoin.
>
> 1: IP isn't guaranteed to work correctly both because you might be using a
> VPN out Tor.

Still possible using web browser extension.
>
> 2: Yes, the site can display all options right away, but are you willing to
> read all of them too?

Why not? And again, browser extension can do it without bitcoin wallet
- no need to connect unrelated things.
>
> 3: Detailed information is not necessary, nor does it have to be unprompted.
> It doesn't need to tell you more than which country you are in. It can even
> prompt you with a popup that has a slider that shows exactly how much
> information and of what kind you're about to share (including none, if
> that's your choice).
>
> 4: It doesn't need to share raw data. Take a look at anonymous credentials:
> http://www.zurich.ibm.com/idemix/
> https://eprint.iacr.org/2013/622.pdf
>
> 5: It can wait for prompting until you add the first item to the cart.

Everything you described is possible without Bitcoin involved - why
would we mix unrelated things?

P.S.: I believe in Unix philosophy. ;)

📅 Original date posted:2015-02-10 📝 Original message:Why ...

2023-06-07T15:30:00Z

In reply to nevent1q…2a68
_________________________

📅 Original date posted:2015-02-10
📝 Original message:Why would anyone want to do anything about payment before choosing
what he wants to buy and for what price? I've never used Amazon but
isn't filling a form with shipping information enough?

2015-02-10 11:21 GMT+01:00 Natanael <natanael.l at gmail.com>:
> BIP70 is a protocol for getting a user's wallet client communicate with a
> merchant's server in order to agree on details like where to send the
> payment, how much to send, what the shipping address is, sending a receipt
> back, and much more using various extensions that adds more functionality.
>
> There could even be advanced functionality for automatically negotiating
> terms. One example could be selecting a multisignature arbitrator both sides
> trust. Another could be to agree on the speed and type of delivery. Many
> more types of decisions could be automatically agreed upon.
>
> But as it is now, it is designed to be initiated at the time of payment. If
> you always want next-day delivery from online stores then you won't always
> know if that's an option until you've filled the digital basket and gone
> through checkout. If you only want to shop with an arbitrator involved same
> thing applies.
>
> Everything that BIP70 enables happens at the last step only, as it is right
> now.
>
> If there could be a BIP70 HTML tag on web shops that automatically triggered
> your wallet as soon as you visit the page, it would be possible for a
> browser extension that talks to your wallet to tell you right away if the
> web shop you're currently looking at has terms you consider acceptable or
> not (note: if your wallet client isn't installed on or linked to that same
> machine, a visible Qr code would be an acceptable alternative which you can
> scan in advance before you start shopping). This notification can even be
> automatically updated as you add and remove things from your cart and
> details like shipping options change.
>
> This would massively simplify the shipping experience and make every web
> shop feel like Amazon.
>
> Of course this has privacy implications and increases exposure to potential
> wallet exploits, but the wallet can ask you if you intend to shop or not at
> each site before it even connects and send any information at all in order
> to mitigate both of those problems. This way it should be reasonably safe.
>
> Another option would be to automatically connect but limit what data is sent
> in order to remain privacy preserving, until the user agrees to send private
> information.
>
> This second method would also open up for the merchant to other send
> relevant information such as details about various certifications from third
> parties, which can include a certification that shows they have been been
> audited and approved by by entity X for purpose Y. If your wallet has that
> entity whitelisted it will show you that certificate (for example "Acme
> Audits have audited and approves of Merchant M's privacy policy and data
> protection"). With a list of predefined types of certifications that the
> wallet understand and accepts, it could (by choice of the user) require a
> certificate to be present to even allow you to make a purchase (lack of
> required certifications would result in automatic denial). No certificate =
> your wallet never proceed to send private information.
>
> Thoughts?
>
> - Sent from my tablet
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>

📅 Original date posted:2015-02-10 📝 Original message:I ...

2023-06-07T15:30:00Z

In reply to nevent1q…ztrc
_________________________

📅 Original date posted:2015-02-10
📝 Original message:I still don't understand. The website can have this information
available. This is exactly what e-bay does - it displays shipping
information to my country before I do anything. What's the problem?

Also with other stuff, website can do it and browser extension can do
it too without messing with Bitcoin.

2015-02-10 11:41 GMT+01:00 Natanael <natanael.l at gmail.com>:
> Den 10 feb 2015 11:34 skrev "MⒶrtin HⒶboⓋštiak"
> <martin.habovstiak at gmail.com>:
>>
>> Why would anyone want to do anything about payment before choosing
>> what he wants to buy and for what price? I've never used Amazon but
>> isn't filling a form with shipping information enough?
>
> That's not what this is about.
>
> BIP70 isn't just payment, it is about communication the terms of the sale.
>
> Let's say you're visiting an international webshop. But they don't ship to
> your country. Wouldn't you want to know that before your start filling the
> cart? With this, your wallet / browser extension could tell you right away
> that you can't shop there. No time wasted!
>
> That's just one requirement of many where you would benefit from being told
> right away if it is acceptable for both parties or not.

📅 Original date posted:2015-02-05 📝 Original ...

2023-06-07T15:29:46Z

In reply to nevent1q…jgpr
_________________________

📅 Original date posted:2015-02-05
📝 Original message:That's exactly what I though when seeing the RedPhone code, but after
I studied the commit protocol I realized it's actually secure and
convenient way to do it. You should do that too. :)

Shortly, how it works:
The initiator of the connection sends commit message containing the
hash of his temporary public ECDH part, second party sends back their
public ECDH part and then initiator sends his public ECDH part in
open. All three messages are hashed together and the first two bytes
are used to select two words from a shared dictionary which are
displayed on the screen of both the initiator and the second party.
The parties communicate those two words and verify they match.

If an attacker wants to do MITM, he has a chance of choosing right
public parts 1:65536. There is no way to brute-force it, since that
would be noticed immediately. If instead of two words based on the
first two bytes, four words from BIP39 wordlist were chosen, it would
provide entropy of 44 bits which I believe should be enough even for
paranoid people.

How this would work in Bitcoin payment scenario: user's phone
broadcasts his name, merchant inputs amount and selects the name from
the list, commit message is sent (and then the remaining two
messages), merchant spells four words he sees on the screen and buyer
confirms transaction after verifying that words match.

2015-02-06 0:46 GMT+01:00 Eric Voskuil <eric at voskuil.org>:
> On 02/05/2015 03:36 PM, MⒶrtin HⒶboⓋštiak wrote:
>>> A BIP-70 signed payment request in the initial broadcast can resolve the
>>> integrity issues, but because of the public nature of the broadcast
>>> coupled with strong public identity, the privacy compromise is much
>>> worse. Now transactions are cryptographically tainted.
>>>
>>> This is also the problem with BIP-70 over the web. TLS and other
>>> security precautions aside, an interloper on the communication, desktop,
>>> datacenter, etc., can capture payment requests and strongly correlate
>>> transactions to identities in an automated manner. The payment request
>>> must be kept private between the parties, and that's hard to do.
>>
>> What about using encryption with forward secrecy? Merchant would
>> generate signed request containing public ECDH part, buyer would send
>> back transaction encrypted with ECDH and his public ECDH part. If
>> receiving address/amount is meant to be private, use commit protocol
>> (see ZRTP/RedPhone) and short authentication phrase (which is hard to
>> spoof thanks to commit protocol - see RedPhone)?
>
> Hi Martin,
>
> The problem is that you need to verify the ownership of the public key.
> A MITM can substitute the key. If you don't have verifiable identity
> associated with the public key (PKI/WoT), you need a shared secret (such
> as a secret phrase). But the problem is then establishing that secret
> over a public channel.
>
> You can bootstrap a private session over the untrusted network using a
> trusted public key (PKI/WoT). But the presumption is that you are
> already doing this over the web (using TLS). That process is subject to
> attack at the CA. WoT is not subject to a CA attack, because it's
> decentralized. But it's also not sufficiently deployed for some scenarios.
>
> e
>

📅 Original date posted:2015-02-05 📝 Original message:I ...

2023-06-07T15:29:43Z

In reply to nevent1q…xuty
_________________________

📅 Original date posted:2015-02-05
📝 Original message:I would like to shortly express my opinion:

- Having BT as an alternative is good idea but it must be secure enough
- Signed BIP70 should be enough. I see only two issues regarding BIP70
(but they apply also to TCP/IP, not just BT): key revocations and MITM
attacks by governments.
- Broadcasting faces is very bad idea IMHO.
- Comparing addresses seems complicated but if hash was displayed as a
unique, picture hard to be mistake or long phrase, it could be more
convenient.
- Maybe storing public key (I do NOT mean bitcoin address!) of
merchant after successful transaction is good compromise?

Another idea: I noticed it's extremely easy to compare two strings if
they are the same size (in terms of millimeters, not number of
characters). If the hash of signing key was printed on a sign near the
POS in specified size (90% of smallest available screen?) and phone
would scale correctly, just putting the phone near the sign would be
enough to instantly spot whether the hashes are same.

Maybe instead of hex/base58 hash encoding use colored barcode. But I'm
not sure if it would improve things.

2015-02-05 23:49 GMT+01:00 Roy Badami <roy at gnomon.org.uk>:
> Personally I like the simplicity of tapping two phones together to
> make payment - it should be quicker and easier than scanning QR codes
> and it's a trust model that's hard to misunderstand.
>
> Is NFC good enough for that? I fear even with NFC it is possible to
> produce a device with longer range than one would expect. What
> happened to the idea of tapping two devices together and then
> comparing the timing of the tap (as detected by the phones'
> accelerometers) to make spoofing a transaction harder? I remember
> hearing about that years ago - is that still a thing?
>
> roy
>
> On Thu, Feb 05, 2015 at 02:10:51PM -0800, Eric Voskuil wrote:
>> A MITM can receive the initial broadcast and then spoof it by jamming the original. You then only see one.
>>
>> e
>>
>> > On Feb 5, 2015, at 2:07 PM, Paul Puey <paul at airbitz.co> wrote:
>> >
>> > So if you picked up the BLE broadcast request. All you know is that *someone* within 100m is requesting bitcoin at a certain address. Not necessarily who. The *name* is both optional, and possibly just a *handle* of the user. If I'm sitting 5 ft away from someone at dinner and wanted to pay them via BLE, I might see "Monkey Dude" on my list and simply ask him "is that you?" If so, I send it. If there are two "Monkey Dude's" Then I have to bother with the address prefix, but not otherwise.
>> >
>> >> On Thu, Feb 5, 2015 at 1:46 PM, Eric Voskuil <eric at voskuil.org> wrote:
>> >> BLE has an advertised range of over 100m.
>> >>
>> >> http://www.bluetooth.com/Pages/low-energy-tech-info.aspx
>> >>
>> >> In the case of mass surveillance that range could most likely be extended dramatically by the reviewer. I've seen WiFi ranges of over a mile with a strong (not FCC approved) receiver.
>> >>
>> >> WiFi hotspots don't have strong identity or a guaranteed position, so they can't be trusted for location.
>> >>
>> >> e
>> >>
>> >> On Feb 5, 2015, at 1:36 PM, Mike Hearn <mike at plan99.net> wrote:
>> >>
>> >>>> This sounds horrible. You could basically monitor anyone with a wallet in a highly populated area and track them super easily by doing facial recognition.
>> >>>
>> >>> We're talking about BLE, still? The radio tech that runs in the so called "junk bands" because propagation is so poor?
>> >>>
>> >>> My watch loses its connection to my phone if I just put it down and walk around my apartment. I'm all for reasonable paranoia, but Bluetooth isn't going to be enabling mass surveillance any time soon. It barely goes through air, let alone walls.
>> >>>
>> >>> Anyway, whatever. I'm just bouncing around ideas for faster user interfaces. You could always switch it off or set it to be triggered by the presence of particular wifi hotspots, if you don't mind an initial bit of setup.
>> >>>
>> >>> Back on topic - the debate is interesting, but I think to get this to the stage of being a BIP we'd need at least another wallet to implement it? Then I guess a BIP would be useful regardless of the design issues. The prefix matching still feels flaky to me but it's hard to know if you could really swipe payments out of the air in practice, without actually trying it.
>> >
>
>> ------------------------------------------------------------------------------
>> Dive into the World of Parallel Programming. The Go Parallel Website,
>> sponsored by Intel and developed in partnership with Slashdot Media, is your
>> hub for all things parallel software development, from weekly thought
>> leadership blogs to news, videos, case studies, tutorials and more. Take a
>> look and join the conversation now. http://goparallel.sourceforge.net/
>
>> _______________________________________________
>> Bitcoin-development mailing list
>> Bitcoin-development at lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming. The Go Parallel Website,
> sponsored by Intel and developed in partnership with Slashdot Media, is your
> hub for all things parallel software development, from weekly thought
> leadership blogs to news, videos, case studies, tutorials and more. Take a
> look and join the conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development