Ethan Tuttle

https://video.nostr.build/7efb1f23b85f1f4b6dd59170a99f5363b51804b0a1498e4aa8027ff61d29ba53.mp4 nostr:nevent1qqsyyny5lmp85juc4mga5f846djd0wf72s9g5acj54r7ms0jxp0uuqcppemhxue69uhkummn9ekx7mp0qgs9ajvxw0lwe25ntjq52qtfygf9ngh3xf35u7y35rzn0h9k8meulvgrqsqqqqq5sfs4j0

Ehash is going to be awesome.

Been cooking with gas lately. Talk more soon.

https://github.com/derekross/plektos/pull/1 nostr:nprofile1qqsr7acdvhf6we9fch94qwhpy0nza36e3tgrtkpku25ppuu80f69kfqppemhxue69uhkummn9ekx7mp0qy0hwumn8ghj7mn0wd68yttjv4kxz7fwv3jhyettwfhhxuewd4jj7qg3waehxw309ahx7um5wgh8w6twv5hsleq7kw is my homie. 🤝

Version rolling masks and notify

btc++ is banger. eHash demo today. 1845UTC

Wonder if I could vibe code CTV and CSFS activation on testnet4? 🤔

Notedeck contributor. ✅

Made a PR to #notedeck so you can use Ctrl+Enter to "Post now" when typing out a banger note.

Pushed a commit to https://GitHub.com/EthnTuttle/eHash One message type ported. SetupConnectionMint. nostr:nprofile1qqsdxpfv503a2ga3ajqxw843hws9z7302ghpj4mcmjpa6qagmp9pwrsppemhxue69uhkummn9ekx7mp0qywhwumn8ghj7mn0wd68ytnzd96xxmmfdejhytnnda3kjctv9uq32amnwvaz7tmjv4kxz7fwv3sk6atn9e5k7tczr282l has made a ton of progress but it's all a fork of SRI. That repo will be much to clunky to maintain a fork of. Hashpools will need their own repo. I plan to diff the hashpools to SRI and see what data types he's added. Extract those out into their own crate. Then circle back to make a binary consuming the eHash crate and Sv2 crates. This structure was inspired by demand pool's open sourge.

Officially a NIP contributor

#ecash is blinded cryptographic attestation

#eHash subsidize your friends, not the pools. https://github.com/vnprc/hashpool

Bitcoin Park is amazing. Always so amazed with the amazing people I meet here.

Happy New Year!

My write up on how #cashu #ecash like shares might he used for a #mining pool. https://delvingbitcoin.org/t/ecash-tides-using-cashu-and-stratum-v2/870/20 #Ecash TIDES using #Cashu and #StratumV2 Recommended reading/References: - Cashu ecash protocol - ecash Proof of Liabilities - Ocean TIDES - Stratum v2 Spec (Sv2) Goals: - Auditability - Small payouts - Privacy Using the Blind Diffie-Hellmann key exchange (BDHKE) from Cashu as a Sv2 Protocol Extension, a pool can provide auditable, small scale, private pool rewards in the form of eHash. A hash provider (HP) connects to a pool and begins job negotiation. This aspect remains largely unchanged from current paradigms. However, the HP will also request the active block_keyset. This is a list of pubkeys as defined in NUT02, but the value amounts for the individual keys correspond to difficulty targets for various miners which is used as a share weight in the TIDES rewards. The unit for these keysets is left up to specific implementations. A block_keyset is rotated once the pool finds a block or when the network difficulty adjustment occurs. When the HP finds a valid share, in addition to standard share data, the HP will generate a secret and send a blinded message (B_) to the pool. The inputs for this blinded message could be done at an individual ASIC level or as part of a farm proxy implementation, with the latter seemingly ideal for larger farms. This blinded message (eShare) would be included in Sv2 channel messaging as a protocol extension. This signals to the pool that there is a valid share and requests a signature using the appropriate key from the active block_keyset. The same blinded message could be reused multiple times as long as special consideration is given on the pool/mint side for tallying these submissions. Reuse of blinded messages may be necessary during implementation if computing these blinded messages is too costly for a given HP, otherwise a new blinded message should suffice and lower complexity. When the pool receives an eShare, it first validates the share itself, as usual. Once validated, the pool signs the blinded message, completing the DHKE and providing the blinded signature (C_) back to the HP. This share + blinded signature are then added to the time ordered TIDES defined share_log. The HP retains the blinded message data inputs (x) and the unblinded signature (C) as defined in the Cashu protocol NUT00 1. This share process continues until a new difficulty adjustment occurs, after which a new keyset is issued with appropriate difficulty targets, OR a block is found by the pool. A keyset rotation after a difficulty adjustment accounts for new share target difficulties. A keyset may be reusable across difficulty adjustments as a % delta from network difficulty. When a block is found by the pool, a full list of shares and associated blinded signatures is published by the pool. This signals to the HP that the eHash shares are available for redemption. Now the pool references the share_log using the share_log_window (defined in TIDES) for what eHash is eligible for redemption. As HP’s redeem their eHash, the eHash is recorded alongside the public record of shares and blinded signatures as defined in the ecash Proof of Liabilities 5. Redemption of eHash can be any of the available Cashu or ecash mechanisms appropriate for the HP. Other thoughts: Cashu supports spending conditions, such as P2PK (NUT10 1 and NUT11) the blinded message secret uses hash_to_curve(x) computation which could be offloaded to an ASIC, maybe. Since this is an ecash usage, Fedimint is also a viable option but has not been considered in depth. P.S. I look forward to feedback and considerations I may have missed. This post was an effort to solidify my idea into something more concrete and shareable. A vocal (and probably less comprehensive/coherent) monologue of this idea can be found here. I hope to create a diagram to help illustrate this proposal.

nostr:npub1xtscya34g58tk0z605fvr788k263gsu6cy9x0mhnm87echrgufzsevkk5s

Anything cool happening in #ecash?

It's been a bit. What's happening in #ecash?