Pages:
Author

Topic: Louisd’or(codename)- first anonymous PoS, CN-based currency (technical review) - page 4. (Read 22144 times)

hero member
Activity: 770
Merit: 500
FLY DONATION ADDRESS IN SIGNATURE
So has this coin been released yet? Are we able to start mining it yet? Let me know please and thank you
@bb
full member
Activity: 137
Merit: 100
We all want cryptonight  Wink

Well, we concidered cryptonight as option but finally we decided to go in different way, but still - it's not e kay feature of this project.
BTW, current implementation of PoS is significantly changed compared with that was shared in public repo.

Zoidberg

So to confirm, this will no longer be a cryptonight PoS coin?

Dont worry because the protocol still cryptonote much more advanced than bitcoin.
@bb
full member
Activity: 137
Merit: 100
We all want cryptonight  Wink

I had the same hope.  Sad

Criptonight had been optimized for cpu mining, even for one core botnet would have almost same hash with high end gpu, too bad it had not been optimized for gpu.
legendary
Activity: 1498
Merit: 1000
Looking fwd for this project, so excited!
hero member
Activity: 574
Merit: 500
hero member
Activity: 714
Merit: 504
We all want cryptonight  Wink

Well, we concidered cryptonight as option but finally we decided to go in different way, but still - it's not e kay feature of this project.
BTW, current implementation of PoS is significantly changed compared with that was shared in public repo.

Zoidberg

So to confirm, this will no longer be a cryptonight PoS coin?
hero member
Activity: 976
Merit: 646
We all want cryptonight  Wink

Well, we concidered cryptonight as option but finally we decided to go in different way, but still - it's not e kay feature of this project.
BTW, current implementation of PoS is significantly changed compared with that was shared in public repo.

Zoidberg
hero member
Activity: 976
Merit: 646

PoW hash has been changed, it's not a criptonight and it's not WildKeccak - it's well known hash with opens source gpu miners.

Zoidberg


Any known hashfunction is fine, just make sure it already well optimized imho, if possible even when the asic of the hashfunction will be made there are no room or just little room to crank up performance.

What about the scratchpad? Still use it or not?



Nope, for PoW we use common approach with usual hash function.

Zoidberg
sr. member
Activity: 240
Merit: 250
@bb
full member
Activity: 137
Merit: 100

PoW hash has been changed, it's not a criptonight and it's not WildKeccak - it's well known hash with opens source gpu miners.

Zoidberg


Any known hashfunction is fine, just make sure it already well optimized imho, if possible even when the asic of the hashfunction will be made there are no room or just little room to crank up performance.

What about the scratchpad? Still use it or not?

hero member
Activity: 976
Merit: 646
Snipped....

We have about 4-5 BTC of bounties for people who gonna find bugs/flaws in design or implementation: most serious critical flaw gonna get 2 BTC, next less critical 1 BTC, next 0.5 BTC and so on.

Brief description link(mini-whitepaper): http://162.243.101.90/lui_share.pdf
Implementation: https://github.com/cryptobender/lui
Notice: Implementation does not completely reflect mini-whitepaper description, it still in development, so i often do some commits and restart test network every 2-3 days. Atm we have network that running about of couple of days and seems to be okay.

Feel free to post any questions and ideas here or to PM.

Zoidberg

I read the white paper, there is mentioned about iteration of hash.

1. I think the hash shouldnt be iterated at 500k times, just let it plain 1 iteration, because when somebody figure out how to trick it with getpassediteration() function then he/she might get 50 times faster miner. Just learn from B*R how someone got 100x faster miner by passed the iteration. By letting it without iteration anyone will have same opportunity with maximum hash depending on hardware configuration.

2. If this project's target to make coin asic-proof then the scratchpad should be no less than 2MB but bigger scratchpad would be great to stay away from asic development. Because we know all hashfunction can be asic-fied.

CMIIW.



Quote
because when somebody figure out how to trick it with getpassediteration() function

Can you clarify it ?

Zoidberg


I didnt mean literally there is a "getpassediteration()" function, but the optimization is out there where people try to make asic, by evident to what has happened to the hashrate of B*R in the beginning i remembered, and deduction method of thinking, i believe someone has optimized this iteration.

So if the hash is already optimized without iteration, someone try to optimized it will be futile or just get little faster hash.

Still not clear from me.
You mention that you read the whitepaper... can you refer or give a quote ? cz i can't even understand if you mean PoW or PoS mining iteration ?


It is the POW sir. 500k iteration and lower scratxhpad to 1MB. If the iteration down to 1 what will happened to the hashrate? Higher or lower?

