BitShares Forum
Main => General Discussion => Topic started by: bytemaster on October 13, 2014, 07:25:29 pm
-
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.
-
+5%
-
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...
-
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.
-
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.
-
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?
-
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.
-
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^^^
-
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.
-
Could we implement something like this for secure login.
https://www.grc.com/sqrl/sqrl.htm
-
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
-
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
+5%
-
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).
-
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.
-
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.
-
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.
Exactly! It makes many transactions simple.
-
+5%
-
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.
In what way is multisig used on openbazaar now? If it works like an escrow service, then it probably won't be that much different from their point of view, other than being on a different chain/wallet/api. Also the end user probably won't notice the underlying mechanics, just as long as it works.
So anybody have any idea how the multi-sig fits in the design of openbazaar?
-
Here is another specialization of multisig beyond the escrow-specific one (and beyond the time-based one I have mentioned previously). Imagine an M-of-N multsig where one of the keys is special (designated the primary key). If the output simply lists the keys in order, it can be defined to be the first key. If the output is a pay-to-script style hash of the multisig script that has a deterministic way of sorting the N public keys, then the script would also need to include a number acting as an index into the sorted list of public keys to designate the primary key.
The balance would be spent in the regular multisig way except there would be an additional way to transfer the balance. A transaction that includes this special multisig balance as an input can do so with a signature for only the primary key (regardless of what M is) if the transaction includes an output which: has the exact same balance value as the sum of the balances for all of these special multisig inputs in the transaction; and pays to the exact same pay-to-script as all of the special multisig outputs being spent in the inputs of this transaction (which of course implies that all of those special multisig outputs being spent in this transaction need to share the same pay-to-script hash).
What this means is that these special multisig balances can be transferred by the holder of the primary private key alone, however this person can only transfer the balances in a way such that the same parties who had authorization to spend the money still have the same authorization to spend the money and no one new has gained authorization to spend the money. Keep in mind, additional funds would need to be included to pay the transaction fees since they could not come out of the special multisig balances without making the transaction invalid. The reason someone would bother transferring the funds in this manner would be to change the delegates they vote for. Furthermore, if these were BitAssets (ignore the fact that they do not vote for delegates for now) the transaction could be modified to designate the output to be a variable amount that automatically balances the special multisig inputs with added yield included. That way the primary private key holder (or a hacker who stole that key from a hot client) couldn't even steal the yields on the BitAssets; they would only have the power to change the votes.
The typical way I imagine this would be used would be with a 2-of-2 special multisig on balances meant to be held in cold storage. The primary key would be the one kept in the hot client. The secondary key would be generated on an offline computer with a live Linux environment, encrypted with a memorable passphrase, converted into a list of dictionary words, and stored (written down or printed) on a piece of paper which is kept in a fireproof safe at home. Users could then frequently update the votes with their balances (and avoid any possible inactivity fees) very easily using their hot client for a tiny cost of a transaction fee, but would not be able to spend the money to another account directly from the hot client, which means someone who hacked their computer would also not be able to steal their funds. If the user wanted to transfer some of the money into their "checking account" so they can spend it, they would need to get out the paper backup, boot the live Linux environment, do the offline transaction signature, and go through the whole process one needs to go through with Bitcoin (hopefully user-friendly tools can eventually make this very straightforward).
-
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.
Exactly! It makes many transactions simple.
I am beginning to see the beauty of the solution. Less is more. +5%