[ANN] [SHLD] ShieldCoin - X15 - PoS - Fair Launch - Whitepaper RELEASE!

[shieldcoindevs]

UPDATE

A description of the anon implementation I've been working on is below. I'm releasing this rough draft because the community wants it, but I will clean it up and present it properly with some charts after I get some rest


Rough draft of anon implementation description, as requested by the community. Please note this is a work in progress, and there will be ongoing changes and revisions if issues are discovered.


Shieldcoin: Anonymous Coin Transaction Transfer Mechanism

Transferring data (encrypted keys) or files in a P2P network involves sending and recieving

data packets between computers on the internet. In typical P2P protocols, a peer connects

directly with other peers and gets a small part of the data from each. This involves many

computers which are unknown to each other but still identified by their IP address.

Determining which peers are serving data is simple, one just needs to add a peer to this

network and provide lots of data, and record the IP address of the machines that connect. The

direct connections between a client and the source is a weak point of security.



Shieldcoin aims to solve this problem by using explicit data connections only between trusted

wallets, which send encrypted verification messages to each other using signed SSL

certificates. These wallet connections are chained together to provide secure and anonymous

transfer tunnels across the whole Shieldcoin network. Each wallet will act as an anonymous

mixer, transferring and mixing coins between each other, with the outputs saved in an anonymous

and encrypted sidechain. This method will prevent classical IP spying techniques and more

advanced spying mechanisms based on man-in-the-middle attacks.



The anonymous routing model will allow wallets to exchange keys anonymously using tunnels. The

data is by nature re-encrypted as it passes through each pair of friends along the tunnel.

A, as a client requests data through trusted wallets only. The sources B and C and are not

known to A, and A is not known to them either.


The original idea was taken from the PhD thesis of Petr Matejka: Security in Peer-to-Peer

Networks [1].



An anonymous transaction request is performed by broadcasting a public key packet to all

connected wallets. The wallets forward it to other wallets, until the request is too old. If a

matching private key is found, a reply is send back by the inverse route that the request took.

If the request is too old and the destination wallet is not online, the request is archived in

a cache of public key broadcasts. The cache is examined each time a new request is received. If

already present, the request is discarded. An additional transfer fee will be added to

anonymous coin transfers to prevent spam attacks.




Shieldcoin tunnel establishment protocol

Tunnels are established using the same protocol as the anonymous transfers. A seperate cache is

used to store the tunnel requests, and route tunnel accept packets back to the original client.

The half-id of a tunnel request is a non reversible hash of the client SSL id, and the file

hash for which the tunnel will be used. It is salted by a session-dependent random number. Once

a peer responds to the tunnel request, it will merge this half-id with his own half-id, in a

non symmetric way to obtain the final tunnel id (Shieldcoin users see tunnels as “anonymous

tunnel 0x45eb7a34″. The ending number is the tunnel id). This means that:

tunnels between a given source and destination for a given hash, always have the same tunnel id

(although the tunnel request id changes every time) whatever the route they take;
the tunnel id is non symmetrical. This means that a tunnel from A to B for a given hash will

not have the same id than a tunnel from B to A for this hash;

from the half-id alone (resp. tunnel id), it is not possible to brute-force the requesting peer

id, because of the salting mechanism.



The second property is important because two peers might have two tunnels to each others for

the same transaction request going both ways. This happens when both peers are clients for a

hash that is swarming between multiple peers. The two tunnels might cross in between and their

ids should cause no ambiguity.



The tunnel protocols in Shieldcoin use no global addressing, as opposed to the original design

by Matejka [1]. Once established, a tunnel is always represented at each peer along the tunnel

by a pair of wallets. When data comes from one wallet, it is automatically forwarded to the

other wallet and vis versa.



Shieldcoin tunnel life handling

One major difference between the implementation of tunnel network in Shieldcoin and the

original implementation described by P.Matejka in his thesis, is that tunnels in Shieldcoin do

not need additional management packets such as for closing a tunnel, or managing bandwidth.


Tunnels are removed from the list of existing tunnels by each peer when the traffic along the

tunnel is null for a definite period of time (60 seconds). This simple technique allows us to

