Bitcoin Forum
October 28, 2021, 12:02:26 AM *
News: Latest Bitcoin Core release: 22.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 [70] 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 ... 200 »
  Print  
Author Topic: [SKY] Skycoin Launch Announcement  (Read 381231 times)
tobeaj2mer01
Legendary
*
Offline Offline

Activity: 1098
Merit: 1000


Angel investor.


View Profile
November 24, 2014, 09:22:21 AM
 #1381

@skycoin
Do you know Meshnet project, it is promising too.
https://projectmeshnet.org/

Sirx: SQyHJdSRPk5WyvQ5rJpwDUHrLVSvK2ffFa
1635379346
Hero Member
*
Offline Offline

Posts: 1635379346

View Profile Personal Message (Offline)

Ignore
1635379346
Reply with quote  #2

1635379346
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1635379346
Hero Member
*
Offline Offline

Posts: 1635379346

View Profile Personal Message (Offline)

Ignore
1635379346
Reply with quote  #2

1635379346
Report to moderator
Lordoftherigs
Sr. Member
****
Offline Offline

Activity: 313
Merit: 250


View Profile
December 01, 2014, 03:33:47 PM
 #1382

is it possible that skycoin will launch in Q1 2015 ? or is it too optimistic view ?
yourstruly
Sr. Member
****
Offline Offline

Activity: 308
Merit: 250


thrasher.


View Profile WWW
December 01, 2014, 03:40:22 PM
 #1383

"Skycoin protects its users from identification for increased safety in hostile countries (ex. HTTPS/TLS tunneling)"

How does HTTPS connections protect your privacy? It encrypts the data within but all the meta data is still available.

A lot of this sounds interesting but a lot comes off as someone talking about technology they don't understand. I would be interested in learning more to see if there is something to this or if its just marketing.

Excoin - Innovative Cryptocurrency Exchange - https://exco.in
LemonAndFries
Sr. Member
****
Offline Offline

Activity: 462
Merit: 250


View Profile
December 03, 2014, 03:43:05 AM
 #1384

Still watching and waiting.

Very promising tech if it ever launches
juicejoyce
Legendary
*
Offline Offline

Activity: 882
Merit: 1001



View Profile
December 03, 2014, 12:39:06 PM
 #1385

is it possible that skycoin will launch in Q1 2015 ? or is it too optimistic view ?
many people are watching the project,
any update from dev?

.Ambit.    ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  █████
██
████████████
   Become part of the mining family   
✔ SECURED  │ WHITEPAPER │  ★ 171% ROI
██   
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
█████  ██
██
████████████
wktian
Jr. Member
*
Offline Offline

Activity: 44
Merit: 13


View Profile
December 03, 2014, 02:27:55 PM
 #1386

# command-line-arguments
cmd/skycoin/skycoin.go:202: cannot use "github.com/skycoin/skycoin/src/cipher".MustPubKeyFromHex("02b0333bd8f1910663b8b1f60fb2e154b70436a2c19efb79cdbdf09bf9bb2056dc") (type "github.com/skycoin/skycoin/src/cipher".PubKey) as type string in field value
cmd/skycoin/skycoin.go:203: unknown Config field 'BlockchainSeckey' in struct literal
cmd/skycoin/skycoin.go:412: cannot use c.BlockchainPubkey (type string) as type "github.com/skycoin/skycoin/src/cipher".PubKey in argument to "github.com/skycoin/skycoin/src/cipher".AddressFrom
juicejoyce
Legendary
*
Offline Offline

Activity: 882
Merit: 1001



View Profile
December 04, 2014, 09:03:33 AM
 #1387

# command-line-arguments
cmd/skycoin/skycoin.go:202: cannot use "github.com/skycoin/skycoin/src/cipher".MustPubKeyFromHex("02b0333bd8f1910663b8b1f60fb2e154b70436a2c19efb79cdbdf09bf9bb2056dc") (type "github.com/skycoin/skycoin/src/cipher".PubKey) as type string in field value
cmd/skycoin/skycoin.go:203: unknown Config field 'BlockchainSeckey' in struct literal
cmd/skycoin/skycoin.go:412: cannot use c.BlockchainPubkey (type string) as type "github.com/skycoin/skycoin/src/cipher".PubKey in argument to "github.com/skycoin/skycoin/src/cipher".AddressFrom

what that means for skycoin?
code is ready?

.Ambit.    ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  █████
██
████████████
   Become part of the mining family   
✔ SECURED  │ WHITEPAPER │  ★ 171% ROI
██   
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
██  ██
█████  ██
██
████████████
wizzardTim
Legendary
*
Offline Offline

Activity: 1708
Merit: 1000


Reality is stranger than fiction


View Profile
December 04, 2014, 04:20:09 PM
 #1388

