[XMR] Monero - A secure, private, untraceable cryptocurrency

[americanpegasus]

If there were an easy way to have the block time automatically adjust itself to usage, such an algorithm would probably set it very high right now and then decrease if and when usage increases.

 
  
This is an interesting idea I've pondered myself.  The blocktime is a 'guess' by the software which aims to achieve a certain blocktime by looking at the current hash rate of the network and assigning a difficulty to the next problem which should be solved in approximately the desired blocktime, right?  
  
So what would be wrong with looking at total transactions attempted instead and adjusting the difficulty to target something between 2 minutes and 10 minutes based on transaction volume?  I think we can agree that 2 minutes is about as fast as blocks should be targeted, given current network technology.  I think it's also pretty accepted that more than 10 minutes isn't necessary [and could be dangerous if the network experiences a sudden loss of mining power].  Let's say that currently the network only sees <1 transaction a second and as a result of this sets the block time to the maximum of 10 minutes.  Each successive 'target blocktime' is calculated based on the current attempted transactions this block.  If it sees a massive and sudden influx of transactions, it retargets a new blocktime very quickly - the very next cycle.  If it sees a slow increase in transaction volume it will gradually adjust it's difficulty multiplier so that instead of a 10 minute target we move down to 9, then 8.... all the way down to the arbitrary 2 minute minimum.  (with no minimum we would open up the network to possible attack by way of people attempting to force the blocksize too low with too many transactions, but setting a minimum seems possible).  
  
Thoughts on this?  Has this idea already been explored elsewhere?

[1714992025]

1714992025

[1714992025]

1714992025

[1714992025]

1714992025

[1714992025]

1714992025

[1714992025]

1714992025

[1714992025]

1714992025

[smooth]

If there were an easy way to have the block time automatically adjust itself to usage, such an algorithm would probably set it very high right now and then decrease if and when usage increases.

 
  
This is an interesting idea I've pondered myself.  The blocktime is a 'guess' by the software which aims to achieve a certain blocktime by looking at the current hash rate of the network and assigning a difficulty to the next problem which should be solved in approximately the desired blocktime, right?  
  
So what would be wrong with looking at total transactions attempted instead and adjusting the difficulty to target something between 2 minutes and 10 minutes based on transaction volume?  I think we can agree that 2 minutes is about as fast as blocks should be targeted, given current network technology.  I think it's also pretty accepted that more than 10 minutes isn't necessary [and could be dangerous if the network experiences a sudden loss of mining power].  Let's say that currently the network only sees <1 transaction a second and as a result of this sets the block time to the maximum of 10 minutes.  Each successive 'target blocktime' is calculated based on the current attempted transactions this block.  If it sees a massive and sudden influx of transactions, it retargets a new blocktime very quickly - the very next cycle.  If it sees a slow increase in transaction volume it will gradually adjust it's difficulty multiplier so that instead of a 10 minute target we move down to 9, then 8.... all the way down to the arbitrary 2 minute minimum.  (with no minimum we would open up the network to possible attack by way of people attempting to force the blocksize too low with too many transactions, but setting a minimum seems possible).  
  
Thoughts on this?  

Transaction volume is pretty easy to use as a denial of service attack, as reasonable fees are pretty low. Normally that doesn't do much other than take up space but if you can force the block time lower too it might encourage more spam.

[myagui]

There's this Tronsmart Ara x5 for $150 which is fanless, has an Intel Atom x5-Z8300 CPU (2MB cache and supports AES-NI!), 2GB of RAM, and 32GB eMMC.

Unfortunately the cache on Atom is 1 MB for each 2 cores, thus not usable for Cryptonight. Well, usable but the performance is poor.

The power usage on those is so low that the mining efficiency still isn't terrible, but it is mediocre.

It has USB ports so when the internal storage runs out you can plug in a drive and keep going.

How about this one:
https://www.parallella.org/board/

A crowd funded project to turn these into Monero nodes would be pretty sweet! The onchip FPGA cache seems tiny, but it also appears to have a reasonably high off-chip memory bandwidth. Any takers? Wolf'? 

[Globb0]

hmmmmmm interesting

[myagui]

Custom board would be better.

Agree! But this one is quite cheap, has a sizable support community, and is readily available.
Just saying, custom boards tend to introduce a whole bunch of other problems (accessibility, hardware issues, availability, price, etc...). Avoiding all those obstacles, then absolutely, a custom board would be awesome!

[dEBRUYNE]

Crosspost:

https://www.reddit.com/r/Monero/comments/3pw30d/ringct_for_monero_updated_versions/

New update on RingCT

[Eastwind]

Maybe we can set the block time to be 10 min now,then reduce it 1% every certain period (month), until it becomes 30s, which is suitable in the future.

[BoscoMurray]

Crosspost:

https://www.reddit.com/r/Monero/comments/3pw30d/ringct_for_monero_updated_versions/

New update on RingCT

Great stuff! Monero just gets better and better.


Re block time - if it is changed to 2 minutes, will the block reward be doubled to keep the emission curve the same?

[dEBRUYNE]

Crosspost:

https://www.reddit.com/r/Monero/comments/3pw30d/ringct_for_monero_updated_versions/

New update on RingCT

Great stuff! Monero just gets better and better.


