[coinb.in] Open Source, Multi Signature, HD Wallet, SegWit/Bech32 and more!

[Abdussamad]

How does your mediation service work? Specifically:

- Does your 1% fee apply to every transaction or only those transactions involving disputes?

- bitrated has a field where you can enter a transaction agreement or contract that specifies, among other things, what the modes of payment will be and what proof of payment must be provided in the event of a dispute. There is no such field on coinb.in. So how would you decide what to do in the event of a dispute?

Hey,

As it stands, the 1% fee would only be applied to those transactions involving disputes.

Most users here seem to make an agreement and sign it with their PGP key in the event a dispute arises, a few other users will get in touch first. Saying that, I suppose a possible solution could be to have users create a message/agreement and sign it (in the browser) with their corresponding private key and then that could be used by the mediator if their is a dispute.

Do you have suggestions or preferences yourself? (or anybody else?)

Easiest solution would be that the buyer and seller come to an agreement and email it to you. You verify receipt by replying with a quote.

Multisig is hard enough as it is. I think if you asked people to sign messages with private keys they would just blank out

[1714171847]

1714171847

[1714171847]

1714171847

[1714171847]

1714171847

[1714171847]

1714171847

[OutCast3k]

- snip -

Easiest solution would be that the buyer and seller come to an agreement and email it to you. You verify receipt by replying with a quote.

Multisig is hard enough as it is. I think if you asked people to sign messages with private keys they would just blank out

I tend to agree, I think I'll just drop a little message explaining they should contact the mediator first.

Thanks for the feedback

[OutCast3k]

OutCast3K, thank you, the code is neat!

I wish you the best, along with a tip

Good to hear you find the project useful!

Many thanks for the tip

[jcrubino]

Does the multisig address function accept mixed compressed and uncompressed pubkeys?

[unick]

this is great! keep up the good work.

* I think it would great to explain the process and concepts in more detail on the site. What is a redeem script?

* say I want to implement the following: pay 0.01 BTC to address #A12 if the year in the timestamp of the last block is equal to 2014. what would it take to make this work?

* btw, the link on the site to your profile is broken. I think you want this: https://bitcointalk.org/index.php?action=profile;u=34834  

Thanks for the feedback

You're right, I will defiantly add more information to the site about the process shortly.

A "redeem script" contains 2 pieces of information, the public keys and the minimum number of signatures required to use it as a spendable input. It is also used to generate the multi signature address itself. There should be some information on the bitcoin wiki about this, but I will also add it to the site shortly.

I believe its possible to manipulate the timestamp of the transaction in the way you've requested, although I will need to do a little bit of testing first.

Thanks for pointing out the broken link, I've since fixed it.

What if I lose the redeemScript? is there a way to retrieve it or regenerate it?  If I don't have the RedeemScript, is it still possible to spend the coins given you have the required keys to "unlock" the transaction?

[RagnarDanneskjold]

this is great! keep up the good work.

* I think it would great to explain the process and concepts in more detail on the site. What is a redeem script?

* say I want to implement the following: pay 0.01 BTC to address #A12 if the year in the timestamp of the last block is equal to 2014. what would it take to make this work?

* btw, the link on the site to your profile is broken. I think you want this: https://bitcointalk.org/index.php?action=profile;u=34834  

Thanks for the feedback

You're right, I will defiantly add more information to the site about the process shortly.

A "redeem script" contains 2 pieces of information, the public keys and the minimum number of signatures required to use it as a spendable input. It is also used to generate the multi signature address itself. There should be some information on the bitcoin wiki about this, but I will also add it to the site shortly.

I believe its possible to manipulate the timestamp of the transaction in the way you've requested, although I will need to do a little bit of testing first.

Thanks for pointing out the broken link, I've since fixed it.

What if I lose the redeemScript? is there a way to retrieve it or regenerate it?  If I don't have the RedeemScript, is it still possible to spend the coins given you have the required keys to "unlock" the transaction?

Yes you can regenerate the redeem script.  You cannot lose your multisig address; you can lose some privkeys - as long as you [or your Agents] saved the total number required to sign.  Best to move & back them up securely [pref using thumbdrive & a browser on a computer that has never connected to the internet ever]

[RagnarDanneskjold]

Does the multisig address function accept mixed compressed and uncompressed pubkeys?

