The problem with multi-sig transactions...

[bytemaster]

Users have to create, share, distribute, and manage partially signed transactions.   This is not viable for almost all users.  Only the most paranoid and patient of users.  The infrastructure required to "get this right" is significant. 

As a general policy I think there should be no situation where a user cannot sign and submit a valid transaction to the blockchain.   Multisig is a generic tool employed by Bitcoin to solve any arbitrary voting policy on spending funds.   Being generic means it is harder to use.

I think we can identify the 2 most common use cases and make it even better than Multisig. 

These use cases are: 
1) escrow 
2) transaction confirmation via 2 factor authentication service

The 2 factor authentication service is much more complicated and will require full use of multi-sig along with a "bot" that will automatically transfer all incoming TITAN transfers to unique multi-sig accounts. 

In the case of escrow:
1) Sender Key
2) Receiver   Key
3) Escrow Agent  Key

The escrow agent should only have the power to divide amount between the Sender or the Receiver and no one else. 
The Sender only has the power to give the funds to the Receiver.
The Receiver only has the power to give the funds to the Sender. 

In this case we can create a simple state transition on who controls the funds and any user can create/sign a transaction that will update that state transition:
1) Initiate transfer
2) Sender confirms transfer *or* Receiver returns transfer
3) *or* Escrow agent resolves dispute... and divides the funds between the parties.
   
I believe this simple escrow operation is much easier for users to interact with than multi-sig.   It would involve selecting an escrow agent at time of transfer and then clicking a "release funds" when the goods arrive.    On the receiver side they can click "return funds" at any time.   In the event of a dispute they both have to contact the escrow agent and pay for dispute resolution. 


 

[Mysto]

[mf-tzo]

What am going to say might be completely irrelevant (again..) but I will say it anyway..

Could this be the Insurance DAC? Somehow we make an insurance for the transactions, or theft, or loss of funds and the insurer makes sure that I have X amount of funds and I want to send them to Y and process the payment (like the escrow), or settles the case in case of dispute, or covers the funds in case of theft (from fees generated in the DAC) etc etc...

 

[Shentist]

in my understanding multisig is just like escrow, so with your solution i am fine.

i would suggest that this kind of transaction has higher fees and the fees will go to escrow agents with every transaction. every escrow agent will place an offer to do escrow service like your proposed insurance agent. after the dispute is solved the agent will rate the parties with + or - . In escrow you could later select you want only do business with accounts older than x and with not less then X - points.

[Rune]

This would unfortunately make open bazaar integration much less straightforward, or at least be used differently on OB than other coins, leading to confusion (BTSX' greatest weakness). But otoh I agree that this is a better solution overall, due to its user friendliness.

I think the emergence if this inbuilt escrow system, and others like it, would create an industry wide debate about how to handle the reputation system of escrow agents. Should they be platform based (such as OB), coin based or universal as an external system to the others?

I personally predict that OB will end up becoming the only p2p trade platform, so it would make sense to have it be the default WoT for the entire crypto economy. That might also be an argument against a BTSX escrow system that doesn't fit into OB, unless btsx development takes the lead in implementing a custom OB bitUSD integration.

In the long run I'd like to see this system for Titan txs and regular multisig for non-Titan txs.

[Gentso1]

In multisig you have a key that is broken into pieces, put all the pieces together and you have access to a address, this is at least how I understand it.

In this case we can create a simple state transition on who controls the funds and any user can create/sign a transaction that will update that state transition:
1) Initiate transfer
2) Sender confirms transfer *or* Receiver returns transfer
3) *or* Escrow agent resolves dispute... and divides the funds between the parties.


Do you worry that by trying to implement a new type of escrow system you will further divide our system from the current standard of multi-sig? 

[Shentist]

In multisig you have a key that is broken into pieces, put all the pieces together and you have access to a address, this is at least how I understand it.

In this case we can create a simple state transition on who controls the funds and any user can create/sign a transaction that will update that state transition:
1) Initiate transfer
2) Sender confirms transfer *or* Receiver returns transfer
3) *or* Escrow agent resolves dispute... and divides the funds between the parties.


Do you worry that by trying to implement a new type of escrow system you will further divide our system from the current standard of multi-sig? 

if the suggested escrow solution would be better (easier to use and understand) we should do it. we don't need to follow always taken ways.

[Mysto]

In multisig you have a key that is broken into pieces, put all the pieces together and you have access to a address, this is at least how I understand it.

In this case we can create a simple state transition on who controls the funds and any user can create/sign a transaction that will update that state transition:
1) Initiate transfer
2) Sender confirms transfer *or* Receiver returns transfer
3) *or* Escrow agent resolves dispute... and divides the funds between the parties.


Do you worry that by trying to implement a new type of escrow system you will further divide our system from the current standard of multi-sig? 

if the suggested escrow solution would be better (easier to use and understand) we should do it. we don't need to follow always taken ways.

This^^^

[arhag]