# command-line-arguments
cmd/skycoin/skycoin.go:202: cannot use "github.com/skycoin/skycoin/src/cipher".MustPubKeyFromHex("02b0333bd8f1910663b8b1f60fb2e154b70436a2c19efb79cdbdf09bf9bb2056dc") (type "github.com/skycoin/skycoin/src/cipher".PubKey) as type string in field value
cmd/skycoin/skycoin.go:203: unknown Config field 'BlockchainSeckey' in struct literal
cmd/skycoin/skycoin.go:412: cannot use c.BlockchainPubkey (type string) as type "github.com/skycoin/skycoin/src/cipher".PubKey in argument to "github.com/skycoin/skycoin/src/cipher".AddressFrom

what that means for skycoin?
code is ready?

Looks like a type casting related error

Behold the Tangle Mysteries! Dare to know It's truth.

- Excerpt from the IOTA Sacred Texts Vol. I
newtothescene
Full Member
***
Offline Offline

Activity: 147
Merit: 100


View Profile
December 05, 2014, 03:45:13 AM
 #1389

Blizzard must be behind this project. 

Coming Soon™




Still watching this and have high hopes for it Smiley
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
December 09, 2014, 07:39:03 PM
Last edit: December 11, 2014, 02:54:42 PM by skycoin
 #1390

Update


Consensus Algorithm

We have a new member on team focused on the consensus algorithm. His work has been great and we are making a lot of progress.
 We now have a discrete event simulator in Python and have tested several candidate consensus algorithms on real world social graphs from the wikimedia admin dataset. Failure modes such as collusion, or nodes timing out have been implemented and tested.

The naive consensus algorithm, converged quickly enough for 15 second blocks. Refinements to this algorithm have been developed which have significantly faster convergence rates. I think the main consensus algorithm will be ready to be written in Golang and moved into the code base within a few months.

The single round decision context is worked out. It is much simpler than Ripple. It can be understood by a human. It can be modeled mathematically. Simulations can be performed against different attacks easily. The implementation will be only a few hundred lines of code after libraries are pulled in. Consensus occurs in public, so it can be audited for manipulation by anyone.

This system will quickly eliminate need for PoW for securing blockchains. I will leave analysis of the algorithm and its advantages till after release.

Meshnet Update

It has been two and a half years since the begining of project meshnet and OP redecentralize.

https://www.youtube.com/watch?v=1tEkyLOh-tY

In July we finished implementation of the basic meshnet/darknet. Upon testing, we discovered that Wifi is unable to provide the range or bandwidth required for a viable meshnet.

We do not believe that is feasible to build a viable meshnet with 802.11 on the 2.4 Ghz band. We determined that if every third house in city, had a meshnet node, the nodes would be unable to connect to each other. 802.11n devices are using multiple bonded overlapping channels and competitive transmission power. Attempting to connect two meshnet nodes over a house with an 802.11n device, results in the device increasing transmission power until the link connectivity fails.

The range of devices on the 2.4 Ghz band for 802.11 will never exceed 500 ft and beamforming had not resulted in significant range improvements for wifi. However, free space performance is very good. 100 Mb/s, 50 km line-of-sight links are easily possible for backhaul. Signal attenuation is less than 0.2 dB per km in free space.

There was debate over whether we should go forward with IPO, until we are certain that we are able to deliver a working meshnet.

After nearly six months of research and testing, we have found solution to the range limitations. We believe a viable meshnet is possible. However, the work required is significantly more than anticipated. We need FPGAs (later ASICs), directional antennas and to develop a software defined radio platform for operating on the 600 Mhz to 700 Mhz whitespace bands. We have a few hundred pages of notes on the radio requirements that are being edited, organized and prepared for publication.

Cryptosystems for Geographic Time Scales: Future Proofing Skycoin

Gold has retained value for thousands of years and had relatively low interest rates. Bitcoin may not survive on that time-scale because of social and technological advance. Gold may lose its scarcity if future improvements in robotics or mining technology dramatically reduce cost of gold extraction. Future advances (such as robotics) may allow mining large quantities of previously inaccessible gold veins deep in the earth, on the ocean floor or in space.

Gold may fail as a store of value, within the next hundred years. As gold prices increase, more deposits become profitable to extract from. This price dynamic puts a price ceiling on gold. If price increased 100x, then ocean floor production or marginal productivity mining sites become profitable, and supply increases, until the supply meets the demand curve.

Mathematics such as cryptography allows us to create new assets, which are scare and superior to gold in many ways. However, there is no insurance that these mathematics/software systems can be stable over hundreds of years of technological and social change.

Future Proofing Skycoin: Salted Hashes at Network Level

Bitcoin, Skycoin's hashing and cryptography algorithms will be vulnerable within twenty years. Skycoin can survive complete vulnerability and defeat of SHA256. There are two methods for this