Re block time - if it is changed to 2 minutes, will the block reward be doubled to keep the emission curve the same?

You're correct.

[luigi1111]

Crosspost:

https://www.reddit.com/r/Monero/comments/3pw30d/ringct_for_monero_updated_versions/

New update on RingCT

Great stuff! Monero just gets better and better.


Re block time - if it is changed to 2 minutes, will the block reward be doubled to keep the emission curve the same?

You're correct.

Yes of course, it's not some trick to change the social contract. 

[digicoin]

Monero 0.9beta Windows 7, RAM 6 GB, free disk: 3 GB/90GB, free CPU:70%, free memory: 1.5GB

> Prepare blocks took: 5342ms

What really happened at "Prepare blocks"? Any idea why it was so slow

[iCEBREAKER]

More exciting news from our pro coder moneromooo!

Now at 180 hours, with the following since last update:

    more work on the hard fork code (functional changes (mixin/dust recommendations), and speedups on the initial scan)
    a check_tx command (to complement the get_tx_key command)
    blockchain_export can now export the blockchain's block hashes in a format that can be used by NoodleDoodle's fast sync code
    improvements to existing tx/block query RPC to return JSON representations, and fixing print_block
    misc other tweaks and fixes

https://github.com/monero-project/bitmonero/commits/master

https://forum.getmonero.org/9/work-in-progress/334/fund-a-developer-moneromoo-will-work-part-time-on-monero-for-260-hours-over-approx-6-months?page=&noscroll=1#post-4229

[Jungian]

More exciting news from our pro coder moneromooo!

Now at 180 hours, with the following since last update:

    more work on the hard fork code (functional changes (mixin/dust recommendations), and speedups on the initial scan)
    a check_tx command (to complement the get_tx_key command)
    blockchain_export can now export the blockchain's block hashes in a format that can be used by NoodleDoodle's fast sync code
    improvements to existing tx/block query RPC to return JSON representations, and fixing print_block
    misc other tweaks and fixes

https://github.com/monero-project/bitmonero/commits/master

https://forum.getmonero.org/9/work-in-progress/334/fund-a-developer-moneromoo-will-work-part-time-on-monero-for-260-hours-over-approx-6-months?page=&noscroll=1#post-4229

Very nice! I hope he'll continue later on for another round of funding

[GingerAle]

How many forks can we post until the hardfork?




lets be productive!!

[phishead]

How many forks can we post until the hardfork?




lets be productive!!

Ughh... all I have is this spork...

[dEBRUYNE]

Monero 0.9beta Windows 7, RAM 6 GB, free disk: 3 GB/90GB, free CPU:70%, free memory: 1.5GB

> Prepare blocks took: 5342ms

What really happened at "Prepare blocks"? Any idea why it was so slow

If I recall correctly, it prepares a set of blocks (don't know precisely how much), that's why it takes that long. Also, 5s isn't that slow in my opinion :-P After syncing the blockchain RAM usage should also be somewhere around 100 MB or lower. The syncing speed also depends on the kind of hard drive, an SSD will sync way faster than a HDD.

[Hueristic]

https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

[smooth]

https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

Does not apply to Monero. We use ECDH not DH. Same principle, but different math.

Within the "recommendations" section of the paper:

Transition to elliptic curves. Transitioning to elliptic curve Diffie-Hellman (ECDH) key exchange with appropriate parameters avoids all known feasible cryptanalytic attacks.

[Hueristic]

https://weakdh.org/imperfect-forward-secrecy-ccs15.pdf

Does not apply to Monero. We use ECDH not DH. Same principle, but different math.

Within the "recommendations" section of the paper:

Transition to elliptic curves. Transitioning to elliptic curve Diffie-Hellman (ECDH) key exchange with appropriate parameters avoids all known feasible cryptanalytic attacks.

I tend to drop all crypto related papers in this thread. I think anyone interested in this coin is interested in privacy in general. But thanks for clarifying that.

Also after some research I've come across this.

For the most common strength of Diffie-Hellman (1024 bits), it would cost a few hundred million dollars to build a machine, based on special purpose hardware, that would be able to crack one Diffie-Hellman prime every year.

So really not to worrisome. Quantum is the real danger.

ADDED:

This is a great read, I had no Idea there are recruited student groups spying on each other on campuses. Sounds eerily familiar, wonder where I remember that happening before? Am I weird that that is the only thing that really bothered me in this narrative?

https://webcache.googleusercontent.com/search?q=cache:J2gV7Dc3zDkJ:www.tcf.org/blog/detail/scholarship-security-and-spillage-on-campus+&cd=1&hl=en&ct=clnk&gl=us

[kazuki49]

So really not to worrisome. Quantum is the real danger.

edit: Quantum is no danger.

Is the encryption used by VeraCrypt vulnerable to Quantum attacks?

VeraCrypt uses block ciphers (AES, Serpent, Twofish) for its encryption. Quantum attacks against these block ciphers are just a faster brute-force since the best know attack against these algorithms is exhaustive search (related keys attacks are irrelevant to our case because all keys are random and independent from each other).
Since VeraCrypt always uses 256-bit random and independent keys, we are assured of a 128-bit security
level against quantum algorithms which makes VeraCrypt encryption immune to such attacks.

I think the algorithms used in Monero are even stronger than in VeraCrypt.