robustly handle any incidental change of the network topology. If a tunnel is e.g. broken

because a peer disconnects, the tunnel will be removed by all other participating peers after

60 seconds, without the need to send a special tunnel closing packet.


From the point of view of the anonymous transfer send/recieving, each tunnel appears as just

another connected peer to which data chunks can be requested.

From the outside it is not able to read the data which is transferred between the Peers

(DarkNet). Because of the Authentication between the nodes, it should not be possible to use a

Man-in-the-middle Attack and log and manipulate the data-stream.


In an upcoming paper, I will treat the more technical aspects of the tunnel network and

anonymous transfer protocols - speed, anonymous transfer security in the case of rogue peers,

and other nasty algorithmic details.


Again, this paper and the ideas contained are a work in progress. There are some hurdles to

overcome, but I am working with a member of another open-source project which uses a similar

network tunneling method and making good strides.



Section 2:

Shieldcoin Distributed Chat System

Still working on this part. I released this early because the community has been asking me to.

References:

[1] Safe and Private Data Sharing with Turtle: Friends Team-Up and Beat the System
Popescu, B.C. ; Crispo, B. ; Tanenbaum, A.S.
Proceedings of the 12th Cambridge International Workshop on Security Protocols, 2004

[1714795106]

1714795106

[1714795106]

1714795106

[1714795106]

1714795106

[1714795106]

1714795106

[1714795106]

1714795106

[tm2013]

Dev, If you release this working, we are going to pass darkcoin, no problem. Could this be a finally working model for decentralized anon?

Great Work!

[Liquid71]

UPDATE

A description of the anon implementation I've been working on is below. I'm releasing this rough draft because the community wants it, but I will clean it up and present it properly with some charts after I get some rest


Rough draft of anon implementation description, as requested by the community. Please note this is a work in progress, and there will be ongoing changes and revisions if issues are discovered.


Shieldcoin: Anonymous Coin Transaction Transfer Mechanism

Transferring data (encrypted keys) or files in a P2P network involves sending and recieving

data packets between computers on the internet. In typical P2P protocols, a peer connects

directly with other peers and gets a small part of the data from each. This involves many

computers which are unknown to each other but still identified by their IP address.

Determining which peers are serving data is simple, one just needs to add a peer to this

network and provide lots of data, and record the IP address of the machines that connect. The

direct connections between a client and the source is a weak point of security.



Shieldcoin aims to solve this problem by using explicit data connections only between trusted

wallets, which send encrypted verification messages to each other using signed SSL

certificates. These wallet connections are chained together to provide secure and anonymous

transfer tunnels across the whole Shieldcoin network. Each wallet will act as an anonymous

mixer, transferring and mixing coins between each other, with the outputs saved in an anonymous

and encrypted sidechain. This method will prevent classical IP spying techniques and more

advanced spying mechanisms based on man-in-the-middle attacks.



The anonymous routing model will allow wallets to exchange keys anonymously using tunnels. The

data is by nature re-encrypted as it passes through each pair of friends along the tunnel.

A, as a client requests data through trusted wallets only. The sources B and C and are not

known to A, and A is not known to them either.


The original idea was taken from the PhD thesis of Petr Matejka: Security in Peer-to-Peer

Networks [1].



An anonymous transaction request is performed by broadcasting a public key packet to all

connected wallets. The wallets forward it to other wallets, until the request is too old. If a

matching private key is found, a reply is send back by the inverse route that the request took.

If the request is too old and the destination wallet is not online, the request is archived in

a cache of public key broadcasts. The cache is examined each time a new request is received. If

already present, the request is discarded. An additional transfer fee will be added to

anonymous coin transfers to prevent spam attacks.




Shieldcoin tunnel establishment protocol

Tunnels are established using the same protocol as the anonymous transfers. A seperate cache is

used to store the tunnel requests, and route tunnel accept packets back to the original client.

The half-id of a tunnel request is a non reversible hash of the client SSL id, and the file

hash for which the tunnel will be used. It is salted by a session-dependent random number. Once

a peer responds to the tunnel request, it will merge this half-id with his own half-id, in a

non symmetric way to obtain the final tunnel id (Shieldcoin users see tunnels as “anonymous

tunnel 0x45eb7a34″. The ending number is the tunnel id). This means that:

tunnels between a given source and destination for a given hash, always have the same tunnel id

(although the tunnel request id changes every time) whatever the route they take;
the tunnel id is non symmetrical. This means that a tunnel from A to B for a given hash will

not have the same id than a tunnel from B to A for this hash;

from the half-id alone (resp. tunnel id), it is not possible to brute-force the requesting peer

id, because of the salting mechanism.



The second property is important because two peers might have two tunnels to each others for

the same transaction request going both ways. This happens when both peers are clients for a

hash that is swarming between multiple peers. The two tunnels might cross in between and their

ids should cause no ambiguity.



The tunnel protocols in Shieldcoin use no global addressing, as opposed to the original design

by Matejka [1]. Once established, a tunnel is always represented at each peer along the tunnel

by a pair of wallets. When data comes from one wallet, it is automatically forwarded to the

other wallet and vis versa.



Shieldcoin tunnel life handling

One major difference between the implementation of tunnel network in Shieldcoin and the

original implementation described by P.Matejka in his thesis, is that tunnels in Shieldcoin do

not need additional management packets such as for closing a tunnel, or managing bandwidth.


Tunnels are removed from the list of existing tunnels by each peer when the traffic along the

tunnel is null for a definite period of time (60 seconds). This simple technique allows us to

robustly handle any incidental change of the network topology. If a tunnel is e.g. broken

because a peer disconnects, the tunnel will be removed by all other participating peers after

60 seconds, without the need to send a special tunnel closing packet.


From the point of view of the anonymous transfer send/recieving, each tunnel appears as just

another connected peer to which data chunks can be requested.

From the outside it is not able to read the data which is transferred between the Peers

(DarkNet). Because of the Authentication between the nodes, it should not be possible to use a

Man-in-the-middle Attack and log and manipulate the data-stream.


In an upcoming paper, I will treat the more technical aspects of the tunnel network and

anonymous transfer protocols - speed, anonymous transfer security in the case of rogue peers,

and other nasty algorithmic details.


Again, this paper and the ideas contained are a work in progress. There are some hurdles to

overcome, but I am working with a member of another open-source project which uses a similar

network tunneling method and making good strides.



Section 2:

Shieldcoin Distributed Chat System

Still working on this part. I released this early because the community has been asking me to.

References:

[1] Safe and Private Data Sharing with Turtle: Friends Team-Up and Beat the System
Popescu, B.C. ; Crispo, B. ; Tanenbaum, A.S.
Proceedings of the 12th Cambridge International Workshop on Security Protocols, 2004

[/quote]

Looks good, a lot of it over my head but the market is loving it 

[bitcoinwonders010]

dev post

Shieldcoin: Anonymous Coin Transaction Transfer Mechanism

Transferring data (encrypted keys) or files in a P2P network involves sending and recieving data packets between computers on the internet. In typical P2P protocols, a peer connects directly with other peers and gets a small part of the data from each. This involves many computers which are unknown to each other but still identified by their IP address. Determining which peers are serving data is simple, one just needs to add a peer to this network and provide lots of data, and record the IP address of the machines that connect. The direct connections between a client and the source is a weak point of security. Shieldcoin aims to solve this problem by using explicit data connections only between trusted  wallets, which send encrypted verification messages to each other using signed SSL certificates. These wallet connections are chained together to provide secure and anonymous transfer tunnels across the whole Shieldcoin network. Each wallet will act as an anonymous mixer, transferring and mixing coins between each other, with the outputs saved in an anonymous and encrypted sidechain. This method will prevent classical IP spying techniques and more  advanced spying mechanisms based on man-in-the-middle attacks. The anonymous routing model will allow wallets to exchange keys anonymously using tunnels. The data is by nature re-encrypted as it passes through each pair of friends along the tunnel. A, as a client requests data through trusted wallets only. The sources B and C and are not known to A, and A is not known to them either.The original idea was taken from the PhD thesis of Petr Matejka: Security in Peer-to-Peer

Networks [1].