Salted Hashes:
- Each person generates a random "salt" and the data to be hashed is salted.
- The SHA256, the salt value and salted hash is sent.
- You download the data for the hash one peer. (you want to verify the data you received is not different than the data other peers have for same hash, even if SHA256 is easily preimaged attacked)
- You have the salted hash of the data, computed by a list of user selected trusted peers and all the peers you are connected to.
- You compute the salted hash of the data received, using the salt value, for each for the trusted peers.
- If the salted hashes match, for each peer then the data is correct.
- If the data was modified, so that it has same SHA256 hash as intended data but is something else, then its easily detected.

If the internal state of the hash algorithm, between rounds is N bits and the hash salt value is M bits and its validated against n peers, then if n*M is greater than N, then it is not even possible to generate a piece of data that will pass the n salted hash checks (with probability 1).
- even if the hashing algorithm is completely weak (you could use XOR function), as long as outputs of hash are "random enough" function of the input and salt value
- even if the opponent knows the peers and salts that the hash will be validated against.
- We can prove this with Kolmorogov complexity theory.

Future Proofing Skycoin: Rolling State Hashes at Blockchain level

Salted hashes are very useful for validation at the network level, assuming the hashing algorithm is broken and weak against preimage attack. This is one way of future proofing Skycoin so that will continue to operate, regardless of future mathematical or computational advances.

Another future proofing mechanism, is that the Skycoin blockchain state is functional and has canonical binary serialization. If S is the state of the block chain and B is a block, then there is function mapping S x B -> S. The block is applied against the state and there are no side effects, in that output only depends on the two inputs.
- a block is validated transaction by transaction (to make sure they are valid)
- the transactions are validated against each other (to make sure they do not double spend the same inputs or conflict)

There is a canonical binary serialization of the outputs and the "state" of the blockchain. As operations are applied that change the blockchain state, the inputs to these operations can be rolled into a hash. Each block must have a matching hash, for the internal state which it was created to be applied against.

This means, that two clients will only arrive at the same internal state hash from the genesis block, only if they applied the same sequence of blocks. Even if SHA256 is broken completely, there is no way to generate a valid sequence of blocks that will be accepted for Skycoin. For Bitcoin, if SHA256 is broken, an adversary may be able to construct and insert a modified block between two blocks in the chain and it will be accepted.

These safety measures at the network and blockchain level were developed, after analyzing Bitcoin against "oracle attacks", where we assume a god-like computer can do arbitrary SHA256 preimage and collision attacks attacking the blockchain.

Future Proofing Skycoin: Cryptography For Geographic Timescales

Can a software system based upon cryptography operate securely for hundreds of years, despite future advances in mathematics?

secp256k1 will be broken or insecure within a few decades. The development of a quantum computer would eliminate the security of existing public key systems. RSA, secp256k1, Bitcoin and to a lesser extent Skycoin would be vulnerable to attacks.

In Bitcoin/Skycoin, if an address has never been used before, only the owner knows the public key. Therefore an adversary who can break sepk256k1 has to wait until someone uses the address in a transaction to begin attacking. If a user can break secp256k1 and generate a privatekey from a public key in 200 hours of work, they can steal coins from addresses suffering from address reuse.

If they can break secp256k1 in under 10 minutes, they can read public keys off transactions, recover the private key and inject a new transaction that spends the coins before the other person's transaction is in a block. They can have a higher reward for the transaction and Bitcoin miners will prefer the theft transaction, to the original. Miners may even orphan blocks, to collect the higher transaction fees from the theft transactions.

In Skycoin
- With blocks at 3 to 15 seconds each (maybe even 1 second depending on how testing goes), there is less time and ability to crack public keys
- address reuse is mostly being eliminated. It is still allowed, but we are moving towards options with better usability and security. If you have a users public key, you can generate new addresses for that user, that have never been used before. You have a public key and salt value and give it to user and they can generate infinite addresses for you, with ECDA. Even if the pubkey is published and private key recovered, both the pubkey and salt need to be recovered to steal the funds.
- Communication addresses allow you to request a new address for transaction. Most transactions will eventually have receipts/invoices for ecommerce (hopefully machine readable). We are streamlining usability here.
- Today, you can view your credit card invoice, but you cant click an item and see what items you bought at grocery store and spent $30 on. You cannot click an item on bill and see the tracking number for shipping or where it was mailed to. You cannot click a payment and be able to message the merchant. In Skycoin, this will eventually be integrated and receipts/invoices may even be machine readable someday. "Communication addresses" are at a level above the blockchain and eliminate address reuse. The whole purpose of asynchronous messaging infrastructure is to support this. The communication addresses are used for DHT lookup and are shorter than Bitcoin addresses, but are secure until the hashing algorithm is broken. If the hashing algorithm is broken, it can be upgraded to an unbroken hashing algorithm. If no secure hashing algorithms exist, then longer or unique communication addresses needed. This decreases usability (long strings to type in, no autocomplete), but is still secure in the event of advances that render all known hashing systems insecure.
- If an attacker can crack a public key, recover private key in under 1 second, there is also a commitment scheme. We plan to have signatures on the people introducing blocks to network. If you need secrecy, you can communicate the block directly to block creator, without public publication until it is entered into the block. If the attacker is not colluding with the block publisher, the network can continue operation securely until solution is found.

