WHY ARE YOU NOT JUMPING UP AND DOWN ABOUT SPIDERCHAIN?! \ stacker news ~bitcoin

WHY ARE YOU NOT JUMPING UP AND DOWN ABOUT SPIDERCHAIN?!

5063 sats \ 21 comments \ @joda 29 Jan bitcoin

zaps forwarded to @calle (100%)

I've been taking a break from Bitcoinia for the better part of a year. I had fallen for a scam, and was already pretty pessimistic on Bitcoin growth vis-a-vis a decentralized side/drive/statechain. I didn't (and don't) see private corporation "permission-ful" ("Proof of Public Identity?") federations as a valid scaling solution. So I decided to take a break from it all.

While I was away, I was toying with the idea of a Proof of Stake layer 2 with Bitcoin as the collateral. Did a search and came up with an article on Bitcoin Mag.

I must be missing something, because this looks like a public, permissionless, decentralized layer-2. And since the bonds are denominated on the base chain, which is Bitcoin, it is actually backed by a Proof of Work asset. Malicious "orchestrators" are penalized via bonds, and presumably kicked off the epoch and have to wait to be randomly selected for a peg-in.

I do love Lightning, but have become aware of its limitations, and hope it can run on a Spiderchain. If so, combined with the recent and upcoming changes to Lightning, this has me very optimistic.

I'm still making my way through the article posted by @soggycakes in September 2023. I'm wondering if any of y'all have done some research or have some thoughts on this.

view all related items

1496 sats \ 1 reply \ @anon 29 Jan

Couple of important points here: 1)Getting super excited whether pro or con in Bitcoin at very early testnet stages is bound to often be disappointing. Many things in Bitcoin were "definitely" coming and "definitely" going to be the next big thing on Bitcoin and they went nowhere. I suggest not getting emotionally invested or bother going too deep (unless you're a dev thinking about working on them) until they at least get to working code on mainnet. 2) Where is demand and what is the compelling product market fit? I'm skeptical. I also don't see a strong use case proposed amidst any article I've seen that will grab the average pleb or Bitcoin business. The market does not appear to either as evidenced by no one really being that interested. In all of these articles I never see what any tech project always needs: a super clear and compelling use case that can be explained in 1-3 sentences with little or no technical jargon. Do we really need more tokens and DAPPs (the 2 main use cases cited on Botanix's website)? Despite high fees Liquid is still mostly empty after years of mainnet deployment and development by one of the best bitcoin companies. Why would this get used when almost no one has touched Liquid for 6 years? 3) Security model, I'll politely summarize that I am skeptical. At least I would want to see it deployed with significant volume and have no security issues for a full year or more before I'd even consider touching it. Especially when you're at the proof of concept stage and there is no economic value to be stolen/gamed/scammed it's hard to know what issues could arise even beyond code such as misaligned incentives, exploits, etc. Directly quoting the Bitcoin Magazine article, "As long as the size of individual multisigs are balanced right with the total number of stakers, and the value of all deposits compared with staking bonds, this could be a very workable system." I will say it differently, this is still at the conceptual stage and may work or it may not. If you want to use if/when it makes to mainnet please consider only using small amounts to start. 4) Eth/shitcoin ick factor is not to be underestimated. This will keep a huge portion of Bitcoiners away for a long time(myself included admittedly), maybe forever unless the use case just becomes overwhelmingly compelling. I'm never touching anything that needs metamask, full stop. Why do really we need an EVM sidechain? I'm not saying it's useless. I'm only saying to the average pleb Bitcoiner it doesn't jump out as important or essential to invest time & energy into, and most businesses are still just trying to understand the base layer so they aren't getting anywhere near this any time soon.

With most things like this I think its best to wait and see. If you are excited and have some technical skills its great to go through the Github repo and consider contributing. But getting emotionally invested in whatever the hot new thing in Bitcoin will be is probably just a road to constant disappointment and disillusionment. Bitcoin doesn't need anyone to save it. The market and economic incentives will keep the ecosystem working and vibrant over time.

0 sats \ 0 replies \ @joda OP 29 Jan

1-- Agreed. I usually get pretty excited in technical developments in Bitcoin, but mostly small ones that do get implemented. 2-- I thought the demand for scaling transactions was implicit. Layer 1 doesn't scale, and Lightning doesn't scale well enough. As for Liquid, if others are like me, the reason Liquid doesn't get used is because of the federation model with a single company being the single trusted entity for failure (Blockstream). 3-- Totally agree. 4-- I have never owned or used Ethereum, but I'm sure there are a ton of good devs there. Spiderchain doesn't at all use Eth, so I'm not sure what the real problem is. I know some people left Bitcoin for Ethereum; it would be super if some of them came back and could contribute to a project on Bitcoin using the skills they gained on "the dark side" ( no offense, @DarthCoin ).

1278 sats \ 2 replies \ @elvismercury 29 Jan

One big reason is bc I had never heard of it, but thanks for surfacing this article, it looks interesting. Love to see creative takes on L2 and scaling that are even remotely plausible.

10 sats \ 1 reply \ @AJ1992 29 Jan

I agree. Lightning's base and instantaneous (mostly) transaction speed fixes a lot of layer one's issues but as OP stated it has a lot of limits and created its own set of issues (unable to find a route, ect).

0 sats \ 0 replies \ @joda OP 29 Jan

There was some discussion of this at Bitcoin Amsterdam (available on Youtube).

One of the last couple Bitcoin Review Podcast episodes has some depth on Lightning updates as well.

1105 sats \ 0 replies \ @OT 29 Jan

I remember looking into it and it was stated something like the side chain will never out perform main chain BTC. I thought that a side chain stable coin during a bear market could be one way that the side chain does outperform the main chain. So I kinda tuned out and have been looking into other stuff.

1065 sats \ 1 reply \ @026180d3a3 29 Jan

It's a terrible name?

0 sats \ 0 replies \ @joda OP 29 Jan

Fair. It's also based on something Ethereum does, so there's some ick factor.

31 sats \ 3 replies \ @piecover 29 Jan

Proof of Stake = Scam, no exception

0 sats \ 2 replies \ @joda OP 29 Jan

That's an extreme position, but I'm open to it. Care to elaborate? This is layer 2 staking, if that matters. Nothing changes on the base layer, and malicious actors in layer 2 lose their BTC.

10 sats \ 1 reply \ @piecover 29 Jan

That's the same argument of shitconers, give me your money if I cheat I lose my coins but they never had anything to start with. Where is the stake reward coming from? Who is going to print that to incentivise stake validators validate transactions? Every POS has a back door where a small group can steal all the money if the system did not break before that and nobody knows who owns what, because there is not a decentralized clock time like #Bitcoin base layer powered by real world energy, physics and math

0 sats \ 0 replies \ @joda OP 29 Jan

Reward comes from penalties and fees, as I understand it. If you stake and then Lightning runs on top, you collect the fees there without the high costs if opening and closing channels on the main chain. It may be that your stake (bond) amount limit is tied to the liquidity you can hold in your Lightning channel. I may be wrong, but assume there must be a mechanism there, like a Watchtower that also contains one of the keys to the multisig for your peg-out. That seems feasible.

I'm also skeptical, but trying to be open to the possibility of a PoS which manages to avoid the issues you mention.

I'm not understanding the clock time point. An epoch can use the Bitcoin block height as a clock.

20 sats \ 0 replies \ @harrigan 29 Jan

I had a look at their whitepaper. IIUC, Botanix includes a two-way peg to the Bitcoin blockchain (the Spiderchain), a consensus protocol based on proof-of-stake, a blockchain whose native token is synthetic bitcoin, and an EVM virtual machine. The orchestrator nodes run the Spiderchain, the EVM, and a Bitcoin node. They construct blocks and mint and burn synthetic bitcoin. The orchestrator nodes need to provide stake in order to participate. Pegging-in and out involves locking bitcoin into the Spiderchain using a decentralised multi-signature mechanism. At launch, the peg will be centralised but it will be decentralised over time. The proof will be in the pudding: can then pull off that last step?

35 sats \ 3 replies \ @supertestnet 29 Jan

(1) Custodial

(2) Uses EVM

This ain't it my friend

0 sats \ 2 replies \ @joda OP 29 Jan

Escrow bonds are (I think?) by nature, custodial in some way. If you had "full control" of all the keys to access the BTC, it would defeat the purpose. You only lose the bond if you act improperly on the network. Scaling must involve strangers locking up funds in HTLC.

As for EVM, I'm not sure yet how I feel about it. It's really just using code from another crypto. The majority of Bitcoin's code is not "original" anyway-- many of the ideas already existed. And as far as I can tell, this is not endorsed by or beholden to Ethereum chain, currency, or foundation in any way. I know it can "look bad" for a while, but it isn't changing anything at all on Layer 1, and all I care about is expanding throughput as privately and as non-centralized as possible, even at the expense of some jeers.

1620 sats \ 1 reply \ @supertestnet 29 Jan

Escrow bonds are (I think?) by nature, custodial in some way

I don't think that is true because HTLCs are an escrow bond and they are self-custodial. An HTLC contract says that party A gets money if they reveal a secret within a certain time frame, otherwise party B gets that money. There is no third party C who enforces that contract, the two parties (A and B) enforce it themselves, directly on bitcoin, and until they do so, any money in the contract is escrowed.

If you had "full control" of all the keys to access the BTC, it would defeat the purpose.

In lightning you retain full control of all the keys to access the BTC and it is the purpose. It's an example of a fully self-custodial scaling solution. I would like to see more of them. As well as improvements to lightning itself so it can scale better.

As for EVM, I'm not sure yet how I feel about it. It's really just using code from another crypto.

I have no problem with using good code from another crypto but EVM is bad code. Their decision to use an account model instead of a utxo model needlessly magnifies the complexity of node software, and their reliance on publishing contract data on chain makes their designs pointlessly expensive and wasteful. I greatly prefer the way Liquid does it and would much rather see a Spiderchain that adopts Elements opcodes rather than the EVM.

0 sats \ 0 replies \ @joda OP 29 Jan

Thanks!

10 sats \ 2 replies \ @03479d0ee6 29 Jan

I'm not a fan of sidechains I don't think they have much to offer for bitcoin, bitcoiners don't want ethereum like capabilities. Bitcoin just has to be good money, sidechains have the problem of permission to peg out. I think bitvm could solve this to have permissionless peg outs but, until it's done there is always the tradeoff of trust with more or less multisigs. Sidechains all have the same ideia, only the security model changes, drivechains put the trust on miners, Liquid on exchanges from the federation, and spiderchains on a proof of stake model. It's all tradeoffs, sidechains are only good to have something for degens, defi, gambling etc, bitcoiners don't have that interest and will choose base chain and lightning because its just money functions and the most trustless. Sidechains dont improve much about scalibility because of trust, and peg in/out extra step.

0 sats \ 1 reply \ @joda OP 29 Jan

Thanks, I'll look into bitVM.

I also don't want Ethereum capabilities, but in order to be "good money" as you say, Bitcoin must scale by orders of magnitude. Otherwise it is "just" the best store of value, which will end up being used by custodians to back a fractional reserve currency.

0 sats \ 0 replies \ @03479d0ee6 29 Jan

Well transaction scaling, lightning and other solutions including custodial and other solutions that will come along will probably be enough. Custodial might be ok for a few dollars. The biggest problem might be ownership scaling, if fees get too high many people won't be able to use base chain. For that i think Fedimint might be a better option than sidechains, bc at least i can choose who to trust with my keys, can be some friends of mine, or some known bitcoiners. Otherwise, only increasing the blocksize, which should be done imo in the future if there is demand.

0 sats \ 0 replies \ @joda OP 29 Jan

Following up, Micah from InvalidateBlock created a critique video inside a subway station a while back. The first comment is a reply from Willem, which I'll post here for those who don't dig YT. Hopefully it makes sense out of context:

Hi Micah,

Thanks for the review, appreciate you taking the time to dig through this. The more eyes we have on the design, the more we can improve.

Below some comments on open questions you posed and some clarifications.

In general, the paper is supposed to describe the general protocol design, not a specific implementation description.

(8:35) Stake s for our initial implementation will be fixed 3 BTC and multisig sizes of a 100. Dynamic stakes are very interesting and is a whole set of research with different tradeoffs introducing new sybil attack vectors. Will write a separate post on this one day.   

(11:48) Catching and reporting of malicious attacks. Not specified in the design as there could be multiple ways to implement it. An example of how this could look like:

Catching. A malicious participant send a signing request to all other participants to empty the multisig and divide equally between the participants. All the participants of course see this signing message.
Reporting machanism. You can send an onchain a reporting message portraying the malicious signing request. All Orchestrators will then know who sent the malicious transaction request and who reported it.

The first one to report gets the slashing reward.

(13:06) Apologies on quadratically vs exponentially, is been fixed for the next version.

(14:33) This is incorrect, the size of the reward goes up quadratically. Not sure why you would divide this by the chance of you getting the reward as that’s not the decision you make in a specific instance. The action you will take will be to get the full reward. Therefore the single multisig game theory goes up quadratically.

(16:01) Exit of Orchestrators. As you pointed out the orchestrators will get replaced by random orchestrators ofcourse.   

(20:40) The 50% is an example of multisigs that are generated in the future. The formula is in the paper, the number 50% is at a 2/3rd point to showcase that that the geometric distribution sits at 50% around 2/3rd.

(23:29) This is a probabilistic based approach and will become nearly impossible at a bigger stake size. Important to note the attacker has no control over this.

 (24:10) FTX was fraud and Terra an algorithmic tulip bubble. I don’t think the comparison helps here.   

Thanks again for the review, appreciate it.

Willem