📅 Original date posted:2015-09-21
📝 Original message:
On returning home from the Scaling Bitcoin workshop, I thought it was
great meeting some people in real life and discovering we basically all
want to achieve the same things. Still, I think there are some
differences in how we think certain problems should be addressed.
Design decisions in Lightning don't suffer from the same "consensus"
necessity as the block validity rules in Bitcoin, but still, some
decisions carry a strong network effect, and might be hard to reverse
once made. The people I talked to felt the need to make no mistakes on
these design decisions, but at the same time I feel the need to make
them ASAP, so we can quickly launch a prototype and convince the world
of how great this is.
Because of this, I'd like to have a well-organized process of collecting
and documenting design ideas and trade-off argumentation, and hopefully
reach some consensus on what are good and bad ideas. This should also
serve to increase interoperability between the several pieces of
software that are being developed. Some of my ideas on how to shape
this:
We could have a Git repository, containing all concepts and standards.
New ideas, amendments & so on can be exchanged like pull requests. We
may / may not also need a process to make actual design decisions, but
assigning one Git clone to be the "true" one might be too simplistic (I
don't want to have a dictator). As long as the Lightning dev community
is small, a "100% consensus" rule might still be workable though.
I'd like to make a distinction between concepts and standards. The idea
is that a concept is a non-trivial design decision; typically people can
have strong preference between different alternative, mutually
incompatible concepts. Standards are based on concepts, and fill in all
the trivial design decisions that have to be made to make different
pieces of software inter-operable. For concept choices, I made the
following template:
https://gist.github.com/anonymous/51631fe56f1f83e4af0a
What do you think?
CJP
PS. Rusty suggested something like an RFC-like process for Lightning.
I'm not an expert on RFCs, and my proposal is probably a bit different
from the RFC process. I'm open to other ideas and I'd like to be
informed about why we should use an RFC-like process or something else.
CJP [ARCHIVE] /
npub13q…cuzdm
2023-06-09 12:44:21
in reply to nevent1q…0udg
Author Public Key
npub13q863scgpsaanrjhfn7dd4h48lgnupgkcs828arzj4pckrq8hh6s4cuzdmPublished at
2023-06-09 12:44:21Event JSON
{
"id": "761ea8252b2eec63e34761b9f18ff997e90862ebfd6a254a27d6d3cac9b22b9f",
"pubkey": "880fa8c3080c3bd98e574cfcd6d6f53fd13e0516c40ea3f46295438b0c07bdf5",
"created_at": 1686314661,
"kind": 1,
"tags": [
[
"e",
"df95008c1c275cb49e8d70686b5e66a5fb1bfddfd0d851ed6ccd262a8bcdf777",
"",
"reply"
],
[
"p",
"9456f7acb763eaab2e02bd8e60cf17df74f352c2ae579dce1f1dd25c95dd611c"
]
],
"content": "📅 Original date posted:2015-09-21\n📝 Original message:\nOn returning home from the Scaling Bitcoin workshop, I thought it was\ngreat meeting some people in real life and discovering we basically all\nwant to achieve the same things. Still, I think there are some\ndifferences in how we think certain problems should be addressed.\n\nDesign decisions in Lightning don't suffer from the same \"consensus\"\nnecessity as the block validity rules in Bitcoin, but still, some\ndecisions carry a strong network effect, and might be hard to reverse\nonce made. The people I talked to felt the need to make no mistakes on\nthese design decisions, but at the same time I feel the need to make\nthem ASAP, so we can quickly launch a prototype and convince the world\nof how great this is.\n\nBecause of this, I'd like to have a well-organized process of collecting\nand documenting design ideas and trade-off argumentation, and hopefully\nreach some consensus on what are good and bad ideas. This should also\nserve to increase interoperability between the several pieces of\nsoftware that are being developed. Some of my ideas on how to shape\nthis:\n\nWe could have a Git repository, containing all concepts and standards.\nNew ideas, amendments \u0026 so on can be exchanged like pull requests. We\nmay / may not also need a process to make actual design decisions, but\nassigning one Git clone to be the \"true\" one might be too simplistic (I\ndon't want to have a dictator). As long as the Lightning dev community\nis small, a \"100% consensus\" rule might still be workable though.\n\nI'd like to make a distinction between concepts and standards. The idea\nis that a concept is a non-trivial design decision; typically people can\nhave strong preference between different alternative, mutually\nincompatible concepts. Standards are based on concepts, and fill in all\nthe trivial design decisions that have to be made to make different\npieces of software inter-operable. For concept choices, I made the\nfollowing template:\n\nhttps://gist.github.com/anonymous/51631fe56f1f83e4af0a\n\nWhat do you think?\n\nCJP\n\nPS. Rusty suggested something like an RFC-like process for Lightning.\nI'm not an expert on RFCs, and my proposal is probably a bit different\nfrom the RFC process. I'm open to other ideas and I'd like to be\ninformed about why we should use an RFC-like process or something else.",
"sig": "aaffb25be894b23fccbce40da5a6aae356800bcecef8efaa952298487e7d70dce47d084c112d27d448c699b5e161cd7500e057e9231fcdc57a35e716ff01d810"
}