unnecessary crap. use lightning.
reply
how do I make e2e encrypted payments in lightning? or do p2p pooled liquidity borrowing and lending? and once block space on L1 fills up, how do I close my LN channel without paying a prohibitively high fee?
reply
Learn more about LN, seems that you lack of knowledge about it.
how do I close my LN channel without paying a prohibitively high fee?
You don't. You keep using a LN channel as much as you can, not after each payment.
p2p pooled liquidity borrowing and lending
That's stupid. In a Bitcoin world you are forcing users to go back to use crapcoins or fiatcoins. Bitcoin is savings technology, not fractional crap reserve. You save sats until you are able to buy what you need and you buy only what you really need. You don't have enough BTC? Fine, work harder until you get them.
You can't lend/borrow more BTC than you have.
reply
You keep using a LN channel as much as you can
What happens when you can no longer use the channel? Without the ability to settle on L1, do you think LN works at all?
reply
That's a strawman, LN requires opening of channels, but closing them really is optional. No need to settle if you continue to maintain the channel. It is conceivable that the open-to-close ratio of channels will get very close to 1 over time, a channel could become something that you can pass on to your descendents, if both sides are determined to do so.
reply
If everything is working as intended, sure. Seems like many people are overlooking the concept of being in an adversarial environment.
reply
my point was build it on lightning, not L1. as for borrowing and lending, thats just people being banks, it shouldn't be a thing.
reply
my point was build it on lightning, not L1
it can't be built on lightning
as for borrowing and lending, thats just people being banks, it shouldn't be a thing.
borrowing and lending have been a thing for thousands of years, that's not going to change any time soon. whether you like it or not, people obviously want to do it. so it will continue to be a thing. good luck convincing people otherwise.
reply
Honestly I think it's a decent idea, but it doesn't have that slam dunk "wow this is a fully functional second layer" aspect which is probably needed for traction. (that would be what you are calling 'trustless bridge', i.e. actual validation of state transition on the btc chain, so enforcement via btc consensus).
reply
There really is very few differentiable types of automatable financial contract in existence, so few that it would be possible to count them on two hands. Escrow, Security deposit, Loan, CFD, Payment, Delayed payment, Multi-party payment (in and out), Ownership claim, Stock issuance. There really isn't that many things needed. Sure, maybe there's some that are hard to do with the current scripting engine but really not that many.
Bitcoin is great for checkpointing any kind of outside data though, so it can be a good testing ground for the real utility of new types of contract arrangement enforcable on the network.
reply
So, the idea here is that there is no secondary data communication layer, like a sidechain or new transport protocol? The entire state needed to validate the rollup is stored in the state blob, on chain?
reply
Wouldn't this affect block space?
reply
IIUC, it'd basically be a data dumping ground for some other independent chain? Sure, just pay the fees then go to town or w/e.
reply
it depends on what you mean by "independent". since the chain is storing its state in bitcoin blocks, it is rather dependent on bitcoin. the benefit it gains from that dependence is that it inherits full double-spend resistance from bitcoin, so re-orging the other chain is as difficult as re-orging bitcoin.
reply
I mean Bitcoin itself is unaware of it. There'd be no way peg mechanism, so it's like a sibling chain. That's great, as people can just do it in a permissionless manner.
I think the specifics of double spend protection or not would depend on the consensus system of the sibling chain. Sounds like a cool design space to explore.
reply
true, the "sibling chain" as you put it could allow re-orgs independent of bitcoin. but then I'm not sure what the benefit of putting all of the chain data inside bitcoin blocks would be, as opposed to just putting a hash so that nodes could simply follow a chain of headers and make sure that matches up with the chain other nodes are feeding them. can you think of what the benefits of putting all of the chain data inside bitcoin blocks would be in this case?
reply