bgroff at lavabit.com [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2011-06-16 to 2011-09-19
💬 Posted a total of 13 messages
📚 Participated in the following categories: Bitcoin-development, PULL
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 02:19:01

- reply

📅 Original date posted:2011-08-26
🗒️ Summary of this message: The proposal to whitelist the basic CHECKMULTISIG form seems uncontroversial, but there are some disadvantages to using it, such as the limit of 1000 in a block and the complexity of using HASH160 based addresses. The suggestion is to focus on a more general case to make it easier to validate and innovate with new scripts.
📝 Original message:>> Whitelisting the basic CHECKMULTISIG form (assuming it can be made to
>> work) seems uncontroversial, why not do it today?
>
> That seems like the right way forward.
>
> I just wrote a unit test and stepped through the CHECKMULTISIG code to
> see exactly what the bug is, and the offending line is:
> 797 int isig = ++i;
> 798 i += nSigsCount;
>
> It should be just int isig = i;
>
> The result is CHECKMULTISIG expects one extra item on the stack, so
> the workaround would be a standard transaction type of the form:
>
> scriptSig: OP_0 sig1...m
> scriptPubKey: m pubkey1...n n OP_CHECKMULTISIG
Right, that is the workaround in pull 319.
There is another disadvantage to CHECKMULTISIG - you currently can only
have 1000 of these in a block. This is because a CHECKMULTISIG is counted
as 20 sigop operations in GetSigOpCount, and you can have a maximum of
20000 sigops in a block (MAX_BLOCK_SIGOPS). This is in CheckBlock so
won't change anytime soon.
If you want to use HASH160 based addresses, CHECKMULTISIG looks even less
attractive. The shortest script with CHECKSIG is something like:
0
OVER 2SWAP CHECKSIG SWAP HASH160 {} EQUAL BOOLAND ADD // n times
m GREATERTHANOREQUAL
( thanks to coblee
https://gist.github.com/39158239e36f6af69d6f#gistcomment-47017 )
I think this is actually as short as the shortest you can do with
CHECKMULTISIG.
Another issue that came up during pull 319 discussion is whether to
support more general cases or more specific cases. For example, should we
optimize for the 1-of-2, 2-of-2 and 2-of-3 cases or should we just have
one script template for all m-of-n? I would propose focusing on a more
general case for the following reasons:
* It is easier to validate one general algorithm than an expanding set of
special-purpose functions. For example, I think the most people on this
list can validate the coblee script above for all n and m, but faced with
a bunch of special purpose scripts they might miss a bug.
* We don't have to expose the most general cases to the API, but it would
be nice if we didn't have to keep changing IsStandard as people find use
cases for 2-of-4, etc. With IsStandard remaining narrow, innovation with
new scripts is stifled because most client won't mine or relay
non-standard transactions.
* It would be less work for third-party software to track this
(blockexplorer, android wallet).
--
Bobby Groff

2023-06-07 02:18:39

- reply

📅 Original date posted:2011-08-24
🗒️ Summary of this message: Gavin Andresen proposes multi-signature transactions as the fastest path to secure Bitcoin wallets, with a draft proposal for standard transactions and new Bitcoin addresses.
📝 Original message:"Gavin Andresen" <gavinandresen at gmail.com> wrote:
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
>
> To organize this discussion: first, does everybody agree?
I agree. For example, a corporate wallet can require threshold signatures
to disburse. Or for personal use you can have a couple of additional
keys, one stored on a secure device for confirmation and one offline as
emergency backup if you lose your secure device.
...
> I've been trying to get consensus on low-level 'standard' transactions
> for transactions that must be signed by 2 or 3 keys; current draft
> proposal is here:
> https://gist.github.com/39158239e36f6af69d6f
> and discussion on the forums here:
> https://bitcointalk.org/index.php?topic=38928.0
> ... and there is a pull request that is relevant here:
> https://github.com/bitcoin/bitcoin/pull/319
For context - I am the author of the latter.
> I still think it is a good idea to enable a set of new 'standard'
> multisignature transactions, so they get relayed and included into
> blocks. I don't want to let "the perfect become the enemy of the
> good" -- does anybody disagree?
>
> The arguments against are that if the proposed standard transactions
> are accepted, then the next step is to define a new kind of bitcoin
> address that lets coins be deposited into a multisignature-protected
> wallet.
>
> And those new as-yet-undefined bitcoin addresses will have to be 2 or
> 3 times as big as current bitcoin addresses, and will be incompatible
> with old clients.
Incompatible at the UI level, but not at the block chain level. Changing
the block chain rules will be quite an undertaking. You will have to set
a block number for the rule change a few months in advance and will have
to get agreement from the pools. I think it is important to increase
trust in the bitcoin ecosystem sooner than that. The current flat
exchange rate and difficulty may be a signal that people are getting risk
averse.
> So, if we are going to have new releases that are incompatible with
> old clients why not do things right in the first place, implement or
> enable opcodes so the new bitcoin addresses can be small, and schedule
> a block chain split for N months from now.
>
> My biggest worry is we'll say "Sure, it'll only take a couple days to
> agree on how to do it right" and six months from now there is still no
> consensus on exactly which digest function should be used, or whether
> or not there should be a new opcode for arbitrary boolean expressions
> involving keypairs. And people's wallets continue to get lost or
> stolen.
That is my worry too. We already have working code for this (pull 319),
and the addresses are not so long as to be unusable. I hope we can move
forward on the existing code and in parallel move forward on block chain
rule proposals at an agreed upon block number.
--
Bobby Groff

2023-06-07 02:18:29

- reply

📅 Original date posted:2011-08-26
🗒️ Summary of this message: Gavin Andresen proposes a new Bitcoin script that allows for more complex transactions, but there are concerns about a bug in CHECKMULTISIG and the necessity of some of the proposed cases.
📝 Original message:"Gavin Andresen" <gavinandresen at gmail.com> wrote:
> I wanted to talk about it now so there is rough consensus on what to
> put on the road map, and to get as many smart brains looking at the
> proposal and making it as good as possible. Current proposal is at:
> https://gist.github.com/39158239e36f6af69d6f
>
> I have two issues with it:
>
> 1) groffer reports that there's a bug in CHECKMULTISIG (pops too many
> arguments off the stack), so perhaps we should avoid using it at all.
> Fixing the bug would change its behavior, and is not an option because
> that would cause a blockchain split. We absolutely need unit tests and
> better documentation for how CHECKMULTISIG behaves (perhaps it is
> working as intended, and Satoshi just messed up the description of
> what it does in the comment).
>
> 2) How often will the 1-of-3 and 3-of-3 cases be used? I included them
> just for completeness, but perhaps they should be dropped for now so
> there is less code to write and test. I just don't imagine there are
> many cases where you have exactly three parties and 1-of-3 or 3-of-3
> are required to spend.
Here are some additional use cases:
* Long term lock funds, requiring signatures from 2 officers of a company
to disburse (2 of n for n between 3 and 20)
* Short term lock funds, with 2-factor auth to disburse and an additional
2 of n backup in case one of the factors is lost (2-of-2 OR 2-of-n)
* "Escrow" with the the two parties having to agree or one of two backup
observers helping in case of disagreement (2-of-2 OR 2-of-3 OR 2-of-3)
* An options contract where the outcome is triggered by a key being
broadcast: (Ks AND K1) OR (Kr AND K2) - s gets control of funds if K1 is
broadcast, r gets control if K2 is broadcast.