An anonymous transaction request is performed by broadcasting a public key packet to all connected wallets. The wallets forward it to other wallets, until the request is too old. If a matching private key is found, a reply is send back by the inverse route that the request took. If the request is too old and the destination wallet is not online, the request is archived in a cache of public key broadcasts. The cache is examined each time a new request is received. If already present, the request is discarded. An additional transfer fee will be added to anonymous coin transfers to prevent spam attacks.

Shieldcoin tunnel establishment protocol

Tunnels are established using the same protocol as the anonymous transfers. A seperate cache is used to store the tunnel requests, and route tunnel accept packets back to the original client. The half-id of a tunnel request is a non reversible hash of the client SSL id, and the file hash for which the tunnel will be used. It is salted by a session-dependent random number. Once a peer responds to the tunnel request, it will merge this half-id with his own half-id, in a non symmetric way to obtain the final tunnel id (Shieldcoin users see tunnels as “anonymous tunnel 0x45eb7a34″. The ending number is the tunnel id). This means that: tunnels between a given source and destination for a given hash, always have the same tunnel id (although the tunnel request id changes every time) whatever the route they take; the tunnel id is non symmetrical. This means that a tunnel from A to B for a given hash will not have the same id than a tunnel from B to A for this hash;from the half-id alone (resp. tunnel id), it is not possible to brute-force the requesting peer id, because of the salting mechanism.

The second property is important because two peers might have two tunnels to each others for the same transaction request going both ways. This happens when both peers are clients for a hash that is swarming between multiple peers. The two tunnels might cross in between and their ids should cause no ambiguity.mThe tunnel protocols in Shieldcoin use no global addressing, as opposed to the original design by Matejka [1]. Once established, a tunnel is always represented at each peer along the tunnel by a pair of wallets. When data comes from one wallet, it is automatically forwarded to the other wallet and vis versa.

Shieldcoin tunnel life handling

One major difference between the implementation of tunnel network in Shieldcoin and the original implementation described by P.Matejka in his thesis, is that tunnels in Shieldcoin do not need additional management packets such as for closing a tunnel, or managing bandwidth. Tunnels are removed from the list of existing tunnels by each peer when the traffic along the tunnel is null for a definite period of time (60 seconds). This simple technique allows us to robustly handle any incidental change of the network topology. If a tunnel is e.g. broken because a peer disconnects, the tunnel will be removed by all other participating peers after 60 seconds, without the need to send a special tunnel closing packet.

From the point of view of the anonymous transfer send/recieving, each tunnel appears as just another connected peer to which data chunks can be requested. From the outside it is not able to read the data which is transferred between the Peers (DarkNet). Because of the Authentication between the nodes, it should not be possible to use a Man-in-the-middle Attack and log and manipulate the data-stream. In an upcoming paper, I will treat the more technical aspects of the tunnel network and anonymous transfer protocols - speed, anonymous transfer security in the case of rogue peers, and other nasty algorithmic details. Again, this paper and the ideas contained are a work in progress. There are some hurdles to overcome, but I am working with a member of another open-source project which uses a similar
network tunneling method and making good strides.

Section 2:

Shieldcoin Distributed Chat System
Still working on this part. I released this early because the community has been asking me to.

References:
[1] Safe and Private Data Sharing with Turtle: Friends Team-Up and Beat the System
Popescu, B.C. ; Crispo, B. ; Tanenbaum, A.S.
Proceedings of the 12th Cambridge International Workshop on Security Protocols, 2004[/quote]

[bitcoinwonders010]

dev post

Shieldcoin: Anonymous Coin Transaction Transfer Mechanism

Transferring data (encrypted keys) or files in a P2P network involves sending and recieving data packets between computers on the internet. In typical P2P protocols, a peer connects
directly with other peers and gets a small part of the data from each. This involves many computers which are unknown to each other but still identified by their IP address. Determining which peers are serving data is simple, one just needs to add a peer to this network and provide lots of data, and record the IP address of the machines that connect. The direct connections between a client and the source is a weak point of security. Shieldcoin aims to solve this problem by using explicit data connections only between trusted  wallets, which send encrypted verification messages to each other using signed SSL certificates. These wallet connections are chained together to provide secure and anonymous transfer tunnels across the whole Shieldcoin network. Each wallet will act as an anonymous mixer, transferring and mixing coins between each other, with the outputs saved in an anonymous and encrypted sidechain. This method will prevent classical IP spying techniques and more  advanced spying mechanisms based on man-in-the-middle attacks. The anonymous routing model will allow wallets to exchange keys anonymously using tunnels. The data is by nature re-encrypted as it passes through each pair of friends along the tunnel. A, as a client requests data through trusted wallets only. The sources B and C and are not known to A, and A is not known to them either.The original idea was taken from the PhD thesis of Petr Matejka: Security in Peer-to-Peer

