summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorBryan Bishop <kanzure@gmail.com>2016-11-22 10:56:46 -0600
committerBryan Bishop <kanzure@gmail.com>2016-11-22 10:56:46 -0600
commitdbd7377d0ccec1432371cab31b39198a09f2a83a (patch)
tree13adbf18ebb67df85344b879ca6fed02b2adb302
parent7c2c3ba366685df3901232dbb1040438082ef818 (diff)
downloaddiyhpluswiki-dbd7377d0ccec1432371cab31b39198a09f2a83a.tar.gz
diyhpluswiki-dbd7377d0ccec1432371cab31b39198a09f2a83a.zip
fix typo
-rw-r--r--bitcoin/somewhat-open-problems-draft.mdwn2
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.