Bitcoin Forum
December 16, 2019, 09:46:13 AM *
News: Latest Bitcoin Core release: 0.19.0.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 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 ... 199 »
  Print  
Author Topic: [SKY] Skycoin Launch Announcement  (Read 379702 times)
tobeaj2mer01
Legendary
*
Offline Offline

Activity: 1104
Merit: 1000


Angel investor.


View Profile
July 18, 2014, 03:27:18 PM
 #1141

I don't care what some hero member critics/sceptics say about this coin. It's quite clear that a lot of hard work being added into this projects and posting dev is incredible knowledgeable in the field of digital currency and smart contracts.

I put aside 10 BTC for this coin, let me know when the coin is released.

If you just want to support this project, it's good, but it's not good as an investment, this project is too famous, it will attract a lot of guys to join in the IPO, so the result is like Safecoin, trade price will be below IPO price quickly.

Sirx: SQyHJdSRPk5WyvQ5rJpwDUHrLVSvK2ffFa
1576489573
Hero Member
*
Offline Offline

Posts: 1576489573

View Profile Personal Message (Offline)

Ignore
1576489573
Reply with quote  #2

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

Posts: 1576489573

View Profile Personal Message (Offline)

Ignore
1576489573
Reply with quote  #2

1576489573
Report to moderator
1576489573
Hero Member
*
Offline Offline

Posts: 1576489573

View Profile Personal Message (Offline)

Ignore
1576489573
Reply with quote  #2

1576489573
Report to moderator
altcoinUK
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
July 18, 2014, 03:46:55 PM
 #1142

I don't care what some hero member critics/sceptics say about this coin. It's quite clear that a lot of hard work being added into this projects and posting dev is incredible knowledgeable in the field of digital currency and smart contracts.

I put aside 10 BTC for this coin, let me know when the coin is released.

If you just want to support this project, it's good, but it's not good as an investment, this project is too famous, it will attract a lot of guys to join in the IPO, so the result is like Safecoin, trade price will be below IPO price quickly.

Thanks for letting me know your opinion. I am sure you are right and the price will be hectic, but I am not really interested in short term money making with projects like Ethereum or Vericoin. I am a big supporter of Vericoin, but I think the Skycoin dev is different league than Vericoin - Skycoin is in the league of Ethereum terms of features and innovation.
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
July 18, 2014, 04:14:52 PM
Last edit: July 18, 2014, 11:54:53 PM by skycoin
 #1143

Development Update

Massive changes. Everything is now in one repository. https://github.com/skycoin/skycoin

Changes

skycoin/src/coin is the blockchain parser library
skycoin/src/cipher is the Skycoin Standard Crytographic library
skycoin/src/aether is the distributed application services library
skycoin/src/skywire is the Skycoin Meshnet/Darknet switch
skycoin/src/gui is the HTML local web wallet and infrastructure

- All of the cryptographic and hashing functions have been moved into a common library, that can be imported and used across different applications
- Skywire is now the meshnet/darknet instead of the services daemon.
- the services daemon is deprecated
- dht has been moved into its own library, skycoin/src/aether/dht
- Aether is now the name for the full distributed service stack, not just the distributed key-value store and personal blockchains
- The C implementation of the darknet relay is being pushed to skycoin/src/skywire as the code comes in

Future Changes:

- gnet is being renamed to something better. the library is getting an RPC style interface
- the new RPC interface will allow darknet services to expose machine readable interfaces
- peer lookup for distributed services (PEX) was previous in daemon. It being moved into a struct that can be associated with a distributed service through the RPC interface, instead of having a singleton in daemon for peer discovery. To use pex you will create a PEX struct for the service and then register the struct with the RPC interface.
- gnet currently handles the connection pool. Connection pool management is being switched over to the skywire darknet library. gnet will be deprecated, renamed and responsible for data serialization and the rpc module
- /src/daemon and /src/visor are undergoing heavy refactoring. These are the two modules blocking coin launch. The libraries they depend on are not stable and are rapidly changing. The new visor uses the distributed application infrastructure for blockchain sync and transaction relay.
- gnet functionality is being split up between skywire and aether and therefore the repository for gnet will be deprecated

Skywire: Darknet/Meshnet Switch:

There are four layers in the Skywire stack
- Physical layer. Physical connectivity over public internet, wifi, ethernet, fiber
- Switch layer. Handles circuits and forwarding packets between Skywire switches
- Application layer. This where route discovery, circuit bundling and native distributed application operate.
- Tunnel Layer. Simulates an IPv6 private virtual network so legacy applications can reach public internet or run over Skywire without modification.

At the physical Skywire nodes connect to each other over
- public internet (TCP, UDP)
- wifi (meshnet operation)
- private ethernet (connected by switch over ethernet or fiber)

The switch layer is very simple. A Skywire node connects to another Skywire node and then establishes a circuit. A packet inserted into a circuit is forwarded node to node until it reaches the destination.

- all traffic between Skywire nodes is encrypted
- traffic is encrypted end-to-end
- each node knows the previous hops and next hop, but does not know the source or the destination of traffic
- traffic is encrypted end-to-end
- the nodes keep track of traffic over routes exchange coins every once in a while

Skywire Switch Design
- The switch is written in C and designed to be extremely fast.
- This part of the network can be implemented in Verilog for FPGA/ASIC implementation.
- The switch communicates with a control node for reporting traffic statistics and managing coin payments
- On an ARM meshnet device with FPGA and multiple antennas, the switch would be implemented on the FPGA and the control node software in Golang runs on the ARM core.
- there is a default packet (short form header) and an extensibility flag. If the flag is set, the message will be forwarded to the CPU for processing. This allows for protocol extensions and means the protocol can be upgraded in future.

Division of Labor
- the core devs have enough time to get the switch working
- the community is responsible for the application layer and physical layer, but there are coin bounties for library writers!
- there is a golang library by falcore3000 for scanning and connecting to wifi networks in skycoin/src/aether/wifi

Meshnet Hardware:

We are standardizing on the ARA platform. ARA uses a UniPro baseboard that lets you add and remove modules.  UniPro provides power and up to 10 Gb/s of bandwidth between the components on the baseboard.

For an mesh node, you get a baseboard
- you add a dualcore 1.2 Ghz ARM cpu module with 800 MB of ram
- you add an FPGA module, to run the Skywire switch with full acceleration
- you plug in three antenna modules and wire them to directional antennas
- you plug in a gigabit power over ethernet module to power the node and provide connectivity to the other nodes
- you plug the node into a Ubiquity Power of Ethernet gigabit router

We believe this will be the best platform in the long-term. However, ARA will not be ready until January.

Community Handover:

Marketing, websites and so on will be handed over to members of community as soon as Aether is up we can coordinate it. A wiki will be created and hundreds of pages of documentation, roadmaps, milestones and infrastructure designs will be posted for discussion (and editing). There will be RFC requests for purposing solutions to problems and then process for getting solutions implemented and then integrated.

Skycoin IPO:

The IPO website is under development now. It will not be anything complicated because there is no time. The coins is launching as soon as visor is running on the new distributed applications library.

StorJ IPO:

The StorJ crowd sale has started! Their software looks great. http://storj.io/

I do not know if this is a good investment, but would definitely be worth running a node. They are using counterparty for the coin.

Crypti IPO:

Crypti is doing their crowd sale. New POS coin in Javascript with code base from scratch. Great team.

Tobo
Hero Member
*****
Offline Offline

Activity: 763
Merit: 500


View Profile
July 18, 2014, 07:23:41 PM
 #1144

The StorJ crowd sale has started! Their software looks great. http://storj.io/
I do not know if this is a good investment, but would definitely be worth running a node. They are using counterparty for the coin.


Crypti is also doing their pre sale/ipo - https://bitcointalk.org/index.php?topic=654463

Crypti is a more comparable project to Skycoin.
hill
Member
**
Offline Offline

Activity: 68
Merit: 10


View Profile
July 18, 2014, 07:50:03 PM
 #1145

The StorJ crowd sale has started! Their software looks great. http://storj.io/
I do not know if this is a good investment, but would definitely be worth running a node. They are using counterparty for the coin.


