Topic: Where's the handshake? (Read 2098 times)

Besides the point; yes P2SH is another form of address, and yet again something that should not be called that way (or at least not always).

Both P2SH "addresses" and standard "addresses" are only a template for a public key script. Calling them "address" implies that they are intended to be permanent receive-boxes, intimately linked with someone or someplace's identity. This is sometimes the case, like in my signature below. But in the case of a merchant's website that after checkout shows you an address to pay to, or the change addresses used inside bitcoin (and especially those from e-wallet sites), this is not the case. They are just negotiated or randomly generated and possibly temporary hashes of a public key with a corresponding script. The fact that there is no distinction is made between these cases and both are called "address", is the cause of a lot of confusion, imho.

Address is used because while currently all addresses are hashes of public key that won't always be the case. p2sh for example has addesses but the address is a hash of the script it corresponds to no specific public key.  The script can be complex, have multiple actors, multiple possible outcomes.

p2sh is just one possible extension.  So address is correct.  You pay to an address what that address represents may (and likely will) change over time.

I agree in the sense that it should not be called an address if it is not intended to be used to receive coins forever. I see 'addresses' (meaning things to identify a transaction destination) in the future as a URL, rather than a random-looking string of characters.


I think I wanted to say "communication" here, rather than "confirmation". Sorry, it was late.


I diagree completely. There is no reason to use a costly P2P broadcast for information that the network does not need to verify your transactions. This is private to sender and receiver, so have them negotiate it among themselves. There is no way doing this inside the p2p communication part can ever be efficient, as it requires telling the whole world about it. Especially since, in most cases, you are already communicating with the receiver directly anyway (that was the point I was trying to make earlier, you are already visiting a merchant's wedsite (https), copy-pasting the address from an e-mail (smtp), or receiving it via IM/chat (...)). There is one case where no such communication is intended, namely anonymous donations. Still, there are other solutions for that.


It bothers me that people use addresses as "transaction destinations" rather than "negotiated public key hashes". The number one reason for that behaviour is the fact that no usable alternative addressing scheme exists. Hence a url-based protocol on top of it.

How is that a flaw?  That's exactly my point:  You can not assume that a bitcion address is forever valid.  That's the whole problem that I'm saying needs to be fixed.


Not sure how you got there.  The confirmation doesn't still exist, it doesn't exist yet.


The endorsement comes as a response to the sender broadcasting the transaction.  It's a (near) real-time mechanism.  Nobody would be able to endorse any transaction that wasn't addressed to them.

In the case of a 1-of-2 P2SH address, then either key holder would be able to endorse.

In the case of a paper wallet (or for other reasons), you would generate an address with a bit set to tell the network to accept without endorsement.  In this situation, an idiot could still destroy coins.  General use of this type of address should be discouraged.


MtGox paid 2600 BTC to people who were expecting it and ready for it, but they were still lost because the addresses MtGox actually used were completely invalid.  Recipient endorsement would have prevented those transactions from being accepted into a block.


I disagree.  I think it would have to happen within the protocol itself to avoid privacy issues.  If you're suggesting the construction of a new, anonymous, private, decentralized P2P communications platform for secure out-of-band communications, it would be much more efficient to extend the current bitcion protocol to handle this simple 2-bit mechanism in-band.

OT: Maybe it would be a good idea to implement such a P2P communications platform, which could be used to implement other services, including the bitcoin transactions.  Having a layered system like that could open up all kinds of possibilities.


Agreed.  It really bothers me that Bitcoin, in it's current state, will happily commit transactions without knowing that they can be redeemed.

The flaw here is to assume that a static bitcoin address is forever valid. The assumption is that this confirmation you talk about still exists, but outside of the bitcoin protocol. Someone would tell you "yes pay to that address", or you read it on a website. If you pay someone without them expecting or be ready for it, you are making a mistake.

By nature, this communication cannot be in the bitcoin core protocol itself - that would for example require the receiver to be online at the time of the transaction, and it would have serious privacy implication. Still, I hope that somewhere in the future another protocol is used to negotiate transactions (at least optionally) before broadcasting them.

And here, we get to the heart of the problem.  You cannot guarantee that it will be done right unless you take the human completely out of the process.  That means no human can ever write code, run a client, or initiate a transaction.  I'm sorry, but humans are humans, and errors will happen.

It's not a matter of not liking a P2SH solution, it's the fact that even a nonredeemable P2SH transaction can be committed to the blockchain.

All I'm asking, is that before a transaction (regardless of type) is committed to the blockchain, the recipient have the option to prove that the transaction will be spendable.  The recipient could do this manually, through an automated process, or even automatically by setting a flag in an offline address.

If you want to contribute to help figure out how we might accomplish this, please do so, but stop trying to tell me that transaction level spending options can prevent a nonredeemable transaction from being committed to the block chain in the first place.

-Prayer

No it won't if done right.  While you may not like a P2SH solution if you don't see it then you haven't looked far enough yet.

DandT, thank you so much for challenging me,  you've been a tremendous help in getting my thoughts sorted out and forcing me to learn more about how bitcoin works.  You've also helped me to understand that P2SH, without a doubt, is the wrong answer for this problem, as even a transaction sent to a P2SH address can be DOA when it hits the blockchain, causing a permanent loss of the included funds.

I don't think it'd break anything that's not already going to be broken.  The requirement would be 2 bits in the address, a slight load in the transaction queue, and minimal user-interaction (it could be completely interactive, completely automated, or something in between).

Now I just need to sit down and figure out if those 2 bits are available and the best approach to implementing the solution.

-Prayer

I definitely think that we're still in the very early stages of bitcoin, and it or its successors will definitely include some sort of money transmittal more like what you're talking about and less "give out an address and hope that only the person I intend to puts money there". My wild guess is that it will become normal for senders to sign transactions and send them directly to receivers, who would then package them up with a transaction to take that input and put it where they really want it, and the receiver then submits the package of transactions to miners for block inclusion. But that's my first wild guess, and it seems that even Satoshi's first guess of payments to IPs wasn't really how things have happened, so nobody really knows for sure what's going to catch on. But I'm pretty sure that a merchant giving you an address to copy and paste into your bitcoin client isn't going to be the long-term approach for most transactions.

It'll definitely be interesting to see how this all plays out eventually.

Many people believe bitcoin addresses will not remain part of what users see when using Bitcoin. What comes in its place is far form known, but we can assume some protocol that performs negotiation of addresses (as well as exchange other information about the payment itself).

Maybe I'll enter "[email protected]" as payment destination, and some interaction with somedomain.com's bitcoin wallet server occurs. Note that that isn't that far from how Satoshi envisioned it originally - he thought IP transactions would be the norm, but for various reasons they became unpopular, and later obsolete, and the pay-to-hash-of-pubkey construction known as bitcoin addresses took over. As explained by the OP, they have several problems as well: no explicit communication with the receiver.

No that would be one use of p2sh.  p2sh is pay to script hash.  Period.  Instead of paying to an address which is linked to a public key you are paying to an address which is the hash of a script.

Within some limitations that script can do what you wan't.  It isn't limited to only wallet security.


Possibly.  If Mt. Gox as a policy paid out only to p2sh addresses then those scripts could have a "recall option" to return funds back to them.  In discovering error of the transaction (or when receiver didn't clear the funds in 48 hours) they could complete one option of the script by signing it with private key and having those funds returned to a "return address' specified in the script.


p2sh could be used for endorsement. p2sh is simply paying to a script hash (hence p2sh pay to script hash).

Other examples of using p2sh:
https://en.bitcoin.it/wiki/Contracts

Looks like wiki is down for me but putting that address into google should allow you to view google's cache.



You are talking about a breaking change at the fundamental level of Bitcoin.  It is unlikely any such change will ever happen except to mitigate a catastrophic flaw (SHA-256 compromised for example).  You are free to come up with a system just be aware such a system likely will never exist beyond theoretical stage.

Bitcoin does provide a mechanism to extend the functionality of the protocol in an optional and non-breaking way via scripts.  More complex systems like handshakes could be built on top of the core protocol by using scripts and mult-sig.

No sweat on that... I often have a hard time organizing my thoughts and getting them out properly.  Heck, that last reply took me a while to crank out.

The concept of a handshake... it means different things in different contexts... I never even thought about the network-layer handshake as referenced by genjix.

Endorsement would be a better term here maybe....  the same way a merchant endorses a check to ensure that it gets deposited into the right account when he drops them off at the bank.



I've read many of your posts and I know you have a great handle on what Bitcoin is and what it can do.  I also know you're pretty well aware of what Bitcoin isn't and what it can't do.  I'm very pleased to have you jump into the discussion.

My post did touch on a few different areas of bitcoin, but really only a single topic... endorsement of a transaction before it's made, the handshake.

On the sending side... I think it would be nice to have a safety net to prevent sending coins to any address that would be the equivalent of destroying coins.  The reason (invalid, lost keys, whatever) doesn't matter.

On the receiving side, I think it would be useful to be able to reject inputs from source you don't want to be associated with.  To use a real-world analogy, let's say I mailed you a check and you deposited that check, there's a record of the transaction.  If you later discover that you should not have accepted funds from me, you can issue a refund, but there's still a record of you accepting funds from me in the first place.  If my name is Osama and your name is Obama, that would be a very bad thing...  you should have checked the sender before accepting the transaction.  Perception is everything and 20/20 hindsight won't save you from the black eye, no matter what you do with that money.

To use a non-financial analogy, anyone can come knocking on your door, but that doesn't mean that you have to let them into your home.  With bitcoin, you don't have that option, if someone sends you coin, that coin is in your wallet.


I can see where this would work for acceptance on the part of the receiving party in a friendly transaction, which would be kinda silly, as the receiver is expecting coin and would gladly accept it.  Here's a box, and here's a key to open it.  We still haven't dealt with the fact that the transaction itself might be unwelcome in the first place.

Ok, so I'm a rank newbie here, and while I think I understand the principles behind P2SH, I may be missing something in the implementation, so correct me if I'm wrong in stating that P2SH, as implemented by either BIP, provides a security mechanism to curtail the unauthorized spending of bitcoin.

If P2SH existed a week ago, could it have been used to prevent the Linode heist?  I think so... slush's system would have generated the initial transactions, which would require him to counter-sign the final release.  Problem solved.

If P2SH existed 6 months ago, could it have been used to prevent Mt.Gox from tossing 2600 coins into the BitBucket?  I don't think so, they would have signed away to meet the P2SH requirements, but that would have done nothing to validate or verify the receiving addresses.

So, I think it's fair to say that P2SH is security, while endorsement is more of a safety, but one that could be completely transparent to the end users, unless they choose to interact with it (manually endorsing payments to specific addresses)


Even with my limited understanding of the whole Bitcoin system, I'd agree with you that it wouldn't be possible to implement this into the block chain right now, but at this point, I'm hoping to garner enough interest that maybe this mechanism could be fleshed out, coded, tested, and ready to go when the next big fork comes around.

My only question comes in terms of compatibility at the client level... would it be possible to generate a backwards compatible bitcoin address with option bits before the checksum?  I ask, because I'm not yet seeing any other way to do this completely in-band, and I can already think of at least 2 flags: REQUIRE_ENDORSEMENT and AUTO_ENDORSE (for offline/paper wallets).

Actually, I lie. I can think of a couple more flags for safeguarding incoming transactions, but that would be completely outside the scope of this particular thread.  I'm sure if you thought about all the ways we exchange money, property, and goods in the real world, I'm sure you can think of a few flags to help provide additional safety, accountability and security.

You covered a lot of topics.

First sending Bitcoins to an invalid address is nearly impossible.  Addresses have a 32bit checksum and client will refuse to send coins to an address which is malformed.  Sending coins to an incorrect but valid is so rare to be impossible (1 in 4.3 billion).

As far as preventing transactions.  That isn't possible but since individual coins can be tracked one could return the coins to sending address (possibly having to pay transaction fee).  This is no different than other forms of payment.

From a legal standpoint (outside the blockchain & protocol) you could have a "holding account" where payments are sent and then the receiver transfers them from holding account to their internal account which would constitute acceptance.  The sender could return payments they don't accept to the sending address (although that creates problems w/ systems like Mt.Gox where sending & receiving addresses aren't linked).

Still this requires everything on the senders end and doesn't help if the sender/address/wallet is "gone".  To allow either party to control the "pending payment" you need multi-sig. 

1) Create a script w/ a 1 of 2 key option.  Signing w/ 1 key (sender) returns payment to sender address (can be different than payment address).  Signing w/ other key (receiver) forwards payment on to seller's payment addresss.

