Bitcoin Forum
May 21, 2018, 12:04:30 PM *
News: Latest stable version of Bitcoin Core: 0.16.0  [Torrent]. (New!)
 
   Home   Help Search Donate Login Register  
Pages: « 1 2 3 4 5 6 7 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 ... 803 »
  Print  
Author Topic: [ANN][KMD][dPoW] Komodo - Zcash Zero Knowledge Privacy Secured by Bitcoin  (Read 1083192 times)
PondSea
Legendary
*
Offline Offline

Activity: 1428
Merit: 1000


View Profile
September 23, 2016, 09:33:59 PM
 #821

Minimum investment is 0.0777 which is just under $50.

People can choose to pool their funds together to reach the min or they can just buy BTCD which wont have any minimums to get around this restriction.

Isn't this just taking he whole jl777 thing a bit far? We've had "50 cent" are we getting "jl50 dollars"

Cheers Jon  Cool

Only appropriate in this situation  Grin





░░░░░░░░░▀▀▀█████████
░░░░░░░░░░░░░░░████████
░░░░▄███████▄░░░░████████
░░░░███████████░░░░██████
░░░▀███████████░░░░████░░
███▄░░░░░░░░░░▀████░░░███░░██
█████▄▄▄▄▄▄▄▄▄▄▄████░░░██░░██
█████████████▄░░████░░░░░
░░█████████████░░█████
░░░░█████████▀░░░██████▌
░░░░░░░▀▀▀▀░░░░▄████████▌
░░░░░░░░░░▄▄▄▄███████
SuperNET.org
..BarterDEX..
.
▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
DECENTRALIZED CRYPTOCURRENCY EXCHANGE
Developed to Unite Coin Communities | ✔ SECURE ✔ FREE ✔ VISIBILITY ✔ EASY INTEGRATION |

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬

1526904270
Hero Member
*
Offline Offline

Posts: 1526904270

View Profile Personal Message (Offline)

Ignore
1526904270
Reply with quote  #2

1526904270
Report to moderator
1526904270
Hero Member
*
Offline Offline

Posts: 1526904270

View Profile Personal Message (Offline)

Ignore
1526904270
Reply with quote  #2

1526904270
Report to moderator
1526904270
Hero Member
*
Offline Offline

Posts: 1526904270

View Profile Personal Message (Offline)

Ignore
1526904270
Reply with quote  #2

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

Posts: 1526904270

View Profile Personal Message (Offline)

Ignore
1526904270
Reply with quote  #2

1526904270
Report to moderator
noashh
Sr. Member
****
Offline Offline

Activity: 371
Merit: 250



View Profile
September 24, 2016, 02:04:52 AM
 #822

Taking a short break from debugging. multithreaded networking code is always tricky. I did find and fix some deadlocks, but primarily drastically simplified the control flow. Simple is a lot simpler and much less can go wrong as compared to complex logic.

What is working now are several different types of nodes that are all coexisting in the same (super) network.

Each coin of course has its normal p2p network using the bitcoin protocol. Overlaid on top of that are the supernet nodes which use the same ports, but only do supernet comms to other supernet nodes as identified during the version handshake.

For a coin, a node is either a full relay node or a basilisk lite node that queries the full nodes for the blockchain/blockexplorer data. All wallet, tx construction, signing, is done locally as it is the same codebase with some toggles for basilisk mode where it does a basilisk request instead of scanning local ramchain files.

There is a special coin with no blockchain, called NOTARY and the notary nodes would be the full relay nodes and all the others basilisk nodes for this special coin. The NOTARY p2p is now working as a pubkey messaging server and also a way to find all the active notary nodes. I am adding a layer on top of the low level pubkey messaging so a node wont keep retransmitting if the data is already there. That will make the bandwidth usage much more efficient and allow a lot of DEX trading at the same time.

I also got LP nodes to work even as a basilisk node, though it is of course faster if it is a full iguana node. Still, not having to have a full bitcoin node locally is quite handy. And with the NOTARY pubkey messaging in between, there is no direct IP level interaction between the two parties doing the atomic swap.

In order to minimize the changes needed to be made to the zcash baseline and support dPoW, having a min-diff exception for notary node blocks but still using the same PoW seems the path of least resistance. This will make the seamless transition to fully decentralized block creation in the even all the notary nodes go away, or there is some problems in getting a majority of notaries to agree, much much simpler.