This multisig script does not accept mixed or uncompresed.  [the multisig "function" is not exclusive to this script - you can do multisig txs other ways, but they are not cool]. You can generate new uncompressed keys using this also.  You do not want to sign with a wallet address that's been used or is/was/might ever be holding funds.  You will have to expose your privkey and create unnecessary vulnerabilities to your existing flimsy security efforts.  Better to generate new pubkeys just for controlling your multisig.

[Peter Todd]

Enter the uncompressed public keys of all the participants, to create a multi signature address. Maximum of 20 allowed.

This is incorrect actually. While the underlying CHECKMULTISIG opcode can support up to 20 pubkeys, P2SH has an additional limit of 520 bytes for the scriptPubKey. That gives a size-dependent maximum of 15 compressed pubkeys, and just 7 with the larger uncompressed keys.

[RagnarDanneskjold]

Enter the uncompressed public keys of all the participants, to create a multi signature address. Maximum of 20 allowed.

This is incorrect actually. While the underlying CHECKMULTISIG opcode can support up to 20 pubkeys, P2SH has an additional limit of 520 bytes for the scriptPubKey. That gives a size-dependent maximum of 15 compressed pubkeys, and just 7 with the larger uncompressed keys.

Perhaps I'm missing something - it seems to work fine for me using 20 uncompressed [dont recall if I've tried having all 20 required signers yet - trying now].  I understand this code somewhat[not enough]; Please elaborate if possible & let me know what lines are P2SH - I thought this was a bit different.  I'm digging through it blindly.

Incidentally, i thought the p2sh git referenced "+22 signatures"
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

[Peter Todd]

Perhaps I'm missing something - it seems to work fine for me using 20 uncompressed [dont recall if I've tried having all 20 required signers yet - trying now].  I understand this code somewhat[not enough]; Please elaborate if possible & let me know what lines are P2SH - I thought this was a bit different.  I'm digging through it blindly.

Incidentally, i thought the p2sh git referenced "+22 signatures"
https://github.com/bitcoin/bips/blob/master/bip-0016.mediawiki

That's "signature operations", not signatures. SigOps is just a metric used to restrict the amount of CPU time processing a block takes as an anti-DoS measure - it's got nothing to do with the actual number of signatures.

You'll find you can create that P2SH address with the Bitcoin RPC interface, but you can't actually spend from it succesfully. Kinda misleading really - if you could do up a patch to fix that and make createmultisigaddress raise an error that'd be great.

[sullitf]

Really great work here OutCast!

I'm working on a project to create a multisig service and need to create keys server-side without exposing them to end users.  My first thought was to refactor your work to run in a node.js server.  Does this seem like a good solution, and if so have you looked into doing anything similar? 

Ultimately I need to be able to create key pairs, validate user public keys, and create/sign multisig addresses.  For signing I am planning to have users partially sign a multisig transaction with their keys and then send that to my server for final signature and broadcasting from the server.  This would likely mean needing to confirm partially signed transactions sent to the server, though I haven't looked into the feasibility of that yet.  Does your code already support partial signing and validation?

[waxwing]

Enter the uncompressed public keys of all the participants, to create a multi signature address. Maximum of 20 allowed.

This is incorrect actually. While the underlying CHECKMULTISIG opcode can support up to 20 pubkeys, P2SH has an additional limit of 520 bytes for the scriptPubKey. That gives a size-dependent maximum of 15 compressed pubkeys, and just 7 with the larger uncompressed keys.

Peter,
Is there any prospect in the future for these limits to be increased? It seems to me there are quite a lot of applications for larger than 15.
Or if that just leads to unacceptably big transactions even with appropriate fees, is there some way that I haven't quite thought of to combine multisig keys to get bigger consensus mechanisms? Or is it possible to use some kind of Shamir's secret sharing idea? (I only know the idea vaguely, not sure how it would work in practice).

Btw, nice work on the site guys.

[Peter Todd]

Peter,
Is there any prospect in the future for these limits to be increased? It seems to me there are quite a lot of applications for larger than 15.
Or if that just leads to unacceptably big transactions even with appropriate fees, is there some way that I haven't quite thought of to combine multisig keys to get bigger consensus mechanisms? Or is it possible to use some kind of Shamir's secret sharing idea? (I only know the idea vaguely, not sure how it would work in practice).

Btw, nice work on the site guys.

