I think that bitcoin devs should give a look here:
[PROPOSAL] Give proof of identity to your customers
https://bitcointalksearch.org/topic/proposal-give-proof-of-identity-to-your-customers-58534
It's a possible update on the URIs scheme.
Topic: Bitcoin URIs (Read 1496 times)
thanks. looks good to me
Here the status:
https://github.com/bitcoin/bitcoin/pull/593
https://github.com/bitcoin/bitcoin/pull/593
could not find a better thread to resurrect...
does anyone have an idea what is the status of the whole URI thing?
does anyone have an idea what is the status of the whole URI thing?
For sending money the scheme I described above requires the client to search for the incoming tx by address (public key hash). This might be difficult, in particular for simplified clients (not downloading all tx / whole blocks). Here's a modified scheme that would help this problem. Instead of the send URI containing the address (public key hash) it could contain the transaction identifier and output offset. This would be larger than the address (256+a few bits vs 160 bits) but would allow the URI recipient to directly request the required tx, without any search.
That's interesting. I've been looking lately through forum posts about URIs and in the wiki.
I'd like to try and help get the bitcoin: URI scheme written up and approved by IANA.
The format should be something similar to the mailto: URI scheme:
http://tools.ietf.org/html/rfc6068
The W3C have kindly offered some assistance, so hopefully there's a reasonable chance that that it will get the thumbs up.
I'd like to try and help get the bitcoin: URI scheme written up and approved by IANA.
The format should be something similar to the mailto: URI scheme:
http://tools.ietf.org/html/rfc6068
The W3C have kindly offered some assistance, so hopefully there's a reasonable chance that that it will get the thumbs up.
I have 2 enhancement proposals.
1) Add an optional expires field to the URI - this indicates 'don't send to this address after this date'. This is to alleviate the problem of needing to keep a private key around forever. In many applications clicking on a URI to send bitcoins will result in only 1 tx immediately, but there may be applications that remember the address - this would indicate an expiry date to those applications.
2) Add a facility to receive money via a URI
i.e. clicking on a webpage to receive money from the website, or receiving money by email or SMS.
Here's how the scheme would work. The sender generates a new keypair, and publishes a transaction sending the amount to that keypair using the 'send to IP address' script form:
scriptPubKey: OP_CHECKSIG
scriptSig:
The sender then generates a bitcoin URI - and includes in the URI the hash of the public key, and the private key. (both are short).
Now the recipient receives the URI (i.e. user click on it in a webpage/email/sms) - the recipient's wallet can find the transaction (it has the hash of the public key, so can find the tx), and the recipient can 'claim' the money - by generating another keypair, and doing another 'send to IP address' tx sending the money to themselves.
If the recipient does not claim the money the sender can get it back - perhaps the URI can also include the optional 'expires' field, to indicate the sender will reclaim the money if not claimed within this time period.
1) Add an optional expires field to the URI - this indicates 'don't send to this address after this date'. This is to alleviate the problem of needing to keep a private key around forever. In many applications clicking on a URI to send bitcoins will result in only 1 tx immediately, but there may be applications that remember the address - this would indicate an expiry date to those applications.
2) Add a facility to receive money via a URI
i.e. clicking on a webpage to receive money from the website, or receiving money by email or SMS.
Here's how the scheme would work. The sender generates a new keypair, and publishes a transaction sending the amount to that keypair using the 'send to IP address' script form:
scriptPubKey:
scriptSig:
The sender then generates a bitcoin URI - and includes in the URI the hash of the public key, and the private key. (both are short).
Now the recipient receives the URI (i.e. user click on it in a webpage/email/sms) - the recipient's wallet can find the transaction (it has the hash of the public key, so can find the tx), and the recipient can 'claim' the money - by generating another keypair, and doing another 'send to IP address' tx sending the money to themselves.
If the recipient does not claim the money the sender can get it back - perhaps the URI can also include the optional 'expires' field, to indicate the sender will reclaim the money if not claimed within this time period.
Jump to: