Features - Revision history

Fireduck: /* ASIC Resistance via IO Based Proof of Work */

2020-10-20T17:43:48Z

‎ASIC Resistance via IO Based Proof of Work

Fireduck: /* UTXO in Block Header */

2019-09-03T03:52:46Z

‎UTXO in Block Header

Fireduck: /* Quantum Resistance */

2018-10-31T19:54:42Z

‎Quantum Resistance

Fireduck: migration

2018-10-30T06:00:11Z

migration

New page

== Simple - Modern, Efficient, and Readable ==

Snowblossom is written in a hopefully straightforward fashion so that anyone could verify or maybe even contribute. Snowblossom is also built deterministic ally with bazel

== ASIC Resistance via IO Based Proof of Work ==

ASICs or "Application Specific Integrated Circuits" are super powerful processors made for doing '''one''' thing, ''very'' ''very'' fast. In other cryptocurrencies, these specially created chips have created severe problems with '''miner centralization''', and as a result, threatens their censorship resistance, scaling, and more.

'''With OTHER cryptocurrency mining'''

{|
! Hardware
!align="right"| Hashes Per Second
|-
| CPU
|align="right"| 50,000
|-
| GPU
|align="right"| 100,000,000
|-
| ASIC
|align="right"| '''''14,000,000,000,000!'''''
|}

-----

Snowblossom is designed to cripple specialized hardware attempts by requiring an expanding, massive amount of readily available storage, and relies on the IOPS of that storage. In theory, even millions of dollars in equipment would not be capable of delivering much faster storage or ram.

== Quantum Resistance ==

It is estimated by people much smarter than I that 256-bit elliptic curve (like bitcoin uses) could be broken by a quantum computer with about 1600 qubits. RSA is expected to take 2x the key size (in bits) in qubits.

So a reasonable long term storage multisignature scheme might be a 3of3 consisting of:

* standard secp256k1 - in case someone breaks factoring to break RSA
* RSA 8192-bit - in case someone builds a quantum computer with a few thousand qubits
* DSTU 4145 - just to include something a bit different

This is enabled in the SnowBlossomClient. Simply put "key_mode=qhard" in your configuration before you make your wallet.