I'm at the Financial Crypto conference right now and actually just talked to a guy who claims to know of a researcher who has come up with a n-of-m threshold signature scheme that is compatible with existing Bitcoin signatures. Hopefully this will pan out - if it does you'll be able to do secure multisig without a single-point-of-failure (as Shamir's secret sharing does) with transactions and addresses that look identical to standard ones and are the same size as standard transactions. I didn't ask if there were any limits on how many keys could be combined, but there probably aren't.

[waxwing]

Peter,
Is there any prospect in the future for these limits to be increased? It seems to me there are quite a lot of applications for larger than 15.
Or if that just leads to unacceptably big transactions even with appropriate fees, is there some way that I haven't quite thought of to combine multisig keys to get bigger consensus mechanisms? Or is it possible to use some kind of Shamir's secret sharing idea? (I only know the idea vaguely, not sure how it would work in practice).

Btw, nice work on the site guys.

I'm at the Financial Crypto conference right now and actually just talked to a guy who claims to know of a researcher who has come up with a n-of-m threshold signature scheme that is compatible with existing Bitcoin signatures. Hopefully this will pan out - if it does you'll be able to do secure multisig without a single-point-of-failure (as Shamir's secret sharing does) with transactions and addresses that look identical to standard ones and are the same size as standard transactions. I didn't ask if there were any limits on how many keys could be combined, but there probably aren't.

Thanks. I realised after I wrote that that Shamir shares *secrets* not signatures so that's no good (I guess the clue was in the title ). Could something be hacked together with CoinSwap?

[Peter Todd]

Thanks. I realised after I wrote that that Shamir shares *secrets* not signatures so that's no good (I guess the clue was in the title ). Could something be hacked together with CoinSwap?

I don't think so.

The threshold sig stuff sounds pretty far along; for now 15/20 isn't such a bad limitation IMO.

[waxwing]

Thanks. I realised after I wrote that that Shamir shares *secrets* not signatures so that's no good (I guess the clue was in the title ). Could something be hacked together with CoinSwap?

I don't think so.

The threshold sig stuff sounds pretty far along; for now 15/20 isn't such a bad limitation IMO.

I agree. But no one except Eligius is accepting more than 3 right?

[Peter Todd]

I agree. But no one except Eligius is accepting more than 3 right?

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

[waxwing]

I agree. But no one except Eligius is accepting more than 3 right?

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

Thanks for the tip. Will do

Edit: actually before I go through all that ... doesn't this mean it won't work?:

Code:

bool IsStandard(const CScript& scriptPubKey, txnouttype& whichType)
{
    vector<valtype> vSolutions;
    if (!Solver(scriptPubKey, whichType, vSolutions))
        return false;

    if (whichType == TX_MULTISIG)
    {
        unsigned char m = vSolutions.front()[0];
        unsigned char n = vSolutions.back()[0];
        // Support up to x-of-3 multisig txns as standard
        if (n < 1 || n > 3)
            return false;
        if (m < 1 || m > n)
            return false;
    }

    return whichType != TX_NONSTANDARD;
}

?

[Peter Todd]

I agree. But no one except Eligius is accepting more than 3 right?

Actually no! P2SH doesn't have an explicit limitations beyond the 520byte P2SH redeemScript limit, and more importantly the 500-byte scriptSig limit for IsStandard() transactions, so n and m just need to fit within that. Try it!

Thanks for the tip. Will do

Edit: actually before I go through all that ... doesn't this mean it won't work?:

Code:

bool IsStandard(const CScript& scriptPubKey, txnouttype& whichType)
{
    vector<valtype> vSolutions;
    if (!Solver(scriptPubKey, whichType, vSolutions))
        return false;

    if (whichType == TX_MULTISIG)
    {
        unsigned char m = vSolutions.front()[0];
        unsigned char n = vSolutions.back()[0];
        // Support up to x-of-3 multisig txns as standard
        if (n < 1 || n > 3)
            return false;
        if (m < 1 || m > n)
            return false;
    }

    return whichType != TX_NONSTANDARD;
}

?

Nope - ask yourself if a P2SH output matches that code. Also ask yourself what the code path is that evaluates scriptSigs for standardness.

[waxwing]

Nope - ask yourself if a P2SH output matches that code. Also ask yourself what the code path is that evaluates scriptSigs for standardness.

Cool I managed to do 3 of 4 via an electrum server.

Many thanks for the edumacation

Not quite yet capable of figuring it out from the source; but will try to follow your hints at some point...