Louisd’or(codename)- first anonymous PoS, CN-based currency (technical review)

[sonoIO]

Hi crypto_zoidbrg and doe1138,

Have you considered to severely limit the size of data that can be added with any transaction to disable its misuses? Further, can lui have some funky hack to allow paying using insecure wallet software when having also a piece of ubiquitous hardware?   That would be kinda convenient  

[doe1138]

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?

[BTCspace]

when will you release this?

[sonoIO]

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.

[MadCow]

when will you release this?

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

[crypto_zoidberg]

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

[@bb]

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.

[crypto_zoidberg]

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.

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

Can you clarify it ?

Zoidberg

[@bb]

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.

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.

[crypto_zoidberg]

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.

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]

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.

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?

[crypto_zoidberg]

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.

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]

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?

[bitl0ck]

We all want cryptonight 

[crypto_zoidberg]

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

[crypto_zoidberg]

We all want cryptonight  

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

[rangedriver]

We all want cryptonight  

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?

[bytemuma]

We all want cryptonight 

I had the same hope. 

[klee]

Looking fwd for this project, so excited!

[@bb]

We all want cryptonight 

I had the same hope. 

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.