Bitcoin Forum
December 13, 2024, 12:43:19 AM *
News: Latest Bitcoin Core release: 28.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 [56] 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 ... 319 »
  Print  
Author Topic: [ANN] AEON: Scalable, private, mobile-friendly cryptocurrency  (Read 625712 times)
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 07, 2015, 07:36:10 PM
Last edit: May 07, 2015, 08:08:49 PM by smooth
 #1101

What's the purpose of changing PoW?

To make it faster to verify and more efficient on mobile and mainstream (not high end) desktop CPUs. See roadmap

Quote from: smooth

1. Mobile-friendly PoW (CryptoNight Lite). The current PoW is not ideal for smaller devices because the 2MB scratchpad is too large for the cache size on most mobile and lower-end desktop/laptop CPUs. A tweak to use a 1 MB scratchpad would allow it to run efficiently on lower end CPUs including some mobile processors as well as much better performance on mainstream desktops/laptops. Credit for this idea goes to the Louisd'or project (crypto_zoidberg and doe1138), although they didn't clearly explain the benefits of it.


I've stressed the most important part of quoted text.

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. Proper implementation of checkpoints will solve the full chain verification problem better than scratchpad reduction.

From the other hand small scratchpad will remove one of ASIC / GPU protection layer. It will be easier to build dedicated mining hardware: for example one can assemble a mining rig with embedded CPUs. I don't think that this is a desirable.

Can you measure relative GPU advantage over CPU with reduced scratchpad?
Original CryptoNight implementation is very good from this point of view: GPU is about 2 times faster. This is quite fair.

I've looked at the range of CPU designs and roadmaps and I'm pretty sure that 1 MB/core is a better sweet spot than 2 MB/core, for at least the next several years, in addition to being 2x (or a bit more) faster. 2 MB isn't even optimal on most current higher end desktop and server CPUs, and is definitely a poor fit for anything below that

I will be evaluating the GPU performance but I don't expect a large change, in fact the ratio may improve.

No, checkpoints don't address verification because verification and sync speed both matter even (or perhaps especially) for current blocks. I will also be adding an SPV-like lightweight client model where signatures will not be verified but the block header must still be verified.

As far as mining rigs with embedded CPUs, maybe (and is indeed already possible with the original cryptonight, as the are some embedded CPUs with 2mb/core, but they are rare), but I don't really see it as competitive with people mining on the enormous installed base of embedded CPUs that already exist with zero capital cost. Note this is different from GPUs since high end GPUs are not a mainstream product.

dlightman
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 07, 2015, 07:40:12 PM
 #1102

What's the purpose of changing PoW?

To make it faster to verify and more efficient on mobile and mainstream (not high end) desktop CPUs. See roadmap

Quote from: smooth

1. Mobile-friendly PoW (CryptoNight Lite). The current PoW is not ideal for smaller devices because the 2MB scratchpad is too large for the cache size on most mobile and lower-end desktop/laptop CPUs. A tweak to use a 1 MB scratchpad would allow it to run efficiently on lower end CPUs including some mobile processors as well as much better performance on mainstream desktops/laptops. Credit for this idea goes to the Louisd'or project (crypto_zoidberg and doe1138), although they didn't clearly explain the benefits of it.


I've stressed the most important part of quoted text.

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. Proper implementation of checkpoints will solve the full chain verification problem better than scratchpad reduction.

From the other hand small scratchpad will remove one of ASIC / GPU protection layer. It will be easier to build dedicated mining hardware: for example one can assemble a mining rig with embedded CPUs. I don't think that this is a desirable.

Can you measure relative GPU advantage over CPU with reduced scratchpad?
Original CryptoNight implementation is very good from this point of view: GPU is about 2 times faster. This is quite fair.

I've looked at the range of CPU designs and roadmaps and I'm pretty sure that 1 MB/core is a better sweet spot that 2 MB/core, for at least the next several years, in addition to being 2x (or a bit more) faster. 2 MB isn't even optimal on most current higher end desktop and server CPUs, and is definitely a poor fit for anything below that

I will be evaluating the GPU performance but I don't expect a large change, in fact the ratio may improve.

No, checkpoints don't address verification because verification and sync speed matters even for current blocks.


For current blocks relative time of PoW calculation is less than total signature verification time. The only scenario where you get significant advantage from fast PoW in block verification speed is a low-loaded chain.
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 07, 2015, 07:44:17 PM
 #1103

What's the purpose of changing PoW?

To make it faster to verify and more efficient on mobile and mainstream (not high end) desktop CPUs. See roadmap

Quote from: smooth