2023-06-07 02:10:22

- reply

📅 Original date posted:2011-08-07
🗒️ Summary of this message: Discussion on mining non-standard transactions and the importance of propagation. IsStandard part is uncontroversial and could be implemented quickly.
📝 Original message:> On Wed, Aug 3, 2011 at 2:10 AM, <bgroff at lavabit.com> wrote:
>> Thank you! Â (I think you mean 319 here)
>
> Correct.
>
>> With Eligius mining !IsStandard transactions and probably other pools
>> open
>> to the idea, I am hopeful that we can quickly get 30%+ of mining power
>> to
>> upgrade, which means that we could still mine these in a reasonable time
>> frame (under 1 hour).
>
> It's not just a matter of mining power, it's also a question of
> propagation. Matt and I tried to perform a non-standard transaction
> weeks ago and weren't able to get in mined after many hours. (we
> eventually double spent the input with a normal transaction in order
> to make it go away, interestingly one point about non-propagating txn
> is that they're extra vulnerable to double spending by a standard txn,
> as the non-standard one won't preclude the propagation of the standard
> one)
Right, the user would have to connect directly to miners accepting
non-standard transactions.
> From discussion on IRC it seemed clear enough that the current focus
> on maturity/bugfixes is probably going to delay your full patch, but
> the IsStandard part is uncontroversial and could go in quickly.
With the latest high profile security breaches, I am hoping that the whole
things can be pulled relatively soon. Building secure deposit systems
will improve trust in the ecosystem.
I've included a significant amount of unit tests to "pay" for the
additional feature, and I can add more if needed.
--
Bobby Groff

