Re: [bitcoin-dev] The Cryptographic Relay: An Electrical Device For Smart Transferable Hardware

[Andy Schroder via bitcoin-dev]

See multiple places below


Andy Schroder

On 7/20/20 10:18 AM, ZmnSCPxj via bitcoin-dev wrote:

Introduction


An electrical relay is an electrically-controlled switch, often diagrammed as:

   +-o
   |
   |   \
   |\
   +--o  o---o

 o  |
  ) |
  ) |
  ) |
 o  |

The terminals at the left feed into a coil.
When electricity passes through the coil, it magnetizes a core, and the 
magnetism attracts a switch into a closed position, which would let electricity 
to pass through the terminals at the right.
This can be used to "turn on" or supply power to a different electrical device.

If no electricity is passing through the coil via the terminals on the left, 
then no electricity can pass through the terminals on the right, as the switch 
is an open position at default.

This is a fairly simple logic circuitry, upon which more complicated circuitry 
can be made.

Similarly, a Cryptographic Relay is a hardware electrical component that allows 
control of some electrical circuit.
It has two terminals which are the two terminals of a switch.
It can also be contacted, for example via Bluetooth, by an electronic computing 
device.
The Cryptographic Relay has a public key, which represents the current owner of 
the relay.
If the electronic device is able to provide a proof-of-knowledge of the private 
key (i.e. a signature) corresponding to the public key that the Cryptographic 
Relay knows, then it allows the switch to be controlled by that device.

Motivation
==

Suppose I have a car I wish to sell to you, for Bitcoins.
This car, as it happens, has a Cryptographic Relay: it will only start its 
engine if it gets a signed message from me using a private key I have on my 
phone.
It knows my public key, and will only turn off and on at my command.

Now, you want to be able to know that by paying me Bitcoins, you get sole 
ownership of the car I am selling.

This is in fact, nothing more than a swap operation.
I have an asset, a car, and you have an asset, some Bitcoins.
We want to atomically swap one asset for the other asset, and those assets do 
not exist in a single asset-assignment system.

Paying Bitcoins For Cars Via Succinct Atomic Swaps
==

Fortunately, there is an atomic swap operation, Succinct Atomic Swaps, which 
can be used to create an atomic swap between my car and your Bitcoins.

An important part of this Succinct Atomic Swap is that all timeouts are only in 
one asset-assignment system.
The original Succinct Atomic Swap discussion gives an example of swapping 
Bitcoins for Litecoins.
Each has its own distinct blockchain, which is a distinct distributed 
asset-assignment system.

A crucial part of the Succinct Atomic Swap is that all timelocks are only on 
one asset-assignment system.
The other asset-assignment system need not support anything other than 
assigning ownership of assets to (homomorphically additive) public keys.

This is important as a major simplification of the Cryptographic Relay:
The relay only needs to know its *current owner*, and does not need to know the 
current time!

Thus, in order for you to buy my car:

* You set up the Succinct Atomic Swap on the Bitcoin blockchain.
* We generate fresh private keys, then combine them via MuSig, and I transfer 
the ownership of the car to that MuSig public key.
* If I claim the funds, that atomically reveals my share of the private key to 
you, so you can claim the car using your private key plus my share and transfer 
the car to sole control of you.
* If I fail to claim the funds, then when you reclaim your funds at timeout, 
that atomically reveals your share of the private key to me, so that I can 
claim the car using my private key plus your share and transfer the car back to 
sole control of me.

This is in fact the same as the Succinct Atomic Swap example, except that 
instead of me swapping my Litecoins for your Bitcoins, I am swapping my 
Cryptographic Relay for your Bitcoins.

Cryptographic Relay Operations
==