[https://explorer.snowblossom.org/?search=5dc53f864b6d060f218284121e67c3da85ede422ebe28786510dd3ea371c79b0 QHard TX]

Note: the public keys and signature (which need to be included in a spending transaction will be large for that large of RSA). A transaction spending such a scheme would be at least 4k plus normal transaction overhead, so probably around 4.4k. Compare to a regular standard EC transction, which is around 270 bytes.

So it might cost more in fees but could easily be worth it.

Also, since Snowblossom is designed to support multiple signing algorithms, if someone comes up with a new signing method it can easily be added.

* [https://en.wikipedia.org/wiki/Elliptic-curve_cryptography#Quantum_computing_attacks EC - Quantum_computing_attacks]
* [https://crypto.stackexchange.com/questions/35137/how-many-qubits-are-required-to-break-rsa-2048-or-4096-with-a-universal-quantum how-many-qubits-are-required-to-break-rsa-2048-or-4096-with-a-universal-quantum]

== Multi-algorithm Multi-sig ==

Snowblossom supports multisignature addresses that can take any number and combination of signing algorithms. For example, a user could combine standard secp256k1 keys just like Bitcoin multisig. Or could combine algorithms to meet a specific need.

== Space efficient signing ==

Signing is done at the transaction level, not the input level so if there are multiple inputs that need the same public key, a single signature signs for them all. This makes spending a bunch of small inputs much more efficient in transaction size and computation time.

=== Multiple signing algorithms supported ===

Snowblossom supports the following signing algorithms. The user can pick whichever ones they want to use.

{|
!width="25%"| Algorithm
!width="25%"| Public Key Size
!width="25%"| Signature Size
!width="25%"| Notes
|-
| EC secp256k1 (compressed)
| 33
| 71
| Just like Bitcoin - standard
|-
| EC secp256k1
| 56
| 71
|

|-
| EC secp384r1
| 72
| 103
|

|-
| EC secp521r1
| 90
| 138
|

|-
| EC sect571k1
| 96
| 149
|

|-
| EC sect571r1
| 96
| 151
|

|-
| RSA
| key_size/8 + 30
| key_size/8
| Pick your own key size
|-
| DSA 3072
| 1227
| 70
|

|-
| DSTU4145
| 62 to 95
| 44 to 110
| Size options go from DSTU 4145-163 to DSTU 4145-431
|}

Sizes vary slightly. This is just a rough idea.

== Chain based voting clearly implemented ==

To keep things simple, each block header has a spot in the protocol where miners can clearly signal agreement or disagreement to numbered proposals. This is both clear and space efficient.

== Separate node and wallet ==

In my opinion, a cryptocurrency node is like a big public database, which as the public transaction ledger, it is. For security and isolation reasons it makes sense for that to be separate from the wallet software which holds the private keys. Ideally for privacy a user would only use a node that they directly control, however it is nice to be able to have that node physically or logically separated from the very important private keys.

Snowblossom is build where each node acts as a server to light weight clients (like electrum server in bitcoin) and the client can use any node (again, ideally one controlled by the wallet owner).

== UTXO in Block Header ==

Since the nodes are designed to serve light clients, we've built the UTXO (Unspent Transaction Output) merkle root into the block header. This way, the nodes can provide cryptographic proof that the results they are giving to clients are the whole and complete truth. If a node made up or omitted or modified an output the hashes would no longer match and it would be obvious to a client checking the data.

== Other Typical Features ==

* Block Time Average of 10 minutes
* Child-pays-for-parent (CPFP)
* Transaction immutability
* Double-spend protection
* Resilient peer-to-peer network
* Decentralized design
* Halfing-block reward over time
* First Seen First Added [https://www.yours.org/content/bitcoin-cash--bch--is-effectively-quantum-computing-attack-resistant-adbcd22b87b9 FSFA]

@@ Line 3: / Line 3: @@
 Snowblossom is written in a hopefully straightforward fashion so that anyone could verify or maybe even contribute. Snowblossom is also built deterministic ally with bazel
-== ASIC Resistance via IO Based Proof of Work ==
+== StoatPOW - ASIC Resistance via IO Based Proof of Work ==
 ASICs or &quot;Application Specific Integrated Circuits&quot; are super powerful processors made for doing '''one''' thing, ''very'' ''very'' fast. In other cryptocurrencies, these specially created chips have created severe problems with '''miner centralization''', and as a result, threatens their censorship resistance, scaling, and more.

← Older revision		Revision as of 03:52, 3 September 2019
Line 118:		Line 118:

	Since the nodes are designed to serve light clients, we've built the UTXO (Unspent Transaction Output) merkle root into the block header. This way, the nodes can provide cryptographic proof that the results they are giving to clients are the whole and complete truth. If a node made up or omitted or modified an output the hashes would no longer match and it would be obvious to a client checking the data.		Since the nodes are designed to serve light clients, we've built the UTXO (Unspent Transaction Output) merkle root into the block header. This way, the nodes can provide cryptographic proof that the results they are giving to clients are the whole and complete truth. If a node made up or omitted or modified an output the hashes would no longer match and it would be obvious to a client checking the data.
		+
		+	The UTXO is stored in a structure called a [[Hashed Trie]] which has some unique and cool properties.

	== Other Typical Features ==		== Other Typical Features ==

@@ Line 28: / Line 28: @@
 Snowblossom is designed to cripple specialized hardware attempts by requiring an expanding, massive amount of readily available storage, and relies on the IOPS of that storage. In theory, even millions of dollars in equipment would not be capable of delivering much faster storage or ram.
-== Quantum Resistance ==
+== Quantum Tough ==
-So a reasonable long term storage multisignature scheme might be a 3of3 consisting of:
+Content moved to [[Quantum Tough]]
 == Multi-algorithm Multi-sig ==