2023-06-07 01:55:48

- reply

📅 Original date posted:2011-06-16
🗒️ Summary of this message: Bitcoin's new "escrow" feature allows multiple parties to control coins, reducing trust and eliminating single points of failure in transactions. Feedback is welcome.
📝 Original message:I have a pull request here:
https://github.com/bitcoin/bitcoin/pull/319
>From the README:
Bitcoin "escrow" are coins that are under the control of multiple
parties. The initial implementation allows n parties to vote, with
k good signatures needed (k <= n).
This eliminates single points of failure and reduces the trust required
in many transaction use cases.
Use cases include Escrow (without trusting the escrow agent with the
coins), immediate payment and funds locked with multi-party signatures.
This was inspired by https://forum.bitcoin.org/index.php?topic=8821.0 and
https://forum.bitcoin.org/index.php?topic=4723.msg68804 .
Feedback on the pull is very much appreciated.

2023-06-07 01:38:35

- reply

📅 Original date posted:2011-06-17
🗒️ Summary of this message: Critical issues in Bitcoin include scaling-up problems, wallet security, and the need for a unit testing framework. Multi-signature coins may help with security.
📝 Original message:> 1) Scaling-up issues, like disconnections when downloading the block
> chain.
>
> 2) Wallet security.
>
> 3) Unit testing framework. There was a PULL that had the start of
> boost unit tests; I think that is a critical need, along with a good
> suite of test cases.
I agree that these are critical and I'd love to help, especially on #2 and
#3. #3 will, by necessity, include a thorough review of the code, which
may uncover latent issues.
I think that for #2 it would also be good to publish a "Best security
practices" document to try and educate the user base.
> Those are the big issues for me. Anything that slows those down I'm
> going to ignore (example: love the idea of escrow transactions, but I
> do NOT want to add nifty new features when we're having trouble
> keeping the features we're using now working properly).
That is understandable. However, something to think about later is that
multi-signature coins can help with #2, even with compromised end-user
machines.
--
Bobby Groff

2023-06-07 01:37:41

- reply

2023-06-07 01:21:24

- reply

2023-06-07 01:21:03

- reply

📅 Original date posted:2011-06-22
🗒️ Summary of this message: Proposal for a new type of bitcoin address that requires m of n signatures to spend. A use-case scenario for a 2-of-3 multisign address is presented.
📝 Original message:Gavin wrote:
> It would be spiffy to publish a new type of bitcoin address that is an
> "m of n address", that anybody could pay into, but would require m of
> n signatures to spend. Publishing a really really long address with
> all n public keys would work.
Here's a strawman use-case for a browser centric flow for a 2-of-3 scenario.
Funding:
* User is on Merchant site on the checkout page
* User selects a transaction Observer (I'm trying to get away from using
the word escrow, because the funds are not held by the third party)
* Merchant redirects to the Observer, passing in the Merchant's payout
address
* The User enters User's address
* Observer presents multisign address
"2,merchant-addr,user-addr,observer-addr" and terms and conditions - i.e.
under what circumstances the Observer will sign
* User copy/pastes the multisign address to their bitcoin client and sends
funds
* After some blocks go by, merchant ships
Redemption:
* Merchant reminds User to release funds
* User creates a partial tx paying out to merchant-addr and emails or
copy-pastes to Merchant
* Merchant signs and publishes the tx
Funding requires two pastes and redemption requires one. A browser
plug-in would reduce the User effort to a couple of confirmatory clicks -
"do you want to send X BTC to Merchant Y with Observer Z?" and "do you
want to release X BTC to Merchant Y?".
--
Bobby Groff

2023-06-07 01:20:59

- reply

📅 Original date posted:2011-06-22
🗒️ Summary of this message: A proposed method for reducing address length in Bitcoin transactions may not be practical due to the need to distribute pubkeys ahead of time.
📝 Original message:> Gavin said:
>> 3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL
>> CHECKMULTISIGVERIFY
On second thought, I'm not sure this is workable. You would have to
distribute each party's pubkey ahead of time, otherwise you run the risk
that a party falls off the face of the earth and then you can't provide
the pubkeys to have hash(pubkey1+2+3) EQUALVERIFY.
If you have to distribute the pubkeys ahead of time, then the reduction in
address length becomes moot.
So it seems to be either distribute the pubkeys or distribute the
hash160(pubkey)'s.
--
Bobby Groff

2023-06-07 01:20:56

- reply

📅 Original date posted:2011-06-22
🗒️ Summary of this message: Gavin Andresen proposes a new type of bitcoin address, "m of n address", requiring m of n signatures to spend, and suggests a new transaction type.
📝 Original message:Gavin said:
> It would be spiffy to publish a new type of bitcoin address that is an
> "m of n address", that anybody could pay into, but would require m of
> n signatures to spend. Publishing a really really long address with
> all n public keys would work.
I currently have 2,ADDR1,ADDR2,ADDR3 (2-of-3 example) as this new address
type.
>
> It would be great if the "higher level protocol" for pay-to-escrow was
> just get a bitcoin address via https (or other secure mechanism), like
> we do now for pay-to-single-party. Where the person you're paying has
> their own mechanisms for generating or fetching/authenticating the
> public keys, and knows which bitcoin addresses they've published.
Agreed.
> All of which makes me wonder if the straightforward "n PUBKEYS m
> CHECKMULTISIG" transaction type is the right thing to do.
> Following the pattern of our standard DUP HASH160 etc. transaction
> type, maybe 2 of 2 and 2 of three should be:
>
> 2DUP ADD HASH160 ...hash(pubkey1+2)... EQUALVERIFY 2 2 ROLL
> CHECKMULTISIGVERIFY
> 3DUP ADD ADD HASH160 ...hash(pubkey1+2+3)... EQUALVERIFY 2 3 ROLL
> CHECKMULTISIGVERIFY
>
> Spending those transactions would mean putting the m signatures and
> the n public keys in the TxIn, but sending funds you'd only need the
> hash of the sum of the public keys.
This is similar to the way the current implementation works. It uses
HASH160, but there's no attempt to save space by hashing the sum of the
pubkeys. The major advantage of summing is shorter address for the end
user to copy-paste. The disadvantage is the need for long term storage of
the key set so you know what keys to sign with.
> --
> Gavin Andresen
> http://clearcoin.com/
--
Bobby Groff

2023-06-07 01:20:40

- reply

📅 Original date posted:2011-06-22
🗒️ Summary of this message: The term "escrow" should not be used for all multsig transactions. Instead, Bobby Groff suggests using "multisign" or "multipay" transactions.
📝 Original message:> Oh, one other thing - as you point out yourself, escrow is only one use
> case
> for multsig transactions. So I suggest you don't use the word in the
> patch.
> Maybe instead call them multisign or multipay transactions.
Agreed. I'll rename to multisign.
--
Bobby Groff

2023-06-07 01:20:30

- reply