americanpegasus
|
|
October 22, 2015, 08:15:48 PM |
|
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?
|
Account is back under control of the real AmericanPegasus.
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
October 22, 2015, 08:19:36 PM |
|
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
Legendary
Offline
Activity: 1154
Merit: 1001
|
|
October 22, 2015, 09:10:42 PM |
|
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
Legendary
Offline
Activity: 2688
Merit: 2053
Free spirit
|
|
October 23, 2015, 07:00:10 AM |
|
hmmmmmm interesting
|
|
|
|
myagui
Legendary
Offline
Activity: 1154
Merit: 1001
|
|
October 23, 2015, 09:41:52 AM |
|
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
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
October 23, 2015, 12:05:16 PM |
|
|
|
|
|
Eastwind
|
|
October 23, 2015, 06:25:48 PM |
|
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
|
|
October 23, 2015, 06:45:32 PM |
|
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
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
October 23, 2015, 06:48:12 PM |
|
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
Legendary
Offline
Activity: 1105
Merit: 1000
|
|
October 23, 2015, 10:22:18 PM |
|
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
Legendary
Offline
Activity: 1106
Merit: 1000
|
|
October 24, 2015, 03:16:26 AM |
|
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
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
|
October 24, 2015, 10:58:17 AM |
|
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
|
██████████ ██████████████████ ██████████████████████ ██████████████████████████ ████████████████████████████ ██████████████████████████████ ████████████████████████████████ ████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ████████████████████████████████ ██████████████ ██████████████ ████████████████████████████ ██████████████████████████ ██████████████████████ ██████████████████ ██████████ Monero
|
| "The difference between bad and well-developed digital cash will determine whether we have a dictatorship or a real democracy." David Chaum 1996 "Fungibility provides privacy as a side effect." Adam Back 2014
|
| | |
|
|
|
Jungian
Legendary
Offline
Activity: 930
Merit: 1010
|
|
October 24, 2015, 11:34:03 AM |
|
Very nice! I hope he'll continue later on for another round of funding
|
|
|
|
GingerAle
Legendary
Offline
Activity: 1260
Merit: 1008
|
|
October 24, 2015, 03:55:25 PM |
|
How many forks can we post until the hardfork? lets be productive!!
|
|
|
|
phishead
|
|
October 24, 2015, 04:00:22 PM |
|
How many forks can we post until the hardfork? lets be productive!! Ughh... all I have is this spork...
|
|
|
|
dEBRUYNE
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
October 24, 2015, 04:04:50 PM |
|
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
Legendary
Offline
Activity: 3948
Merit: 5364
Doomed to see the future and unable to prevent it
|
|
October 24, 2015, 06:27:33 PM |
|
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
October 24, 2015, 06:39:54 PM |
|
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
Legendary
Offline
Activity: 3948
Merit: 5364
Doomed to see the future and unable to prevent it
|
|
October 24, 2015, 06:58:06 PM Last edit: October 24, 2015, 07:45:48 PM by Hueristic |
|
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
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
kazuki49
|
|
October 24, 2015, 10:03:46 PM Last edit: November 02, 2015, 09:59:18 PM by 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.
|
|
|
|
|