pull down to refresh
10 sats \ 0 replies \ @JeremyRubin 10 Mar 2022 \ parent \ on: @niftynei AMA: lightning, FOSS, bitcoin, leveling up the next 100 btc devs at Base58 bitcoin
i think you're presuming bad faith -- i asked an open ended question, and asked a follow up. you could have responded with anything -- you said eltoo, and said for the purposes of state compaction being the issue. in the ranking of all problems i didn't think that was so severe. i'm mostly an outsider to lightning development, and AJ's proposal has nothing to do with anything i work on. but if it's a solution for state compaction you didn't know about, that's groovy and i hope useful information. if it's not, i'd love to learn why you don't think so.
doesn't getting rid of state work with just AJ's proposal from https://lists.linuxfoundation.org/pipermail/lightning-dev/2021-October/003278.html
should everyone be focused on that?
w.r.t. musig being the barrier, could we just start using Taproot with a NUMS point and a traditional multisig & still get this benefit?
why do you need MuSig2 at all?
afaiu with just 2p / interactivity there are some much simpler variants that work fine...
if you could magically peacefully get all the LN companies, LN devs, and Bitcoin devs to stop working on what they're working on and prioritize/focus on one thing, what would it be?
Depends on the shop. If it's an average place, pollo asado is usually my go-to, but at a good spot a baja fish taco is unbeatable.
- I agree with you
- I don't know.
Bitcoin has -- perhaps feature, not bug -- an incredibly toxic and unsupportive adversarial culture.
One man's solution for a concrete problem is another man's you are going to destroy bitcoin you evil fuck.
I think this process is highly succeptible to social attack whereby -- if our standard is unanimity -- a few bad actors aimed at freezing bitcoin development to a standstill can have that effect.
I also think a number of the community things can have a net negative impact. E.g., we have no development foundation formally, so most feature upgrades are single-dev efforts that then are reviewed on a casual basis by other devs who have an interest. There's less grand vision / knowledge of where the puck is going and more wisdom of the crowds. Maybe that's OK, but we don't produce useful artifacts as a part of that process oftentimes. E.g., formal security audits, minimal implementations, etc.
Generally I think we should culturally trim down Bitcoin core to the bare minimum for efficient consensus (get rid of a bunch of wallet stuff, gui stuff, etc) and then use a small-step semantic change process to iterate on adding things as easy to verify refinements.
However, because some view soft forks themselves as being incredibly high risk, small steps are seen as not worth it compared to kitchen sink approaches for adding new stuff. And advocating for frequent small soft forks is akin to asking for bitcoin to be attacked regularly!
I don't have the answers, like I said. I just wish there were a way forward where less animosity was held for differing views.
IMO about as healthy as an anemic 3rd degree burn victim with long covid :)
Right now, you can leave your Google job and raise a seed/pre-seed of $1-5M at a $30-50M valuation to build on Ethereum.
You'd have to be nuts to -- on purely financial motives -- decide to work on Bitcoin instead.
That's OK because we don't want the merc's, we want passionate dedicated individuals, but consider if you're trying to build a bitcoin company and that is the ability to pay for talent you have to compete with. It is going to suck.
howdy!
check out https://learn.sapio-lang.org to get started, there's also a ton of content in https://rubin.io/advent21
i hope the lesson is not "this is so hard it's not worth trying again".
that might be my personal takeaway, sadly.
there's not really a "team", it's just me and folks who like the concepts.
I think the biggest tension right now is w.r.t. soft fork processes:
Are soft forks themselves (not the upgrades contained in it) much riskier than the upgrades?
If the answer is "no" then there's pretty wide support for CTV... if the answer is "yes" then people think waiting for us to make the most impact for this ultra high risk process keeps ctv "below the line" of value add.
I don't think there are any current NACKs of the form "this would be, absent costs of doing any fork, bad or technically unsafe for Bitcoin". Or in other words: would Bitcoin be OK if this were a feature that was always in Bitcoin? Trying to reframe the question of not if we should add it, but would we want to remove it were it already there is useful for reasoning about if you think it is unsafe or bad. E.g., OP_CODESEPARATOR in legacy script is something that we might want to remove were it not already there.
There's definitely growing interest, but TBH I could use a lot of help building a team to develop it... as you can imagine, the intersection of qualification, interest, and ability for me to pay for such devs competitively leaves a tiny set of people.
If I had beacoup bucks this would be easier to solve, but I don't. It seems like it would make sense for me to have that funding, but it's been uphill battle for whatever reasons.
I think that I could see a Payment Pool from wasabi/samurai since it can be closely related to CoinJoin.
but from a company perspective I think that lots of businesses (e.g. exchanges?) might connect their hot wallets into payment pools to streamline cut-through between exchanges with higher value caps than might be comfortable for e.g. Lightning.
Well I think what is good about CTV is that it is incredibly explicit with exactly what should happen with each coin you have, so it's relatively easy to model (you know all state transitions!) for wallets. Anything more sophisticated ends up being harder to reason about, by quite a lot!
I think I would want all of my wallets to have this feature... so yes?
eh yeah a bit out of scope...
but it is an AMA.
So let's go with narratives around decreasing the population growth and stuff... I think that consciousness is like the scarcest asset (scarcer than Bitcoin ;) in the universe and as a species it's incredible we can make more of it, so we should be dedicating a lot more energy into figuring out how to sustain 10x the number of people v.s. fighting about little stupid NIMBY issues.
Personally I am really excited about Payment Pools as a Big New Trend™ for Bitcoin, especially with majority rules (v.s. unanimous) on txns, since those look like DAOs. Love em or hate em, I think DAOs as vehicles for capital formation and management is really exciting, and something I'm looking to spend more time making infrastructure for.
Generally, I see current users excited about Vaults since self-sovereign security is a huge deal, and CTV represents a non-marginal improvement to what can be done today.
Non-interactive lightning channels are a super straightforward improvement for lightning companies who oboard many users.
Lastly, the DLC research Lloyd F posted about recently makes DLCs a lot more practical with CTV, which I think is also highly exciting.
-
Not in particular. Would you call any contract happening in Ethereum (arbitrary powerful system) an abuse? Generally these things are opt-in. Also we already have issues that users can create (e.g. wrt to consensus incentives in Bitcoin) without covenants... not too worried here :)
-
No comment really, nothing particularly surprising if that makes sense. Your assesment is correct though.
-
I think in the long run we will never see major ossification. Security in Bitcoin rests on economic demand of on-chain space, so we will constantly have to ensure Bitcoin is serving as the settlement layer of record. That, and at a implementation level, security is an ongoing concern. I think there are bigger risks in implementation stuff v.s. the spec/protocol level, so I don't suspect we gain much from protocol ossification either. IMO even things like PoW are on the table -- my ongoing question is are we getting the best security/censorship resistance for the best price, and I would be surprised if in 50 years we haven't improved on that (imagine computers from 50 years ago and thinking that today's computers would be similar).
There are quite a few, but off the bat:
- Payment Pools represent a technique for CoinJoins with "lazy output creation" where the pooled funds can be kept as a single coin which does iterative (on-chain) updates to make payments on-chain. Update data only has to be shared with your hierarchical neighbors with CTV, so you get some better privacy v.s. other techniques.
- PathCoin is a novel concept for a coin that is off-chain transferrable amongst a group of N users with only the sender/receiver (2) having to communicate (v.s. lightning which requires N of N online)
- Non-Interactive Batched Lightning can make channel opening hidden until close, with opportunity for cooperation (pairs with Payment Pools)
addendnum: in terms of framing, I'd like to see Bitcoin development have a more pragmatic small-step improvement process that works agressively v.s. building big complex overhauls, and I think CTV is a good representative of what that process could look like.