1. Mobile-friendly PoW (CryptoNight Lite). The current PoW is not ideal for smaller devices because the 2MB scratchpad is too large for the cache size on most mobile and lower-end desktop/laptop CPUs. A tweak to use a 1 MB scratchpad would allow it to run efficiently on lower end CPUs including some mobile processors as well as much better performance on mainstream desktops/laptops. Credit for this idea goes to the Louisd'or project (crypto_zoidberg and doe1138), although they didn't clearly explain the benefits of it.


I've stressed the most important part of quoted text.

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. Proper implementation of checkpoints will solve the full chain verification problem better than scratchpad reduction.

From the other hand small scratchpad will remove one of ASIC / GPU protection layer. It will be easier to build dedicated mining hardware: for example one can assemble a mining rig with embedded CPUs. I don't think that this is a desirable.

Can you measure relative GPU advantage over CPU with reduced scratchpad?
Original CryptoNight implementation is very good from this point of view: GPU is about 2 times faster. This is quite fair.

I've looked at the range of CPU designs and roadmaps and I'm pretty sure that 1 MB/core is a better sweet spot that 2 MB/core, for at least the next several years, in addition to being 2x (or a bit more) faster. 2 MB isn't even optimal on most current higher end desktop and server CPUs, and is definitely a poor fit for anything below that

I will be evaluating the GPU performance but I don't expect a large change, in fact the ratio may improve.

No, checkpoints don't address verification because verification and sync speed matters even for current blocks.


For current blocks relative time of PoW calculation is less than total signature verification time. The only scenario where you get significant advantage from fast PoW in block verification speed is a low-loaded chain.

I edited above to mention that I will be adding a lightweight client model that does not verify signatures.

Also, in current CN coins, even putting aside the low-loaded chain issue, signature verification is quite fast compared to PoW and is not fully optimized. Even with a moderately loaded chain, CryptoNight PoW will be significant for full nodes. Finally, signature verification is not critical path; PoW verification is.

dlightman
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 07, 2015, 07:57:38 PM
 #1104

What's the purpose of changing PoW?

To make it faster to verify and more efficient on mobile and mainstream (not high end) desktop CPUs. See roadmap

Quote from: smooth

1. Mobile-friendly PoW (CryptoNight Lite). The current PoW is not ideal for smaller devices because the 2MB scratchpad is too large for the cache size on most mobile and lower-end desktop/laptop CPUs. A tweak to use a 1 MB scratchpad would allow it to run efficiently on lower end CPUs including some mobile processors as well as much better performance on mainstream desktops/laptops. Credit for this idea goes to the Louisd'or project (crypto_zoidberg and doe1138), although they didn't clearly explain the benefits of it.


I've stressed the most important part of quoted text.

I don't think that reduced scratchpad will give significant benefits to anybody because 2Mb and much bigger L3 cache becomes more and more widely used. Mobile CPU will follow soon. Proper implementation of checkpoints will solve the full chain verification problem better than scratchpad reduction.

From the other hand small scratchpad will remove one of ASIC / GPU protection layer. It will be easier to build dedicated mining hardware: for example one can assemble a mining rig with embedded CPUs. I don't think that this is a desirable.

Can you measure relative GPU advantage over CPU with reduced scratchpad?
Original CryptoNight implementation is very good from this point of view: GPU is about 2 times faster. This is quite fair.

I've looked at the range of CPU designs and roadmaps and I'm pretty sure that 1 MB/core is a better sweet spot that 2 MB/core, for at least the next several years, in addition to being 2x (or a bit more) faster. 2 MB isn't even optimal on most current higher end desktop and server CPUs, and is definitely a poor fit for anything below that

I will be evaluating the GPU performance but I don't expect a large change, in fact the ratio may improve.

No, checkpoints don't address verification because verification and sync speed matters even for current blocks.


For current blocks relative time of PoW calculation is less than total signature verification time. The only scenario where you get significant advantage from fast PoW in block verification speed is a low-loaded chain.

I edited above to mention that I will be adding a lightweight client model that does not verify signatures.


In case a node doesn't verifies signatures we don't have to consider it as a full node i.e. we can't rely on such node's decisions because they will accept correct PoW with wrong signature. We have to consider such nodes as light wallets. Network with majority of nodes not verifying signatures can be easily manipulated by big pools.

Let's calculate scratchpad reduction benefit for a low-end device in case of current block verification:

- 120 seconds block target time
- 10 h/s hash calculation speed

In this case one block verification takes 0.083333% of one CPU core time. Is this a showstopper for mobile device?
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 07, 2015, 08:07:19 PM
 #1105