With notary nodes having the min-difficulty exception, it would not be feasible for some high hash rate attacker to do 51% attacks. And even if they can anybody that just waits for the bitcoin confirmation would be protected. That is the power of dPoW as even very weak chains become quite secure.

With this plan, the biggest remaining issue is how to get the election results propagated securely. Using komodo chain to record election results has the issue that if all blocks are created by notaries, then the existing majority could block the activation of the new slate. A natural idea is to use the BTC blockchain to record the election results, but again the issue of who writes that data arises.

My idea is to ratify election results via the majority of existing notaries OR a one third majority + special signature. The special signature would be held by the devteam. With this approach, even if there is a majority of notary nodes unwilling to give up their position, it can be overridden by one third minority and the devteam.

This ties into using the zcash PoW as the method for block generation. Even with a min-diff exception, with enough hash rate a block will be able to be mined by non-notary nodes and so the (one third + special sig) transaction will be able to get onto the blockchain in spite of a hostile notary majority.

I realize this is a bit of a change from using a NXT-style PoS, but the current testnet is working smoothly and I dont see the need to add a lot of complicated balance tracking that using a NXT-style PoS would require. Also, using a peercoin uxto based PoS has the problem that only one utxo per block is able to collect the staking revenues.

The other requirement is for people to be able to get 5% per year, without having to run their own node. at first I was going to rely on the notary nodes to do the staking, but I think an even more efficient way is to award all accrued interest whenever a utxo is spent. This approach might even allow interests to be earned by the protected funds, though in order to prevent abuse, the lower spectrum of the average age would need to be used. Still investigating this, but I am hopeful that something like this will work and it wont consume any measurable resources as it would only require to boost the satoshi total from the inputs based on a deterministic algo. I guess that could be one approach for the protected funds interest rates, the notaries can vote for the current applicable rate.

So you can see that while some details are changing from the original conception, the overall requirements and goals are held intact. By minimizing the changes, reliability is increased.

Words...

Selling 10,000 BTCD at market price: please PM me