So there are different attacks
- an attack that recovers private key from public key in 200 hours (Skycoin is OK. Bitcoin address with address reuse, get coins stolen).
- an attack that recovers private keys from public keys in 5 minutes (Skycoin is OK. Bitcoins used in transactions are being stolen).
- an attack that recovers private keys from public keys in less than 1 seconds (Skycoin needs upgrade in cryptography but can still operate if the servers created blocks are not colluding with attackers)

If there is a closed set of servers, elected by the consensus network which mint the blocks and there is commitment scheme that allows a server colluding with the attacker to be identified and the individual transactions are small enough ($1000) that they are not worth detection over, then the network may be able to continue operation, for hundreds of years, even if secp256k1 is broken.

One commitment scheme
- there is finite set of elected servers who create blocks
- a person publishes their transaction to one of those elected servers, who keeps it secret
- the elected servers communicate transactions to each other as hashes
- the elected servers come to unanimous consensus about the ordering of the transactions in the next block, without any of the servers knowing what the transactions are
- the transactions are revealed after the next block is determined

A more advanced consensus scheme uses an N of M approach, which requires collusion of N servers to collude/cheat to achieve knowledge about the public key.
- a finite set of servers who creates blocks
- a person publishes their transaction to N of M of the minting servers, with secret sharing. Each server have a token identifying the transaction. The N servers need to exchange information to reconstruct the transaction.
- the servers agree on the order of transactions in the next block
- the servers exchange the secrets needed to construct the transactions
- the servers enter the block

Therefore, we believe that a system exists that can survive, even if secp256k1 and all existing public key cryptography are broken. Lamport-signatures will also still work, as long as hash preimage and collusion attacks remain difficult.

Future Proofing Skycoin: Attacks on the Address Generation

The weak part may be the relationship between the addresses and the publickey. Future 3-SAT solvers may be able to invert this relationship within sixty years for Bitcoin addresses. They would have to find a preimage of two SHA256 and an RIPMD160 compression.

The 65 byte public key (520 bits) maps into a 256-bit (32 byte) value from the SHA256 and then is compressed to 160 bits (20 byte) by RIPMD160. For each address, there are 2^96 preimage public keys. Each 32-byte, 256 bit private key maps into a 520 bit public key. Bitcoin uses DER encoding, which may allow malleability and reduce security over a canonical form, however I have not looked at implementation.

With a canonical form, there are a finite number of preimages that are valid public keys, but with DER encoding there may be an infinite number of valid preimage keys and it could be vulnerable to future length extension attack, based upon how SHA256 hashes data blocks together. Skycoin is using a canonical form without malleability. If Bitcoin accepts mutable signatures in DER, there may be an infinite number of input public keys that pass, unless Bitcoin firsts reduces the DER format into a reduced form (removing zero padding). However, there are only a finite number of valid preimages for Skycoin addresses (fixed length, canonical form).

Skycoin has 33 byte compressed pubkeys hashed to 32 bytes (double SHA256), then reduced to 20 bytes (RIPMD160). Private keys are 32 bytes and almost every privatekey corresponds to a valid pubkey. This means that the chance a valid 32 byte seckey exists, for a randomly generated 33 byte public key is better than one in 256.

This means, that if a preimage attack on y = SHA256(SHA256(RIPMD160(x))) is possible, that there are 2^96 preimages and fewer than 256 of them need to be found, before a publickey is found that has a valid seckey, that could possibly recovered. Therefore if secp256k1 and the preimage attack on SHA256(SHA256(RIPMD160(x))) become possible separately, both Bitcoin and Skycoin balances become insecure, even for addresses who public key have not been published.

An improvement to Bitcoin's address function, would be to ensure that statistically, there are a large number (2^96) preimages, to the hash, but that statistically very few (ideally only one) of them has a valid seckey for the resulting preimage of the address.

Another method, is to allow the attack, but only keep balances in 1 to 5 coin amounts per address. If it cost $5 in resources or effect to steal $1 from a random, unknown user, then the money is safe. Deterrence and frustration may ultimately be the only security possible.

The Skycoin addresses are prefixed with a version byte (currently 0), so we can upgrade later if either a preimage attack or secp256k1 is broken. Once communication addresses and asynchronous messaging are implemented, we may move away from 20 byte "human sized" addresses at blockchain level.

