Fork off the XRP ledger with hooks :)

[HAL1000]

 

[at3n]

Interesting. Glad that it's Weitse behind it, someone who I think acts with integrity and not just trying to make a quick buck.

Seems like it could be a good first demonstration of how XRP could break away from Ripple, and see how successful it remains. I like the idea of having a second chain that is more tech-led rather than business-oriented, although I think it would likely take a long time to build as much value as Ripple has added to the existing chain. I also wonder if the nature of a more "techy" chain would allow for a wider diversity of validators as viable options for the UNL, and could users realistically have more options for the set of validators to trust than the current setup. Would be good to try to push hard on the decentralization angle.

A good experiment at least.

Disclaimer: I've done no research into this other than watch the video above.

[HAL1000]

 

[Xrpdude]

Best bit for me: tokens on the new ledger will not be created out of thin air, no pre mine, instead the tokens have to come across 1:1 from the main net. So sounds like just pumping the use case without pumping the supply, in fact as use case grows the supply on main net could reduce. Win-win? certainly sounds good to me

[HAL1000]

2 minutes ago, Xrpdude said:

Best bit for me: tokens on the new ledger will not be created out of thin air, no pre mine, instead the tokens have to come across 1:1 from the main net. So sounds like just pumping the use case without pumping the supply, in fact as use case grows the supply on main net could reduce. Win-win? certainly sounds good to me

That's how I read it, so yep, more utility, but still using XRP as the native underlying value transfer mechanism, who needs Flare, if this works!

[at3n]

1 hour ago, Xrpdude said:

Best bit for me: tokens on the new ledger will not be created out of thin air, no pre mine, instead the tokens have to come across 1:1 from the main net. So sounds like just pumping the use case without pumping the supply, in fact as use case grows the supply on main net could reduce. Win-win? certainly sounds good to me

Ah, even more interesting! How about moving XRP back from Hooks chain to main chain? I assume that wouldn't be implemented at the same time? Looking at Twitter it seems to be unanswered.

Thinking about the price dynamics, if you can go back and forth, then the XRP on both chains could probably be considered the same asset... If you can only move it one way then the prices would diverge and you have two different XRPs, am I thinking right?

I'd think that being able to go both ways would be more valuable (in terms of utility and price).

[peanut56]

I understand the tokens on the hooks if implemented are 1:1 to mainnet xrp. Does that mean that the xrp are held in escrow to represent the token on the hooks chain or they are minting 100bil to match xrp like a mirror? I would hope that xrp would be utilized in the sense that xrp can be converted to x-currency and redeemed for xrp on mainnet as long as x-currency is then deleted from the hooks. Kind of like songbird and flare? Hopefully someone with greater technological understanding can chime in.

[at3n]

2 hours ago, peanut56 said:

Does that mean that the xrp are held in escrow to represent the token on the hooks chain or they are minting 100bil to match xrp like a mirror?

These are the most informative tweets that I've found about the process, which still seems very unclear. But what is clear is that it will not be a full clone of the balances on the existing XRPL, you need to deliberately "move" your XRP between chains...

Quote

"It is a technological fork, new ledger, history back to ledger 1. Starts fresh, no 100bn pre mine, and tokens have to come from mainnet as a 1:1 issuance of what has been moved from mainnet."

https://twitter.com/WietseWind/status/1665058065261944835

 

 

Quote

"We're building it in a way where proof of a transaction from mainnet can be fetched and sent to the side chain, where it will be verified and issued from genesis."

https://twitter.com/WietseWind/status/1665073014130593792

 

 

...and in moving XRP to the hooks chain, you will be reducing the circulating supply on XRPL:

Quote

"Forgive my tech illiteracy here - does that mean the circulating supply on XRPL is reduced in order to create supply on the new chain, and tokens on the new chain aren’t created out of thin air, and new chain health is fundamentally dependent on a healthy XRPL? Absolute win/win?"

https://twitter.com/_Howard_x/status/1665259701192507394

 

I initially thought that would mean that the original XRP would be burned, but it seems not:

Quote

"Native XRP only lives on XRPL mainnet. It'll be a representation of XRP obtained by a mechanism that enables reissuing from mainnet."

https://twitter.com/WietseWind/status/1665057806196563969

 

 

 

So if the plan is that the XRP that is sent to the hooks chain can later be reissued from the main chain, I can only think there must be escrow involved in some way to lock the main chain XRP, to allow it to be unlocked when the time comes to move the XRP back. But I can't think how that would be done in a way that would be flexible enough to allow you to move the XRP back at will, but also prevent the escrow being unlocked until its corresponding XRP on the hooks chain had been locked or burned. Still looking for answers.

Edited June 6 by at3n

[jn_r]

16 hours ago, at3n said:

So if the plan is that the XRP that is sent to the hooks chain can later be reissued from the main chain, I can only think there must be escrow involved in some way to lock the main chain XRP, to allow it to be unlocked when the time comes to move the XRP back. But I can't think how that would be done in a way that would be flexible enough to allow you to move the XRP back at will, but also prevent the escrow being unlocked until its corresponding XRP on the hooks chain had been locked or burned. Still looking for answers.

Same. Trying to crack that puzzle, but without changes to the XRPL I don't see how it can be done. XLS-38d provides imo a well defined structure. But there you need to trust witnesses, so that creates a side-chain where trust is needed. And on top of that some changes to the XRPL have to be made. Maybe you could use some overlapping validators as witnesses, but that still would give those validators power over the door-account on main-XRPL... to prevent that you probably still need the changes on the main XRPL. 

Curious what they have in mind, they are obviously not telling us (yet) 

 

[jn_r]

Listening to the 'Hooks and Evernode' spaces on twitter, I think I hear Richard say that they use (and wait for) the implementation of XLS-38d. At ~4:20: https://twitter.com/i/spaces/1OwxWwQEzVAxQ?s=20

edit: or maybe other solution in the works, like tendermint  - used in the EMV sidechain..(https://opensource.ripple.com/docs/evm-sidechain/intro-to-evm-sidechain/) 

edit2: I see now there is actually discussion on discord / XRP Ledger Developers / hooks channel about the topic :-) Following that now.. (so probably xls-38d will not be used for this)

Edited June 9 by jn_r

[HAL1000]