@New readers: Some people announced
(1: https://bitcointalk.org/index.php?topic=1605144.msg16123524#msg16123524 ss: http://storage7.static.itmages.com/i/16/0903/h_1472918381_9751241_bb67f89f78.png
2: https://bitcointalk.org/index.php?topic=1605144.msg16124429#msg16124429 ss: http://storage2.static.itmages.com/i/16/0903/h_1472918487_6110362_00bcdfa4a9.png
3: http://storage9.static.itmages.com/i/16/0904/h_1473012841_7971883_acabee2127.png )
that they want to spread lies & fear about this ICO & jl777 to increase their own financial gain.

My personal list of FUDsters:
- pvnamk19
- Conqueror
- Hyena
- sofu
- foogatsy
- xmrlove
- airsekui
- ICOcount

(I ignore their posts now so if you are on the list and became resonable again, pm me to be removed.)
stereotype
Legendary
*
Offline Offline

Activity: 1554
Merit: 1000



View Profile
September 24, 2016, 07:39:16 AM
 #823

Taking a short break from debugging. multithreaded networking code is always tricky. I did find and fix some deadlocks, but primarily drastically simplified the control flow. Simple is a lot simpler and much less can go wrong as compared to complex logic.

What is working now are several different types of nodes that are all coexisting in the same (super) network.

Each coin of course has its normal p2p network using the bitcoin protocol. Overlaid on top of that are the supernet nodes which use the same ports, but only do supernet comms to other supernet nodes as identified during the version handshake.

For a coin, a node is either a full relay node or a basilisk lite node that queries the full nodes for the blockchain/blockexplorer data. All wallet, tx construction, signing, is done locally as it is the same codebase with some toggles for basilisk mode where it does a basilisk request instead of scanning local ramchain files.

There is a special coin with no blockchain, called NOTARY and the notary nodes would be the full relay nodes and all the others basilisk nodes for this special coin. The NOTARY p2p is now working as a pubkey messaging server and also a way to find all the active notary nodes. I am adding a layer on top of the low level pubkey messaging so a node wont keep retransmitting if the data is already there. That will make the bandwidth usage much more efficient and allow a lot of DEX trading at the same time.

I also got LP nodes to work even as a basilisk node, though it is of course faster if it is a full iguana node. Still, not having to have a full bitcoin node locally is quite handy. And with the NOTARY pubkey messaging in between, there is no direct IP level interaction between the two parties doing the atomic swap.

In order to minimize the changes needed to be made to the zcash baseline and support dPoW, having a min-diff exception for notary node blocks but still using the same PoW seems the path of least resistance. This will make the seamless transition to fully decentralized block creation in the even all the notary nodes go away, or there is some problems in getting a majority of notaries to agree, much much simpler.

With notary nodes having the min-difficulty exception, it would not be feasible for some high hash rate attacker to do 51% attacks. And even if they can anybody that just waits for the bitcoin confirmation would be protected. That is the power of dPoW as even very weak chains become quite secure.

With this plan, the biggest remaining issue is how to get the election results propagated securely. Using komodo chain to record election results has the issue that if all blocks are created by notaries, then the existing majority could block the activation of the new slate. A natural idea is to use the BTC blockchain to record the election results, but again the issue of who writes that data arises.

My idea is to ratify election results via the majority of existing notaries OR a one third majority + special signature. The special signature would be held by the devteam. With this approach, even if there is a majority of notary nodes unwilling to give up their position, it can be overridden by one third minority and the devteam.

This ties into using the zcash PoW as the method for block generation. Even with a min-diff exception, with enough hash rate a block will be able to be mined by non-notary nodes and so the (one third + special sig) transaction will be able to get onto the blockchain in spite of a hostile notary majority.

I realize this is a bit of a change from using a NXT-style PoS, but the current testnet is working smoothly and I dont see the need to add a lot of complicated balance tracking that using a NXT-style PoS would require. Also, using a peercoin uxto based PoS has the problem that only one utxo per block is able to collect the staking revenues.

The other requirement is for people to be able to get 5% per year, without having to run their own node. at first I was going to rely on the notary nodes to do the staking, but I think an even more efficient way is to award all accrued interest whenever a utxo is spent. This approach might even allow interests to be earned by the protected funds, though in order to prevent abuse, the lower spectrum of the average age would need to be used. Still investigating this, but I am hopeful that something like this will work and it wont consume any measurable resources as it would only require to boost the satoshi total from the inputs based on a deterministic algo. I guess that could be one approach for the protected funds interest rates, the notaries can vote for the current applicable rate.

So you can see that while some details are changing from the original conception, the overall requirements and goals are held intact. By minimizing the changes, reliability is increased.

Words...

Selling 10,000 BTCD at market price: please PM me

@New readers: Some people announced
(1: https://bitcointalk.org/index.php?topic=1605144.msg16123524#msg16123524 ss: http://storage7.static.itmages.com/i/16/0903/h_1472918381_9751241_bb67f89f78.png
2: https://bitcointalk.org/index.php?topic=1605144.msg16124429#msg16124429 ss: http://storage2.static.itmages.com/i/16/0903/h_1472918487_6110362_00bcdfa4a9.png
3: http://storage9.static.itmages.com/i/16/0904/h_1473012841_7971883_acabee2127.png )
that they want to spread lies & fear about this ICO & jl777 to increase their own financial gain.

My personal list of FUDsters:
- pvnamk19
- Conqueror
- Hyena
- sofu
- foogatsy
- xmrlove
- airsekui
- ICOcount

(I ignore their posts now so if you are on the list and became resonable again, pm me to be removed.)
I took the time to read airsekui's posts. I thought they were thought out and reasonable points to make, considering. Why are you not able to refute instead of simply ignoring? Easy to hide your lack of adequate communication skills, behind an 'ignore' statement, dont you think?
JUSTDLISK
Sr. Member
****
Offline Offline

Activity: 442
Merit: 250


Bancor


View Profile
September 24, 2016, 01:05:48 PM
 #824

According to this thread, this isn;t vaporware as a testnet will be released during ICO. why do critics keep saying it will take years to be completed then? or is it just fud.

KomodoPlatform
Sr. Member
****
Offline Offline

Activity: 490
Merit: 251


Set Your Ideas Free


View Profile WWW
September 24, 2016, 05:25:08 PM
 #825



◈▣ KOMODO ● Set Your Ideas Free ▣◈
.......AECOSYSTEFONATIVE BLOCKCHAINS.......
Blockchain Generator | Decentralized Crowdfunding | Decentralized Exchange | Bitcoin Security | Zero-Knowledge Proofs | Blockchain Interoperability | Scalable Infrastructure
KomodoPlatform
Sr. Member
****
Offline Offline

Activity: 490
Merit: 251


Set Your Ideas Free


View Profile WWW
September 24, 2016, 05:36:50 PM
 #826

According to this thread, this isn;t vaporware as a testnet will be released during ICO. why do critics keep saying it will take years to be completed then? or is it just fud.

Komodo development didn't start from scratch as some of the Iguana functionality is required. Iguana is low level tech build by SuperNET. Here is the GitHub: github.com/jl777/SuperNET

The Komodo development has already begun. Here is its GitHub: github.com/jl777/komodo

Zcash is also making good progress, and Komodo will be using their open source technology. Their technology is also very real and open source.

Recently jl777 also started blogging Wink You can read all about the ongoing development from here: komodoplatform.com/devblog/

I hope these points make it clear, that Komodo is definitely not vaporware.

◈▣ KOMODO ● Set Your Ideas Free ▣◈
.......AECOSYSTEFONATIVE BLOCKCHAINS.......
Blockchain Generator | Decentralized Crowdfunding | Decentralized Exchange | Bitcoin Security | Zero-Knowledge Proofs | Blockchain Interoperability | Scalable Infrastructure
criptix
Legendary
*
Offline Offline

Activity: 1526
Merit: 1035


View Profile
September 24, 2016, 06:03:11 PM
 #827

According to this thread, this isn;t vaporware as a testnet will be released during ICO. why do critics keep saying it will take years to be completed then? or is it just fud.

Komodo development didn't start from scratch as some of the Iguana functionality is required. Iguana is low level tech build by SuperNET. Here is the GitHub: github.com/jl777/SuperNET

The Komodo development has already begun. Here is its GitHub: github.com/jl777/komodo

Zcash is also making good progress, and Komodo will be using their open source technology. Their technology is also very real and open source.

Recently jl777 also started blogging Wink You can read all about the ongoing development from here: komodoplatform.com/devblog/

I hope these points make it clear, that Komodo is definitely not vaporware.

Do you guys have any plan to change how some trusted entities have to set up the starting params of the blockchain?

As far as i understand that is one serious problem for zcash.

Bounty Management & ICO Consulting
Inquire
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1056


View Profile WWW
September 24, 2016, 06:20:48 PM
 #828

According to this thread, this isn;t vaporware as a testnet will be released during ICO. why do critics keep saying it will take years to be completed then? or is it just fud.

Komodo development didn't start from scratch as some of the Iguana functionality is required. Iguana is low level tech build by SuperNET. Here is the GitHub: github.com/jl777/SuperNET

The Komodo development has already begun. Here is its GitHub: github.com/jl777/komodo

Zcash is also making good progress, and Komodo will be using their open source technology. Their technology is also very real and open source.

Recently jl777 also started blogging Wink You can read all about the ongoing development from here: komodoplatform.com/devblog/

I hope these points make it clear, that Komodo is definitely not vaporware.

Do you guys have any plan to change how some trusted entities have to set up the starting params of the blockchain?

As far as i understand that is one serious problem for zcash.
It is not as big of an issue as it is made out to be. But since it appears to be the only possible weakness of zcash, a lot of noise is being made about it.

https://z.cash/blog/snark-parameters.html
http://diyhpl.us/~bryan/papers2/bitcoin/snarks/Secure%20sampling%20of%20public%20parameters%20for%20succinct%20zero%20knowledge%20proofs.pdf

The reality is that all of the people involved in creating the parameters have to collude with everyone else, ie. a total conspiracy. Knowing the zcash devs a bit, I do not believe this is anything to worry about.

The other theoretical attack against this is that ALL of the people involved in creating the parameters either collude with everyone else or they run compromised hardware/software that allows an attacker to reconstruct the entire dataset.

Now maybe some govt can run a mission impossible type of op to counteract all the countermeasures in place, but even if the parameters are compromised, the privacy wont be. And since the only entities that I can conceive of that can even think about running such an operation can already print all the money they want, they have no incentive to do such a low return project.

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
baggle
Full Member
***
Offline Offline

Activity: 238
Merit: 100


View Profile
September 24, 2016, 06:45:32 PM
 #829

I'm interested in the project, and will likely follow it, but i definitely can't take it seriously:

https://komodoplatform.com/#about

Dunno... rename the page or something... this isn't "meeting" the team.

Edit: white paper?

KomodoPlatform
Sr. Member
****
Offline Offline

Activity: 490
Merit: 251


Set Your Ideas Free


View Profile WWW
September 24, 2016, 07:34:04 PM
 #830

I'm interested in the project, and will likely follow it, but i definitely can't take it seriously:

https://komodoplatform.com/#about

Dunno... rename the page or something... this isn't "meeting" the team.

Edit: white paper?

White paper is coming.

Noted, we should make a better team introduction.

◈▣ KOMODO ● Set Your Ideas Free ▣◈
.......AECOSYSTEFONATIVE BLOCKCHAINS.......
Blockchain Generator | Decentralized Crowdfunding | Decentralized Exchange | Bitcoin Security | Zero-Knowledge Proofs | Blockchain Interoperability | Scalable Infrastructure
noashh
Sr. Member
****
Offline Offline

Activity: 371
Merit: 250



View Profile
September 24, 2016, 08:24:04 PM
 #831

Taking a short break from debugging. multithreaded networking code is always tricky. I did find and fix some deadlocks, but primarily drastically simplified the control flow. Simple is a lot simpler and much less can go wrong as compared to complex logic.

What is working now are several different types of nodes that are all coexisting in the same (super) network.

Each coin of course has its normal p2p network using the bitcoin protocol. Overlaid on top of that are the supernet nodes which use the same ports, but only do supernet comms to other supernet nodes as identified during the version handshake.

For a coin, a node is either a full relay node or a basilisk lite node that queries the full nodes for the blockchain/blockexplorer data. All wallet, tx construction, signing, is done locally as it is the same codebase with some toggles for basilisk mode where it does a basilisk request instead of scanning local ramchain files.

There is a special coin with no blockchain, called NOTARY and the notary nodes would be the full relay nodes and all the others basilisk nodes for this special coin. The NOTARY p2p is now working as a pubkey messaging server and also a way to find all the active notary nodes. I am adding a layer on top of the low level pubkey messaging so a node wont keep retransmitting if the data is already there. That will make the bandwidth usage much more efficient and allow a lot of DEX trading at the same time.

I also got LP nodes to work even as a basilisk node, though it is of course faster if it is a full iguana node. Still, not having to have a full bitcoin node locally is quite handy. And with the NOTARY pubkey messaging in between, there is no direct IP level interaction between the two parties doing the atomic swap.

In order to minimize the changes needed to be made to the zcash baseline and support dPoW, having a min-diff exception for notary node blocks but still using the same PoW seems the path of least resistance. This will make the seamless transition to fully decentralized block creation in the even all the notary nodes go away, or there is some problems in getting a majority of notaries to agree, much much simpler.

With notary nodes having the min-difficulty exception, it would not be feasible for some high hash rate attacker to do 51% attacks. And even if they can anybody that just waits for the bitcoin confirmation would be protected. That is the power of dPoW as even very weak chains become quite secure.

With this plan, the biggest remaining issue is how to get the election results propagated securely. Using komodo chain to record election results has the issue that if all blocks are created by notaries, then the existing majority could block the activation of the new slate. A natural idea is to use the BTC blockchain to record the election results, but again the issue of who writes that data arises.

My idea is to ratify election results via the majority of existing notaries OR a one third majority + special signature. The special signature would be held by the devteam. With this approach, even if there is a majority of notary nodes unwilling to give up their position, it can be overridden by one third minority and the devteam.

This ties into using the zcash PoW as the method for block generation. Even with a min-diff exception, with enough hash rate a block will be able to be mined by non-notary nodes and so the (one third + special sig) transaction will be able to get onto the blockchain in spite of a hostile notary majority.

I realize this is a bit of a change from using a NXT-style PoS, but the current testnet is working smoothly and I dont see the need to add a lot of complicated balance tracking that using a NXT-style PoS would require. Also, using a peercoin uxto based PoS has the problem that only one utxo per block is able to collect the staking revenues.

The other requirement is for people to be able to get 5% per year, without having to run their own node. at first I was going to rely on the notary nodes to do the staking, but I think an even more efficient way is to award all accrued interest whenever a utxo is spent. This approach might even allow interests to be earned by the protected funds, though in order to prevent abuse, the lower spectrum of the average age would need to be used. Still investigating this, but I am hopeful that something like this will work and it wont consume any measurable resources as it would only require to boost the satoshi total from the inputs based on a deterministic algo. I guess that could be one approach for the protected funds interest rates, the notaries can vote for the current applicable rate.

So you can see that while some details are changing from the original conception, the overall requirements and goals are held intact. By minimizing the changes, reliability is increased.

Words...

Selling 10,000 BTCD at market price: please PM me

@New readers: Some people announced
(1: https://bitcointalk.org/index.php?topic=1605144.msg16123524#msg16123524 ss: http://storage7.static.itmages.com/i/16/0903/h_1472918381_9751241_bb67f89f78.png
2: https://bitcointalk.org/index.php?topic=1605144.msg16124429#msg16124429 ss: http://storage2.static.itmages.com/i/16/0903/h_1472918487_6110362_00bcdfa4a9.png
3: http://storage9.static.itmages.com/i/16/0904/h_1473012841_7971883_acabee2127.png )
that they want to spread lies & fear about this ICO & jl777 to increase their own financial gain.

My personal list of FUDsters:
- pvnamk19
- Conqueror
- Hyena
- sofu
- foogatsy
- xmrlove
- airsekui
- ICOcount

(I ignore their posts now so if you are on the list and became resonable again, pm me to be removed.)
I took the time to read airsekui's posts. I thought they were thought out and reasonable points to make, considering. Why are you not able to refute instead of simply ignoring? Easy to hide your lack of adequate communication skills, behind an 'ignore' statement, dont you think?

He made a lot of wrong statements, ie. that jl777 wants to make money for his own good, never finishes projects or doesn't know how to use git. Those lies have been refuted in this thread already. Still he did not delete or correct his posts so he is still on the list. His lies are definitely not "thought out and reasonable", you should take the time to read the answers to them if you still believe that.
Joint Force
Hero Member
*****
Offline Offline

Activity: 774
Merit: 500

DAO ↔ DApp


View Profile WWW
September 25, 2016, 03:06:24 AM
 #832


I'm buying more $BTCD in preparation of the swap. It seems like a good plan. I get to lock in the bonus price and can swap at anytime over the next year.

Cokezero
Member
**
Offline Offline

Activity: 86
Merit: 10


View Profile
September 25, 2016, 10:08:04 AM
 #833

German translation bounty?

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ◄ matchpool - ICO March 25th 2017 ► ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▄▄▄▄               Meet your match    ◾    Changing the way we date    ◾    Join us now!               ▄▄▄▄
▀▀▀▀▀▀▀▀▀                        Smart contract rewards    ◾    Link people together                        ▀▀▀▀▀▀▀▀▀
KomodoPlatform
Sr. Member
****
Offline Offline

Activity: 490
Merit: 251


Set Your Ideas Free


View Profile WWW
September 25, 2016, 10:14:23 AM
 #834

German translation bounty?

Yes we had one. The thread is already up: https://bitcointalk.org/index.php?topic=1625321.msg16340933#msg16340933



We are looking for volunteers to post and maintain Spanish and Chinese threads. Everything is ready, we just need someone to post them.


◈▣ KOMODO ● Set Your Ideas Free ▣◈
.......AECOSYSTEFONATIVE BLOCKCHAINS.......
Blockchain Generator | Decentralized Crowdfunding | Decentralized Exchange | Bitcoin Security | Zero-Knowledge Proofs | Blockchain Interoperability | Scalable Infrastructure
Cokezero
Member
**
Offline Offline

Activity: 86
Merit: 10


View Profile
September 25, 2016, 10:16:10 AM
 #835

bounty for German translation of upcoming whitepaper?

- Have a Master in Finance.

▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬ ◄ matchpool - ICO March 25th 2017 ► ▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬▬
▄▄▄▄               Meet your match    ◾    Changing the way we date    ◾    Join us now!               ▄▄▄▄
▀▀▀▀▀▀▀▀▀                        Smart contract rewards    ◾    Link people together                        ▀▀▀▀▀▀▀▀▀
KomodoPlatform
Sr. Member
****
Offline Offline

Activity: 490
Merit: 251


Set Your Ideas Free


View Profile WWW
September 25, 2016, 10:21:39 AM
 #836

bounty for German translation of upcoming whitepaper?

- Have a Master in Finance.

Currently we have no plans to translate the whitepaper. Sorry!

◈▣ KOMODO ● Set Your Ideas Free ▣◈
.......AECOSYSTEFONATIVE BLOCKCHAINS.......
Blockchain Generator | Decentralized Crowdfunding | Decentralized Exchange | Bitcoin Security | Zero-Knowledge Proofs | Blockchain Interoperability | Scalable Infrastructure
Wapinter
Copper Member
Legendary
*
Offline Offline

Activity: 1008
Merit: 1018


t.me/wapinter


View Profile
September 25, 2016, 10:39:08 AM
 #837

Taking a short break from debugging. multithreaded networking code is always tricky. I did find and fix some deadlocks, but primarily drastically simplified the control flow. Simple is a lot simpler and much less can go wrong as compared to complex logic.

What is working now are several different types of nodes that are all coexisting in the same (super) network.

Each coin of course has its normal p2p network using the bitcoin protocol. Overlaid on top of that are the supernet nodes which use the same ports, but only do supernet comms to other supernet nodes as identified during the version handshake.

For a coin, a node is either a full relay node or a basilisk lite node that queries the full nodes for the blockchain/blockexplorer data. All wallet, tx construction, signing, is done locally as it is the same codebase with some toggles for basilisk mode where it does a basilisk request instead of scanning local ramchain files.

There is a special coin with no blockchain, called NOTARY and the notary nodes would be the full relay nodes and all the others basilisk nodes for this special coin. The NOTARY p2p is now working as a pubkey messaging server and also a way to find all the active notary nodes. I am adding a layer on top of the low level pubkey messaging so a node wont keep retransmitting if the data is already there. That will make the bandwidth usage much more efficient and allow a lot of DEX trading at the same time.

I also got LP nodes to work even as a basilisk node, though it is of course faster if it is a full iguana node. Still, not having to have a full bitcoin node locally is quite handy. And with the NOTARY pubkey messaging in between, there is no direct IP level interaction between the two parties doing the atomic swap.

In order to minimize the changes needed to be made to the zcash baseline and support dPoW, having a min-diff exception for notary node blocks but still using the same PoW seems the path of least resistance. This will make the seamless transition to fully decentralized block creation in the even all the notary nodes go away, or there is some problems in getting a majority of notaries to agree, much much simpler.

With notary nodes having the min-difficulty exception, it would not be feasible for some high hash rate attacker to do 51% attacks. And even if they can anybody that just waits for the bitcoin confirmation would be protected. That is the power of dPoW as even very weak chains become quite secure.

With this plan, the biggest remaining issue is how to get the election results propagated securely. Using komodo chain to record election results has the issue that if all blocks are created by notaries, then the existing majority could block the activation of the new slate. A natural idea is to use the BTC blockchain to record the election results, but again the issue of who writes that data arises.

My idea is to ratify election results via the majority of existing notaries OR a one third majority + special signature. The special signature would be held by the devteam. With this approach, even if there is a majority of notary nodes unwilling to give up their position, it can be overridden by one third minority and the devteam.

This ties into using the zcash PoW as the method for block generation. Even with a min-diff exception, with enough hash rate a block will be able to be mined by non-notary nodes and so the (one third + special sig) transaction will be able to get onto the blockchain in spite of a hostile notary majority.

I realize this is a bit of a change from using a NXT-style PoS, but the current testnet is working smoothly and I dont see the need to add a lot of complicated balance tracking that using a NXT-style PoS would require. Also, using a peercoin uxto based PoS has the problem that only one utxo per block is able to collect the staking revenues.

The other requirement is for people to be able to get 5% per year, without having to run their own node. at first I was going to rely on the notary nodes to do the staking, but I think an even more efficient way is to award all accrued interest whenever a utxo is spent. This approach might even allow interests to be earned by the protected funds, though in order to prevent abuse, the lower spectrum of the average age would need to be used. Still investigating this, but I am hopeful that something like this will work and it wont consume any measurable resources as it would only require to boost the satoshi total from the inputs based on a deterministic algo. I guess that could be one approach for the protected funds interest rates, the notaries can vote for the current applicable rate.

So you can see that while some details are changing from the original conception, the overall requirements and goals are held intact. By minimizing the changes, reliability is increased.

Words...

Selling 10,000 BTCD at market price: please PM me
I would prefer buying ICO with 25% bonus. That would be cheaper I guess

jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1056


View Profile WWW
September 25, 2016, 07:34:41 PM
 #838

bobfee: https://blockchain.info/tx/c744797a702f05f5af5bfead20f7539dacfd8d705337d027317bc7aefe514877

alicefee: http://explorebtcd.info/tx/f087dbfb61c1c1766e5e55239f3e3a456b9995694b25ecf245f5eeb49f090e98

bobdeposit: https://blockchain.info/tx/aae38c9e59edafda7823f2df5890195ae162491b627a483c09b2e5f77ff51c73

alicepayment: http://explorebtcd.info/tx/82ee2816ba4f7cd69bafeab5b218a1d41e23296f5738e9e9e7ddc71a60c1964a

bobpayment: https://blockchain.info/tx/e0fa2778d16b204b413611f2e96a2643168ecf3316e8d694cfff4dce7ce52506


http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Bavaria
Hero Member
*****
Offline Offline

Activity: 781
Merit: 500


Blockchain Just Entered The Real World


View Profile
September 25, 2016, 08:15:52 PM
 #839


Can someone explain what all this mean?

      ███████████████████████
     ███▄ ▄▄▄▄   ▄▄▄█▀▀  █████
    ███  █▀  ▀█▀▀▀       ▐█ ███
   ███  ▄██▄▄█▀▄▄▄        █▌ ███
  ███ ▄█▀  █     ▀█▄▄     ▐█  ▐██
 ███▄█▀    █        ▀█▄▄  ▄▄▄ ██
████▀      █           ▀██▀   ▀█ ██
 ██▀█▄     █          ▄█▀▀█▄▄▄█▀██
  ██ ▀█▄   █      ▄▄█▀▀    ▐█  ██
   ██  ▀█▄█▀▀█▄▄█▀▀        █▌ ██
    ███  █▄  ▄█▀█▄▄▄      █▌███
     ███  ▀▀▀▀     ▀▀▀█▄▄▐████
      ███████████████████████

 ▄▄       ▄▄▄        ▄▄   ▄▄▄▄▄ 
  ▀█▄   ▄█▀ ▀█▄    ▄█▀ ▄█▀▀   ▀▀█▄
    ▀█▄█▀     ▀█▄▄█▀  ▐█         █▌
    ▄█▀█▄      ▄█▀    ▐█         █▌
  ▄█▀   ▀█▄  ▄█▀       █▄       ▄█
▄█▀       ▀██▀          ▀▀█▄▄▄█▀▀


Network
BLOCKCHAIN JUST ENTERED THE REAL WORLD
..Decentralized Crypto-Location Oracle Network.
.........GET WHITELISTED FOR TOKEN SALE ( Limited )..........

.WHITE PAPER.  ││  ANN Thread  Telegram   Medium   Twitter   Reddit
jl777
Legendary
*
Offline Offline

Activity: 1176
Merit: 1056


View Profile WWW
September 25, 2016, 08:26:50 PM
 #840

When I used a lot of words, I was criticized for it, so I figured I would just post the txids created automatically by the iguana DEX process.

Words dont create txids, only working code does so it is my way to show that there is plenty of working code already.

I still have some issues I am working on with the robustness of the atomic swap state machine and the reclaiming of funds in the custom timelocked transactions, but the primary txcreation is automatic following a few API calls on the two test nodes. After connecting to the testnet notary nodes (8 of them) the following calls are done:

LP node:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"tradebot\",\"method\":\"amlp\"}"
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"tradebot\",\"method\":\"liquidity\",\"targetcoin\":\"BTCD\",\"vals\":{\"profit\":0.005}}"

Now the LP node is operating as a liquidity provider and it is making a market in BTCD <-> BTC swaps at a 0.5% profit margin. Any number of coins can be active on a specific LP node, but enough funds needs to be available for each supported coin.

Once this is setup, any end user node can do:
curl --url "http://127.0.0.1:7778" --data "{\"agent\":\"InstantDEX\",\"method\":\"request\",\"vals\":{\"source\":\"BTCD\",\"amount\":0.1,\"dest\":\"BTC\",\"minprice\":0.004}}"

The above starts a realtime auction among all the BTCD LP nodes and the best price is selected. For the test there is only one LP node, so the minprice is set to make sure at least .004 BTC is obtained.

After the above, the atomic swap DEX statemachine is started on both sides and the 5 transactions were sent back and forth to effect the swap.

Words... indeed

http://www.digitalcatallaxy.com/report2015.html
100+ page annual report for SuperNET
Pages: « 1 2 3 4 5 6 7 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 ... 803 »
  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!