|
O_Omaha
|
 |
October 25, 2016, 07:41:31 PM |
|
I hope this is not another broken down Lisk clone. Will read the white paper and let you know.  |
|
|
|
|
|
|
|
|
|
|
|
|
|
Make sure you back up your wallet regularly! Unlike a bank account, nobody can help you if you lose access to your BTC.
|
|
|
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction.
|
|
|
|
Devasive
|
|
October 25, 2016, 07:42:29 PM |
|
I hope this is not another broken down Lisk clone. Will read the white paper and let you know. There is much to read! Please share your thoughts after you take it all in.  |
|
|
|
|
|
Samuray
|
|
October 25, 2016, 07:43:20 PM |
|
Prepare your Lisk bags for the best project of 2016 !  |
|
|
|
|
cannabanana
|
|
October 25, 2016, 07:44:00 PM |
|
I hope this is not another broken down Lisk clone. Will read the white paper and let you know. You also gotta understand who we are. We're basically part of the group that runs a majority of Lisk testnet and mainnet nodes. Not just a copy and paste team. |
|
|
|
|
leto.atreides
Newbie
 Offline
Activity: 53
Merit: 0
|
|
October 25, 2016, 07:49:44 PM |
|
excellent start guys! good luck Thank you! |
|
|
|
|
|
O_Omaha
|
|
October 25, 2016, 07:57:12 PM |
|
I hope this is not another broken down Lisk clone. Will read the white paper and let you know. There is much to read! Please share your thoughts after you take it all in. I like how you are doing the delegate voting. 1 ark is 1 vote. Lisk does it very different. In Lisk the developer has all the voting power. In Ark looks like the developer can vote himself in but if he votes for his buddy, it splits his power 50/50 over the 2 delegates. Nice change! I like. still reading. |
|
|
|
|
|
cannabanana
|
|
October 25, 2016, 08:00:13 PM |
|
I hope this is not another broken down Lisk clone. Will read the white paper and let you know. There is much to read! Please share your thoughts after you take it all in. I like how you are doing the delegate voting. 1 ark is 1 vote. Lisk does it very different. In Lisk the developer has all the voting power. In Ark looks like the developer can vote himself in but if he votes for his buddy, it splits his power over the 2 delegates. Nice change! I like. still reading. hehe we are well aware of that issue and wanted to correct it for our system as we feel it's a lot more fair. Even when we are done with our token exchange, us individually with our coin split will not have an advantage over the token exchange participants at being able to forge ark |
|
|
|
|
ArkEcosystem
Member
Offline
Activity: 70
Merit: 10
|
|
October 25, 2016, 08:11:16 PM |
|
Thanks all for the Support! We have really great plans for our organization!
|
|
|
|
|
|
MrPresident
|
|
October 25, 2016, 08:16:38 PM |
|
Has a forging solution been found/tested? (sorry, I had to ask)
|
Develop Custom Decentralized Blockchain Applications in JavaScript with LISK!
Website | Blog | BTT Thread | Chat - Be part of the decentralized application movement!
|
|
|
|
cannabanana
|
|
October 25, 2016, 08:20:15 PM |
|
has a forging solution been found? (sorry I had to ask)
yes, we are going to implement pre-approval PBFT blocks. Fixcrypt says that it will do the job right. |
|
|
|
|
|
bitseedmike
|
|
October 25, 2016, 08:21:20 PM |
|
Yes. We are using a combination of Practical Byzantine Fault Tolerance to pre-approve blocks along the lines of what Asch is doing to prevent forks and forging from uncles to allow delegates to create new blocks in cases where the prior block might still be delayed to decrease latency, decreasing blocktime.
|
|
|
|
|
O_Omaha
|
|
October 25, 2016, 08:28:21 PM |
|
I hope this is not another broken down Lisk clone. Will read the white paper and let you know. There is much to read! Please share your thoughts after you take it all in. I like how you are doing the delegate voting. 1 ark is 1 vote. Lisk does it very different. In Lisk the developer has all the voting power. In Ark looks like the developer can vote himself in but if he votes for his buddy, it splits his power over the 2 delegates. Nice change! I like. still reading. hehe we are well aware of that issue and wanted to correct it for our system as we feel it's a lot more fair. Even when we are done with our token exchange, us individually with our coin split will not have an advantage over the token exchange participants at being able to forge ark I must say your whitepaper is very impressive! the "smart bridging" feature, if it actually works and I'm assuming here that it does, can be a huge success. |
|
|
|
|
|
cannabanana
|
|
October 25, 2016, 08:31:17 PM |
|
I hope this is not another broken down Lisk clone. Will read the white paper and let you know. There is much to read! Please share your thoughts after you take it all in. I like how you are doing the delegate voting. 1 ark is 1 vote. Lisk does it very different. In Lisk the developer has all the voting power. In Ark looks like the developer can vote himself in but if he votes for his buddy, it splits his power over the 2 delegates. Nice change! I like. still reading. hehe we are well aware of that issue and wanted to correct it for our system as we feel it's a lot more fair. Even when we are done with our token exchange, us individually with our coin split will not have an advantage over the token exchange participants at being able to forge ark I must say your whitepaper is very impressive! the "smart bridging" feature, if it actually works and I'm assuming here that it does, can be a huge success. being delegates for Lisk, we've spent a lot of time together discussing in our own private slack what we think will fix the Lisk implementation of DPoS and where it went astray from the objectives of the Crypti. We decided to go back to square one and develop it fairly with an even more forward thinking way. |
|
|
|
|
|
MrPresident
|
|
October 25, 2016, 08:31:22 PM |
|
has a forging solution been found? (sorry I had to ask)
yes, we are going to implement pre-approval PBFT blocks. Fixcrypt says that it will do the job right. Yes. We are using a combination of Practical Byzantine Fault Tolerance to pre-approve blocks along the lines of what Asch is doing to prevent forks and forging from uncles to allow delegates to create new blocks in cases where the prior block might still be delayed to decrease latency, decreasing blocktime.
ooh?... Now I'm impressed all to fuck and back. |
Develop Custom Decentralized Blockchain Applications in JavaScript with LISK!
Website | Blog | BTT Thread | Chat - Be part of the decentralized application movement!
|
|
|
|
O_Omaha
|
|
October 25, 2016, 08:32:14 PM |
|
Yes. We are using a combination of Practical Byzantine Fault Tolerance to pre-approve blocks along the lines of what Asch is doing to prevent forks and forging from uncles to allow delegates to create new blocks in cases where the prior block might still be delayed to decrease latency, decreasing blocktime.
So this will stabilize the core? |
|
|
|
|
|
MrPresident
|
|
October 25, 2016, 08:34:50 PM |
|
uuugh, so now I wait. Only 20k lisk in pocket and a gazillion in ICN holding me up as LSK rises haha my luck.
|
Develop Custom Decentralized Blockchain Applications in JavaScript with LISK!
Website | Blog | BTT Thread | Chat - Be part of the decentralized application movement!
|
|
|
freemind1
Legendary
Offline
Activity: 1526
Merit: 1014
|
|
October 25, 2016, 08:35:19 PM |
|
Yes. We are using a combination of Practical Byzantine Fault Tolerance to pre-approve blocks along the lines of what Asch is doing to prevent forks and forging from uncles to allow delegates to create new blocks in cases where the prior block might still be delayed to decrease latency, decreasing blocktime.
So this will stabilize the core? Yes @O_Omaha, and allows delegates to forge. |
|
|
|
|
|
cannabanana
|
|
October 25, 2016, 08:36:28 PM |
|
Yes. We are using a combination of Practical Byzantine Fault Tolerance to pre-approve blocks along the lines of what Asch is doing to prevent forks and forging from uncles to allow delegates to create new blocks in cases where the prior block might still be delayed to decrease latency, decreasing blocktime.
So this will stabilize the core? yes. and also with many other things, when you add MORE features to the core you also introduce more points of faults which can be potentially compromised. Our system streamlines our core to make it more secure and fast but also uses other blockchain layers to help handle the issues associated with js. but Short answer, yes it will fix the problems. |
|
|
|
|
|
MrPresident
|
|
October 25, 2016, 08:36:55 PM
Last edit: October 25, 2016, 09:05:49 PM by MrPresident |
|
WAIT!
I have an itch to spend BTC but there's no ico yet hahaha
|
Develop Custom Decentralized Blockchain Applications in JavaScript with LISK!
Website | Blog | BTT Thread | Chat - Be part of the decentralized application movement!
|
|
|
|
Devasive
|
|
October 25, 2016, 08:37:40 PM |
|
Yes. We are using a combination of Practical Byzantine Fault Tolerance to pre-approve blocks along the lines of what Asch is doing to prevent forks and forging from uncles to allow delegates to create new blocks in cases where the prior block might still be delayed to decrease latency, decreasing blocktime.
So this will stabilize the core? Faster block-times as well due to the lower active delegate number of 51. |
|
|
|
|
|
