Bitcoin Forum
November 19, 2017, 01:29:44 AM *
News: Latest stable version of Bitcoin Core: 0.15.1  [Torrent].
 
   Home   Help Search Donate Login Register  
Poll
Question: Did you see the new thread?
Yes https://bitcointalk.org/index.php?topic=875651.0
No

Pages: « 1 ... 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 121 122 123 ... 501 »
  Print  
Author Topic: [ANN][SUPERCOIN]First P2p Decentralized Trustless Anonymous Wallet Coming Soon  (Read 465810 times)
cyberhacker
Legendary
*
Offline Offline

Activity: 1106



View Profile WWW
June 13, 2014, 02:01:58 AM
 #1441

GUYS,

we will have anon beta test this weekend.

Please send your coin suggest here https://support.mintpal.com/index.php?module=tickets&sec=submit.step1


choose "Coin Suggestion" and submit ticket.

Mintpal is very cooperative and they may reply to your request soon.

since we have steady market support and active development, we may succeed.


Please do it right now!

BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
1511054984
Hero Member
*
Offline Offline

Posts: 1511054984

View Profile Personal Message (Offline)

Ignore
1511054984
Reply with quote  #2

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

Posts: 1511054984

View Profile Personal Message (Offline)

Ignore
1511054984
Reply with quote  #2

1511054984
Report to moderator
1511054984
Hero Member
*
Offline Offline

Posts: 1511054984

View Profile Personal Message (Offline)

Ignore
1511054984
Reply with quote  #2

1511054984
Report to moderator
supercoindev
Member
**
Offline Offline

Activity: 63


View Profile
June 13, 2014, 02:16:56 AM
 #1442

Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them.


Q: What is the overall plan for SUPER to support anonymous features?

A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized.

Remember that this is a trustless system, any node may cheat if it can.

In order to achieve this goal, we divide our work into 2 steps:
   
  • Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
  • Phase-2. To implement a fully de-centralized peer-to-peer anonymous system

What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy.

So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below).
 
For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool.


Q: So what is your Phase-1 solution?
A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram:

The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination.

Basically it is done like this:
   A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination)

where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool,
and these addresses are periodically refreshed, phased out, and created).

The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses).

The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly.


Q: Sounds good, is mixing pool software and coin wallet client are two different software?
A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed.


Q: What is a trust system, and what is a trustless system?
A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat.
A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains.


Q: Can you give some details on the mixing pool?
A: OK, it is basically a wallet client, with a pool feature configured as shown below.

A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms.


Q: Looks good for Phase-1. What about Phase-2? Is it feasible?
A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on
details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it.
The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc).

Supercoin - 1st true peer-to-peer decentralized trustless anonymous wallet using multisig technologies!
timerland
Hero Member
*****
Offline Offline

Activity: 588


View Profile
June 13, 2014, 02:43:57 AM
 #1443

Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them.


Q: What is the overall plan for SUPER to support anonymous features?

A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized.

Remember that this is a trustless system, any node may cheat if it can.

In order to achieve this goal, we divide our work into 2 steps:
   
  • Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
  • Phase-2. To implement a fully de-centralized peer-to-peer anonymous system

What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy.

So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below).
 
For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool.


Q: So what is your Phase-1 solution?
A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram:

The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination.

Basically it is done like this:
   A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination)

where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool,
and these addresses are periodically refreshed, phased out, and created).

The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses).

The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly.


Q: Sounds good, is mixing pool software and coin wallet client are two different software?
A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed.


Q: What is a trust system, and what is a trustless system?
A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat.
A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains.


Q: Can you give some details on the mixing pool?
A: OK, it is basically a wallet client, with a pool feature configured as shown below.

A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms.


Q: Looks good for Phase-1. What about Phase-2? Is it feasible?
A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on
details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it.
The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc).


Excellent description, very knowledgeable dev!

some138
Full Member
***
Offline Offline

Activity: 159


View Profile
June 13, 2014, 02:45:42 AM
 #1444

Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them.


Q: What is the overall plan for SUPER to support anonymous features?

A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized.

Remember that this is a trustless system, any node may cheat if it can.

In order to achieve this goal, we divide our work into 2 steps:
   
  • Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
  • Phase-2. To implement a fully de-centralized peer-to-peer anonymous system

What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy.

So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below).
 