coin@coin
Legendary
*
Offline Offline

Activity: 1722
Merit: 1000



View Profile
December 10, 2014, 01:52:00 PM
Last edit: December 10, 2014, 04:48:43 PM by coin@coin
 #1391

Great update! Now I have something to read, will take a little while to digest.
I'm glad to see ongoing progress!  Smiley
chompyZ
Sr. Member
****
Offline Offline

Activity: 291
Merit: 250


View Profile
December 11, 2014, 09:18:50 AM
 #1392

There is nothing in the crypto-space that i like to read as much as these updates.
It WOWs me every time.

The crypto evolution is not a quick fad that rises and falls in a year.
It takes years to develop, with a lot of ingenuity and patience.
Way to go!!!
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
December 11, 2014, 02:22:33 PM
 #1393

Update

This is over view of current development status and priorities

Consensus

Consensus is being worked on. The earlier algorithms are being implemented, bench-marked. Then testing them against the newer algorithms, so we have comparison. This is currently in python. Will be moved to golang and integrated as soon as its ready.

This is not required for IPO, because we can use central signing key until decentralized consensus is implemented. 

Coin

The coin is mostly done. There are only a very few changes.

Right now, visor is managing wallets and the json API daemon is inside of daemon. We want to move the wallet management and json daemon into its own library. The webwallet interfaces through JSON API daemon and the daemon hooks in to visor through function calls. We want the json API to be very close to Obelisk/Dark Wallet. We believe the Dark Wallet API is better than the Bitcoind API.

Once consensus is done, it will act as a state controller for visor.

In Bitcoin, loading wallets takes too long, because the whole blockchain needs to be loaded from scratch and the whole history scanned. Skycoin uses a leaner interface. When a wallet is loaded, the addresses are checked for unspent outputs associated with the address. So checking current balance is instant. The API will also allow you to check balances for addresses, without have the private keys loaded. There are many things you cannot do in bitcoind (like check balances for address easily) and we think Obelisk/Dark Wallet has the best API for developers and want to move away from bitcoind.

The local client and remote/thin clients will be on same API. You can run APIs for balances or injection transactions on a local or remote server just the same. So a cell phone who does not have a copy of the blockchain, but has a wallet file can query balances or inject transactions.

History is not implemented right now. It will likely be a separate library on top. It is outside of the core, needed to run the blockchain. The blockchain on disc will have the blocks and will have copy of unspent output set at interval. Then it can rewind back a month to an unspent output set, then apply the blocks in that month in order until the next checkpoint. So we can load wallet histories going from most recent transactions, going farther back in time.

This means wallets will load instantly, balances will be available instantly, coins can be sent instantly and history (when implemented) will load in background. As the Bitcoin blockchain gets longer, loading wallets will continue to slow down.

Skycoin already has multiwallet support, so you can load/unload multiple wallets in the client. Importing deterministic wallets from keys need to be added to the gui, after the wallet internals and refactor is done.

Bitcoin used Berkeley Key value store for serialization format of the wallet and there was problems. As the library was updated, only version wallets from very early Bitcoin versions, appeared empty when loaded. The old serialization format could not be loaded by the new client. So a wallet may say it is empty, but actually contain 100,000 Bitcoin. You have to manually extract the private keys with a tool and then reimport them on the command line. This caused some confusion and frustration.

Skycoin is using a JSON wallet format. All wallets are deterministic and the generation key will be in the wallet file. As long as you have the wallet seed, you can recover the private keys and coins. The internal format of the JSON wallet is something we have not had time to think through and finalize, but we can safely nuke everything in the wallet file except the wallet seed without risk of losing coins when the wallet storage format is upgraded.

In Bitcoin using unspent output set snapshots was a security risk, because there was no way to validate them without starting from the genesis block and applying every block since genesis. In Skycoin, there is a rolling hash of the operations applied to the blockchain state, so if you have two checkpoints and apply the blocks between the checkpoint to the first checkpoint, you will get the second checkpoint. This means that the blockchain can be divided into check point intervals and each interval can be validated in parallel. So you can validate backwards and can validate forwards, where as Bitcoin only lets you validate forwards.

The system is designed that way, so eventually you will not need to have the whole blockchain on every node. A node only needs a trusted copy of the unspent output set and then every block since that checkpoint. Then it can check balances and inject transactions.

We are evaluating this. We will probably have two hashes. One is the XOR of the SHA256 of each unspent output at the beginning of the block. This is weak hash, but has constant time to update. In theory, someone can add ~300 unspent outputs to the set and find a subset that generate the same same hash for this. We are not relying on this for validation, but it is good for sanity checking.

