tezaurop
Member
Offline
Activity: 79
Merit: 10
|
|
June 28, 2017, 09:36:00 AM |
|
New original and unique MONERO abstract paintings-click to zoom,please use PM for any details Original price 400 USD Price now 180 USD click to ZOOM this true?
|
|
|
|
KizaruOG
Member
Offline
Activity: 107
Merit: 10
|
|
June 28, 2017, 09:42:05 AM |
|
Update on current and future achievements regarding XMR adoption. https://www.reddit.com/r/Monero/comments/6juluf/any_new_updates_on_xmr_adoption/Summarized it seems that the devs are making Monero now quite easier to adopt. Also - the work on mobile wallets is very unique and great. If the cryptoworld actually has some logic(which I from time to time doubt) and any financial/economic culture Monero should be at top 3 coins. Good news! I'm very proud for the monero team! Good development and marketing.
|
|
|
|
birr
|
|
June 28, 2017, 01:27:31 PM |
|
I'm pleased to hear that subaddresses are on the roadmap. Sounds like it might be a little clumsy to use them, however: One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056) It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation. Have a table of pre-generated addresses, and make sure you don't run out of them. It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication.
|
|
|
|
Nathan047
|
|
June 28, 2017, 02:29:12 PM |
|
Update on current and future achievements regarding XMR adoption. https://www.reddit.com/r/Monero/comments/6juluf/any_new_updates_on_xmr_adoption/Summarized it seems that the devs are making Monero now quite easier to adopt. Also - the work on mobile wallets is very unique and great. If the cryptoworld actually has some logic(which I from time to time doubt) and any financial/economic culture Monero should be at top 3 coins. This is great, thanks for the share! Also, I'm glad to hear XMR is being added to Coinomi. I already use it so now I'll have the ability to store my XMR on my phone instead of my usual exchanges and mymonero.com.
|
I'm starting a technology blog T4CH.top, check it out!
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5385
Doomed to see the future and unable to prevent it
|
|
June 28, 2017, 02:58:21 PM Last edit: June 28, 2017, 10:12:07 PM by Hueristic |
|
I'm pleased to hear that subaddresses are on the roadmap. Sounds like it might be a little clumsy to use them, however: One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056) It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation. Have a table of pre-generated addresses, and make sure you don't run out of them. It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication. Thanks for pointing this out, for years I never knew this was an issue as I only use a few addresses and all of them are on sites except one. Because you don't want people to be able to associate you with that anonymous identity by Googling your address, you'd want to use separate wallet addresses for these two purposes. While you can easily do so by simply creating two wallets separately, you're going to spend twice the time for scanning the blockchain and need twice the storage for the wallet cache. And this cost grows in proportion to the number of additional wallet addresses you'd like to have.
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
dEBRUYNE
Legendary
Offline
Activity: 2268
Merit: 1141
|
|
June 28, 2017, 03:55:16 PM |
|
I'm pleased to hear that subaddresses are on the roadmap. Sounds like it might be a little clumsy to use them, however: One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056) It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation. Have a table of pre-generated addresses, and make sure you don't run out of them. It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication. If I recall correctly, the hashtable contains 10k subaddresses by default, which should be sufficient for the normal user. Although, I agree that in the future we might want to look at a more elegant solution.
|
|
|
|
aminorex
Legendary
Offline
Activity: 1596
Merit: 1030
Sine secretum non libertas
|
|
June 28, 2017, 05:30:59 PM |
|
Is there an official Chinese name for Monero? 私币 is logical but lacks poetry and seems too venial. 私宝币 is only slightly better. 自由币 Perhaps?
|
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.
|
|
|
bitebits
Legendary
Offline
Activity: 2251
Merit: 3592
Flippin' burgers since 1163.
|
|
June 28, 2017, 10:11:18 PM Last edit: June 29, 2017, 08:46:37 AM by bitebits |
|
As usual part of aminorex's posts read like Chinese to us mortals.
|
- You can figure out what will happen, not when /Warren Buffett - Pay any Bitcoin address privately with a little help of Monero.
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5385
Doomed to see the future and unable to prevent it
|
|
June 28, 2017, 10:18:34 PM |
|
As usual part of aminorex's post read like Chinese to us mortals.
Hah good one. Is there an official Chinese name for Monero? 私币 is logical but lacks poetry and seems too venial. 私宝币 is only slightly better. 自由币 Perhaps?
Well since Monero is just the English word money in Esperanto I guess you'll have to ask the language experts.
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
Millionero
|
|
June 28, 2017, 11:54:31 PM |
|
I'm pleased to hear that subaddresses are on the roadmap. Sounds like it might be a little clumsy to use them, however: One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056) It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation. Have a table of pre-generated addresses, and make sure you don't run out of them. It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication. Thanks for pointing this out, for years I never knew this was an issue as I only use a few addresses and all of them are on sites except one. Because you don't want people to be able to associate you with that anonymous identity by Googling your address, you'd want to use separate wallet addresses for these two purposes. While you can easily do so by simply creating two wallets separately, you're going to spend twice the time for scanning the blockchain and need twice the storage for the wallet cache. And this cost grows in proportion to the number of additional wallet addresses you'd like to have. At leastin the CLI wallet, you don't have to scan the blockchain to start a new wallet. You can choose the block to start the wallet scan at. So just choose the current block. You don't need to scan the blockchain for a new wallet, because such a wallet has nothing in it. Am I right?
|
|
|
|
nioc
Legendary
Offline
Activity: 1624
Merit: 1008
|
|
June 29, 2017, 12:43:06 AM |
|
^^^ maybe they are talking about after the wallet is created and having to sync after a certain period of time not having synced it. Even in this case it seems a non issue to me as the wallet synced very fast, we are not talking about the daemon.
As far as a separate wallet cache, is this really an issue? Who has just one wallet?
Edit: I think if is possible to choose a wallet sync height with the GUI. I created a GUI wallet for the first time not long ago as I needed another wallet where I could easily check tx hx and that is easy to do with the GUI.
|
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5385
Doomed to see the future and unable to prevent it
|
|
June 29, 2017, 12:59:12 AM |
|
I'm pleased to hear that subaddresses are on the roadmap. Sounds like it might be a little clumsy to use them, however: One slight caveat with this scheme is that when restoring a wallet from the seed, the wallet might miss transfers to subaddresses if they aren't stored in the hashtable yet. To mitigate this issue, for each account, the wallet generates 100 (a constant SUBADDRESS_LOOKAHEAD_MINOR defined in wallet2.h) subaddresses of indices beyond the "fresh" index. The wallet also generates 10 (a constant SUBADDRESS_LOOKAHEAD_MAJOR defined in wallet2.h) accounts beyond the current largest major index. This means that the wallet restoration process is guaranteed to find incoming transfers to subaddresses as long as the major and minor indices of the used subaddresses differ by less than those predefined numbers. Even if the differences are bigger than those, you can still make the wallet recognize the incoming transfers by just expanding the hashtable manually and rescanning the blockchain.
(from https://github.com/monero-project/monero/pull/2056) It sounds a little bit like the way Bitcoin handled change addresses many years ago, before the advent of HD address generation. Have a table of pre-generated addresses, and make sure you don't run out of them. It would be nice to have a more elegant solution for monero subadresses, one that eliminates inconvenience and complication. Thanks for pointing this out, for years I never knew this was an issue as I only use a few addresses and all of them are on sites except one. Because you don't want people to be able to associate you with that anonymous identity by Googling your address, you'd want to use separate wallet addresses for these two purposes. While you can easily do so by simply creating two wallets separately, you're going to spend twice the time for scanning the blockchain and need twice the storage for the wallet cache. And this cost grows in proportion to the number of additional wallet addresses you'd like to have. At leastin the CLI wallet, you don't have to scan the blockchain to start a new wallet. You can choose the block to start the wallet scan at. So just choose the current block. You don't need to scan the blockchain for a new wallet, because such a wallet has nothing in it. Am I right? ^^^ maybe they are talking about after the wallet is created and having to sync after a certain period of time not having synced it. Even in this case it seems a non issue to me as the wallet synced very fast, we are not talking about the daemon.
As far as a separate wallet cache, is this really an issue? Who has just one wallet?
Edit: I think if is possible to choose a wallet sync height with the GUI. I created a GUI wallet for the first time not long ago as I needed another wallet where I could easily check tx hx and that is easy to do with the GUI.
I have no clue maybe it is old info that wasn't updated? I'd like to know though.
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
|
USAS-12
Newbie
Offline
Activity: 51
Merit: 0
|
|
June 29, 2017, 01:31:14 PM |
|
Announce!Special price on XMR!!!
Trusted OTC exchange runs on a new level! Now we are accepting any cryptocurrency! If you need to make fast and well priced exchange we are here to help you!
Your privilege: Fee - 1% from the deal Minimum transaction amount - $500 The best counterparty range Fast and smooth exchange 2 ways of support during the deal Escrow service/agent upon request
In this regard, we're announcing the Special price on XMR!!!
Write me now to get more information!
|
|
|
|
CryptoScientist
Newbie
Offline
Activity: 53
Merit: 0
|
|
June 29, 2017, 06:19:40 PM |
|
Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?
|
|
|
|
Febo
Legendary
Offline
Activity: 2730
Merit: 1288
|
|
June 29, 2017, 08:22:21 PM |
|
Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?
They were every half year. Next should be in few months. I am sure block number is already set. In anonymity aspect it should set minimal mixing. Basically is not really needed, and that was a reason why i had problems to remember why this hard fork is needed, since like only 0.1% of transactions are non RingCT.
|
|
|
|
nioc
Legendary
Offline
Activity: 1624
Merit: 1008
|
|
June 29, 2017, 10:28:38 PM |
|
Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?
They were every half year. Next should be in few months. I am sure block number is already set. In anonymity aspect it should set minimal mixing. Basically is not really needed, and that was a reason why i had problems to remember why this hard fork is needed, since like only 0.1% of transactions are non RingCT. It is not mixing it is ring signatures. Ring signatures was also given an unfortunate name of mixin for the number of signatures for a transaction other than yours. mixin does not equal mixing. The other thing the Sept fork will do is make it mandatory for the minimum ring signature to be 5 (mixin 4) and currently that minimum is 3 (mixin 2) Please note that there is discussion about increasing the mandatory minimum ring signature size beyond 5 for this Sept. No decision has been made regarding it at this time.
|
|
|
|
smooth
Legendary
Offline
Activity: 2968
Merit: 1198
|
|
June 30, 2017, 12:49:34 AM |
|
Forgive or Excuse for a silly question. I read for a long time that the monero is conducting a series of forks to introduce complete anonymity and there they specified the date of summer-autumn 2017. so with each fork there could be problems but I glimpsed that it was successfully implemented without any problems. So, this series of forks is already over or is still going on? And is it at all, maybe I'm just confusing something)?
They were every half year. Next should be in few months. I am sure block number is already set. In anonymity aspect it should set minimal mixing. Basically is not really needed, and that was a reason why i had problems to remember why this hard fork is needed, since like only 0.1% of transactions are non RingCT. The more significant change in this fork will be increasing the minimum ring size. Although the default is 5, still a very high number of transactions use 3 (because people want to reduce cost and choose the minimum, even though this is currently a negligible savings). The fork will increase the minimum to at least 5 and possibly higher. The cost difference of even 10-20 is currently fairly small, and the improved resistance to blockchain analysis is significant. Mandatory RingCT is largely irrelevant as you point out since nearly all already use RingCT and that would continue to get closer and closer to 100% anyway.
|
|
|
|
binaryFate
Legendary
Offline
Activity: 1512
Merit: 1012
Still wild and free
|
|
July 01, 2017, 08:21:59 AM |
|
XMR.TO introduces zero-confirmation, instant conversions. We also added integrated addresses, and increased the maximum amount you can convert in one go to 20BTC. Enjoy!
|
Monero's privacy and therefore fungibility are MUCH stronger than Bitcoin's. This makes Monero a better candidate to deserve the term "digital cash".
|
|
|
Hueristic
Legendary
Offline
Activity: 3976
Merit: 5385
Doomed to see the future and unable to prevent it
|
|
July 02, 2017, 01:02:14 AM |
|
ExchangeD.I2P will be starting Monero trading on July 1 Traders will be able to exchange Monero for Bitcoin anonymously without any KYC or ID verification Also Traders can Trade Monero for USD, EUR and other Fiat currencies using our P2P Fiat exchange Nothing up yet, I'll have to check it out when I get back. Looking forward to seeing your XMR support. Guess I'll have to setup I2p.
|
“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
|
|
|
|