For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool.


Q: So what is your Phase-1 solution?
A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram:

The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination.

Basically it is done like this:
   A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination)

where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool,
and these addresses are periodically refreshed, phased out, and created).

The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses).

The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly.


Q: Sounds good, is mixing pool software and coin wallet client are two different software?
A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed.


Q: What is a trust system, and what is a trustless system?
A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat.
A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains.


Q: Can you give some details on the mixing pool?
A: OK, it is basically a wallet client, with a pool feature configured as shown below.

A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms.


Q: Looks good for Phase-1. What about Phase-2? Is it feasible?
A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on
details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it.
The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc).


Very well described, thanks dev!
qingtiananhao
Jr. Member
*
Offline Offline

Activity: 40


View Profile
June 13, 2014, 02:51:59 AM
 #1445

Supercoin beyond LTC within the next two years, I believe that this is not a dream! It is possible. Smiley
cyberhacker
Legendary
*
Offline Offline

Activity: 1106



View Profile WWW
June 13, 2014, 03:06:09 AM
 #1446

Supercoin beyond LTC within the next two years, I believe that this is not a dream! It is possible. Smiley

wet dream!

but i love it

BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
provenceday
Legendary
*
Offline Offline

Activity: 1022



View Profile
June 13, 2014, 03:06:39 AM
 #1447

Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them.


Q: What is the overall plan for SUPER to support anonymous features?

A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized.

Remember that this is a trustless system, any node may cheat if it can.

In order to achieve this goal, we divide our work into 2 steps:
   
  • Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
  • Phase-2. To implement a fully de-centralized peer-to-peer anonymous system

What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy.

So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below).
 
For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool.


Q: So what is your Phase-1 solution?
A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram:

The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination.

Basically it is done like this:
   A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination)

where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool,
and these addresses are periodically refreshed, phased out, and created).

The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses).

The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly.


Q: Sounds good, is mixing pool software and coin wallet client are two different software?
A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed.


Q: What is a trust system, and what is a trustless system?
A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat.
A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains.


Q: Can you give some details on the mixing pool?
A: OK, it is basically a wallet client, with a pool feature configured as shown below.

A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms.


Q: Looks good for Phase-1. What about Phase-2? Is it feasible?
A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on
details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it.
The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc).


great! it's more clear now.
thanks for the hard work dev.
provenceday
Legendary
*
Offline Offline

Activity: 1022



View Profile
June 13, 2014, 03:07:31 AM
 #1448

Supercoin beyond LTC within the next two years, I believe that this is not a dream! It is possible. Smiley

First we may rank top 20 on coinmarketcap several weeks later. Grin
CrazyLeoW
Full Member
***
Offline Offline

Activity: 126

XC


View Profile
June 13, 2014, 03:12:50 AM
 #1449

Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them.


Q: What is the overall plan for SUPER to support anonymous features?

A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized.

Remember that this is a trustless system, any node may cheat if it can.

In order to achieve this goal, we divide our work into 2 steps:
   
  • Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
  • Phase-2. To implement a fully de-centralized peer-to-peer anonymous system

What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy.

So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below).
 
For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool.


Q: So what is your Phase-1 solution?
A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram:

The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination.

Basically it is done like this:
   A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination)

where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool,
and these addresses are periodically refreshed, phased out, and created).

The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses).

The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly.


Q: Sounds good, is mixing pool software and coin wallet client are two different software?
A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed.


Q: What is a trust system, and what is a trustless system?
A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat.
A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains.


Q: Can you give some details on the mixing pool?
A: OK, it is basically a wallet client, with a pool feature configured as shown below.

A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms.


Q: Looks good for Phase-1. What about Phase-2? Is it feasible?
A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on
details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it.
The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc).



It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

xchat: XNvUSCdvZgZcXsYd3Gs91w8tKQmeMKHS9G
Pubkey: 2Ax9bYXwifbqyxsmC9pbhfGyPoLJNf3wdtQ7dFdzKK1ZX
cyberhacker
Legendary
*
Offline Offline

Activity: 1106



View Profile WWW
June 13, 2014, 03:17:16 AM
 #1450

It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

lol.

both of them are not open source. how to steal "concept"

the DRK steal concept form Coin Join?

BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
jly77
Full Member
***
Offline Offline

