Benefits of multisig usage? | Bitcointalksearch.org

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Quote from: kjj on September 29, 2012, 11:15:11 PM

Quote from: nimda on September 29, 2012, 10:53:13 PM

Quote from: kjj on September 29, 2012, 10:49:40 PM

Quote from: cunicula on September 29, 2012, 10:23:29 PM

Quote from: kjj on September 29, 2012, 10:20:24 PM

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

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?

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: nimda on September 29, 2012, 10:53:13 PM

Quote from: kjj on September 29, 2012, 10:49:40 PM

Quote from: cunicula on September 29, 2012, 10:23:29 PM

Quote from: kjj on September 29, 2012, 10:20:24 PM

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

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.

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Quote from: kjj on September 29, 2012, 10:49:40 PM

Quote from: cunicula on September 29, 2012, 10:23:29 PM

Quote from: kjj on September 29, 2012, 10:20:24 PM

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

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.

kjj

legendary

Activity: 1302

Merit: 1026

Quote from: cunicula on September 29, 2012, 10:23:29 PM

Quote from: kjj on September 29, 2012, 10:20:24 PM

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

Okay. Awareness of time would be a useful feature.

And a huge can of worms...

cunicula

legendary

Activity: 1050

Merit: 1003

Quote from: kjj on September 29, 2012, 10:20:24 PM

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

Okay. Awareness of time would be a useful feature.

kjj

legendary

Activity: 1302

Merit: 1026

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.

cunicula

legendary

Activity: 1050

Merit: 1003

Quote from: etotheipi on September 29, 2012, 09:45:40 PM

Quote from: cunicula on September 29, 2012, 09:42:22 PM

(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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: cunicula on September 29, 2012, 09:42:22 PM

(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.

cunicula

legendary

Activity: 1050

Merit: 1003

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)

HostFat

staff

Activity: 4270

Merit: 1209

I support freedom of choice

Can it be somehow useful with the mental poker?

Poker and the shared pot at the table in a decentralised network
https://bitcointalksearch.org/topic/poker-and-the-shared-pot-at-the-table-in-a-decentralised-network-1487

grazcoin

sr. member

Activity: 284

Merit: 250

Quote from: ildubbioso on September 15, 2012, 07:04:27 PM

Quote from: etotheipi on September 15, 2012, 02:04:38 PM

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).

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

There is already an open source remote solution implemented for this case in https://bitcointalksearch.org/topic/alpha-double-signed-wallet-with-a-patternlock-107074 [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

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: Andrew Vorobyov on September 29, 2012, 04:05:07 PM

Quote from: cbeast on September 15, 2012, 01:42:03 PM

n-of-(2n-1)

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.

Andrew Vorobyov

hero member

Activity: 558

Merit: 500

Quote from: cbeast on September 15, 2012, 01:42:03 PM

n-of-(2n-1)

What is it good for?

szuetam

sr. member

Activity: 377

Merit: 253

Quote from: etotheipi on September 16, 2012, 10:24:23 AM

Quote from: szuetam on September 16, 2012, 09:31:53 AM

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 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 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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: szuetam on September 16, 2012, 09:31:53 AM

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 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 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

).

szuetam

sr. member

Activity: 377

Merit: 253

Quote from: etotheipi on September 15, 2012, 10:11:29 PM

Quote from: nimda on September 15, 2012, 10:03:37 PM

Escrow is a great one:
Alice wants to buy a burger (shipped by priority mail Tongue

) 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 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.

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.

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Quote from: etotheipi on September 15, 2012, 10:11:29 PM

Quote from: nimda on September 15, 2012, 10:03:37 PM

Escrow is a great one:
Alice wants to buy a burger (shipped by priority mail Tongue

) 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 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

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

Quote from: nimda on September 15, 2012, 10:03:37 PM

Escrow is a great one:
Alice wants to buy a burger (shipped by priority mail Tongue

) 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 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.

nimda

hero member

Activity: 784

Merit: 1000

0xFB0D8D1534241423

Escrow is a great one:
Alice wants to buy a burger (shipped by priority mail Tongue

) 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.

etotheipi

legendary

Activity: 1428

Merit: 1093

Core Armory Developer

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).

Quote from: ildubbioso on September 15, 2012, 07:04:27 PM

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

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.

Topic: Benefits of multisig usage? (Read 1812 times)