Crypti is also doing their pre sale/ipo - https://bitcointalk.org/index.php?topic=654463

Crypti is a more comparable project to Skycoin.
SKYCOIN is more professional than crypti.
STORJ is really a big progress in the cloud storage. I like it.

Good Luck For Everyone!
Bitseed
Member
**
Offline Offline

Activity: 97
Merit: 10


View Profile WWW
July 18, 2014, 10:19:47 PM
 #1146

The StorJ crowd sale has started! Their software looks great. http://storj.io/
I do not know if this is a good investment, but would definitely be worth running a node. They are using counterparty for the coin.


Crypti is also doing their pre sale/ipo - https://bitcointalk.org/index.php?topic=654463

Crypti is a more comparable project to Skycoin.

Crypti has exceeded its 750 BTC cap on investment, but there is a waiting list which will receive Crypti if refunds between now and the end of the pre-sale bring the total investment below the 750 BTC limit.

Members of the Crypti team have been following the Skycoin project very closely and tested the Skycoin client, including running it on a quad core ARM board. While starting with the NanoPC, we are now going with the Odroid-U3, which will be the processing end of the first generation of our Skywire mesh networking node. The Odroid has 2Gb DDR2 RAM and comes with a heatsink installed - important for an always on device. The Odroid also functions as a secure dedicated coin box for other PoS/PoR type coins, like Crypti, NXT, and the various storage coins coming out.

Bitseed - dedicated full node hardware
Slaphead
Newbie
*
Offline Offline

Activity: 52
Merit: 0


View Profile
July 18, 2014, 10:30:40 PM
 #1147

What frequency bands do you intend to use for the mesh network? Most countries have strict restrictions on radio broadcasts and the most suitable bands are already in use. Will people need a government license to run a transceiver because this seems to be required for almost all frequencies apart from CB radio bands, unless I have got it wrong?
*Sakura*
Legendary
*
Offline Offline

Activity: 1540
Merit: 1000

I wish you all love and profitable investments!!!


View Profile
July 18, 2014, 11:07:08 PM
 #1148

Development goes faster and faster... I can not wait to start...
Bitseed
Member
**
Offline Offline

Activity: 97
Merit: 10


View Profile WWW
July 18, 2014, 11:25:30 PM
 #1149

What frequency bands do you intend to use for the mesh network? Most countries have strict restrictions on radio broadcasts and the most suitable bands are already in use. Will people need a government license to run a transceiver because this seems to be required for almost all frequencies apart from CB radio bands, unless I have got it wrong?

2.4 GHz, 5 GHz, and TV White space - 802.11ac, Bluetooth 4, and 802.11af. We presented today to an incubator interested in our Google Ara module, and I will be talking to Open Garden tonight, since they have expressed interest as well. The Ara effort has delayed our coinbox development a couple of weeks, but would be well worth it if the overall Ara project pans out. We presented a brief explanation of Skycoin and Skywire and its benefits as well, since they are an integral part of our plan to encourage viral adoption of the mesh networking.

I've been encouraging Google to take the Endo (base board the modules plug into) open source, which they may do, but they are currently concerned with "fragmentation". My view is that open architecture prevents fragmentation, as evidenced by the durability of the PC ATX architecture over decades, while mobile devices are fragmented precisely because of the closed, proprietary nature of the industry, other than Android. Even Android devices are fragmented by closed hardware.

Bitseed - dedicated full node hardware
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
July 19, 2014, 12:04:04 AM
 #1150

What frequency bands do you intend to use for the mesh network? Most countries have strict restrictions on radio broadcasts and the most suitable bands are already in use. Will people need a government license to run a transceiver because this seems to be required for almost all frequencies apart from CB radio bands, unless I have got it wrong?

2.4 GHz, 5 GHz, and TV White space - 802.11ac, Bluetooth 4, and 802.11af. We presented today to an incubator interested in our Google Ara module, and I will be talking to Open Garden tonight, since they have expressed interest as well. The Ara effort has delayed our coinbox development a couple of weeks, but would be well worth it if the overall Ara project pans out. We presented a brief explanation of Skycoin and Skywire and its benefits as well, since they are an integral part of our plan to encourage viral adoption of the mesh networking.