Thus, a Cryptographic Relay needs to support only the following basic 
operations.
These operations are triggered by its owner sending a message, plus a signature 
verifiable by the public key, to the Cryptographic Relay.
(Cryptographer warning: if using Schnorr, the message hashed into the signature 
also has to include the public key that is signing it, since BIP32 nonhardened 
derivation allows a Schnorr signature created by one child private key to be 
trivially malleated into a signature for the same message by a sibling private 
key; this does not exist in ECDSA due to its nonlinearity.
message sends need not include the public key, it can be added by the 
cryptographic relay since it has to know the public key of the owner anyway.
Of note is that the bip-340 description of Schnorr includes the public key in 
the hash operation of signatures 

Re: [bitcoin-dev] Authentication BIP

[Andy Schroder via bitcoin-dev]

On 08/08/2016 01:42 PM, Gregory Maxwell wrote:

On Mon, Aug 8, 2016 at 5:09 PM, Andy Schroder via bitcoin-dev
<bitcoin-dev@lists.linuxfoundation.org> wrote:

I have mixed feelings about strictly tying the identity-public-keys with a

[...]

guaranteed static IP address. The second reason is because the DNS PTR

I don't see any reason that it couldn't also accept a DNS name there.

The purpose of that table is so the client knows which server ID to expect.


Okay, that may be fine. You are saying otherwise you'd have to do a 
trial and error and this tying to a network identifier just speeds 
things up? If the DNS is spoofed, it's no big deal because the 
authentication will fail anyway?







I consider it a good thing from a privacy perspective if my IP address
changes every once and a while.

And the design seeks to preserve that privacy.


Maybe a strict check option where the identity-public-keys must optionally
match a specific network identifier would be a compromise? Maybe this is up

The client must know the identity of the server it is expecting. The
server does not announce itself. If it did then your changing of IPs
would provide you with no privacy at all.


Good point.



If the design is to provide any protection against MITM you need to
know who you expected to connect to in any case.


I think the purpose of this is to detect if someone has physically stolen and 
compromised my bitcoin node and placed it on another network under control of 
an attacker.

Huh. No. Almost the opposite. The system is designed to inhibit
fingerprinting. You can't tell what identity key(s) a node has unless
you already know them. This means that if you don't publish your node
pubkey, no one can use it to track your node around the network.


Cool.




Is there an option for a wildcard here? Couldn't there be a case where the
client wants to authenticate, but the bitcoin node does not care who it's
clients are? This would be similar to many of the http based bitcoin block
explorer API services that are out there. The API operators have built up
some reputation, so people use them, but they don't necessarily care about
who their users are.

Then they're just not listed in the file. The client can ask the server to
authenticate without authenticating itself.


Simple enough.




Does openssh have this same problem?

No. OpenSSH doesn't make an effort to protect the privacy of its users.


I'm assuming this could be parallelized very easily, so it is not a huge
problem?

It's not a issue because we're not aware of any usecase where a node
would have a large list of authenticated peers.


Each peer can configure one identity-key (ECC, 32 bytes) per listening

network interface (IPv4, IPv6, tor).

I'm not aware of any reason for this limitation to exist. A node
should be able to have as many listening identities as it wants, with
a similar cost to having a large authorized keys list.



So you are saying that you agree with me that the original text needs to 
be revised slightly or I am just misinterpreting the original text?





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andy Schroder via bitcoin-dev]

Only large merchants are able to maintain such an infrastructure;
(even
Coinbase recently failed at it, they forgot to update their
certificate). For end users that is completely unpractical.


Payment protocol is for when you buy stuff from purse.io 
, not really needed for face-to face transfers, end 
users, IMO.




I disagree with your statements. There are many face to face use cases 
where the payment protocol is essential. Pretty much anything where the 
payee's hardware device that the payer interacts with is automated in 
public and/or operated or accessible by untrusted employees. In any of 
those cases the software on the payee's hardware device can be modified. 
Providing a signed payment request gives the payer additional confidence 
that they are paying the correct person.


See some examples here: http://andyschroder.com/BitcoinFluidDispenser/2.3/


There was a secure bluetooth protocol that Andreas Schildbach and Eric 
Voskuil and I were working on, but we never pulled it all the way 
together. This would also need a two way exchange for a face to face 
payment. This could be used without using some sort of key/certificate 
verification service if being done between two humans who are the direct 
senders and receivers of the payment and are using hardware that they 
personally own (not necessarily the case of untrusted employees or 
public vulnerable machines).






The same benefit can be achieved without the complexity of BIP70, by
extending the Bitcoin URI scheme. The requestor is authenticated using
DNSSEC, and the payment request is signed using an EC private key. A
domain name and an EC signature are short enough to fit in a
Bitcoin URI
and to be shared by QR code or SMS text.

 bitcoin:address?amount=xx=yyy=john.example.com
=zzz


I agree.  A TXT record at that name could contain the pubkey.



Did you not see my previous message about the size of the bitcoin: URI 
getting too big for NFC and QR codes? Do you not care about giving the 
payer the option of using multiple destination payment addresses? This 
is important for many reasons.




That extension is sufficient to provide authenticated requests,
without
requiring a https server. The signed data can be serialized from the
URI, and DNSSEC verification succeeds without requesting extra
data from
the requestor. The only assumption is that the verifier is able to
make
DNS requests.


The problem is that there's no way for a merchant to /refuse /a 
payment without a direct communication with the merchant's server.
Verify first / clear later is the rule.   Check stock, ensure you can 
deliver, and clear the payment on the way out the door.


So, are you saying first the payer should send an unsigned transaction 
for review, and then once the payee has agreed it's good, they can send 
an ACK message back and then wait for the signed version? I don't think 
this is a bad option to have. Many wallets simultaneously broadcast a 
signed transaction to their peers and and also back to the payee via 
https or bluetooth. So, you'd have to add another step to do the 
unsigned transaction review in order to avoid a transaction being 
accidentally broadcast that both parties don't like.





Also, as a merchant processing monthly subscriptions, you don't want 
the first time you hear about a user's payment to be /after /it hits 
the blockchain.  You could add a refund address to deal with it after 
the fact... stuff a refund address int OP_RETURN somehow?