Activity: 154


View Profile
June 13, 2014, 03:17:19 AM
 #1451

This coin seems to be nothing but scam. Only copied some concepts from other coins.
jly77
Full Member
***
Offline Offline

Activity: 154


View Profile
June 13, 2014, 03:18:01 AM
 #1452

It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

lol.

both of them are not open source. how to steal "concept"

the DRK steal concept form Coin Join?

That's why they steal concept but not source.
CrazyLeoW
Full Member
***
Offline Offline

Activity: 126

XC


View Profile
June 13, 2014, 03:18:10 AM
 #1453

It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

lol.

both of them are not open source. how to steal "concept"

the DRK steal concept form Coin Join?

maybe ...
So just make some fuds and let's buy some cheap coins. LOL

xchat: XNvUSCdvZgZcXsYd3Gs91w8tKQmeMKHS9G
Pubkey: 2Ax9bYXwifbqyxsmC9pbhfGyPoLJNf3wdtQ7dFdzKK1ZX
cyberhacker
Legendary
*
Offline Offline

Activity: 1106



View Profile WWW
June 13, 2014, 03:18:58 AM
 #1454

It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

lol.

both of them are not open source. how to steal "concept"

the DRK steal concept form Coin Join?

That's why they steal concept but not source.

silly FUDs. only expecting cheap coin.

get on board right now, or you cry later

BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
jly77
Full Member
***
Offline Offline

Activity: 154


View Profile
June 13, 2014, 03:19:26 AM
 #1455

It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

lol.

both of them are not open source. how to steal "concept"

the DRK steal concept form Coin Join?

That's why they steal concept but not source.

silly FUDs. only expecting cheap coin.

get on board right now, or you cry later

Never!
520Bit
Sr. Member
****
Offline Offline

Activity: 462


I love Bitcoins


View Profile
June 13, 2014, 03:20:19 AM
 #1456

Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them.


Q: What is the overall plan for SUPER to support anonymous features?

A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized.

Remember that this is a trustless system, any node may cheat if it can.

In order to achieve this goal, we divide our work into 2 steps:
   
  • Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
  • Phase-2. To implement a fully de-centralized peer-to-peer anonymous system

What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy.

So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below).
 
For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool.


Q: So what is your Phase-1 solution?
A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram:

The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination.

Basically it is done like this:
   A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination)

where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool,
and these addresses are periodically refreshed, phased out, and created).

The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses).

The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly.


Q: Sounds good, is mixing pool software and coin wallet client are two different software?
A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed.


Q: What is a trust system, and what is a trustless system?
A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat.
A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains.


Q: Can you give some details on the mixing pool?
A: OK, it is basically a wallet client, with a pool feature configured as shown below.

A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms.


Q: Looks good for Phase-1. What about Phase-2? Is it feasible?
A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on
details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it.
The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc).



It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

I can do the same copy.

cyberhacker
Legendary
*
Offline Offline

Activity: 1106



View Profile WWW
June 13, 2014, 03:26:48 AM
 #1457

lmao.

fuds will only push price up.

beta test is coming THIS WEEKEND.

push the buying button with your shaky fingers. right now.

BTC12.COM 
Elastic.pw Elastic Network: The Decentralized Supercomputer 
ANNOUNCEMENT THREAD | JOIN THE SLACK
suppersz
Sr. Member
****
Offline Offline

Activity: 336

There is a day to be born, and another to die


View Profile
June 13, 2014, 03:31:08 AM
 #1458

Some people asked for details of our plan and implementations, here are some information on it. I'll use question/answer format to give details. Please post more questions if you have, the dev team will do our best to answer them.


Q: What is the overall plan for SUPER to support anonymous features?

A: Our ultimate goal is to create a peer-to-peer and completely de-centralized anonymous system. This is shown in the following diagram. Any node can become an intermediate "mixing" node, if some minimum requirements are satisfied. There is no central control parts. Everything is peer-to-peer and de-centralized.

Remember that this is a trustless system, any node may cheat if it can.

In order to achieve this goal, we divide our work into 2 steps:
   
  • Phase-1. To achieve anonymous wallet with a simplified, and easy to implement system
  • Phase-2. To implement a fully de-centralized peer-to-peer anonymous system

What is an anonymous system? Simply put, it is a system that people can not trace clearly the transactions from the blockchain, and see where the transaction really originated and where it is terminated. This protects people's privacy.

