For those who haven't noticed yet, rehrar has revamped the official website:
https://getmonero.org/
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 375. (Read 4671575 times)
Hello guys,
here Serhack, the man of web integrations.
I have discovered this forum 3 days ago and then I wrote this post for you about my updates.
Some days ago community funded me on https://forum.getmonero.org/9/work-in-progress/87734/monero-integrations-with-web-apps (thanks again).
With or without xmr, I would develop web integrations for every e-commerce system like prestashop, woocommerce, whmcs (ugh.. it's difficult)..
Progress in 1 month:
- Monero PHP Library https://github.com/monero-integrations/monerophp
With Monero PHP library, client (any ecommerce system) can communicate with wallet rpc. Client can know the address, height of blocks, payments : useful things for a merchants!
Some Reddit posts:
https://www.reddit.com/r/Monero/comments/6g9ps5/web_integrations_update/
https://www.reddit.com/r/Monero/comments/6hytn5/web_integrations_update_2/
https://www.reddit.com/r/Monero/comments/6j796u/web_integrations_update_first_milestone_completed/
- Monero WooCommerce Payment Gateway
Buy something, scan qr code and pay with monero by clicking on your wallet gui!
Reddit posts:
https://www.reddit.com/r/Monero/comments/6k8ife/web_integrations_update_4_woocommerce_plugin/
Video:
https://streamable.com/505kd
If you have questions, suggestions, please pm me on reddit, here or slack
Thanks!
here Serhack, the man of web integrations.
I have discovered this forum 3 days ago and then I wrote this post for you about my updates.
Some days ago community funded me on https://forum.getmonero.org/9/work-in-progress/87734/monero-integrations-with-web-apps (thanks again).
With or without xmr, I would develop web integrations for every e-commerce system like prestashop, woocommerce, whmcs (ugh.. it's difficult)..
Progress in 1 month:
- Monero PHP Library https://github.com/monero-integrations/monerophp
With Monero PHP library, client (any ecommerce system) can communicate with wallet rpc. Client can know the address, height of blocks, payments : useful things for a merchants!
Some Reddit posts:
https://www.reddit.com/r/Monero/comments/6g9ps5/web_integrations_update/
https://www.reddit.com/r/Monero/comments/6hytn5/web_integrations_update_2/
https://www.reddit.com/r/Monero/comments/6j796u/web_integrations_update_first_milestone_completed/
- Monero WooCommerce Payment Gateway
Buy something, scan qr code and pay with monero by clicking on your wallet gui!
Reddit posts:
https://www.reddit.com/r/Monero/comments/6k8ife/web_integrations_update_4_woocommerce_plugin/
Video:
https://streamable.com/505kd
If you have questions, suggestions, please pm me on reddit, here or slack
Thanks!
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!
We also added integrated addresses, and increased the maximum amount you can convert in one go to 20BTC.
Enjoy!
Those are major improvements to an already very usable service. Thanks binaryFate for your hard work and great product.
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.
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!
We also added integrated addresses, and increased the maximum amount you can convert in one go to 20BTC.
Enjoy!
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.
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.
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.
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)?
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!
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!
Strong signals for Monero - You guys may like this (or not): https://www.youtube.com/watch?v=k5GILFQKJR4&t=45m49s
Personally I would be happy to see some more realistic prices, especially in comparison to Dash.
Personally I would be happy to see some more realistic prices, especially in comparison to Dash.
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.
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.
Quote
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.
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.
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.
^^^ 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.
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'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.
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.
Quote
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.
Am I right?
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?
私币 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.
As usual part of aminorex's posts read like Chinese to us mortals.
Is there an official Chinese name for Monero?
私币 is logical but lacks poetry and seems too venial.
私宝币 is only slightly better.
自由币 Perhaps?
私币 is logical but lacks poetry and seems too venial.
私宝币 is only slightly better.
自由币 Perhaps?
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.
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.
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.
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.
Quote
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.
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. 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.
Jump to: