aminorex
Legendary
Offline
Activity: 1596
Merit: 1030
Sine secretum non libertas
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2015, 10:17:36 PM |
|
Big pump?
Just fiat-stability in a declining btc world. There is a speculation thread for this sort of thing, though.
|
Give a man a fish and he eats for a day. Give a man a Poisson distribution and he eats at random times independent of one another, at a constant known rate.
|
|
|
Bassica
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2015, 10:20:55 PM |
|
Wow!! How long has this been open?! Funded for more than 90% already!
|
|
|
|
dEBRUYNE
Legendary
Offline
Activity: 2268
Merit: 1141
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2015, 10:23:36 PM |
|
Wow!! How long has this been open?! Funded for more than 90% already! 8 hours approximately. Besides, I guess we should thank ArticMine for that, he donated ~12k. Big props!
|
|
|
|
nioc
Legendary
Offline
Activity: 1624
Merit: 1008
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2015, 11:18:55 PM |
|
Yes 97.09% funded ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) If you want to donate hurry up before you are unable to
|
|
|
|
iCEBREAKER
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 11, 2015, 11:45:08 PM |
|
Yes 97.09% funded ![Smiley](https://bitcointalk.org/Smileys/default/smiley.gif) If you want to donate hurry up before you are unable to The more funding XMR devs request, the faster their requests are fulfilled. I like this trend! ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) Go Mustangs!
|
██████████ ██████████████████ ██████████████████████ ██████████████████████████ ████████████████████████████ ██████████████████████████████ ████████████████████████████████ ████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ████████████████████████████████ ██████████████ ██████████████ ████████████████████████████ ██████████████████████████ ██████████████████████ ██████████████████ ██████████ 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
|
| | |
|
|
|
mmortal03
Legendary
Offline
Activity: 1762
Merit: 1011
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 02:55:38 AM |
|
I would say closer to ZeroCash. I've heard from the relevant experts that Monero is not computationally-efficient enough to stand on its own, but I have similar problems with ZeroCash standing on its own (it is almost "too private", for people to check and make sure it's working correctly). However, I think both (and/or, the concept of "coin privacy") will be among the first practical, usable, sidechain applications. I think that people will sidechain coins over, mix them on the sidechain, and then send them back. What are they implying by "not computationally-efficient enough to stand on its own"?
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 03:04:07 AM |
|
I would say closer to ZeroCash. I've heard from the relevant experts that Monero is not computationally-efficient enough to stand on its own, but I have similar problems with ZeroCash standing on its own (it is almost "too private", for people to check and make sure it's working correctly). However, I think both (and/or, the concept of "coin privacy") will be among the first practical, usable, sidechain applications. I think that people will sidechain coins over, mix them on the sidechain, and then send them back. What are they implying by "not computationally-efficient enough to stand on its own"? I'm honestly not sure. There are criticisms about the chain being larger than Bitcoin. That's one thing, maybe an issue in practice, maybe not, but not really the same question as "computationally efficient". There have also been criticisms of the PoW being too slow. This was a bigger concern before it got optimized and verifying a PoW took a second or something. But now at 20 ms, I don't really see this as disastrous. Even if it is, it could easily be replaced, and doesn't constitute a scaling issue (PoW cost doesn't go up as usage increases, in fact it decreases per-tx). I'm not really sure where a criticism of the protocol itself being too computationally inefficient would come from. The signature verification is based on DJB's elliptic curve methods that are designed to be very efficient. We can verify something like 1400 signatures/sec on CPUs that are a couple of generations out of date. And that isn't even fully optimized. So who knows. Sometimes memes based on a tiny bit of information, possibly taken out of context or misinterpreted, just get out there and take on a life of their own, making them very hard to ever fully kill off.
|
|
|
|
iCEBREAKER
Legendary
Offline
Activity: 2156
Merit: 1072
Crypto is the separation of Power and State.
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 05:53:02 AM |
|
I would say closer to ZeroCash. I've heard from the relevant experts that Monero is not computationally-efficient enough to stand on its own, but I have similar problems with ZeroCash standing on its own (it is almost "too private", for people to check and make sure it's working correctly). However, I think both (and/or, the concept of "coin privacy") will be among the first practical, usable, sidechain applications. I think that people will sidechain coins over, mix them on the sidechain, and then send them back. What are they implying by "not computationally-efficient enough to stand on its own"? No coin stands on its own, so long as shapeshift, localbitcoins, btc-e, poloniex, etc. exist. They are implying they missed the opportunity to buy Monero at ~0.001 BTC. ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif)
|
██████████ ██████████████████ ██████████████████████ ██████████████████████████ ████████████████████████████ ██████████████████████████████ ████████████████████████████████ ████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ██████████████████████████████████ ████████████████████████████████ ██████████████ ██████████████ ████████████████████████████ ██████████████████████████ ██████████████████████ ██████████████████ ██████████ 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
|
| | |
|
|
|
ArticMine
Legendary
Offline
Activity: 2282
Merit: 1050
Monero Core Team
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 05:59:23 AM |
|
|
|
|
|
TooDumbForBitcoin
Legendary
Offline
Activity: 1638
Merit: 1001
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 11:27:12 AM |
|
I would say closer to ZeroCash. I've heard from the relevant experts that Monero is not computationally-efficient enough to stand on its own, but I have similar problems with ZeroCash standing on its own (it is almost "too private", for people to check and make sure it's working correctly). However, I think both (and/or, the concept of "coin privacy") will be among the first practical, usable, sidechain applications. I think that people will sidechain coins over, mix them on the sidechain, and then send them back. What are they implying by "not computationally-efficient enough to stand on its own"? No coin stands on its own, so long as shapeshift, localbitcoins, btc-e, poloniex, etc. exist. They are implying they missed the most recent opportunity to buy Monero at ~0.001 BTC, and will have to wait a liitle while for the next one. ![Cheesy](https://bitcointalk.org/Smileys/default/cheesy.gif) FTFY
|
|
|
|
luigi1111
Legendary
Offline
Activity: 1105
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 03:16:02 PM Last edit: November 12, 2015, 03:36:37 PM by luigi1111 |
|
I would say closer to ZeroCash. I've heard from the relevant experts that Monero is not computationally-efficient enough to stand on its own, but I have similar problems with ZeroCash standing on its own (it is almost "too private", for people to check and make sure it's working correctly). However, I think both (and/or, the concept of "coin privacy") will be among the first practical, usable, sidechain applications. I think that people will sidechain coins over, mix them on the sidechain, and then send them back. What are they implying by "not computationally-efficient enough to stand on its own"? I'm honestly not sure. There are criticisms about the chain being larger than Bitcoin. That's one thing, maybe an issue in practice, maybe not, but not really the same question as "computationally efficient". There have also been criticisms of the PoW being too slow. This was a bigger concern before it got optimized and verifying a PoW took a second or something. But now at 20 ms, I don't really see this as disastrous. Even if it is, it could easily be replaced, and doesn't constitute a scaling issue (PoW cost doesn't go up as usage increases, in fact it decreases per-tx). I'm not really sure where a criticism of the protocol itself being too computationally inefficient would come from. The signature verification is based on DJB's elliptic curve methods that are designed to be very efficient. We can verify something like 1400 signatures/sec on CPUs that are a couple of generations out of date. And that isn't even fully optimized. So who knows. Sometimes memes based on a tiny bit of information, possibly taken out of context or misinterpreted, just get out there and take on a life of their own, making them very hard to ever fully kill off. I assume you meant transactions instead of signatures. For example this recent tx "06246f5c78aefac38b6c539ffc2ead5d48d452a38dbffe019cb63668aba657ed" has 15 inputs at mix 1, or 30 signatures. It took 3ms to verify on my machine (i7-4770). That would imply 10k sigs verified per second (not sure if this is multithreaded or not, and I'm not sure how much overhead there is on verifying beyond sig checking).
|
|
|
|
hudd
Newbie
Offline
Activity: 12
Merit: 0
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 05:53:36 PM |
|
New version indeed consumes less memory but refreshing the wallet is much much slower. It took an eternity to sync from scratch (as recommended) and then another eternity to refresh my old wallet. Not to mention that disk space required for LMDB blockchain is much larger than previous version. I wonder how do we attract new adopters with such terrible user experience. Pointing them to hosted wallet such as MyMonero isn't the solution. Syncing blockchain and refreshing the wallet somehow should be combined in one process to reduce the pain for new users.
On the side note, it seems wallet created in Windows could not be opened in Linux. I had to recover using 25 seed words.
|
|
|
|
GingerAle
Legendary
Offline
Activity: 1260
Merit: 1008
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 06:14:14 PM |
|
New version indeed consumes less memory but refreshing the wallet is much much slower. It took an eternity to sync from scratch (as recommended) and then another eternity to refresh my old wallet. Not to mention that disk space required for LMDB blockchain is much larger than previous version. I wonder how do we attract new adopters with such terrible user experience. Pointing them to hosted wallet such as MyMonero isn't the solution. Syncing blockchain and refreshing the wallet somehow should be combined in one process to reduce the pain for new users.
On the side note, it seems wallet created in Windows could not be opened in Linux. I had to recover using 25 seed words.
First bold - yeah, the refreshing of the wallet is a thorn in my side as well. I know fluffypony mentioned on IRC one time that some serious effort needs to be put into making that fast, so its on the radar. And there may or may not have been an option at some point to refresh from a certain height, so you don't have to scan the entire blockchain if you you just created your wallet yesterday. second bold - this is an artifact of "sparse file format" https://en.wikipedia.org/wiki/Sparse_file . And the argument has been made that a larger database on disk is better than a smaller database in ram. Third bold - its the fundamentals. This coin, its developers and the community have continuously pushed for the fundamentals over user experience. I don't expect this to change anytime soon, and I'm glad. Fourth bold - that could be interesting, though if a "refresh from block X" is ever integrated, this will be moot.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 06:19:04 PM |
|
I would say closer to ZeroCash. I've heard from the relevant experts that Monero is not computationally-efficient enough to stand on its own, but I have similar problems with ZeroCash standing on its own (it is almost "too private", for people to check and make sure it's working correctly). However, I think both (and/or, the concept of "coin privacy") will be among the first practical, usable, sidechain applications. I think that people will sidechain coins over, mix them on the sidechain, and then send them back. What are they implying by "not computationally-efficient enough to stand on its own"? I'm honestly not sure. There are criticisms about the chain being larger than Bitcoin. That's one thing, maybe an issue in practice, maybe not, but not really the same question as "computationally efficient". There have also been criticisms of the PoW being too slow. This was a bigger concern before it got optimized and verifying a PoW took a second or something. But now at 20 ms, I don't really see this as disastrous. Even if it is, it could easily be replaced, and doesn't constitute a scaling issue (PoW cost doesn't go up as usage increases, in fact it decreases per-tx). I'm not really sure where a criticism of the protocol itself being too computationally inefficient would come from. The signature verification is based on DJB's elliptic curve methods that are designed to be very efficient. We can verify something like 1400 signatures/sec on CPUs that are a couple of generations out of date. And that isn't even fully optimized. So who knows. Sometimes memes based on a tiny bit of information, possibly taken out of context or misinterpreted, just get out there and take on a life of their own, making them very hard to ever fully kill off. I assume you meant transactions instead of signatures. For example this recent tx "06246f5c78aefac38b6c539ffc2ead5d48d452a38dbffe019cb63668aba657ed" has 15 inputs at mix 1, or 30 signatures. It took 3ms to verify on my machine (i7-4770). That would imply 10k sigs verified per second (not sure if this is multithreaded or not, and I'm not sure how much overhead there is on verifying beyond sig checking). Actually I completely misremembered not only the number but the context of it. It was 2.5ms/tx average according to NoodleDoodle on a i7-2600. I originally thought it was single threaded which would yield 1600/sec not 1400, but now I'm not sure how that was measured since multithreaded verification was added at some point, though not sure if it is signatures or PoW. I guess signatures since most syncing PoW uses the precomputed hashes now anyway. We could look into the code more carefully here to see how it is being done, but all of these numbers agree that "computationally efficient" doesn't make sense to raise an issue. And of course both your numbers and NoodleDoodle's numbers are aging to old midrange desktop CPUs. You would run into huge problems with storage, bandwidth, centralization, etc. long before computational cost because a bottleneck. That's true for all blockchains so I just don't understand the original statement except as a misunderstanding.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 06:25:07 PM |
|
Fourth bold - that could be interesting, though if a "refresh from block X" is ever integrated, this will be moot.
If you create a new wallet, this is already done. The issue is that there is no creation date as part of seed words, so when you restore using seed words it has to scan the entire chain, starting from the genesis block. Probably at some point in the future when seed words are improved (especially with better error detection and correction) some sort of date indicator can be added. As for performance and efficiency (including storage space) overall, it is important to recognize that the database right now is close to the first implementation and the main goal was to get it to work (not quite the first since NoodleDoodle did optimize some of it). Further optimizations and improvements are good goals for the future.
|
|
|
|
luigi1111
Legendary
Offline
Activity: 1105
Merit: 1000
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 12, 2015, 06:51:00 PM Last edit: November 12, 2015, 07:48:07 PM by luigi1111 |
|
I would say closer to ZeroCash. I've heard from the relevant experts that Monero is not computationally-efficient enough to stand on its own, but I have similar problems with ZeroCash standing on its own (it is almost "too private", for people to check and make sure it's working correctly). However, I think both (and/or, the concept of "coin privacy") will be among the first practical, usable, sidechain applications. I think that people will sidechain coins over, mix them on the sidechain, and then send them back. What are they implying by "not computationally-efficient enough to stand on its own"? I'm honestly not sure. There are criticisms about the chain being larger than Bitcoin. That's one thing, maybe an issue in practice, maybe not, but not really the same question as "computationally efficient". There have also been criticisms of the PoW being too slow. This was a bigger concern before it got optimized and verifying a PoW took a second or something. But now at 20 ms, I don't really see this as disastrous. Even if it is, it could easily be replaced, and doesn't constitute a scaling issue (PoW cost doesn't go up as usage increases, in fact it decreases per-tx). I'm not really sure where a criticism of the protocol itself being too computationally inefficient would come from. The signature verification is based on DJB's elliptic curve methods that are designed to be very efficient. We can verify something like 1400 signatures/sec on CPUs that are a couple of generations out of date. And that isn't even fully optimized. So who knows. Sometimes memes based on a tiny bit of information, possibly taken out of context or misinterpreted, just get out there and take on a life of their own, making them very hard to ever fully kill off. I assume you meant transactions instead of signatures. For example this recent tx "06246f5c78aefac38b6c539ffc2ead5d48d452a38dbffe019cb63668aba657ed" has 15 inputs at mix 1, or 30 signatures. It took 3ms to verify on my machine (i7-4770). That would imply 10k sigs verified per second (not sure if this is multithreaded or not, and I'm not sure how much overhead there is on verifying beyond sig checking). Actually I completely misremembered not only the number but the context of it. It was 2.5ms/tx average according to NoodleDoodle on a i7-2600. I originally thought it was single threaded which would yield 1600/sec not 1400, but now I'm not sure how that was measured since multithreaded verification was added at some point, though not sure if it is signatures or PoW. I guess signatures since most syncing PoW uses the precomputed hashes now anyway. We could look into the code more carefully here to see how it is being done, but all of these numbers agree that "computationally efficient" doesn't make sense to raise an issue. And of course both your numbers and NoodleDoodle's numbers are aging to old midrange desktop CPUs. You would run into huge problems with storage, bandwidth, centralization, etc. long before computational cost because a bottleneck. That's true for all blockchains so I just don't understand the original statement except as a misunderstanding. Just going from memory, I'm fairly certain the POW verification is multithreaded now, and was changed before the fast-block-sync stuff. So I don't know if tx verification is multithreaded as well, but I tend to think yes. Edit: wallet "refresh" command I'm fairly certain is *not* multithreaded.
|
|
|
|
|
g4q34g4qg47ww
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 13, 2015, 06:31:20 AM |
|
Still here, bot has loved the upward motions, and done just as well on the downward motions. Going to sit on my pile of XMR and not touch, but set up bots in other markets, and perhaps tweak bot to set aside profits in form of xmr. They seem to handle bordom, dumps, and pumps just fine. Time to stick my "liquidity providers" in as many markets as i can manage, perhaps divert profits towards MRO. I think the FTSE and my bots are a match made in heaven. Slow buy preasure incoming. Dump low, give the devs a chance to snag up cheap before .9, they deserve it. Just dont get caught with your pants down late to party.
|
|
|
|
florida.haunted
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 13, 2015, 09:10:01 AM |
|
As menetioned above in the thread, New version indeed consumes less memory but refreshing the wallet is much much slower.
and I know fluffypony mentioned on IRC one time that some serious effort needs to be put into making that fast.
So as you can see, Fluffypony has encountered severe fundamental problems with developing v. 0.9, and because exactly this reason he can not release v. 0.9 officially. I am afraid he never can. ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Fluffypony, refute me please, I wanna be wrong.
|
|
|
|
GingerAle
Legendary
Offline
Activity: 1260
Merit: 1008
|
![](https://bitcointalk.org/Themes/custom1/images/post/xx.gif) |
November 13, 2015, 10:58:53 AM |
|
As menetioned above in the thread, New version indeed consumes less memory but refreshing the wallet is much much slower.
and I know fluffypony mentioned on IRC one time that some serious effort needs to be put into making that fast.
So as you can see, Fluffypony has encountered severe fundamental problems with developing v. 0.9, and because exactly this reason he can not release v. 0.9 officially. I am afraid he never can. ![Sad](https://bitcointalk.org/Smileys/default/sad.gif) Fluffypony, refute me please, I wanna be wrong. jeeeez. optimizing wallet refreshes is not critical to 0.9 release AFAIK. 0.9 is our hardfork man. We don't want this to be buggy. So cool your jets.
|
|
|
|
|