PoW hash has been changed, it's not a criptonight and it's not WildKeccak - it's well known hash with opens source gpu miners.

Zoidberg
@bb
full member
Activity: 137
Merit: 100
Snipped....

We have about 4-5 BTC of bounties for people who gonna find bugs/flaws in design or implementation: most serious critical flaw gonna get 2 BTC, next less critical 1 BTC, next 0.5 BTC and so on.

Brief description link(mini-whitepaper): http://162.243.101.90/lui_share.pdf
Implementation: https://github.com/cryptobender/lui
Notice: Implementation does not completely reflect mini-whitepaper description, it still in development, so i often do some commits and restart test network every 2-3 days. Atm we have network that running about of couple of days and seems to be okay.

Feel free to post any questions and ideas here or to PM.

Zoidberg

I read the white paper, there is mentioned about iteration of hash.

1. I think the hash shouldnt be iterated at 500k times, just let it plain 1 iteration, because when somebody figure out how to trick it with getpassediteration() function then he/she might get 50 times faster miner. Just learn from B*R how someone got 100x faster miner by passed the iteration. By letting it without iteration anyone will have same opportunity with maximum hash depending on hardware configuration.

2. If this project's target to make coin asic-proof then the scratchpad should be no less than 2MB but bigger scratchpad would be great to stay away from asic development. Because we know all hashfunction can be asic-fied.

CMIIW.



Quote
because when somebody figure out how to trick it with getpassediteration() function

Can you clarify it ?

Zoidberg


I didnt mean literally there is a "getpassediteration()" function, but the optimization is out there where people try to make asic, by evident to what has happened to the hashrate of B*R in the beginning i remembered, and deduction method of thinking, i believe someone has optimized this iteration.

So if the hash is already optimized without iteration, someone try to optimized it will be futile or just get little faster hash.

Still not clear from me.
You mention that you read the whitepaper... can you refer or give a quote ? cz i can't even understand if you mean PoW or PoS mining iteration ?


It is the POW sir. 500k iteration and lower scratxhpad to 1MB. If the iteration down to 1 what will happened to the hashrate? Higher or lower?
hero member
Activity: 976
Merit: 646
Snipped....

We have about 4-5 BTC of bounties for people who gonna find bugs/flaws in design or implementation: most serious critical flaw gonna get 2 BTC, next less critical 1 BTC, next 0.5 BTC and so on.

Brief description link(mini-whitepaper): http://162.243.101.90/lui_share.pdf
Implementation: https://github.com/cryptobender/lui
Notice: Implementation does not completely reflect mini-whitepaper description, it still in development, so i often do some commits and restart test network every 2-3 days. Atm we have network that running about of couple of days and seems to be okay.

Feel free to post any questions and ideas here or to PM.

Zoidberg

I read the white paper, there is mentioned about iteration of hash.

1. I think the hash shouldnt be iterated at 500k times, just let it plain 1 iteration, because when somebody figure out how to trick it with getpassediteration() function then he/she might get 50 times faster miner. Just learn from B*R how someone got 100x faster miner by passed the iteration. By letting it without iteration anyone will have same opportunity with maximum hash depending on hardware configuration.

2. If this project's target to make coin asic-proof then the scratchpad should be no less than 2MB but bigger scratchpad would be great to stay away from asic development. Because we know all hashfunction can be asic-fied.

CMIIW.



Quote
because when somebody figure out how to trick it with getpassediteration() function

Can you clarify it ?

Zoidberg


I didnt mean literally there is a "getpassediteration()" function, but the optimization is out there where people try to make asic, by evident to what has happened to the hashrate of B*R in the beginning i remembered, and deduction method of thinking, i believe someone has optimized this iteration.

So if the hash is already optimized without iteration, someone try to optimized it will be futile or just get little faster hash.

Still not clear from me.
You mention that you read the whitepaper... can you refer or give a quote ? cz i can't even understand if you mean PoW or PoS mining iteration ?






@bb
full member
Activity: 137
Merit: 100
Snipped....

We have about 4-5 BTC of bounties for people who gonna find bugs/flaws in design or implementation: most serious critical flaw gonna get 2 BTC, next less critical 1 BTC, next 0.5 BTC and so on.

Brief description link(mini-whitepaper): http://162.243.101.90/lui_share.pdf
Implementation: https://github.com/cryptobender/lui
Notice: Implementation does not completely reflect mini-whitepaper description, it still in development, so i often do some commits and restart test network every 2-3 days. Atm we have network that running about of couple of days and seems to be okay.

Feel free to post any questions and ideas here or to PM.

Zoidberg

I read the white paper, there is mentioned about iteration of hash.

