"Gavin Andresen" 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 t
>> 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 i
On Fri, Aug 26, 2011 at 01:09:37PM +0200, Mike Hearn wrote:
> > On the github pull request I posted a general scheme that can convert
> > arbitrary
> > expressions over signature-checks (given in RPL notation) to bitcoin
> > scripts.
> > Maybe we can define an address type that encodes an express
> 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
> It seems to me the fastest path to very secure, very-hard-to-lose
> bitcoin wallets is multi-signature transactions.
Agreed.
That said I'm not sure it makes sense for payers to care about the
details of how somebody is protecting their wallets (which is what new
address types means). It's possi
> On the github pull request I posted a general scheme that can convert
> arbitrary
> expressions over signature-checks (given in RPL notation) to bitcoin scripts.
> Maybe we can define an address type that encodes an expression in RPL form
> (which
> should be more compact and more easily parsea
> 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.
What is the bug, exactly? Perhaps it can be worked around.
--
EMC VNX: the wo
A few years ago I wrote a least authority based set of filesystems named
MinorFs that worked closely together with AppArmor (suse/ubuntu) to give '
pseudo persistent processes' their own private but decomposable and
delegatable piece of filesystem storage:
http://www.linuxjournal.com/magazine/mino
8 matches
Mail list logo
