Bitcoin Forum

Could someone list benefits of multisig usage?
What exactly we could do?

I think Satoshi Nakamoto and the Bitcoin Devs will earn a Nobel Prize for the development of 2-of-2, 3-of-3, n-of-(2n-1), and m-of-n escrows.

Simply put:  regular bitcoins only need to be signed by one address (private key) in order to be spent.  If coins are encumbered in a multi-signature transaction, it requires multiple signatures -- perhaps multiple, different, geographically separated computers.  Or multiple people.  Perhaps 2 out of 3 owners of a company will need to supply signatures to send the coins.

There's a very rich set of functionality that can be enabled through multi-sig.  Escrows, contracts, I can't even fathom all of them myself.  But the key is that there is no longer a single point of vulnerability for multi-signature-required coins.  An attacker will have to compromise multiple computers/people/nodes/servers in order to steal those coins.

EDIT: there's other features of multi-sig that might actually make it easier to spend [allow any one of multiple people to access them], or produce escrow such that defending against an attacker is not exactly the intent.  But I expect that the most common use-case will be for regular users to split their private keys between two devices (such as primary computer and smartphone), such that both devices need to be compromised for the attacker to get the coins (and the user will have to access both devices to use it).

Unfortunately, all this comes with a lot of extra complexity.  But it's up to application developers (like me), to try to make it useful for non-Bitcoin-experts.  And I look forward to digging into it after Armory becomes beta.

And I'm sure many appreciate your dedication.

So, soft is not ready, I know it, but technically it is possible now right?
Is it possible to make transactions like this time or block dependent?
Example transaction:
Person A borrows from me 1000 BTC but as insurance he have persons C, D, E who pays 20 BTC each to ensure me that person A is worth my trust.
Person A have to send me back 1010BTC (with interest) before next Friday (block number), and if he will not, automatically C, D, E will lost their 60BTC and I will get that.
If A will send me BTC back in time C, D, E will get their money back.
Is it technically possible now?

If time relation is not possible, we could engage some third party as time responsible and trustworhy company with some satoshi-s profit.

And another Q:
In addition to previous scenario, could we obligate C, D, E to keep 500BTC till Friday on their specific addresses, and if they won't do that if one of them will default others will auto-transfer their 500BTC to me.
Do we have to engage additional institutions to track C, D, E wallets value?

This scenario lest me to lend money without takeing risk, makeing my profit shure in given time, and all risk is dived for C, D, E.

What you would say for that auto dept mechanism?

It's off topic. I'm just looking for answ. for tech. questions, if idea is worth discussion - I'll start new thread.

What if one loses his smartphone? Nowadays how does it works with the double authentication in this case?

I just want to keep it quite simple, in this case he will just lost others money so they have to trust others, but we can increase number of trust persons CDE to larger one CDEFGHIJ.. and give a rules like two can lost their insurance level etc making it more and more complicated.

Benefit from that is that me could make use of my amount of money without taking risk, or manage risk without additional cost of risk put in banking system (or lower risk replacing banking system with more transparent bitcoin system).

But It's not thread about this it was just example to get some tech question.
I'm still looking for answer over forum.

