Think about to interpreter API design for checksigfromstack
Nessuno ha ancora preso questa issue.
Valutazione
- Difficoltà
- 5/5
- Tempo stimato
- Più di una settimana
- Idoneità per principianti
- 25/100
- Tipo di issue
- Funzionalità
- Chiarezza
- Da chiarire
- Stato di attività
- Ferma
- Stack tecnologico
- rust
- Ambito
- backend-api-design
Direzione di ricerca
Inizia dal punto di ingresso checksigfromstack e dalla gestione delle firme basata su closure esistente descritta nell’issue. Leggi la discussione della pull request collegata, confronta le opzioni API elencate e conferma che il design scelto gestisca sia i normali sighash delle firme sia l’interpretazione di miniscript senza controlli non necessari; il lavoro è completato quando la direzione dell’API è concordata e documentata o implementata.
Scritto dal modello di indicizzazione a partire dal testo della issue.
Descrizione
So, to handle the existing checksigs we have the user pass in a closure. There were two reasons for this
- To check normal signatures you need to compute a sighash, which is hard to do from the interpreter
- I wanted to be able to interpret miniscripts without checking the signatrues, since this is really expensive and doesn't give you much value if you're checking things that are in the chain anyway
I have a couple thoughts about how we could handle this here
- Not check the signature and offer no way to do so (this seems like a bad idea)
- Make the user pass a second closure in for this (ughh)
- Adapt the existing closure to take a message hash (ugly, doesn't really match the existing closure signature)
- Replace the existing closure with an optional secp context argument (but then how can we compute the sighash for normal checksigs?)
- Require our signatures to have R = P = 1, and then we can verify the signature with :P
None of these are really clean, but I'm leaning toward adding a second closure to the API.
Originally posted by @apoelstra in https://github.com/sanket1729/elements-miniscript/pull/4#discussion_r584986887
- Lingua principale
- Rust
- Stelle
- 15
- Fork
- 17
- Merge medio
- 19h 36m
- PR unite (30g)
- 1
Preparare l'ambiente
Non abbiamo ancora controllato i file di configurazione di questo progetto. Parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.
Come iniziare
- Leggi tutta la issue e poi la guida ai contributi del progetto.
- Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
- Fai un fork del repository e lavora su un branch.
- Apri una pull request che faccia riferimento al numero della issue.
Altre issue di ElementsProject/elements-miniscript
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 72/100
-
Difficoltà 3/5 1-2 giorni Idoneità per principianti 68/100
-
Difficoltà 4/5 3-5 giorni Idoneità per principianti 30/100
ElementsProject/elements-miniscript#80 · 4 commenti ·
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 35/100
ElementsProject/elements-miniscript#72 · 1 commento ·
-
Difficoltà 5/5 Più di una settimana Idoneità per principianti 20/100
ElementsProject/elements-miniscript#69 · 2 commenti ·
Tutte le issue di ElementsProject/elements-miniscript
Issue simili
-
`sysknife history --help` says --since takes ISO-8601, and the parser refuses offsets and bare datesApertabug easy good first issue help wanted
Difficoltà 1/5 1-3 ore Idoneità per principianti 94/100
lacs-project/sysknife#519 ·
I maintainer di solito rispondono entro 1 giorno
-
enhancement
Difficoltà 1/5 Meno di un'ora Idoneità per principianti 72/100
-
area:breg bug criticality:p3 triage:needs-implementation
Difficoltà 2/5 1-3 ore Idoneità per principianti 78/100
registrystack/registry-stack#1699 ·
I maintainer di solito rispondono entro 1 giorno
-
documentation
Difficoltà 1/5 1-3 ore Idoneità per principianti 84/100
-
Difficoltà 2/5 1-3 ore Idoneità per principianti 88/100
lbjlaq/Antigravity-Manager#3539 · 2 commenti ·
I maintainer di solito rispondono entro 1 giorno