2) Create a p2sh address for the script.

3) Send payment to p2sh address.

4a) Receiver accepts:  Receiver signs and payment is forwarded to their internal address.
4b) Receiver rejects:  Receive leaves payment in limbo and sender signs to return payment themselves.


There is no way AFAIK to automate this at the blockchain level (i.e. return if not signed in 100 blocks)  but clients at both ends could be setup to auto-sign and forward based on conditions (i.e. merchant auto accepts and forwards if payment matches a valid order, sender auto-returns any payments not accepted in 24 hours).

That likely is the closest you would get to what you proposed.  Support p2sh so we can have multi-sig transactions for this (and hundreds of other purposes).

I see.  I actually had a related idea earlier: why not create a way to add an expiration time to an address?

If you want to be sure someone has that address right now, get one created now with an expiration time in 5 minutes.  When generating addresses generally you can make one that expires in a month or two to prevent legacy addresses from accumulating coins.

The expiration wouldn't need to be enforced by mining.  It's just a sanity check in your client.  Using an expired address would just pop up a warning before you can proceed.

I probably worded that wrong... it's not really about trusting the other party, it's about trusting that the destination address is (still) valid.  By extension, about the recipient being able to selectively decline incoming transactions for any reason.

If Bitcion ever goes mainstream, it will be subject to fun things like taxes, audits, freedom of information, etc..., certain entities will have to account for everything they receive, so will limit incoming transactions to known sources only.  Just imagine if a political candidate unwittingly received a donation from Al Qaeda.  This could be very damaging, even though the candidate had no way to refuse the donation and had no control over who can send donations in.