There's lots of different things that are possible, including time-locked transactions which are similar to what you asked about.  But the exact mechanics of how these things work in the bitcoin world can be kind of complicated, so I'll simply refer you googling (there's lots of information out there).


The most straightforward way is that the transactions will be encumbered with an [(A and B) or C] multisig requirement.  A is your primary computer, B is your smartphone, C is in a safety-deposit box that is very inconvenient, but accessible if you need it. 

Actually, the way Armory will do it will just be (A and B), and you will print off paper backups of both and keep those in your safety-deposit box.  You never want to have any coins floating without a secondary backup like that.

Escrow is a great one:
Alice wants to buy a burger (shipped by priority mail :P) from Bob, but they don't trust each other, and neither one wants to send first. They both trust Eugene, though. Alice creates a 1-of-2 transaction which can pay to Bob once signed by either Alice or Eugene. The three scenarios:
1. Alice creates the transaction; Bob sends burger. Alice signs the transaction and Bob gets his money.
2. Alice creates the transaction; Bob doesn't send the burger. Eugene sees that Bob is a scammer and doesn't sign the transaction; no money changes hands.
3. Alice creates the transaction; Bob sends the burger. Alice refuses to pay. Once Eugene is satisfied with Bob's proof that he sent the burger, Eugene signs the transaction. Bob gets paid.

It's possible to do this with a 2-of-2 transaction between buyer and seller.  Then both parties have to find an agreeable resolution before anyone gets the money.  Thus, neither party has any incentive to try scamming the other.  However, there's a risk that the coins are locked forever if there is no resolution, so I had started a thread (https://bitcointalk.org/index.php?topic=75481.0) to discuss how it might be done without a third-party.  It's complicated, but it works if you include "risk deposits."  I think most of the complexity can be hidden under-the-hood, though. 

In most cases, you should just use a third-party.  It's very cheap for third-parties to operate because they never really "handle" the money themselves.  But one of the beauties of Bitcoin is that you can have the bitcoin network itself act as your "trusted third-party" in cases where privacy is critical, or the two parties can't agree on a trustworthy third-party.

There is the oft-quoted idea in cryptography that "anything which can be done with a trusted third party can be done without one." We're getting there :)

We can ad time limit to get agreement between them, if not cash will go to charity, ad some cash guarantee deposit of seller.
I have lots of ideas.

Just to pre-empt you, since you're asking about this now but the concepts have been discussed for 2 years now, start with what's already been discussed.  First, read through the examples on the Bitcoin Contracts (https://en.bitcoin.it/wiki/Contracts) page.  There's lot of examples mixing multi-sig with locktime, etc.  Also, for the specific buyer-seller escrow case, read through the thread that I started with Gavin (https://bitcointalk.org/index.php?topic=75481.0) to discuss exactly that -- create ways for two-party escrow without risk of coins being lost forever.

The buyer-seller problem is complicated because the situation is not symmetric, and dealing with the asymmetries requires some care to not give either party an advantage to being a dick.  I'd appreciate if you read and responded in those threads with your ideas, so that progress can continue ironing them out (but of course, read them first :)).

THX for links, I'll do it at night.
:)

What is it good for?

Consider the various values of n:

n=1:  1-of-1
n=2:  2-of-3
n=3:  3-of-5
n=4:  4-of-7
n=5:  5-of-9
...

It's any transaction with an odd number of public keys, and any majority subset of those signatures makes the transaction valid.  Democratic money:  perhaps 9 board members on a company all have their public keys in a 5-of-9 "wallet".  Any five signatures is enough to spend it.

There is already an open source remote solution implemented for this case in https://bitcointalk.org/index.php?topic=107074.0 [Double signed wallet with a patternlock] where the phone owner can generate a secondary key which is kept on a remote server (and on paper backup). An attacker must have both the device and the remote server secret to get the coins.
If the smartphone is lost, the one that finds the phone cannot spend the coins. The original owner of the phone on the other hand, can take her primary key from the paper backup and using the service (or the secondary key backup) move the funds to a new address.

Grazcoin

Can it be somehow useful with the mental poker?

Poker and the shared pot at the table in a decentralised network
https://bitcointalk.org/index.php?topic=1487.0

Can multisig be time dependent? Suppose I want rely on multisig so that sending my coins requires signatures from two devices.
However, I'm worried that I might misplace 1 of the 2 devices.

Can multisig require 2 of 2 signatures for the next 6 months and then default back to 1 of 2 signatures after the 6 month period expires?

This would make me feel comfortable using a smartphone as a source of 1 signature. Otherwise, it is just too easy to lose the smartphone.
(This can be resolved with backups, but I feel that backups are quite a nuisance from the user's perspective)

So is reverting to a previously-considered-insecure security model after 6 months, which is long enough for the user to forget about it.

Anyone who handles important documents/information makes copies.  They keep them in a safe place for when they need them.  Bitcoin private keys should be handled the same way.

But many people won't make copies. It is not helpful to tell stupid people they shouldn't be stupid. The consequences of idiocy can be mitigated through good design choices.

The reversion could be extended automatically for another six months every time a new 2 of 2 txn is signed. The point is that if a 2 of 2 txn doesn't happen for a long enough period, then at least 1 of the 2 factors is likely lost. I think most users would prefer insecurely stored coins to no coins at all.
 

The scripts have no notion of time, and this is for good reasons.

Maybe try 2-of-3, with an option to print and forget one of the keys.  That way, if the second device is lost, you can load that key up, recover all of the transactions that used it, and make new ones.

Okay. Awareness of time would be a useful feature.

And a huge can of worms...

Blocks have timestamps which need to be accurate within a few hours. Blockcount can also more or less work.

Yes, but the scripts do not.

Basically, transactions only depend on their order, specifically they must come after their inputs, and before their own double-spend attempt.  Adding a notion of time or block count would make it possible to have transactions that might be valid in one block, but not another, which could have cascading consequences and be a big ugly mess.  And that is only the most obvious problem, the one that we are aware of, there are probably plenty of others too.

Doesn't nLockTime make use of blockcount and timestamps?