Networks [1].

An anonymous transaction request is performed by broadcasting a public key packet to all connected wallets. The wallets forward it to other wallets, until the request is too old. If a matching private key is found, a reply is send back by the inverse route that the request took. If the request is too old and the destination wallet is not online, the request is archived in a cache of public key broadcasts. The cache is examined each time a new request is received. If already present, the request is discarded. An additional transfer fee will be added to anonymous coin transfers to prevent spam attacks.

Shieldcoin tunnel establishment protocol

Tunnels are established using the same protocol as the anonymous transfers. A seperate cache is used to store the tunnel requests, and route tunnel accept packets back to the original client. The half-id of a tunnel request is a non reversible hash of the client SSL id, and the file hash for which the tunnel will be used. It is salted by a session-dependent random number. Once a peer responds to the tunnel request, it will merge this half-id with his own half-id, in a non symmetric way to obtain the final tunnel id (Shieldcoin users see tunnels as “anonymous tunnel 0x45eb7a34″. The ending number is the tunnel id). This means that: tunnels between a given source and destination for a given hash, always have the same tunnel id (although the tunnel request id changes every time) whatever the route they take; the tunnel id is non symmetrical. This means that a tunnel from A to B for a given hash will not have the same id than a tunnel from B to A for this hash;from the half-id alone (resp. tunnel id), it is not possible to brute-force the requesting peer id, because of the salting mechanism.

The second property is important because two peers might have two tunnels to each others for the same transaction request going both ways. This happens when both peers are clients for a hash that is swarming between multiple peers. The two tunnels might cross in between and their ids should cause no ambiguity.mThe tunnel protocols in Shieldcoin use no global addressing, as opposed to the original design by Matejka [1]. Once established, a tunnel is always represented at each peer along the tunnel by a pair of wallets. When data comes from one wallet, it is automatically forwarded to the other wallet and vis versa.

Shieldcoin tunnel life handling

One major difference between the implementation of tunnel network in Shieldcoin and the original implementation described by P.Matejka in his thesis, is that tunnels in Shieldcoin do
not need additional management packets such as for closing a tunnel, or managing bandwidth. Tunnels are removed from the list of existing tunnels by each peer when the traffic along the tunnel is null for a definite period of time (60 seconds). This simple technique allows us to robustly handle any incidental change of the network topology. If a tunnel is e.g. broken because a peer disconnects, the tunnel will be removed by all other participating peers after 60 seconds, without the need to send a special tunnel closing packet.


From the point of view of the anonymous transfer send/recieving, each tunnel appears as just another connected peer to which data chunks can be requested. From the outside it is not able to read the data which is transferred between the Peers (DarkNet). Because of the Authentication between the nodes, it should not be possible to use a Man-in-the-middle Attack and log and manipulate the data-stream. In an upcoming paper, I will treat the more technical aspects of the tunnel network and anonymous transfer protocols - speed, anonymous transfer security in the case of rogue peers, and other nasty algorithmic details. Again, this paper and the ideas contained are a work in progress. There are some hurdles to overcome, but I am working with a member of another open-source project which uses a similar
network tunneling method and making good strides.



Section 2:

Shieldcoin Distributed Chat System

Still working on this part. I released this early because the community has been asking me to.

References:

[1] Safe and Private Data Sharing with Turtle: Friends Team-Up and Beat the System
Popescu, B.C. ; Crispo, B. ; Tanenbaum, A.S.
Proceedings of the 12th Cambridge International Workshop on Security Protocols, 2004

[/quote]

this feels like XC coin all over again. hold your coins we only have 1.09million

[cryptoholic11]