I've been encouraging Google to take the Endo (base board the modules plug into) open source, which they may do, but they are currently concerned with "fragmentation". My view is that open architecture prevents fragmentation, as evidenced by the durability of the PC ATX architecture over decades, while mobile devices are fragmented precisely because of the closed, proprietary nature of the industry, other than Android. Even Android devices are fragmented by closed hardware.

Crypti is very interesting. I like that the coin is in Javascript and that its from scratch. The Bitcoin codebase is a bit of a mess.

I wish Google would open source the Endo baseboards. Even if ARA fails, we are set on UniPro for interconnect standard. It could not be too much to produce our own modules and baseboards if absolutely necessarily. People doing UAVs, robotics, enterprise blade servers will want these baseboards. I dont think they should be pigeon holed into just being for cell phones.

With a UniPro baseboard, we can create independent modules for software defined radio and just plug multiple SDR modules into the board for antennas. China has $4 USB SDR units for digital television. They are receive only, but we know now that the units can be single chip and do not have to be expensive.

Bitseed
Member
**
Offline Offline

Activity: 97
Merit: 10


View Profile WWW
July 19, 2014, 12:11:02 AM
 #1151

I talked to some of the people working on the Endo at the Ara conference, and they agreed it has much more potential than just cell phones, but mentioned that at the moment they were being paid to only think about sell phones. Unipro is an open standard, so yes, we can implement it independently. I also see a lot of ways to reduce cost and complexity from the planned design, with injection molded parts instead of machined aluminum. extending the Unipro bus into a wireless personal network for wearable and remote devices, integrated with Skywire as a tunneled VPN makes a lot of sense.

Bitseed - dedicated full node hardware
Bitseed
Member
**
Offline Offline

Activity: 97
Merit: 10


View Profile WWW
July 19, 2014, 03:38:48 AM
 #1152

With a UniPro baseboard, we can create independent modules for software defined radio and just plug multiple SDR modules into the board for antennas. China has $4 USB SDR units for digital television. They are receive only, but we know now that the units can be single chip and do not have to be expensive.

I have considered having a beamforming antenna array inside the module shells, suggested having an antenna bus with standardized jack location in the module interface. Trying to think how to keep the separate antenna phasing synced over the Unipro Bus. Maybe your idea of having a separate SDR to go with each antenna would work, if the SDRs can be synced and the phase and amplitude shifted via the unipro bus by a master controller, mounted up in the shell with the antenna so it frees up the module slots for other uses. Our aim is towards a ZYNQ 7000 series dual core ARM Cortex-A9 processor with FPGA to do the routing and encryption. The Odroid is also Cortex-A9, allowing a consistent development path.

Bitseed - dedicated full node hardware
altcoinUK
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
July 19, 2014, 11:30:54 AM
 #1153

It seems you are focusing most on the SkyWire protocol, which is fine, you define the strategy, but personally I believe the smart contract/smart property handling could be equally important - no wonder Ethereum focus is on smart contracts. Do you have any update on smart contracts, is there any developments in the smart contract field?
coin-swap
Member
**
Offline Offline

Activity: 98
Merit: 10


View Profile
July 19, 2014, 11:44:03 AM
 #1154



Get listed at Coin-Swap.net


How to get listed
You can get listed immediate if you meet the requirements at https://coin-swap.net/newcoin
or
You can vote once per hour in our IRC channel #coin-swap
Registration
Register

Support
Contact

Deposits
Confirmations are currently set to 10. You can watch the status of your deposit from your Deposit page.
altcoinUK
Hero Member
*****
Offline Offline

Activity: 784
Merit: 1000


View Profile
July 19, 2014, 12:26:11 PM
 #1155

Also, could you give any info how complete your source code is, I mean how far are you from the start? Is there many more days, weeks or months of development until the start?
yxxyun
Member
**
Offline Offline

Activity: 100
Merit: 10



View Profile
July 20, 2014, 04:05:05 PM
 #1156

Any news about the IPO?
mladen00
Legendary
*
Offline Offline

Activity: 1848
Merit: 1004


K-ing®


View Profile
July 21, 2014, 06:04:10 AM
 #1157