In case a node doesn't verifies signatures we don't have to consider it as a full node i.e. we can't rely on such node's decisions because they will accept correct PoW with wrong signature. We have to consider such nodes as light wallets.

Exactly, yes, that's why I called them a "lightweight client model" Smiley

Quote
Network with majority of nodes not verifying signatures can be easily manipulated by big pools.

Full nodes will still verify signatures (but as I mentioned earlier this is not critical path).

Quote
Let's calculate scratchpad reduction benefit for a low-end device in case of current block verification:

- 120 seconds block target time
- 10 h/s hash calculation speed

In this case one block verification takes 0.083333% of one CPU core time. Is this a showstopper for mobile device?

It could be. If you are two days behind when you open your wallet, that is 144 seconds to sync. Quite a long wait.

Also, I'm not sure that 10 h/s is achievable on a mobile device with scratchpad in RAM. Maybe, but that is aggressive. It is more realistic if scratchpad is in cache.
dlightman
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 07, 2015, 08:16:37 PM
 #1106

In case a node doesn't verifies signatures we don't have to consider it as a full node i.e. we can't rely on such node's decisions because they will accept correct PoW with wrong signature. We have to consider such nodes as light wallets.

Exactly yes, that's why I called them a "lightweight client model" Smiley

Quote
Network with majority of nodes not verifying signatures can be easily manipulated by big pools.

Full nodes will still verify signatures.

Quote
Let's calculate scratchpad reduction benefit for a low-end device in case of current block verification:

- 120 seconds block target time
- 10 h/s hash calculation speed

In this case one block verification takes 0.083333% of one CPU core time. Is this a showstopper for mobile device?

It could be. If you are two days behind when you open your wallet, that is 144 seconds to sync. Quite a long wait.

Also, I'm not sure that 10 h/s is achievable on a mobile device with scratchpad in RAM. Maybe, but that is aggressive. It is more realistic if scratchpad is in cache.

Scratchpad in RAM is about 8-10 times slower than scratchpad in cache. Speed on embedded CPU depends also on x64 mul/div and aes-ni. Emulation of both will be really slow. Do you plan to remove these instructions also? Wink

In case of low-end device and light-client being two days behind it's probably more user friendly to start from transactions (check if there is some incoming coins). In case there are some incoming transactions you can display amounts as not verified yet and check PoW in the background. This way user will wait several second for downloading and transactions verification.
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 07, 2015, 08:19:08 PM
 #1107

Those are good suggestions dlightman!

What is your level of interest? You are obviously quite knowledgable so I hope you stick around and contribute to this coin!

I'm going to stick with the CryptoNight Lite experiment for now and see how it goes. I expect this coin to be in an active development phase for some time with a number of necessary hard forks so if things don't work out we can always change it.

dlightman
Newbie
*
Offline Offline

Activity: 28
Merit: 0


View Profile
May 07, 2015, 08:44:41 PM
 #1108

Those are good suggestions dlightman!

What is your level of interest? You are obviously quite knowledgable so I hope you stick around and contribute to this coin!

I'm going to stick with the CryptoNight Lite experiment for now and see how it goes. I expect this coin to be in an active development phase for some time with a number of necessary hard forks so if things don't work out we can always change it.


I'm an angel of common sense Tongue
99% of forum members are very far from understanding many important details. They can't "verify signatures" but have to trust instead (light-client model in social communication). This is dangerous in case we talk about privacy. I can't promise to read the thread but you can ping me with PM.

It will be very interesting to see details about relative CPU / GPU performance of light version and native C++/asm hash rate on actual embedded CPU.

Hardfork is possible only in case people agree with. It's easy to change PoW with low hashrate network. Later there will be a lot of miners against because they already invested into HW. Bitcoin is the best example.
papa_lazzarou
Hero Member
*****
Offline Offline

Activity: 649
Merit: 500



View Profile
May 07, 2015, 09:25:50 PM
 #1109

Release Phoenix standalone test (PLEASE TEST!)

I have created a standalone test setup for the upcoming release Phoenix. Please test and report any issues.

It went as described hashrate from 5.5 to 22 and diff from 7 to 60 (Linux Mint Qiana / Pentium(R) Dual-Core CPU       T4300  @ 2.10GHz)
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 08, 2015, 05:59:03 AM
Last edit: May 08, 2015, 10:25:43 AM by smooth
 #1110

If your IP is 198.175.x.x please PM me. It looks like something is wrong with your node, and I'd like to get to the bottom of it. Thanks.

EDIT: resolved

h0g0f0g0
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