I think reposting the draft over and over again is fucking annoying, especially scrolling down to read other posts. Once per page should be suffice no?

Btw, nice draft dev. This coin looks really promising!

[tm2013]

Does the current PoS implementation add inflation or just work off of TX fees? If it is really 15% inflation compounding on all staked coins, this is too good of a system to keep the rate that high: We need to keep it rare...

Edit: lol, it never fails: the classic bump, dump, then massive pump/re-evaluation on news V.S. the pump then massive dump on hype/lies. Remember, we can surpass dark if this anon system is released and works... Let the weak hands sell, they will all be kicking themselves like many did with BC, XC, DRK, etc... Only the strong holders survived to realize the massive payoff.

[nrg_wolf]

multipool dump again....
get ya cheap coins while ya can

[bitcoinwonders010]

I think reposting the draft over and over again is fucking annoying, especially scrolling down to read other posts. Once per page should be suffice no?

Btw, nice draft dev. This coin looks really promising!

i reposted the draft because it was a really long post. just took up alot of space. its the same post much shorter. dev should make a PDF file for final version with diagrams, that would help understand it much better, but from what i read so far, no one is doing what shield coin is doing. this could be interesting

[cryptoholic11]

I think reposting the draft over and over again is fucking annoying, especially scrolling down to read other posts. Once per page should be suffice no?

Btw, nice draft dev. This coin looks really promising!

i reposted the draft because it was a really long post. just took up alot of space. its the same post much shorter. dev should make a PDF file for final version with diagrams, that would help understand it much better, but from what i read so far, no one is doing what shield coin is doing. this could be interesting

Yea I agree +1. A road map with relative ETAs would stabilize the price too imo. I know Ill get shit for this from some people, but I'll be that guy that asks for ETAs.

[bitcoinwonders010]

I think reposting the draft over and over again is fucking annoying, especially scrolling down to read other posts. Once per page should be suffice no?

Btw, nice draft dev. This coin looks really promising!

i reposted the draft because it was a really long post. just took up alot of space. its the same post much shorter. dev should make a PDF file for final version with diagrams, that would help understand it much better, but from what i read so far, no one is doing what shield coin is doing. this could be interesting

Yea I agree +1. A road map with relative ETAs would stabilize the price too imo. I know Ill get shit for this from some people, but I'll be that guy that asks for ETAs.

dev did say its a draft, the final version should inc all this which will be out in 10 hours i think, but ateast we have more info on the new anon method

[shieldcoindevs]

I think reposting the draft over and over again is fucking annoying, especially scrolling down to read other posts. Once per page should be suffice no?

Btw, nice draft dev. This coin looks really promising!

i reposted the draft because it was a really long post. just took up alot of space. its the same post much shorter. dev should make a PDF file for final version with diagrams, that would help understand it much better, but from what i read so far, no one is doing what shield coin is doing. this could be interesting

I will soon, after some rest.  

[bitcoinwonders010]

I think reposting the draft over and over again is fucking annoying, especially scrolling down to read other posts. Once per page should be suffice no?

Btw, nice draft dev. This coin looks really promising!

i reposted the draft because it was a really long post. just took up alot of space. its the same post much shorter. dev should make a PDF file for final version with diagrams, that would help understand it much better, but from what i read so far, no one is doing what shield coin is doing. this could be interesting

I will soon, after some rest.  

awesome can't wait,

[cryptoholic11]

thanks dev

[bitcoinwonders010]

dev shorten your post in the OP. copy my post where i shrunk it taking out unnecessary space. it will help not scrolling down too much

[randol_8o8]

I've been in and this has been quite a bumpy ride but I'm sure the market will only go up from here!

[bitcoinwonders010]

Alright Im in, developer don't let me down.

no premine, helps build confidence. im in and ain't getting out

[tm2013]

I realize the blocks are going to be infrequent, but my goodness, 2 hours is unacceptable. C'mon people, start staking!

[bitcoinwonders010]

interest is rising. this a coin to hold. with only 1 million coins and a anon system which look awesome. believe it or not 0.01 is very possible. full details soon, but from the info so far you know that dev knows what he is talking about. 

[knievel]

0.00025666 btc and still rising. amazing!