Skycoin will be one of the best digital currencies, top 5 my OP

but we need IPO date?


IOTA
Storj
Newbie
*
Offline Offline

Activity: 30
Merit: 0


View Profile WWW
July 22, 2014, 02:53:45 AM
 #1158

StorJ IPO:

The StorJ crowd sale has started! Their software looks great. http://storj.io/

I do not know if this is a good investment, but would definitely be worth running a node. They are using counterparty for the coin.
Thank you for the mention! If anybody has any questions, feel free to ask. Smiley
lovely89
Sr. Member
****
Offline Offline

Activity: 378
Merit: 250


View Profile
July 23, 2014, 04:32:06 AM
 #1159

Skycoin, what do you think if the Ethereum public offering? Was just announced today.

Bitrated user: vanlovely.
skycoin
Hero Member
*****
Offline Offline

Activity: 498
Merit: 500


View Profile WWW
July 23, 2014, 09:47:43 AM
Last edit: July 23, 2014, 05:47:23 PM by skycoin
 #1160

Research Update

Incredible breakthrough on consensus. We have been discussing methods for distributed consensus, creating terminology for understanding the consensus process. We think we have a good formal mathematical model now.

We drew out a finite state machine diagram for client transition states and found a new way of reasoning about state. We discovered that there are security measures that can be layered on to coins, which provably only improve the security of the coin without possibility of introducing a new attack. The coin client has a finite state machine and there is an operator that composes with the finite state machine, creating  a new finite state machine. If a mapping from the new state machine back into the original state machine, exists, which satisfies a property, then no sequence of input exists where the new state machine fails where the original state machine did not also fail with respect to a security property.

The property was originally proven using a state machine and constructing a binomial lattice type diagram of the transitions for the state machine for a single input. The result generalized to machine with arbitrary sequence of input.

We are looking at Harel Statecharts and Hierarchical Moore Machines models now, for modeling the Skycoin consensus process and proving properties. We have very good results so far. If this works we can implement the Skycoin consensus system as a formal state machine being emulated by a golang program to ensure we get the mathematical guarantees on the security properties (such as state unreachability).

Types of Double Spending Attacks:

Types of double spending attacks
- Public Chain Forks: Two different groups of miners are mining on different branches, but are publicly publishing the blocks. This is not bad, because the client can run and replicate both forks. The client knows transactions are not final until the alternatives have been reduced to one. Exchanges avoid double spending by not crediting accounts until "10 confirmations AND there is only one public candidate chain". In contrast, Bitcoin switches from one branch to another aruptly, instead of running both alternatives until resolved and one chain is abandoned. Concurrent execution may be desired to switch over for some stability. Awareness of the publicly published alternatives allows exchanges and merchants to eliminate double spending as long as their clients are aware of the fork.
- Private Chain Forks: A miner with majority hash power, mines a longer chain in secret and then publishes it. Everyone switches to the new chain and previously "confirmed" transactions and blocks are reverted. This is the real threat.

Bitcoin is susceptible to double spending from Public Chain fork attacks, where a fork is public and eventually grows to overcome the main chain. Skycoin is not. The Skycoin client tries to be aware of alternate chains and for older history its impossible to create a public chain fork from blocks past a certain number of confirmations, which can become a consensus chain. The only issue left is ruling out chains that were mined in secret and then published to network.

We have identified two types of client behavior with respect to forks
- Hard Forking: As soon as the client sees a longer blockchain, it switches over immediately (Bitcoin)
- Soft Forking: A client is aware of forks and maintains state for both chains. The client has awareness that there is not consensus among the publicly published chains. Exchanges avoid double spending by not crediting accounts or counting transactions as executed until there is a single alternative chain (or until the transaction has been executed on both candidate chains). This is how Skycoin handles forking behavior.

We show that public chain forks are benign. They cannot result in double spending with a properly designed client.

We show that timestamping can be used to eliminate the Private Chains from being accepted. This is the last challenge to eliminating economically significant double spending attacks in Bitcoin like systems. For simplicity, we examine different centralized solutions, then will discuss decentralized alternatives.

Example System for Analysis:

Example 1: Insecure Time Stamping
- Security property: 51% attack proof (a person should not be able to get client to change to a blockchain fork  once a block has reached 10 confirmations.
- In Bitcoin the longest chain is valid. A person can mine a longer chain in secret and publish the chain and each node will switch to the new chain.
- Example Attack. At block 5 a person mines a secret chain fork to block 20. The public chain is at block 15. Block 5 has 10 confirmations.  
- Attack: Each public node accepts the chain with 15 blocks as valid. The attacker publishes the secret 20 block chain. Each node sees that the chain is longer and downloads it. Each node switches to the new chain. Transactions may have been reverted (The attacker deposits Bitcoin to exchange, gets Dogecoin, then uses the chain fork to revert the deposit transaction. The attacker now has his Bitcoin back and the Dogecoin).

Here we have
- node state
- condition transition between the nodes states
- an attack success state
- a security property (reachability of the attack state)

Assume we have a trusted 3rd party time stamping server. The server signs each publicly announced block after it has received five confirmations. A client will use the time stamps to determine which chain is valid.

In this system
- an attack on the time stamp server can be used to 51% attack (by only signing blocks on a chain fork instead of signing the public consensus blocks, resulting in the clients rejecting the valid chain.)
- an attacker with majority hash rate cannot perform a 51% attack without also compromising the timestamp server. If they mine a longer chain in secret and later publish the chain, then the clients will examine the time stamps by the 3rd party, realize that the blocks which would cause a 51% attack were not published to the network and reject the chain.

This system is not stronger than hashing. It introduces a new attack state transition (compromising the timestamp server).

Diagrams

To simplify analysis, we will gloss over network state and focus on individual clients. We will also simplify issue of orphan chains. To simplify analysis and diagrams, we assume that
- the client has a consensus chain (the longest chain the client knows about)
- we ignore issues of orphans and assume blocks are either successors to consensus chain or an unpublished side chain, that is being published in a 51% attack.
- this analysis for simplicity is client level, not network level

Some of these nodes are "State nodes" which represent changes in state of the client chain. The state nodes are the symbols the model emits in each round in response to an input. Other nodes are decision nodes, where a node must make a decision. There is actually a series of "state nodes" in succession, an input comes in and then an output is emitted by the machine on certain nodes, then the machine resets and the next symbol comes in. The diagram over a sequence of inputs actually looks like a linked Markov model diagram. Each transition node itself, could be a program which looks at some state variables and outputs the transition.

The decision nodes, themselves may be state machines themselves (hierarchical state machines). The network enters the sub-machine and the submachine emits the transition the parent machine is to take, as an output.

These diagrams are simplifications of a more precise hierarchical state transition model which is still on paper. Issues such as netsplits, clients joining the network are ignored as special cases.

System1:



Rules:
- Normal Bitcoin
- Client Accepts Longest Chain accepted

States:

S1: Client accepts new block on existing chain
S2: 51% attack. Client accepts chain that forks at a block which has more than N confirmations

Transitions:
T2: Normal operation. Addition of blocks or acceptance of new chain, which does not fork at a block with more than N confirmations
T1: New chain is longer and forks at a block which has more than N confirmations

End Nodes:
S1: emits action to do nothing or extend the current consensus chain
S2: changes the consensus chain

The client reaches S2 and the 51% attack succeeds only if the new chain is longer (more hashing power).

System 2:

System two is system 1 but with a developer run timestamp server, to prevent 51% attack



Rules:
- Client accepts longest chain
- If blocks with more than N confirmations must be signed by time stamp server or are rejected

States:
S1: Normal Functioning (stop node)
S2: A new longer chain has been presented to client. The presented chain forks current consensus chain before a block that has N confirmations. The client needs to decide between the old consensus chain and newly presented chain. The client accepts the chain based upon time stamps
S3: Attacker succeeds and attack chain was accepted

Transitions
T1: Normal operation. Extension of current consensus chain. Block must extend the current chain. If addition of the new block to the chain would cause the block to go over N confirmations, then it must be timestamped by the server.
T2: New longer chain presented to client
T3: Client accepts chain which is potential 51% attack
T5: Client rejects 51% attack chain and maintains current consensus chain
T4: 51% attack without majority hash power. Attacker compromises timestamp server and client rejects the legitimate chain for the attack chain. The client will reject blocks with more than N confirmations, which do not have timestamps. The attacker simply only timestamps the attack chain, until it becomes longer than the current consensus chain.

State Nodes:
S1: emits action to do nothing or extend the current consensus chain
S3: changes the consensus chain

Decision Nodes:
S2: checks time stamping server to determine whether to reject the 51% attack chain (T5), or accept the chain (T3)

The machine starts at S1. Under normal operation (a new block extending the current consensus chain) T1 is taken and the consensus chain is extended uneventfully.

There are 4 conditions
1. normal operation (no 51% attack and working timestamp server)
2. 51% attack and non-compromised timestamp server (attack fails)
3. Attacker does not have enough hash power to create a longer chain, but compromises the timestamp server to get clients to reject the legitimize chain (attack succeeds)
4. Attack has majority hash rate and controls time stamp server (attack succeeds)

This system is interesting
- it cannot operate without the developer timestamp server. the system stops without the timestamp server
- the timestamp server has no control over transactions in blocks but can veto blocks and cause small forks which revert up to N blocks by not time stamping blocks from that chain
- with linked timestamping, signatures and peer-to-peer replication, the timestamp server cannot backdate timestamps
- there is no 51% attack. After N block, confirmation consensus cannot be reverted, regardless of hash power. Transactions are finalized
- depending on implementation the 51% attack requires compromising the timestamp server and backdating timestamps (which can trigger a STOP condition, requiring human resolution). This should be treated as a special condition which cannot be handled automatically in software and requires human judgement.

System 3:

Here we use a timestamp server to rule out chains that were mined in secret and later published. However, we only fallback or even look at the timestamps if a switch over between chains is being considered. The timestamp server can prevent a double spending attack, but cannot be used to cause one.

- System 3 is system 2 with the T4 transition removed.
- System 3 is exactly like Bitcoin normally
- A third party timestamps blocks as it sees them, signs the timestamp and publishes it
- A 3rd party block timestamps only when a client receives a chain which would cause its consensus chain to change. Otherwise timestamps are ignored.

Rules
- the timestamp server timestamps all valid published blocks as it sees them
- timestamps are only used in S2. Timestamps are only examined if an incoming blockchain is long enough to become the new consensus chain and if that chain would replace the existing chain.
- S3 state literally means "Accept new longest chain"
- S1 state literally means "remain on current chain"



End States:
S1: extend current chain by one block or do nothing
S3: accept new consensus chain (accept fork)

Decision States:
S2: Check timestamps on forked blocks and decide to accept the chain as the new consensus chain(S3) or reject the chain and keep the current chain (S1)

Transitions:
T2: A new longer chain has appeared that would change the consensus chain. Move to S2
T5: The timestamps of the new chain were examined and the new chain was determined to be a 51% attack attempt (someone mined an unpublished chain until it was longer than current public chain and then published it). The new chain was rejected.
T3: The attack chain was accepted

In this system
- Two systems, instead of one must be compromised. The attacker must control both the timestamping server and must have majority hash rate, for the attack to be successful. The previous system failed if either of two systems were compromised. The current system "composes" by replacing a state node with a a sub-machine, which is only triggered if the first security measure has failed.
- Compromising the timestamping server cannot result in a 51% attack
- It is impossible to mine blocks in secret and the publish them to network to 51% attack, if timestamping server is working


Challenges:
- A client connecting to network must ensure that it has the same head and consensus chain as the other clients before running this algorithm, or it may end up in a different state than the other clients. Discussing this edge cause would complicate discussion, but there is a resolution if you work through it.
- Clients need a notion of "network state" and need to ensure they are converged. We think we have this solved (but not within Bitcoin framework, will discuss it later). Skycoin clients have notion of "network state" which is different from client state. Each client only has local information, so sometimes network state can only be inferred probabilisticly and requires a randomized process for global convergence from local information.

Assumptions:
- blocks may come in, in different orders on different clients and state of client will be same eventually, but propagation delay has to be reasonably low. We assume that if a block is valid the client will have received it reasonably quickly. Although blocks may come in different order on different clients,  If a block exists but is not propagating, the client needs to know, or else it can end up in a divergent state from the other clients.
- The client needs way of getting to the consensus state the other clients are in, before beginning the process or it may end up in a divergent state
- Monitoring whether the node is "converged" is part of the "network state". Network state is a property of the whole network of nodes, as opposed to the individual client or node state. Local state is based upon local information, where as Network state is an estimation of a property of all nodes as a network. The most important network state attributes for ensuring convergence, are netsplit detection and determining whether blocks exist that have been published publicly but which the client is not receiving within a temporal window.
- as long as the client can accurately estimate global state variables, then the edge cases at client startup and during netsplits can be mitigated. The attacks resulting from invalid global state estimation are rare, difficult to produce and not that severe. They can be ruled out by simply cross referencing the local client's estimate of global state variables against a number of user chosen trusted clients. Global state estimation can be made arbitrarily reliable, depending on the requirements of the applications (exchanges which may be subject to double spending attacks will want higher reliability in global state variable estimation, where as normal clients will likely not care).

Implications:


By using a honest third party service which timestamps each block we can eliminate the Private Chain Fork attack. The timestamp acts as a proof of publication of the block. Blocks mined in secret and then later published will not have timestamps and therefore can be identified as 51% attack attempts.

Fair Timestamping:

The original Skycoin consensus system, gives each user a personal blockchain. The users publish blocks and subscribe to other user's blockchains. When a user becomes aware of a block, they publish the hash of the block in the next block published to their personal blockchain. Each published block is timestamped and therefore attests to the existence and publication of the block.

Alternatives:
- web of trust, distributed timestamping system (like Skycoin)
- delegated Proof-Of-Stake is used to elect five "fair" timestamping servers
- putting the timestamps in the Bitcoin blockchain
- putting timestamps or block headers in different altcoin chains and then referencing them against each other. This exploits tags like Mastercoin uses, which are not stored in the unspent outputs but which can be embedded in blockchain and querried.
- each coin can be check-pointed in the blockchain of other coins and the checkpoints countersigned. A significant 51% attack which reverts a coin back to significantly earlier block, now requires simultaneously 51% attacking a dozen other coins. This is Skycoin's distributed timestamping system, but operating on altcoins chains instead of personal chains.
- banks and financial institutions running centralized cryptocoins who do not want to incur the security costs of mining, may run their own centralized timestamping servers

Proof-of-Stake with Delegated Timestamping:

Bitcoin combines three separate things in a single entity in the block headers
- consensus, determining which chain is the correct one, "network state"
- choosing who gets to create each block
- rate limiting block creation

In Bitcoin these separate functions are combined into a single block header.
- the group of miners with the most hash power determines which chain is valid
- the miners choose what is in each block
- difficulty rate limits block creation rate

However, it does not have to be designed that way. In Skycoin these functions are separated out in a more fine grained way.

We could imagine a system where
- blocks are created by hashing through Proof-of-Stake (coinhours can be burned to reduce target or substitute for hashing).
- Proof-of-Stake is used to elect five timestamping servers (one coin one vote). Bad timestamp servers are automatically voted out.
- Each block is timestamped and signed by the public keys of each of the five elected servers. Consensus is determined by the timestamps (first block published wins. average of time the five timestamps).
- The timestamp servers will only sign blocks after they have been confirmed for five confirmations
- no block rewards for mining
- transaction costs in coinhours (no transaction costs, but rate limiting through coinhours)

In these systems the questions to ask are
- who determines what blocks are created
- how is the consensus chain determined

There can be different groups of people serving these functions

The consensus mechanism can be complex, can be outside of the blockchain and can contain multiple factors or mechanisms. Hashing is the weakest mechanism and most expensive per unit of security. Proof of stake is second mechanism but also imperfect. An ideal system would combine Proof of Stake with a second mechanism indepedent of coin ownership, where even a majority coin holder could not attack the system without also compromising the independent mechanism.

Pages: « 1 ... 8 9 10 11 12 13 14 15 16 17 18 19 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 ... 199 »
  Print  
 
Jump to:  

Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!