By “cryptographic attestation”, I mean that the pool/mint is signing the individual shares and those signatures can be checked and cannot be modified after that fact. Since this signature happens at time of share validation, the hash provider knows that anything modified after the fact is malicious behavior.
IIUC, the point of this proposal is to introduce privacy for payouts. That’s it. So far, I see mostly discussions about unrelated or at best mildly related issues here.
1 Like
Ok so if an ehash is sent to another person before redemption would the pool/mint need to update the share log to keep track of the swap?
I think I understand how this would work now for an ehash to be paid multiple times: when an ehash is redeemed the share is looked up in the share log, if the share is still in the share window then a new ehash is provided. If the ehash falls out of the share window, then it can no longer be redeemed. Is my understanding correct?
ehash is sent to another person before redemption would the pool/mint need to update the share log to keep track of the swap?
No. But the receiver of the ehash would want to redeem what is received ASAP to avoid a sender double spend. This is true of ecash as well. When you send ecash to an other user, you’re sharing the root secret used in the blinded signature and so the receiver is incentivized to redeem that sooner than later, although the transfer may be done offline.
when an ehash is redeemed the share is looked up in the share log, if the share is still in the share window then a new ehash is provided. If the ehash falls out of the share window, then it can no longer be redeemed.
Correct. There is something to be considered with the share window that the TIDES doc calls out:
If the network difficulty goes up, the size of the window increases. Older shares end up being in the window again, despite having “slid out” before the difficulty change.
So there is a perpetually rolling list of ehash that the pool should be tracking.
Sure, but they could just sign the shares as they’re submitted (a trivial extention to Sv2 to have the pool sign all SubmitShares.Success messages would suffice)? There’s no need to tie that directly to ecash in any way.
This proposal is very substantially overcomplicated if that is the only goal. If this is the goal, the pool simply needs to make payouts using lightning/ecash, it doesn’t require tying shares to ecash or anything fancy like this.
If the goal was expanded to include making pool shares into a tradable asset, would you see benefits in using e-cash?
For a centralized pool, I’m not quite sure why you’d want that (at best they’d trade at roughly par?), unless the pool didn’t support withdraws via echas/lightning natively (but they should just do that instead!). That said, tradable shares is one of the two key insights to braidpool, but the reason they make the shares tradable is because they can only do payouts for the top N (probably, like, 10) miners owed the most in any given block, so you need to let users with lower hashpower sell their shares to larger miners for lightning/ecash.
Braidpool chooses to pay every difficulty adjustment epoch (2016 blocks) because in this window the hash price is constant, and tradable shares are a natural forward contract. We could just as easily do PPLNS and pay in every block. It’s a trade-off (as you indicate) between wasting block space with miner payouts (OCEAN/PPLNS pays up to 8x in multiple blocks for the same share) and paying smaller miners as you indicate. Tradable shares will be a V2 feature for Braidpool, we won’t launch with it. Anyway we have a new idea here that I think is worth trying. It’s always possible to fork Braidpool using a different payout mechanism if our current proposal turns out to be undesirable for some reason. And criticism is welcome.
Forward/futures contracts are a fundamental risk management tool for commodities producers. This is one way we want to make Braidpool more profitable/desirable than other pools, and other design considerations like the 2016 block window are chosen to enable this. While I encourage the development of other ideas, we’re going to end up fragmenting the market with different kinds of forward/futures contracts (braidpool shares, eCash, Luxor futures, indexed futures, etc) that are not the same and not tradable amongst each other. This is the difference between a futures contract and a forward contract. Any private bespoke contract which pays in the future is a forward, whereas futures contracts are standardized to make them tradable and increase market liquidity. Anyway I look forward to further development on the topic and I’d like to see what eCash can come up with. Centralized pools running on top of Braidpool can provide unique payout mechanisms including eCash and Lightning.
Cheers, – Bob
I think maybe this is where confusion is being generated. As I understand the proposal, a share represented by an e-cash token is not equivalent to a payout, so I’m not sure what you mean by your comment.
IIUC, hypothetically, a miner would receive a share for proof of work in the form of an e-cash token. In a TIDES payout scheme, shares represented by an e-cash token must be redeemed multiple times (i.e., 8 in the average case) to collect the appropriate payouts when the pool finds a block. Thus, the withdrawal mechanism of the pool doesn’t matter because the e-cash shares aren’t payouts.
When I read the proposal, I saw this distinction and immediately realized the possibility of a market (which I think will be crucial because miners want FPPS, but the pools will have trouble supporting that as TX fees outpay the block subsidy). Apologies if I distracted us from the technical aspects of the proposal with the economics of it.
1 Like
The first presentation in this video is Hashpools by @vnprc
1 Like