Checkpoints of the unspent output set need to have a full merkle-tree hash of the SHA256 of the serialization of each unspent output and have to be tied to a particular block header. The checkpoint needs to be signed by a public key of person who vouches for it. If check points are enabled, you would put in public key for ~8 trusted nodes (exchanges, friends, maybe dev key). It would download the 8 copies of the checkpoint hash from each person and make sure they all agree. If two different people in the trusted set have different hashes for the serialized unspent output set at a given checkpoint, then client should go into a warning/emergency mode until it is resolved by user.

The second has is a merkle tree root of the SHA256 of the serialization of the consumed/produced outputs from the block, accumulated into the hash from the previous block. This makes the block header, not only a function of the previous block input, but also a function of the "state" of the blockchain (the unspent output set) when the block was applied. There are three levels
- block header is only function of previous block header and transactions (data in the block), (Bitcoin does this)
- block header is a function of previous block header, contents of current block and subset of "state" the block is being applied against (Skycoin)

We are trying to determine if this adds anything or if it is redundant. If two clients have different internal state, such as an output being created and then having bit flipped randomly in the balance by hardware failure, this will detect the divergence in the next block if the affected data is an input (consumed) or output (created by) of the transaction. This will also detect an error, where a 32 bit system or 64 bit system output different values (rounding errors, optimization, different versions of compiler).

We can catch these errors in the next block, where as in Bitcoin they may persist many blocks until the unspent output is used and then cause a fork. For instance, this method guards against unintentionally introduce rounding errors and protects against the Block Index 0 fork, if Satoshi tried to spend the reward on block 0. We catch the non-determinism in the output set, in the next block.

If two people apply the same block against different states, the header of the accumulator hash in the next block will be different (ideally). Ideally, you would compute a hash of the full state, each block. However, we could not find a fast enough updating function for this and felt a full merkle tree hash each block would slow down block validation too much. The best compromise, is to check the full merkle-hash at the checkpoints. The full merkle-hash will also detect any single bit-errors, in any outputs that have not been spent yet.

Coin Development Priorities

IPO Requirements:
- move JSON API/wallet management into its own library, out of visor/daemon
- make the JSON API look like Obelisk/Dark Wallet, so that balance of addresses can be checked without loading wallet. Allow unspent outputs to be queried for address without loading wallet. Allow transaction injection. Allow fine grained control of which inputs are used in transaction and the outputs created.
- update webwallet to use new API, add deterministic wallet import

Longer Term:
- figure out what is in skycoin/daemon and replace the daemon with the skywire daemon. This is required for consensus integration.
- blockchain history, API for history queries?

Skywire Development Priorities

Skywire has multiple components and it was not clear how things should be structured.
- there needs to be a base interface for a physical "connection" where bytes come in through callback function and bytes can be written out. Polling should be minimized, to avoid adding 1 ms per hop.
- we assume messages are 4 byte length prefixed, so there should probably be "bare metal" layer beneath current golang abstraction.
- we need to make route setup simple, for creating route from A to B to C. Protocol needs to be worked through, finalized. Or just get it working and break it later.
- If a user receives a pubkey hash for an endpoint, they must be able to find a route to that pubkey over network. Nodes either must self-publish connectivity through DHT or service must scrape the network topography. Easiest first version is publication through DHT, with latency/performance self-report, then move towards 3rd party reports.

Skywire Advanced/Not Essential
- bonding multiple routes into a route at application layer
- meet-in-middle type "hidden services" advertised on multiple nodes. This was scrapped in version 1. Version 1 assumes a daemon has single public key and each daemon can run multiple applications, which listen. Opening port on remote node and advertising multiple endpoints is separate.
- RPC for exposing golang objects over network. This may not be used for anything. May improve services implementation?
- syndicated asynchronous messaging. not used for anything yet. based on XMPP. may be needed for short UDP like packets for some types of lookups or communication.

DHT
- need serialization format. Just list of 16 bit key, 32 bit length, bits. Is there better serialization format for entry? Just use this for now
- key is hash of public key, there is a PoW hash to prevent spam,
- assume full replication of whole DHT, between all nodes with gossip protocol.

Merkle-Dag
- this is the most important part to users, but on back-burner because it is not blocking completion of anything else right now

Goal:
- get minimum skywire working for routes
- get minimum DHT working (for ghetto routes, where each node has full table)
- use DHT to advertise routes to every other client
- get clients connecting by public key
- fix problems later

Skywire Meshnet Development Priorities

Our basic 1st generation target for the software defined radio is
- a software defined radio module, with direct amplitude modulated signal at 700 Mhz. Target 700 Mhz carrier output with with 8-bit of quantization, using amplitude modulation (positive and negative part of sin wave), for maximum of 11.2 Gb/s. This will either be a CLPD or ADC/DAC+FPGA with an ARM processor. We can fund ASICs from the FPGA or CLPD prototype to get to to full rate. The SDR module should have external antenna port and communicate over Unipro. This an ARA module.
- an antenna. This should be directional. It should be steerable electronically.