Users have to create, share, distribute, and manage partially signed transactions.   This is not viable for almost all users.  Only the most paranoid and patient of users.  The infrastructure required to "get this right" is significant. 

As a general policy I think there should be no situation where a user cannot sign and submit a valid transaction to the blockchain.   Multisig is a generic tool employed by Bitcoin to solve any arbitrary voting policy on spending funds.   Being generic means it is harder to use.

Your escrow-specific transaction is a nice bonus to the traditional multisig, but I am more interested in the second use case: multi-factor authentication.

Following the policy that a user should be able to sign and submit a valid transaction to the blockchain without having to first coordinate partially signed transactions out-of-band, why not allow submitting partially signed transactions to the blockchain with additional signatures added later? So, there could be a balance on the blockchain sitting in an output of tx1 which is spendable by an M-of-N multisig transaction. I can then submit tx2 intending to spend the output of tx1 and sign the transaction using one of the N keys. The transaction could also pay in advance for the other (M-1) mini-transactions that need to be added to make the transaction whole and active; this way the next (M-1) unique mini-transactions providing the other necessary signatures can be added to the blockchain at no cost to the signers. The other (N-1) entities can be alerted in their clients (either through the TITAN check mechanism that already exists and/or the mail server notification system for lightweight clients that is planned) that there is a partially-signed transaction on the blockchain awaiting further signatures that they can provide. Then, if (M-1) of those (N-1) agree to sign that partially-signed transaction which would add their signatures to the blockchain as they each sign, the transaction will become whole and activated (meaning the funds would have been officially moved from the output of tx1 to the output of tx2). Prior to activation, those transactions are just data sitting on the blockchain, the output of tx1 is still valid, and it is possible for another transaction to spend the output before tx2.


Edit: I just thought of another improvement. In TITAN the encrypted memo field has two pieces of information: the sender information along with the SHORT_SIGNATURE to prove it, and the memo text. I suggest splitting these two pieces of information so that they are encrypted with separate keys. The sender information and SHORT_SIGNATURE would be encrypted by SECRET1, and the memo text + SECRET1 would be encrypted by SECRET, where OneTimePrivateKey * RECIPIENT_EXT_PUBLIC_KEY => SECRET. OneTimePrivateKey * SECONDARY_EXT_PUBLIC_KEY => SECRET1, where SECONDARY_EXT_PUBLIC_KEY is one of the public keys in the multisig transaction that is spending the funds. This way the holder of RECIPIENT_EXT_PRIVATE_KEY (the main recipient of the multisig transaction) can decrypt both the sender information and the memo text as usual, while the holder of SECONDARY_EXT_PRIVATE_KEY (likely the second-factor authentication service) can only see the sender information but not the memo text. The holder of SECONDARY_EXT_PRIVATE_KEY can check that one of the RECEIVE_PUBLIC_KEYs in the multisig output of tx1 belong to it, that tx2 has legitimately initiated the multisig transaction spending the tx1 output, and by decrypting the sender information in the memo field of tx2 it can determine which of its customers initiated the transaction. This allows it to know who to contact for further verification (say SMS verification or a telephone conversation) before adding their signature through a mini-transaction to the multisig transaction.

[Pheonike]

Could we implement something like this for secure login.

https://www.grc.com/sqrl/sqrl.htm

[toast]

Could we implement something like this for secure login.

https://www.grc.com/sqrl/sqrl.htm

Already done.

Sent from my SCH-I535 using Tapatalk

[bobmaloney]

Could we implement something like this for secure login.

https://www.grc.com/sqrl/sqrl.htm

Already done.

Sent from my SCH-I535 using Tapatalk

 

[theoretical]

Users have to create, share, distribute, and manage partially signed transactions.   This is not viable for almost all users.  Only the most paranoid and patient of users.  The infrastructure required to "get this right" is significant. 

What's wrong with allowing users to store partially signed transactions on the blockchain?  It'd fix "share", "distribute" and to some extent "manage".  "Create" and the rest of "manage" is more a UI thing.

Being generic means it is harder to use.

These use cases are: 
1) escrow 

I agree that having explicit support for escrow would be positive (especially well-integrated with TITAN accounts).  I'm not a multisig expert, but I suspect it'll largely be a UI effort that'll use multisig under the hood at the blockchain level (maybe using the transaction memo to store a hint).

[bitsapphire]

We are implementing for one of our clients a bitcoin multisig solution for escrow. The client has been asking for a potential bitUSD integration for some time. So the market for it is definitely there.

[speedy]

So if I understand this correctly, if BitShares has an escrow multisig built into the wallet, it seems like a localbitcoins.com-like website for BTSX would be trivial to setup.

A localbts.com website wouldnt even need to store any funds, it would just act as the 3rd party signature and 99% of the time the website wouldnt need to do anything because the buyer and seller would agree and give both of the required signatures.

This is in contrast to Bitcoin, where multisig is complicated so localbitcoins.com stores the funds exclusively on its server, with all the added security problems.