On Wed, Jul 16, 2014 at 10:56 AM, Jeremy wrote:
> Hey all,
> I had an idea for a new transaction type. The base idea is that it is
> matching on script hashes much like pay to script hash, but checks for one
> of N scripts.
This seems strictly less flexible and efficient than the Merkelized
Abstr
* the general cost of any network-wide change, versus P2SH which is
already analyzed by devs, rolled out and working
* the cost of updating everybody to relay this new transaction type,
whereas P2SH Just Works already
fair -- I think that there may be a big benefit realizable with this kind
of syst
In a system like bitcoin, where the system has to keep running, you
have to consider how to roll out upgrades, and the costs associated
with that.
* the general cost of any network-wide change, versus P2SH which is
already analyzed by devs, rolled out and working
* the cost of P2SH output is predic
Additional costs would be in terms of A) chance of user error/application
error -- proposed method is much simpler, as well as extra bytes for
control flow ( 4 per script if I am counting right).
The costs on a normal script do seem slightly more friendly, except this
method allows for hidden-til
On Wed, Jul 16, 2014 at 1:56 PM, Jeremy wrote:
> Right now, this could be expressed multiple ways (ie, using an op_dup if
> then else chain) , but all would incur additional costs in terms of
> complicated control flows. Instead, I would propose:
Can you quantify "additional costs in terms of com
Hey all,
I had an idea for a new transaction type. The base idea is that it is
matching on script hashes much like pay to script hash, but checks for one
of N scripts.
A motivating case is for "permission groups". Let's say I want to have a
single "root user" script, a 2 of 3 group, and a 2 of 2
6 matches
Mail list logo
