Quote from: Yliz on August 07, 2021, 11:47:08 PM

Forgive me if some of this stuff has been explained or if I'm wrong, but I feel like there's not enough simplified information about what Haircomb does or why it'd be valuable, at least for people who aren't very experienced with these things. If I understand claiming, you send a specific amount to your own generated BTC address, but the transaction also needs to be at the front of a BTC block in order to successfully claim. So that'd mean right now we can claim with the highest transaction fee, although some day miners can just put their own transaction at the front of a block to claim it themselves since they organize the blocks. Is that correct? That seems like it could help a ton with mining incentive, but what about the use of COMB itself? It's private, but at what cost? COMB holders basically each have their own piece of the ledger and each need to have synced BitcoinCore running in order to use COMB. That doesn't seem ideal when the core is ~400GB. Even at a smaller size, it's not as easy to use as other cryptocurrencies. Is it possible for that to change at some point or is that just how it is since we'd each own our transaction data? Is there a way for it to be easier to use in the future? Then there's liquidity stacks. They seem really interesting - a transaction with infinite outputs could help a ton with scaling in certain scenarios, but starting that first liquidity stack still requires BTC transactions and can't scale beyond BTC's capabilities. Is there any way the initial input could scale better? There's also deciders/decider's purse that I see, I'm not sure how that correlates with any of this. Do I understand COMB for the most part? I'd like to know where I'm wrong and what could fix the problems I think I see. This token is very interesting, but it's hard to understand.

You get the basics, yeah.

When it comes to the filesize, that is an issue that I don't really have an answer for, other than technological advances. However, I also view it as a positive because it offloads tx data from one chain that everybody needs to own, to a local file that only you need to know. To me this seems like a plus for scaling.

Earlier in the thread we talked a bit about the potential ways to reduce the commits-per-tx. Most of them would require a soft/hard fork of some kind, or sacrificing a little bit of your security, but they'd work. The core method that would work in comb's current form would be utilizing a centralized transaction wallet, through which multiple people would funnel their transactions, and the wallet owner would redirect them all to the appropriate locations. You can use deciders to make this process more secure.

Contracts that have deciders can have funds deposited into them; when the person who has the decider private key signs a number, that contract executes depending on the number signed. The contract has two resolution addresses that the funds can go too, known as the forwards address and the rollback address. A decider/contract address is generated from the related addresses and the public key of the decider. Signing a decider only takes 2 BTC commits.

Using this structure, if there is a dedicated centralized wallet, what I like to call a turbine, the following methodology can be used to mostly secure funds while reducing personal tx cost.

1. User makes a Decider_A.
2. User makes a Contract (Contract_1) with the Decider_A, the Turbine's wallet address as the forward address, and the User's backup wallet as the rollback address.
3. User deposits all their funds into Contract_1. This will now act as the users wallet until the User is ready to make a transaction.
4. When the user is ready, the user makes another Contract (Contract_2); this one also uses the Decider_A, the Turbine's next address as the rollback address, and whatever address the user wants to send their funds to as the forward address.
5. The user tell the Turbine Operator that they want to make a transaction, and shows the turbine operator the two Decider/Contracts that they made. The turbine operator can look at this and know that there can be one of 2 outcomes:
a) the Decider is signed forwards; any funds from Contract_1 will go to the Turbine's Address, and any funds from Contract_2 will go to the user's destination address
b) the Decider is signed rolback; any funds from Contract_1 will go to the User's backup address, and any funds from Contract_2 will go to the Turbine's next address.
6. Knowing this, the Turbine operator includes a LStack in it's next transaction cycle that will redirect X funds from the Turbine into the Contract_2 address, where X = the funds in Contract_1, minus the turbine's fee.
7. The user signs the decider.

This reduces your personal commit footprint down to 2 commits per tx. There is a bit of an attack vector though; information imbalance. The user could sign the decider to rollback, but not tell the Turbine that they did so. Doing this would lock up X turbine funds indefinitely. Theoretically in an ecosystem that required turbines to facilitate comb transactions, if the user ever used their comb in any other transaction the tx history would likely ripple out to other users of the turbine who weren't actively keeping the data from the turbine operator, and would eventually make its way to the turbine to unlock the funds. Another attack vector is just a kamikaze attack; just don't sign the decider.

All this can be done automatically and simply, provided that the correct infrastructure is built for it.