I answered this while you were posting... I'm not really talking about verifying the person... only that the address is still valid and active, so that the coins won't land in a black hole.


Wow, that's a few layers lower than what I'm referring to, but thanks!

http://gitorious.org/libbitcoin/libbitcoin/blobs/master/src/network/handshake.cpp

How do you ensure the handshake is happening with the right person?  Cut-and-pasting a handshake is just as vulnerable as cut-and-pasting an address.

Once upon a time, gentlemen would shake hands to confirm a deal.  Where's the handshake in Bitcoin?

I know that bitcoin was designed to take trust out of the equation, but some might prefer that some level of trust be available.  Sure, you can exchange signed messages and the sort out-of-band, but that does nothing to actually provide trust at the transaction level itself, which may be desirable or even required by some parties.

As an example, let's say that 1Newbie sends all their BTC to 1BitBucket.  Their coin is gone forever.  However, if there was a handshake available, 1Newbie could have asked for one, and his transaction would have expired because there's nobody @1BitBucket to complete the handshake.

As another example of how this could be useful, is that 1Merchant is very anal about business and does not want to accept any BTC from any unknown source.  He could generate an address that requires every transaction to have a two-way handshake.  A merchant might require this, but also set their wallet to auto-confirm every incoming transaction.

One instance really jumps out at me as a potential use... last October, MtGox lost ~2600BTC?  If a handshake mechanism were in place and being used, this wouldn't have happened.

Now, I'm not advocating that every transaction require a handshake, just that it be available as an option by either party for any given transaction.  I think it would be a very popular feature for people who are exchanging large amounts of BTC.

I've not deciphered enough of the source to figure out an implementation yet.  I'd imagine that something could be scripted in the transaction, but that only protects one side.  The other side would have to have some mechanism to let the network know to get a handshake before processing.

This could possibly be done with P2SH (send to a jointly signed p2sh address that requires both buyer and seller to redeem), but that's like bouncing the ball rather than throwing it straight to the other guy.

Would it be possible to generate an address that could somehow raise a flag that would trigger special handling?  If there's room, maybe set aside a few bits for this and other flags to trigger special handling.


-Prayer