Bitcoin Forum
January 18, 2026, 11:57:49 AM *
News: Latest Bitcoin Core release: 30.2 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 [1752] 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 ... 2131 »
  Print  
Author Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency  (Read 4675859 times)
birr
Hero Member
*****
Offline Offline

Activity: 871
Merit: 587


View Profile
June 28, 2017, 01:27:31 PM
 #35021

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
Sr. Member
****
Offline Offline

Activity: 504
Merit: 250



View Profile
June 28, 2017, 02:29:12 PM
 #35022

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 Offline

Activity: 4424
Merit: 6788


Doomed to see the future and unable to prevent it


View Profile
June 28, 2017, 02:58:21 PM
Last edit: June 28, 2017, 10:12:07 PM by Hueristic
 #35023

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.

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.



“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
dEBRUYNE
Legendary
*
Offline Offline

Activity: 2268
Merit: 1141


View Profile
June 28, 2017, 03:55:16 PM
 #35024

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. 

Privacy matters, use Monero - A true untraceable cryptocurrency
Why Monero matters? http://weuse.cash/2016/03/05/bitcoiners-hedge-your-position/
aminorex
Legendary
*
Offline Offline

Activity: 1596
Merit: 1030


Sine secretum non libertas


View Profile
June 28, 2017, 05:30:59 PM
 #35025

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 Offline

Activity: 2321
Merit: 3795


Flippin' burgers since 1163.


View Profile
June 28, 2017, 10:11:18 PM
Last edit: June 29, 2017, 08:46:37 AM by bitebits
 #35026

As usual part of aminorex's posts read like Chinese to us mortals.

You can figure out what will happen, not when /Warren Buffett
Hueristic
Legendary
*
Offline Offline

Activity: 4424
Merit: 6788


Doomed to see the future and unable to prevent it


View Profile
June 28, 2017, 10:18:34 PM
 #35027

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. Tongue



“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
Millionero
Sr. Member
****
Offline Offline

Activity: 808
Merit: 423


View Profile
June 28, 2017, 11:54:31 PM
 #35028

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.

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.

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 Offline

Activity: 1624
Merit: 1008


View Profile
June 29, 2017, 12:43:06 AM
 #35029

^^^ 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 Offline

Activity: 4424
Merit: 6788


Doomed to see the future and unable to prevent it


View Profile
June 29, 2017, 12:59:12 AM
 #35030

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.

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.

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.”
Kryptowerk
Legendary
*
Offline Offline

Activity: 2324
Merit: 1499


Disobey.


View Profile
June 29, 2017, 09:40:39 AM
 #35031

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.

HODOR.
USAS-12
Newbie
*
Offline Offline

Activity: 51
Merit: 0


View Profile
June 29, 2017, 01:31:14 PM
 #35032

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 Offline

Activity: 53
Merit: 0


View Profile
June 29, 2017, 06:19:40 PM
 #35033

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 Offline

Activity: 2758
Merit: 1288



View Profile
June 29, 2017, 08:22:21 PM
 #35034

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 Offline

Activity: 1624
Merit: 1008


View Profile
June 29, 2017, 10:28:38 PM
 #35035

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 Offline

Activity: 2982
Merit: 1203



View Profile
June 30, 2017, 12:49:34 AM
 #35036

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 Offline

Activity: 1512
Merit: 1012


Still wild and free


View Profile
July 01, 2017, 08:21:59 AM
 #35037

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 Offline

Activity: 4424
Merit: 6788


Doomed to see the future and unable to prevent it


View Profile
July 02, 2017, 01:02:14 AM
 #35038



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. Smiley

“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
bitebits
Legendary
*
Offline Offline

Activity: 2321
Merit: 3795


Flippin' burgers since 1163.


View Profile
July 02, 2017, 03:14:35 PM
 #35039

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!


Those are major improvements to an already very usable service. Thanks binaryFate for your hard work and great product.

You can figure out what will happen, not when /Warren Buffett
serhack
Member
**
Offline Offline

Activity: 107
Merit: 168

Security Researcher and Writer


View Profile WWW
July 02, 2017, 06:42:43 PM
 #35040

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!


Pages: « 1 ... 1702 1703 1704 1705 1706 1707 1708 1709 1710 1711 1712 1713 1714 1715 1716 1717 1718 1719 1720 1721 1722 1723 1724 1725 1726 1727 1728 1729 1730 1731 1732 1733 1734 1735 1736 1737 1738 1739 1740 1741 1742 1743 1744 1745 1746 1747 1748 1749 1750 1751 [1752] 1753 1754 1755 1756 1757 1758 1759 1760 1761 1762 1763 1764 1765 1766 1767 1768 1769 1770 1771 1772 1773 1774 1775 1776 1777 1778 1779 1780 1781 1782 1783 1784 1785 1786 1787 1788 1789 1790 1791 1792 1793 1794 1795 1796 1797 1798 1799 1800 1801 1802 ... 2131 »
  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!