diff options
author | Bryan Bishop <kanzure@gmail.com> | 2016-11-22 10:56:46 -0600 |
---|---|---|
committer | Bryan Bishop <kanzure@gmail.com> | 2016-11-22 10:56:46 -0600 |
commit | dbd7377d0ccec1432371cab31b39198a09f2a83a (patch) | |
tree | 13adbf18ebb67df85344b879ca6fed02b2adb302 | |
parent | 7c2c3ba366685df3901232dbb1040438082ef818 (diff) | |
download | diyhpluswiki-dbd7377d0ccec1432371cab31b39198a09f2a83a.tar.gz diyhpluswiki-dbd7377d0ccec1432371cab31b39198a09f2a83a.zip |
fix typo
-rw-r--r-- | bitcoin/somewhat-open-problems-draft.mdwn | 2 |
1 files changed, 1 insertions, 1 deletions
diff --git a/bitcoin/somewhat-open-problems-draft.mdwn b/bitcoin/somewhat-open-problems-draft.mdwn index 9661a07..67a0b36 100644 --- a/bitcoin/somewhat-open-problems-draft.mdwn +++ b/bitcoin/somewhat-open-problems-draft.mdwn @@ -38,7 +38,7 @@ It would be interesting to give a way for CPU mining to give subsidy rewards to * (2) Interactive protocol and proofs between 2 nodes to do secure multiparty computation, to prove that all parties are running bitcoin consensus validation rules. Don't send coins to someone who isn't running bitcoin consensus rules. Or, alternatively, don't send coins to somebody who isn't at least participating in CPU mining. -* (3) Transactions could encode proofs of consensus enforcement and validation work by their nodes (either sender or recipient, probably sender). Consensu-enforced rule could be introduced that transactions must conform to this format? +* (3) Transactions could encode proofs of consensus enforcement and validation work by their nodes (either sender or recipient, probably sender). Consensus-enforced rule could be introduced that transactions must conform to this format? * (4) utxo set + private key + snark could be used to show that a node at least has a utxo set that they can do computation with (or that they are silly enough to outsource their private key...) however it only shows that they have the utxo set data, not that they are doing validation work with consensus rules... oops. |