We need to be able to set the amplitude of a sin wave, for the positive and negative half of the sin wave at 700 Mhz. At 700 Mhz with 8-bit of quantization, using amplitude modulation at 700 Mhz, we can transmit 11.2 Gb/s. This is the target, but we may only be able to do 300 million values per second without upgrading to ASICs. The change of amplitude must occur at the zero crossing to avoid snapping.

There is ringing in antenna and other factors. So we will probably be using the same amplitude for positive and negative portion of the carrier at start. The amplitude value will change slowly over the cycles. Lower resolution in the DAC is acceptable for prototype, but objective is setting amplitude 1.4 billion times per second at the zero crossing and at-least 8 bits of resolution in output.

For the radio module, we need to determine
- CLPD with direct digital synthesis? What is fastest CLPD? Can CLPD do 300 Mhz ADC/DAC? What is highest clock rate and cost.
- FPGA with expensive ADC/DAC?
- CLPD for ADC/DAC direct digital synthesis, fed into FPGA? How fast can we get with a CLPD and what is speed limitation for ASIC?
- What is best cable for external antenna port?
- What are best options for ADC/DAC vs CLPD? In terms of cost and performance.

Notes:
- CLPD is our best option for getting a good open source design and validating it, before going to ASICs
- we may be able to find a cheap ADC/DAD or direct digital synthesis chip for a few dollars
- the decoding of symbols from radios, can be done in CPU at first, but must be pushed to FPGA. The higher level forward error correction code may be handled on CPU.
- we want FPGAs/CLPD that are cheap in bulk and require minimum components on PCB. They should have integrated pullup resistors and not clutter the PCB board with components. CLPDs can be $1 and FGPAs can be $5 in quantity.
- There may be way of duplexing a 350 Mhz, CLPD to achieve 700 Mhz with two 350 Mhz units and cleaver timing. We may not need ASICs.
- We will need higher end FPGA with 3 Gigasamples/second 14-bit DAC/ADC to determine antenna transfer function and determine gains from compensation in antenna transfer function and DAC resolution.
- we need to focus on module components that can be evolved, improved independently.

For the antenna
- meshnet needs directional beams to be viable at high device densities and long ranges
- we need a measurement platform for collecting data on antennas. hackrf and a 3d printed or laser cut acrylic platform with 2 degrees of freedom (servos), to rotate antenna and image the side beams
- we need electronically steerable antennas for 2.4 Ghz.
-- This could be a parabolic reflector with two $5 Chinese servos on a gimbal, controlled by an arduino
-- This could be a traditional phased array, with variable capacitors for delay lines
-- This could be a fractal antenna, cut into copper clad PCB with a laser cutter and arduino with SPI DAC chip for modifying the control elements
-- flat, electronically steerable 2.4 Ghz antenna panels are good for roof and hanging out windows and have line-of-sight
- We need electronically steerable antennas for 600 Mhz to 700 Mhz
-- traditional phased array is too large at this frequency, but possible. We have the matlab software for simulating different antenna configurations.
-- Fractal PCB trace antenna have better side lobes, smaller size. Can be laser cut from PCB
-- If antenna has N control elements (amplifiers, variables capacitors) we have the equations for beam forming, if we can measure output with control platform.
- beamforming, antenna must be under software control

The signal attenuation at 2.4 Ghz for going through a single 5" wall, is 23 dB. Every 3 dB is 50% loss of power. Every 6 dB is 50% loss of voltage.

The signal attenuation at 700 Mhz, for going straight through shopping mall sized concrete building is only 18 dB. The range can be miles and still achieve extremely high speeds. However, if a large number of devices with unidirectional antennas are deployed, with competitive transmission power, then the same congestion and noise floor problems occur as on 2.4 Ghz. However, it is slightly different because almost none of the energy between transmitter and receiver on 2.4 Ghz is on a line-of-sight path, its mostly multipath interference. Simulation shows that viable high density meshnet will need directional antennas (120 degree coverage maximum) and needs pencil beams.

Directional beams allow very important simplifying assumptions
- you can always boost the transmission power to achieve given bandwidth and exceed the noise floor at the receiver. This means lower resolution DACs can be used for same signal level.
- You can assume that the received signal is the strongest signal, regardless of whether it is the closest transmitter. In 802.11 on 2.4 Ghz, if you have a 12 bit DAC and the nearest transmitter is 24 dB louder than signal you are trying to receive, you lose 8 bits of accuracy on the DAC, effectively having a 4 bit ADC, severely reducing data rate
- competitive transmission power has minimum effect on other receivers. In 802.11 on 2.4 Ghz, attempting to make a connection over a 802.11n router, often causes it to jack up signal power, transmitting on multiple overlapping bonding channels, acting like a wideband signal jammer.