bitcoin:address?amount=xx=ccc=yyy=john.example.com 
=3d=1m=zzz


Again, my comments above about issues with using bitcoin: URI for 
everything. Also, why do you want to bloat the blockchain with 
unnecessary refund transaction data?





signature.asc
Description: OpenPGP digital signature
___
bitcoin-dev mailing list
bitcoin-dev@lists.linuxfoundation.org
https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev

Re: [bitcoin-dev] Even more proposed BIP extensions to BIP 0070

[Andy Schroder via bitcoin-dev]

Bluetooth exchange of payment requests already has a noticeable lag with 
protocol buffers, so that would be another reason to argue against JSON, 
because JSON is less efficient size wise, correct? I will say that 
although protocol buffers have good platform support, I don't know that 
the documentation for each platform is very good. This is the main 
drawback I see with them. One additional advantage of protocol buffers 
is that the .proto file is a specification, whereas with JSON, you'd 
just have an example file, right?


Isn't keybase a centralized infrastructure? Are you against a blockchain 
based identification? There are a few out there. There is some confusion 
because onename's efforts are breaking away from namecoin though.


I like the idea of PGP signatures of payment requests. This allows for 
manual verification (in my mind, the highest quality) of key 
authenticity (or, with PGP you also have the option to opt into some 
centralized service for key verification). This can be useful when 
dealing with semi-manually issued invoices for goods and services. The 
local bitcoin wallet could just interact with the local PGP keyring. 
Although, one can already just send the payment request in a PGP signed 
e-mail, so I'm not sure if PGP signing is really needed if you're using 
PGP email. The main benefit may just be consolidating/itemizing into 
your bitcoin wallet's transaction history whether the payment 
destination/request was securely received or not. It may also be useful 
for someone to be able to extract a signed payment request from a signed 
PGP e-mail and send it to someone else to make a payment for you (maybe 
you don't want your accounting person to need your entire e-mail 
correspondence with a supplier to be able to just verify the payment 
request and make a payment for your company).


I'm concerned about extending the URI scheme too much. Isn't this going 
to reach the practical size limit of NFC and QR codes pretty quickly?





Andy Schroder

On 06/21/2016 05:43 AM, Andreas Schildbach via bitcoin-dev wrote:

Protobuf vs. JSON was a deliberate decision. Afaik Protobuf was chosen
because of its strong types, less vulnerability to malleability and very
good platform support. Having coded both, I can say Protobuf is not more
difficult than JSON. (Actually the entire Bitcoin P2P protocol should be
based on Protobuf, but that's another story.)

Yes, all extensions to BIP70 should go into new BIPs. Note the plural
here: if you have orthogonal ideas I strongly suggest one BIP per idea
so they can be discussed and implemented (or rejected) separately.


On 06/20/2016 07:33 PM, Erik Aronesty via bitcoin-dev wrote:

BIP 0070 has been a a moderate success, however, IMO:

- protocol buffers are inappropriate since ease of use and extensibility
is desired over the minor gains of efficiency in this protocol.  Not too
late to support JSON messages as the standard going forward

- problematic reliance on merchant-supplied https (X509) as the sole
form of mechant identification.   alternate schemes (dnssec/netki), pgp
and possibly keybase seem like good ideas.   personally, i like keybase,
since there is no reliance on the existing domain-name system (you can
sell with a github id, for example)

- missing an optional client supplied identification

- lack of basic subscription support

/Proposed for subscriptions:/

- BIP0047 payment codes are recommended instead of wallet addresses when
establishing subscriptions.  Or, merchants can specify replacement
addresses in ACK/NACK responses.   UI confirms are /required /when there
are no replacement addresses or payment codes used.

- Wallets must confirm and store subscriptions, and are responsible for
initiating them at the specified interval.

- Intervals can /only /be from a preset list: weekly, biweekly, or 1,
2,3,4,6 or 12 months.   Intervals missed by more than 3 days cause
suspension until the user re-verifies.

- Wallets /may /optionally ask the user whether they want to be notified
and confirm every interval - or not.   Wallets that do not ask /must
/notify before initiating each payment.   Interval confirmations should
begin at /least /1 day in advance of the next payment.

/Proposed in general:
/
- JSON should be used instead of protocol buffers going forward.  Easier
to use, explain extend.

- "Extendible" URI-like scheme to support multi-mode identity mechanisms
on both payment and subscription requests.   Support for keybase://,
netki:// and others as alternates to https://.

- Support for client as well as merchant multi-mode verification

- Ideally, the identity verification URI scheme is somewhat
orthogonal/independent of the payment request itself

Question:

Should this be a new BIP?  I know netki's BIP75 is out there - but I
think it's too specific and too reliant on the domain name system.

Maybe an identity-protocol-agnostic BIP + solid implementation of a
couple major protocols without any mention of payment URI's ...