-
Notifications
You must be signed in to change notification settings - Fork 785
Rejected features
It would be possible to put a send and receive action in to a single block but this would require a connection and agreement between the sender and receiver as to where the transaction should go in their respective block chains. Connecting in order generate a transaction would add complexity and breach much of the pseudonymity of the ledger. Interlocked transactions could also temporarily freeze either account for fork resolution if either of them generated a fork.
It's possible to express each account balance as a fraction of the total coin supply. This would require peers to be able to operate on large rational numbers and there would need to be consensus guarding against fractions with large numerators and denominators that represents a disproportionately small balance. Using a fraction would also make block size variable which can hurt some block storage optimizations. The only necessary form of fractional balance would be n/2^m where m can be increased to generate smaller balances. This complexity seems unnecessary if we operate on integral coins from a sufficiently large pool.
It would be possible to construct blocks that could take multiple inputs and multiple outputs but this adds complexity to the receiving part of a transaction because we not only have to name the source send block but which entry in the send block we're receiving. This would also make blocks variable size which requires framing and hurts some block store optimizations. The same block would also be in multiple chains and the entire block would need to be rolled back if any the entries created a fork. Multiple inputs and outputs greatly increases complexity of the ledger algorithms.
We decided against using FIPS and NIST elliptic curves for a number of reasons. NIST and FIPS curves have some undesirable properties from an engineering standpoint, the recommended curves around the security range we're looking for, 256bit, were either far off from this number e.g. 233 or 283 bits, or were very close but inconveniently not exactly 256 bits e.g. they're 256 bits plus 1 sign bit. These curves also have a number of undesirable properties from a side-channel analysis perspective making decisions based on secret information which leaks timing information and given enough time can leak the keys used. There are a number of other complicated implementation details that are hard to get right. Attackers like difficult things because difficulty leads to mistakes and mistakes lead to vulnerabilities. ED25519 is an incredibly easy to use digital signing scheme, for more information see http://ed25519.cr.yp.to/
Some cryptocurrencies try to provide interoperability to other systems or to a physical asset in the hope of providing a secure trading mechanism. The correctness and security of these schemes can range from difficult to implement requiring changes to all involved system, to single-directional, to completely broken. We felt a better and more reliable way to trade between systems is via a trusted escrow service rather than attempting to build it in to the security layer. Ultimately when RaiBlocks are exchanged for a physical asset there will need to be dispute resolution system that's better provided by an entity with legal recourse.
Like most other cryptocurrencies, RaiBlocks is pseudonymous via account numbers. There is research being done in to true anonymity but we haven't yet found a design that's correct and practical.
Many other cryptocurrency protocols include some ability to include sideband data with transactions. The idea is for applications to use this information in some way. The two main reasons why we chose to not include a block message are:
- People tend to not understand what guarantees come with the message. Some applications built on top of using these messages are poorly implemented and don't give assurances users think they do.
- Going with the theme of minimizing data footprint we felt putting messages in blocks when people might infrequently use them would bloat the size of the ledger to little benefit.
Though someone could use steganography to put a message in to the balances being transferred, we encourage people to put sideband data in a sideband channel rather while allowing the RaiBlocks layer to be devoted to managing ledger transfers.