The first generation equipment will be a single output or perhaps two. It will be working out bugs and driving down cost. We chose a very modest technology and encoding, that minimizes technical risk. This should allow deployment rapidly. There is a very short lead-time between someone figuring out an opensource design and when commercial manufacturing/assembly/distribution of PCB boards.

The HackRF was built by people who had no experience in electronics. They were able to learn everything from Google and build a software defined radio that goes between 0 hz and 6 Hz, with 20 Mhz bandwidth. With no experience they were able to design a $160 SDR that is more powerful than $15,000 commercial SDRs. That is very encouraging. To bring the meshnet into the physical world, will require multiple teams working on different parts of the problem.

The AM encoding does not interfere with the users of the digital television band. The FM receivers will not even lock on to it. The gain for the directional beams is 20 dB to 30 dB on the receiver and transmitter. The interference produced is below level of spurious emissions from cell phones, computers and wireless telephones. A horizontal beam polarization yields 30 dB attenuation for digital television, receivers. The beam should be horizontally polarized whenever possible.

Second generation meshnet may have ~16 separate antenna elements on a chip for doing digital delay lines and driving phased arrays. The signal may be a directional gaussian type ultra-wideband pulse, with 700 Mhz pulse frequency. The AM modulated signal with 8-bit ADC caps out at 11.2 Gb/s. The ultra-wideband Gaussian modulation has extremely low level emissions across a very large spectrum and can reach theoretical rate that are measured in terabits/second. However, the technology is new and encoding 1024 bits per pulse, will require more complicated electronics, special antennas, novel encodings and engineering work. Even if the bandwidth rate is not improved, the technology is low probability of intercept and below the noise floor a few meters off the beam axis, which is desirable for operation in particular countries.



loveyouforever
Sr. Member
****
Offline Offline

Activity: 269
Merit: 250


View Profile
December 12, 2014, 03:49:41 AM
 #1394

This project is really fantastic and well know, it can raise 100000+ BTC very easily in IPO, let us wait and see.
-Greed-
Hero Member
*****
Offline Offline

Activity: 910
Merit: 1000


Decentralized Jihad


View Profile
December 12, 2014, 08:06:25 PM
 #1395

Almost a year has passed and nothing. All supporters abandoned this project. It seems like @skycoin spends much more time for writing these useless walls of text that nobody reads then coding. *Removed the topic from bookmarks.*

Corleone1918
Sr. Member
****
Offline Offline

Activity: 248
Merit: 250


View Profile
December 13, 2014, 01:39:39 AM
 #1396

This project is really fantastic and well know, it can raise 100000+ BTC very easily in IPO, let us wait and see.

you are crazy!
lovely89
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
December 13, 2014, 02:53:01 AM
 #1397

Almost a year has passed and nothing. All supporters abandoned this project. It seems like @skycoin spends much more time for writing these useless walls of text that nobody reads then coding. *Removed the topic from bookmarks.*

Cool story.

Bitrated user: vanlovely.
mladen00
Legendary
*
Offline Offline

Activity: 2127
Merit: 1013


K-ing®


View Profile
December 13, 2014, 05:11:27 AM
 #1398

dev, aprox date for IPO/ICO?

IOTA
Wit22
Member
**
Offline Offline

Activity: 103
Merit: 10


View Profile
December 13, 2014, 12:42:03 PM
 #1399

For those of us who see massive potential in skycoin, could you please PM me and let me know what other INNOVATIVE projects you're following that are in development and pre-IPO/ICO (e.g. zerocash). I'm only interested in truly innovative projects that solve a problem, not copy and pasted trash. Only an innovative project can serve as a hedge against bitcoin (e.g. potentially monero or skycoin could hedge against a massive and catastrophic failure in the bitcoin protocol).

These are the only currencies I am interested in.

Regards,
Wit
merkalor
Full Member
***
Offline Offline

Activity: 177
Merit: 100


View Profile
December 13, 2014, 12:57:56 PM
 #1400

For those of us who see massive potential in skycoin, could you please PM me and let me know what other INNOVATIVE projects you're following that are in development and pre-IPO/ICO (e.g. zerocash). I'm only interested in truly innovative projects that solve a problem, not copy and pasted trash. Only an innovative project can serve as a hedge against bitcoin (e.g. potentially monero or skycoin could hedge against a massive and catastrophic failure in the bitcoin protocol).

These are the only currencies I am interested in.

Regards,
Wit

Im interested too
Emunie? Etherum?

LISK    Develop Decentralized Applications & Sidechains in JavaScript with Lisk!
Pages: « 1 ... 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 [70] 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111 112 113 114 115 116 117 118 119 120 ... 200 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!