1. I think the hash shouldnt be iterated at 500k times, just let it plain 1 iteration, because when somebody figure out how to trick it with getpassediteration() function then he/she might get 50 times faster miner. Just learn from B*R how someone got 100x faster miner by passed the iteration. By letting it without iteration anyone will have same opportunity with maximum hash depending on hardware configuration.

2. If this project's target to make coin asic-proof then the scratchpad should be no less than 2MB but bigger scratchpad would be great to stay away from asic development. Because we know all hashfunction can be asic-fied.

CMIIW.



Quote
because when somebody figure out how to trick it with getpassediteration() function

Can you clarify it ?

Zoidberg


I didnt mean literally there is a "getpassediteration()" function, but the optimization is out there where people try to make asic, by evident to what has happened to the hashrate of B*R in the beginning i remembered, and deduction method of thinking, i believe someone has optimized this iteration.

So if the hash is already optimized without iteration, someone try to optimized it will be futile or just get little faster hash.
hero member
Activity: 976
Merit: 646
Snipped....

We have about 4-5 BTC of bounties for people who gonna find bugs/flaws in design or implementation: most serious critical flaw gonna get 2 BTC, next less critical 1 BTC, next 0.5 BTC and so on.

Brief description link(mini-whitepaper): http://162.243.101.90/lui_share.pdf
Implementation: https://github.com/cryptobender/lui
Notice: Implementation does not completely reflect mini-whitepaper description, it still in development, so i often do some commits and restart test network every 2-3 days. Atm we have network that running about of couple of days and seems to be okay.

Feel free to post any questions and ideas here or to PM.

Zoidberg

I read the white paper, there is mentioned about iteration of hash.

1. I think the hash shouldnt be iterated at 500k times, just let it plain 1 iteration, because when somebody figure out how to trick it with getpassediteration() function then he/she might get 50 times faster miner. Just learn from B*R how someone got 100x faster miner by passed the iteration. By letting it without iteration anyone will have same opportunity with maximum hash depending on hardware configuration.

2. If this project's target to make coin asic-proof then the scratchpad should be no less than 2MB but bigger scratchpad would be great to stay away from asic development. Because we know all hashfunction can be asic-fied.

CMIIW.



Quote
because when somebody figure out how to trick it with getpassediteration() function

Can you clarify it ?

Zoidberg
@bb
full member
Activity: 137
Merit: 100
Snipped....

We have about 4-5 BTC of bounties for people who gonna find bugs/flaws in design or implementation: most serious critical flaw gonna get 2 BTC, next less critical 1 BTC, next 0.5 BTC and so on.

Brief description link(mini-whitepaper): http://162.243.101.90/lui_share.pdf
Implementation: https://github.com/cryptobender/lui
Notice: Implementation does not completely reflect mini-whitepaper description, it still in development, so i often do some commits and restart test network every 2-3 days. Atm we have network that running about of couple of days and seems to be okay.

Feel free to post any questions and ideas here or to PM.

Zoidberg

I read the white paper, there is mentioned about iteration of hash.

1. I think the hash shouldnt be iterated at 500k times, just let it plain 1 iteration, because when somebody figure out how to trick it with getpassediteration() function then he/she might get 50 times faster miner. Just learn from B*R how someone got 100x faster miner by passed the iteration. By letting it without iteration anyone will have same opportunity with maximum hash depending on hardware configuration.

2. If this project's target to make coin asic-proof then the scratchpad should be no less than 2MB but bigger scratchpad would be great to stay away from asic development. Because we know all hashfunction can be asic-fied.

CMIIW.
hero member
Activity: 976
Merit: 646
when will you release this?

Would like to know also, any rough eta? This year?

Working hard, expect to start public betta in 1 month.

Zoidberg
hero member
Activity: 655
Merit: 500
when will you release this?

Would like to know also, any rough eta? This year?
full member
Activity: 209
Merit: 100
Have you considered to severely limit the size of data that can be added with any transaction to disable its misuses?
Hello!

What limit exactly would you suggest? Even if you're allowed to put only 10 additional bytes per transacton, you can make up for it by increasing the number of tour transactions.

And what kind of misuses do you have in mind?

Hi doe1138,

some ppl are concerned about this kind of abuses
http://cointelegraph.com/news/113806/warning-kaspersky-alerts-users-of-malware-and-blockchain-abuse
I suppose you should consider  minimizing possibility for them significantly, if it does not reduce usability of lui in a way that merchants could hardly work around. It may be worth considering even if it "only" minimizes a potentially strong FUD vector on privacy oriented coin.
hero member
Activity: 952
Merit: 501
when will you release this?
Pages:
Jump to: