📅 Original date posted:2014-03-29
📝 Original message:Nobody is exactly thrilled by IsStandard, but it's not a deal-killer. If
you have a use for a new type of script it can be added, and people do
upgrade:
http://getaddr.bitnodes.io/dashboard/chart/?days=30
As you can see the 0.9 rollout is going OK. If a new script type had been
made standard for 0.9 like OP_RETURN was, I'm guessing it'll only be
another month or so and it'll be quite usable.
On Sat, Mar 29, 2014 at 3:55 PM, Matt Whitlock <bip at mattwhitlock.name>wrote:
> On Saturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote:
> > On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock <bip at mattwhitlock.name>
> wrote:
> > > Multisig does not allow for the topology I described. Say the board
> has seven directors, meaning the majority threshold is four. This means the
> organization needs the consent of six individuals in order to sign a
> transaction: the president, the CFO, and any four of the board members. A
> 6-of-9 multisig would not accomplish the same policy, as then any six board
> members could successfully sign a transaction without the consent of the
> president or CFO. Of course the multi-signature scheme could be expanded to
> allow for hierarchical threshold topologies, or Shamir's Secret Sharing can
> be used to distribute keys at the second level (and further, if desired).
> >
> > Disagree with "does not allow" Review bitcoin's script language.
> >
> > Bitcoin script can handle the use case you describe. Add conditionals
> > to the bitcoin script, OP_IF etc. You can do 'multisig AND multisig'
> > type boolean logic entirely in script, and be far more flexible than a
> > single CHECKMULTISIG affords.
>
> Depends on your definition of "can." Bitcoin's scripting language is
> awesome, but it's mostly useless due to the requirement that scripts match
> one of a select few "standard" templates in order to be allowed to
> propagate across the network and be mined into blocks. I really hate
> IsStandard and wish it would die.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/a39febd9/attachment.html>;
Mike Hearn [ARCHIVE] /
npub17t…4qgyd
2023-06-07 15:16:38
in reply to nevent1q…mq77
Author Public Key
npub17ty4mumkv43w8wtt0xsz2jypck0gvw0j8xrcg6tpea25z2nh7meqf4qgydPublished at
2023-06-07 15:16:38Event JSON
{
"id": "f17dcd762c73071e6d1fbb5630ea8a4b60f7493d07e64ff62502b2956ec71a84",
"pubkey": "f2c95df3766562e3b96b79a0254881c59e8639f23987846961cf55412a77f6f2",
"created_at": 1686150998,
"kind": 1,
"tags": [
[
"e",
"cd470d06d90a3107c21da4b48b344ebdd3b4ab813362bb85b0e7a02311012700",
"",
"root"
],
[
"e",
"224f39fc7b90aa21b60bbfc555086f6984f3dcf4e6afa05b4efb4447b211ce6a",
"",
"reply"
],
[
"p",
"f00d0858b09287e941ccbc491567cc70bdbc62d714628b167c1b76e7fef04d91"
]
],
"content": "📅 Original date posted:2014-03-29\n📝 Original message:Nobody is exactly thrilled by IsStandard, but it's not a deal-killer. If\nyou have a use for a new type of script it can be added, and people do\nupgrade:\n\nhttp://getaddr.bitnodes.io/dashboard/chart/?days=30\n\nAs you can see the 0.9 rollout is going OK. If a new script type had been\nmade standard for 0.9 like OP_RETURN was, I'm guessing it'll only be\nanother month or so and it'll be quite usable.\n\n\nOn Sat, Mar 29, 2014 at 3:55 PM, Matt Whitlock \u003cbip at mattwhitlock.name\u003ewrote:\n\n\u003e On Saturday, 29 March 2014, at 10:19 am, Jeff Garzik wrote:\n\u003e \u003e On Sat, Mar 29, 2014 at 10:10 AM, Matt Whitlock \u003cbip at mattwhitlock.name\u003e\n\u003e wrote:\n\u003e \u003e \u003e Multisig does not allow for the topology I described. Say the board\n\u003e has seven directors, meaning the majority threshold is four. This means the\n\u003e organization needs the consent of six individuals in order to sign a\n\u003e transaction: the president, the CFO, and any four of the board members. A\n\u003e 6-of-9 multisig would not accomplish the same policy, as then any six board\n\u003e members could successfully sign a transaction without the consent of the\n\u003e president or CFO. Of course the multi-signature scheme could be expanded to\n\u003e allow for hierarchical threshold topologies, or Shamir's Secret Sharing can\n\u003e be used to distribute keys at the second level (and further, if desired).\n\u003e \u003e\n\u003e \u003e Disagree with \"does not allow\" Review bitcoin's script language.\n\u003e \u003e\n\u003e \u003e Bitcoin script can handle the use case you describe. Add conditionals\n\u003e \u003e to the bitcoin script, OP_IF etc. You can do 'multisig AND multisig'\n\u003e \u003e type boolean logic entirely in script, and be far more flexible than a\n\u003e \u003e single CHECKMULTISIG affords.\n\u003e\n\u003e Depends on your definition of \"can.\" Bitcoin's scripting language is\n\u003e awesome, but it's mostly useless due to the requirement that scripts match\n\u003e one of a select few \"standard\" templates in order to be allowed to\n\u003e propagate across the network and be mined into blocks. I really hate\n\u003e IsStandard and wish it would die.\n\u003e\n-------------- next part --------------\nAn HTML attachment was scrubbed...\nURL: \u003chttp://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140329/a39febd9/attachment.html\u003e",
"sig": "e065eb07e7674cafa31e62f0256268c59fe8189c9c5bccbc1178db39f491b559bf789501ad356f4aa2f04a3d2ec13b3e345a1f8ea4c170c29063d5af826fde0a"
}