So why we don't go directly to our end-goal? This is because from our surveys and investigations, it is very complex and difficult to achieve a completely decentralized anonymous system. The key here is the "trust". When you do A->X->B, where X is some sort of the middle "mixer" node, the send or sign or commit of A->X and X->B (or its equivalent, such as a double-signed address, mini-escrow, etc), can not completely happen simultaneously, the one side (sender or Mixer-node) that has the last act can always cheat, though sometimes the cheat does not give the cheater benefits, but it can cause damage to the other party. Therefore, a complete trustless system is more difficult to be implemented (though it is possible - we'll discuss some more below).
 
For this reason, in phase-1 we decided to develop a system that will depend on some sort of the trust, it is much easier to implement, and will give people the anonymous feature. This trust will be done through the dev team, or a credible mining pool.


Q: So what is your Phase-1 solution?
A: Our initial anon solution will involve some middle trusted mixing pools. This is shown in the following diagram:

The mixing pools will be hosted initially by dev team, and can also be hosted by credible mining pools. The anon send will be directed to these mixing pools by wallet and mixed and then send to its destination.

Basically it is done like this:
   A (source) -> {Xi} (i = 1, ..., m), then {Yi} (i = 1, ..., n)->B (destination)

where {Xi} and {Yi} are randomly chosen addresses from a large pool of addresses (belonging to a mixing pool,
and these addresses are periodically refreshed, phased out, and created).

The source amount from A is split randomly into m parts (for now we choose m = 2,3 or 4 randomly in the anon version we will release for testing, but it will be a configurable parameters later), they are sent to m random addresses in randomly chosen mixing pool. The pool, on confirming the amounts received, will send the same amount in n parts to the destination (for our testnet we choose n=1, again this can be changed and configured). The result transaction is not traceable (at least extremely difficult to trace, given the large number of addresses in the mixing pool and dynamism of the addresses).

The main part of our phase-1 solution is implemented, and we will release a version for testnet shortly.


Q: Sounds good, is mixing pool software and coin wallet client are two different software?
A: Absolutely not. They are exactly the same. It is the SUPER coin wallet. Eventually this will be used for peer-to-peer system (in phase-2), so no reason to be different. Now we configure only a few special nodes as trusted nodes. Once we implement the trustless system in phase-2, no special config is needed.


Q: What is a trust system, and what is a trustless system?
A: A trust system will have at least one node that everyone trusts. This node will never cheat. Other nodes may or may not cheat.
A trustless system is that any nodes will cheat if they can. So to implement a trustless system it is more difficult as you have to implement mechanisms to prevent or discourage a node to cheat. If a node cheats, it will lose much more than it gains.


Q: Can you give some details on the mixing pool?
A: OK, it is basically a wallet client, with a pool feature configured as shown below.

A array of the incoming/outgoing addresses are created and refreshed dynamically, and randomly chosen for each transaction. Incoming and outgoing addresses balance their coins with predefined algorithms.


Q: Looks good for Phase-1. What about Phase-2? Is it feasible?
A: Phase-2 is absolutely feasible, albeit more difficult. We actually already defined a workable scheme, and work on
details now. It involves a complex system with multi-signature (m-to-n signature) addresses and multi-signature transactions. We can not reveal more details now. We will publish the full scheme design details after we implement, test and release it.
The Phase-2 will be built on top of the Phase-1 codebase. In phase-2, any node (wallet client) can become an intermediate mixing node if it satisfy some minimum requirements (e.g. minimum balance, network connectivity etc).



It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.

I can do the same copy.
You believe Honorcoin(See your signature),Do not believe this?LOL. Grin

fastrabbit
Member
**
Offline Offline

Activity: 88


View Profile
June 13, 2014, 03:41:51 AM
 #1459

Very nice and credible plan from dev, SUPER will become a superstar! Go!
some138
Full Member
***
Offline Offline

Activity: 159


View Profile
June 13, 2014, 03:43:17 AM
 #1460

It's quite clear now. Your Phase-1 steals masternode conception from DRK, and your future plan steals Xnode conception from XC.
You're lucky one since none of them have patented their innovations.
Good luck, you and your scam.
Steal?? Does DRK steal from BTC/LTC? You idiot!
Pages: « 1 ... 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 121 122 123 ... 501 »
  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!