View Profile
May 08, 2015, 06:08:30 AM
 #1111

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 08, 2015, 06:09:56 AM
 #1112

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA

Thanks!

Reminder, this is a bench test and does not connect to the live network. See test instructions here: https://bitcointalk.org/index.php?topic=641696.msg11299446#msg11299446
nikos64
Sr. Member
****
Offline Offline

Activity: 283
Merit: 250


View Profile
May 08, 2015, 06:59:21 AM
 #1113

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA
Well, the Windows build synchronized with the main chain in the AppData\Roaming\aeon directory.
Didn't supposed to do that, right?
muchoman
Sr. Member
****
Offline Offline

Activity: 465
Merit: 250


View Profile
May 08, 2015, 07:05:35 AM
 #1114

Windows build does not work for me and there is no aeone dir.
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 08, 2015, 07:12:07 AM
 #1115

Release Phoenix testing binaries:

Windows - https://mega.co.nz/#!sdsiiCxS!mm9ZutrXKVHEjHzBdAjB87LNOQVRdmKofV1pkudA2CY

Linux - https://mega.co.nz/#!wdcWRShR!SUPemRxbxxPrvLzTBwX4XVGa-YUw9m5ISclVFRF7ICA
Well, the Windows build synchronized with the main chain in the AppData\Roaming\aeon directory.
Didn't supposed to do that, right?

That is strange.

I don't know what those builds are. I would hold off on trying them until h0g0f0g0 explains what he built. Sounds like maybe he didn't switch to the branch before compiling.
smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 08, 2015, 07:37:13 AM
Last edit: May 08, 2015, 09:30:20 AM by smooth
 #1116

If your IP is 198.175.x.x please PM me. It looks like something is wrong with your node, and I'd like to get to the bottom of it. Thanks.

I got in touch with the node owner and we diagnosed a firewall problem. Fortunately, no impact on the network although he did lose some mined blocks (orphaned).

Here's an update on the donation balance. Nothing has been spent from the wallet:

balance: 113845.066127230582, unlocked balance: 113845.066127230582

smooth
Legendary
*
Offline Offline

Activity: 2968
Merit: 1198



View Profile
May 08, 2015, 10:18:20 AM
 #1117

Seed node is now up, and github master has been updated accordingly.

If you are already connected to the network this does not affect you, only new users.
h0g0f0g0
Sr. Member
****
Offline Offline

Activity: 295
Merit: 250


View Profile
May 08, 2015, 03:42:17 PM
Last edit: May 08, 2015, 04:04:37 PM by h0g0f0g0
 #1118

Updated binaries (with seed node included):

Windows:

https://mega.co.nz/#!IIcWyYgA!9oFezJX1YKSpI_wUgjTEEYB9Fch5ViDH-wsZ_R6WpXo

Linux:

https://mega.co.nz/#!gM1XQLqb!R5oCb_nlEtAvqlw5esiQelfNmuQj-IWo3gWHg2BVC4w

These builds are made by following steps described in op to save time for others. If it's not working please post an error message or screenshot but for me it worked fine on both OSes.
Phantas
Sr. Member
****
Offline Offline

Activity: 311
Merit: 250


View Profile
May 08, 2015, 05:57:12 PM
 #1119

Updated binaries (with seed node included):

Windows:

https://mega.co.nz/#!IIcWyYgA!9oFezJX1YKSpI_wUgjTEEYB9Fch5ViDH-wsZ_R6WpXo

Linux:

https://mega.co.nz/#!gM1XQLqb!R5oCb_nlEtAvqlw5esiQelfNmuQj-IWo3gWHg2BVC4w

These builds are made by following steps described in op to save time for others. If it's not working please post an error message or screenshot but for me it worked fine on both OSes.

Thank you for your support Wink

Merge Mine 5 other Blake 256 coins - 6x your hash power  https://www.blakecoin.org/
Arux
Hero Member
*****
Offline Offline

Activity: 500
Merit: 500



View Profile
May 08, 2015, 10:06:16 PM
 #1120

Release Phoenix standalone test (PLEASE TEST!)
Done, windows 7 64 bits on intel Penryn/Harpertown (no aes instructions) / 4gb of ram

...blocks being mined with a block target of 1 second, with the difficulty converging to your hash rate
happened

Once you get to block 1000 ... see the difficulty increase by a factor of 8, your hash rate double
#1000: diff 18 --> ~140-150   hashrate: 18-->41

test perfomed with my own building according to the OP instructions (thanks to Cryptrol  Wink)

Pages: « 1 ... 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 [56] 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 ... 319 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!