STAHP feeding this guy.
Yes. You Monerians with your righteous indignation. How many times has smooth caused FUD and panic in other threads here? Serves you boys right. What goes around comes around. You should probably stop feeding me now, I smell blood. I keep pulling at this thread and the whole tapestry comes unwoven, savvy? You wont hear from me again as long as you guys stop playing crypto-guardians. You cant even best me. And this BCN thing is totally 50/50. And yes, having your devs ID's known is risky moving forward. Anon currency requires Anon devs. WAKE UP FFS and get with the program… it's Big Brother shit out there!!! p.s. IF u quote me at least have the respect the quote me fully… Laterz * Wanderlust wanders off ROFL. Bye now. |
|
|
|
Will it be possible to produce view keys to reveal properties of just one particular transaction, or will view key's reveal all transactions relating to one Monero address?
I can envisage scenarios where there is a need to prove a payment took place, so maybe view keys for for single transactions would be useful.
Yes. It would vary depending on if you're the sender or receiver. For the receiver, you could release the key derivation (ECDH); this would allow the "unmasking' of the stealth addresses given your (the reciever's) public spend key. It doesn't 'technically' confirm that the ECDH was derived from your viewkey, but in practice it's *unlikely* that you're revealing someone else's transaction that happens to be using the exact same spend keypair as you. For the spender, you can sign a message (probably hash of the tx pub key) with the tx priv key. You can also provide the ECDH (and receiver's public spend key) if you need to prove where it went. Edit2: in practice, I don't think the software stores r (tx private key), so you wouldn't be able to prove anything after the fact (unless you specifically kept r on hand) as the sender regarding where the funds went (beyond as your own change). Edit: Will it be possible to produce view keys to reveal properties of just one particular transaction, or will view key's reveal all transactions relating to one Monero address?
The view key that's part of the address reveals all payments to that address. Every transaction sent uses a transaction specific key, however, and that key can theoretically be shared with a third party, who can then use it to decrypt the transaction. I'm not sure whether that third party could know which outputs are change, though (and thus the exact amount). The addresses the outputs get sent to would be one time addresses, and thus not directly linkable to a standard address. Given the transaction specific key, you also need the receiver's public view key to compute ECDH. It's not so much a "decrypt" as "trial 'encrypt' and compare", but it definitely allows linking to standard addresses given the right information. |
|
|
|
I`m interested in lending money on Polo. Is there a chance that the borrower of the funds does not pay me my money and runs away?
I guess you can obtain your answer from here -> https://poloniex.com/support/aboutMarginTradingDon't have time to read it thorougly now. Thank you for your reference, but those infos do not include the answer to my question. It should be pretty apparent from that page. The answer is not really. The borrower has no choice in the matter of paying/not paying. What *could* happen is a market experiences atypical volatility and the borrower's account is unable to be settled with a positive balance. How real a risk this is depends on the market and Polo's algorithms, not the borrower. |
|
|
|
You're breaking the rules of the thought experiment. the IF they dont sell must be observed. if it is i believe the statement true. whilst one cannot be sure the devs are not de-anoning their own tech it is arguably better not to give a bad player a chance at doing so.
"So you can choose your poison. Either certain traceability by the original fraudulent developers, or easier traceability by a subsequent attacker"
assuming the devs dont work for 3-letter orgs it's a close call. they have less motive to de-anonymize than most. the latter provides no greater reassurances than the former.
No. No. No. A thousand times no. Your "thought experiment" is meaningless. Particularly this bit: ...it's a close call No, it's not a close call. Smooth already demolished it: Furthermore I'd add that it won't work, because given such a premine and intelligent users (or wallet developers) they will simply avoid mixing with the premine outputs. This in turn makes the task of an attacker easier, because now that attacker need only control a large portion of the remaining outputs, a far smaller number. This has nothing to do with "breaking the rules" and nothing to do with the devs keeping their word and not selling. The idea that they could keep 80% of the outputs to "prevent" someone else from doing so makes it *easier* for the malicious entity. Clearly CN coins have a prob. On the BTC network there is no diff between users save the amounts in their addys. On CN coin networks there is no diff except for the balances AND the ability of large stakeholders to have a chance at de-anoning tx's. Either way with ALL CN coins we have to trust that large holders do not conspire to de-anon our tx's  You're not getting it. A CN coin where a majority of outputs are controlled by a single entity or group is STILL much more anonymous than BTC. CN > degraded CN > BTC it follows the CN/BCN devs might take the only theoretical measure to prevent bad actors (or bad actors other than themselves) from doing just that. No. It doesn't follow at all. You can reach all kinds of "reasonable" conclusions from the (limited) data we have available on the situations. The above is not one of them. Good luck in your hunt for knowledge. |
|
|
|
2015-Jun-21 12:35:33.245248 Initializing cryptonote protocol...
2015-Jun-21 12:35:33.246312 Cryptonote protocol initialized OK
2015-Jun-21 12:35:33.246458 Initializing p2p server...
2015-Jun-21 12:35:33.919206 Set limit-up to 128 kB/s
2015-Jun-21 12:35:33.920365 Set limit-down to 128 kB/s
2015-Jun-21 12:35:33.921370 Set limit to 128 kB/s Now I understand why it took me 5 days download the blockchain but I do not understand why putting limits if one wanted them did set them alone When we didn't have QoS then we had people complaining about the bandwidth usage. Now we have QoS and a sane bandwidth limit, and people are complaining about it not using enough bandwidth:-P More about lack of a config file. You have to plaster the binary with command line arguments. Not everybody's favorit. or just type limit 999 into the daemon console, or start up bitmonerod with some limit flag "--limit-rate 999"... or put the CLI command mess into a script and then run the script..... https://www.youtube.com/watch?v=NQ-8IuUkJJcYeah instead of a "config" file, just launch with a batch file or shell script. Edit: I also agree 128 KBps is quite low for initial sync. 128 KBps upload on the other hand will likely be too high for many home connections. FWIW, I believe some "reasonable" limits should be in place by default, but perhaps it should be a bit more publicized that they exist and how to change them (though it is obvious from --help). The reason the defaults are best kept low for now is that the syncing part of the p2p code is currently quite inefficient. If you allow it to use more bandwidth, it wastes disproportionately more bandwidth (by downloading the same block multiple times), including from peers who have graciously donated their upstream bandwidth. Somewhere on the development plan is a goal to replace it with a better and more maintainable implementation, although I don't rule out that useful tweaks are possible too. If it were just a matter of trading more bandwidth over a shorter period of time for less bandwidth over a longer period of time, then a download limit wouldn't really make sense at all, but that's not the case. Ah, I wasn't aware of that, thanks. |
|
|
|
Curious how much monero the core team donations wallet received ? Now you can look! With latest git: ./build/release/bin/simplewallet --generate-from-view-key 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8a HYjA3jk3o1Bv16em:e422831985c9205238ef84daf6805526c14d96fd7b059fe68c7ab98e495e5703:/home/user/monero-core-team-donations-watch refresh Enjoy  awesome! can this already be applied to other sites like safedice for a proof of solvency? Somewhat. It makes received transactions visible. So this could be use for periodic proof of solvency as follows: There is a verification account with a public view key, and the reserve coins are regularly moved to that address. At the time of that transaction, it can be seen that the coins exist and immediately after that transaction are in control of the account corresponding to the view key. But you can't currently monitor a view key address to see if the coins are spent. To do that the account holder needs to publish the key images for any received payments, and then tools need to be created to use those images in a view type wallet to identify spends. Either that or protocol changes. I wrote up another method of doing proof-of-solvency using just payment IDs a while back. It involves first publishing the hash of a one-time payment ID you are going to use then doing the proof-of-solvency transaction with that payment ID. This proves you are in control of all of the coins moved by that transaction, since no one else could have published the hash before you did the tranasction. That is good idea, to publish the PID hash before the transaction to prove solvency. Although we have to send it to separate address each time we want to do that, right? Monero doesn't allow sending coin to the same address. Sure it does. Or it should. I think there may have a been a recent bug near head, but there's no technical reason why you can't. As far as proving solvency: using the viewkey functionality in simplewallet (while really cool!) for something like safedice isn't that practical, as every "auditor" would have to input your information, then spend minutes of processing time to detect all your outputs, only to find they don't actually know the state of your account because they can't reliably detect spends. Smooth's idea of publishing a pID hash prior to sending a TX would work well, though you'd want an easy way for folks to do the hash themselves (probably in Javascript). Similarly, I have a page that can "decode" the stealth addresses for a tx, which would essentially accomplish the same thing. Passing *all* of your funds around regularly of course isn't ideal in either case (cold storage and all that). If you have a decent amount in cold storage that likely stays untouched for long periods of time, then providing signatures validating the key images for the outputs in question would be more ideal (need a way to generate these signature and also an API to check the key images against). |
|
|
|
2015-Jun-21 12:35:33.245248 Initializing cryptonote protocol...
2015-Jun-21 12:35:33.246312 Cryptonote protocol initialized OK
2015-Jun-21 12:35:33.246458 Initializing p2p server...
2015-Jun-21 12:35:33.919206 Set limit-up to 128 kB/s
2015-Jun-21 12:35:33.920365 Set limit-down to 128 kB/s
2015-Jun-21 12:35:33.921370 Set limit to 128 kB/s Now I understand why it took me 5 days download the blockchain but I do not understand why putting limits if one wanted them did set them alone When we didn't have QoS then we had people complaining about the bandwidth usage. Now we have QoS and a sane bandwidth limit, and people are complaining about it not using enough bandwidth:-P More about lack of a config file. You have to plaster the binary with command line arguments. Not everybody's favorit. or just type limit 999 into the daemon console, or start up bitmonerod with some limit flag "--limit-rate 999"... or put the CLI command mess into a script and then run the script..... https://www.youtube.com/watch?v=NQ-8IuUkJJcYeah instead of a "config" file, just launch with a batch file or shell script. Edit: I also agree 128 KBps is quite low for initial sync. 128 KBps upload on the other hand will likely be too high for many home connections. FWIW, I believe some "reasonable" limits should be in place by default, but perhaps it should be a bit more publicized that they exist and how to change them (though it is obvious from --help). |
|
|
|
...
thx for the replies smooth, much obliged.
*Andrey N. Sabelnikov
OK, lets see some proof of this sig. ...that's not a sig, it's an asterisk. |
|
|
|
For those interested in running bitmonerod on a Raspberry Pi 2, it seems to work now with LMDB.
I don't know why, all I did was sudo apt-get update && upgrade after a period of not using the rpi.
Sync time is still slow, but it seems faster than BDB.
When I tried with LMDB approx two months ago, sync time was >10 days. (I shut down my RPi2 after 10 days.) Has the ARM code base been updated, so that things are faster now? I think I spoke too soon because the daemon froze at block 345, now I seem to be having input/output problems with the SD card. Going to try it later with the blockchain stored on a USB drive. From what I understand, the SD card interface is utter trash; USB can perform much better. |
|
|
|
I think a big issue with exchange adoption has been the support burden surrounding payment IDs, which was why I was pushing the integrated address/PayID solution. I'm betting exchanges will be more open to supporting XMR when that's out of the way.
yes this seems very useful: - no missing payment id's - no UI modification (maybe make address field bigger  ) what did i forget? still, they will need to implement the back end btw. can you point me to info about this? i did not notice it  I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.
Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.
No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge. I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs. I disagree that we need to do nothing while we work on something better (obviously one does not preclude the other at all). There is no checksum now. The length and valid characters are checked but that's it. The exact same thing can still be checked if the format is changed, slightly to something like Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em-e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac Instead of Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em
and use this payment ID
e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac
Adding the payment ID with checksum seems fairly simple. I went and created a test address just now: Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m
Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy What I did: Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard. cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity): 12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 (done) or something for the "Integrated Address". |
|
|
|
shapshift has not enough liquidity. also no real price detection can happen there. its a nice service, but can not replace an exchange. the only real untraceable coin can only be bougth through a KYC exchange. What worries me most is that i seem to be the only one worrying  Its not becasue of me. but i think some of our potential users could be hindered by this. and users is what we need and what we want. You are certainly not the only one worrying about it. Bittrex is available, but liquidity isn't great, and who knows how long it'll be 'til they have KYC as well. Barely seems worth it to try to move liquidity there if it's going to end up the same way. So yes, it'd be nice to have another exchange. How do we get one?  |
|
|
|
i think the current (non existing) moves in price reflect the lack of infrastructure at least to some degree. Polo is the only liquid exchange. Xmr is one of the only coins that are not possible to buy without registering.
this is a handicap. people are lazy and will always be.
it really depends on what btc does the next few days i think. the xmr buy side is exhausted, there has been no recovery since the last outflow some days ago.
How did DASH manage to get on Bitfinex? Did they pay for it? Connections... [bold] Shapeshift? |
|
|
|
Is the Mnemonic seed created by this compatible to mymonero as well? only the simplewallet but it can be imported to mymonero by paying a 10 XMR fee It's compatible with both. Just for clarification, we can easily make standard MyMonero-style seeds instead, but there's onlymostly disadvantages (Pro: the seed is smaller, but matches the presumed security level of our private keys). It won't work with current simplewallet, and you'll *still* have to pay the 10 XMR fee if you want to pull past transactions on MyMonero. |
|
|
|
About the logo, it autoscales, yes. It doesn't look bad here, but I'm on a laptop so I guess it doesn't look so large compared to the text... I guess you can add width="50%" to the img tag.
The image was taken from getmonero.org btw.
Oh, that's what's going on. On a 1080p screen it gets quite large indeed. |
|
|
|
It has been requested many times, and it is here, at last. https://github.com/moneromooo-monero/monero-wallet-generator is a browser based offline wallet generator for Monero. This means you can generate a new Monero address/wallet without the simplewallet binary. The page is self contained, so is suitable for saving and using offline (ie, possibly on a computer which is not connected to the network). The git commits are GPG signed. If you know how to do so, I encourage you to verify the signature is a valid one. My key can be found in the Monero source tree: https://github.com/monero-project/bitmonero/blob/master/utils/gpg_keys/moneromooo.ascThe Cryptonote code was adapted from MyMonero. I had to change the way it derives the view key to make it compatible with simplewallet. This means the wallets generated are NOT compatible with MyMonero, but with simplewallet. Wallets generated with monero-wallet-generator can be restored at any time with simplewallet: ./build/release/bin/simplewallet --restore-deterministic-wallet --wallet-file mynewwalletfilename Choose a new password, copy the seed you got from monero-wallet-generator, and the wallet will be restored. Only English seeds are supported, due to issues with UTF-8 preventing restoring other languages. This will hopefully change in the future (though low priority). Same thing for non Firefox browsers. I don't have them, so any fixing there is low priority. Last, no warranty. If you have the opportunity, a test restore before moving monero to a new wallet is a good idea, though I guess it kinda defeats the purpose. Ah, nice, you beat me to it. And all in one too, that's handy. Your logo is, kinda big.  |
|
|
|
Hi Guys. I have some questions about simplewallet/generic wallet commands. What is the best/easiest way of managing a large amount of addresses? Will simplewallet allow for creating new addresses frequently? How does poloniex manage their wallet?
Wrong information. I think they can handle this they need to manage a large amount of wallets. I dont kow but maybe simplewallet's or bitmonerod's APIs have a function for creating new wallets. Well, Poloniex does not manage a large number of wallets. They have one address and manage a large number of payment ID's which is the purpose of TheKoziTwo's script above. Maybe there is a new way of doing it with the recent commits by Moneromoo but its still new stuff. It's in current head now (#317), so I guess it's a matter of getting it out there (MyMonero adding support as well would be nice). |
|
|
|
A friend of mine wants to test Monero. He already created a account on MyMonero.com. Is there a site / faucet to get a little amount of Monero to play around?
If your friend has a profile with more than say, 50 activity, have him PM me his address: I'll send him 1. Actually, I'll do this for any member (for up to 50 total) that has an account with >50 activity and isn't already a member of our community (determined by me). |
|
|
|
I don't remember who stated it above, but I do agree that the lack of exchange/merchant adoption might have something to do with the hassle of depending on users to include payment IDs.
Pay ID serialisation into the receiving address looks pretty far down on the roadmap. In the meantime, is there a reason why Payment IDs can't simply be appended to the address and parsed automatically by the client? That would make it much easier for third parties to manage payments until "stealth" payment IDs eventually get implemented.
No checksum is one reason why this will potentially backfire. That and the payment ID space is unnecessarily huge. I'll take a look at my notes from the MRL meetup in November last year, we had some ideas about fixing the payment ID format and serialising it, there may be a quick win to be had whilst we chip away at the stealth payment IDs. I disagree that we need to do nothing while we work on something better (obviously one does not preclude the other at all). There is no checksum now. The length and valid characters are checked but that's it. The exact same thing can still be checked if the format is changed, slightly to something like Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em-e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac Instead of Send to this address: 46BeWrHpwXmHDpDEUmZBWZfoQpdc6HaERCNmx1pEYL2rAcuwufPN9rXHHtyUA4QVy66qeFQkn6sfK8aHYjA3jk3o1Bv16em
and use this payment ID
e981847d2b9e1860d56bcb2263864db976d52e88c9c97db5e734d204f06bedac
Adding the payment ID with checksum seems fairly simple. I went and created a test address just now: Standard Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byMUKoz6m
Payment ID: feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed Integrated Address: 44sKiMHpNjRivdd2NQUyViGYZy4wbJ9L9KhFUaqSSE6JQP9LLbxL9tSikwrhYTRu3x2zKR28txuEc3zSGPduQ9byXSb563RKvyBgorjsFGwyx9gorjsFGwyx9gorjsFGwyx9TpPbbCy What I did: Instead of the standard hex format - ('12' network byte) + (public spend key 64 digits) + (public view key 64 digits) + (checksum 8 digits) - I stripped the checksum and appended the payment ID, then recalculated and appended the new checksum. This creates a 101 byte address instead of the standard 69 byte, and 139 "Public Address" characters vs 95 standard. cnBase58 --> hex the above "Integrated Address" and you get (separated for clarity): 12 55a1e49673f5a8faa6ba4f942585695ceee5c7522496be6fc38d3f09905e3f8b ca6313deac11aff9a7241e7095863b0be3099d50d7a0cd11e0adbcf4990e64b5 feedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeedfeed b1d0950e The code just needs to check for length to determine the type. Alternatively, (I don't know what all the other cryptonotes are using) the network byte could be changed to 0x13 (done) or something for the "Integrated Address". |
|
|
|
Hey guys, I was asking about making Paper Wallets for Monero a page or so back. I only have like 50 Monero coins, which I know is not much, but I want to stash them away safely and just try and forget about them until I check back in on what they're worth in the future. Don't want to be tempted to spend/sell them if I need some BTC for a purchase.
A few people pointed out MyMonero.com as a good web wallet. In your opinion, can the site be trusted to hold my Monero funds securely for a while? And is that the user fluffypony's project?
You should never trust any web wallet regardless of who is developing it. Just like you should never trust any exchanges with your funds. The largest theft of coins originated from compromised online web wallets (blockchain.info), exchanges (Gox/Mintpal) and marketplaces (countless). Trust yourself and your own system and never take advice from anywhere who says otherwise. The biggest problem with XMR paper wallets right now is the lack of an easy way to use the view key to verify a balance. For example if someone sends XMR to your cold wallet how can you verify that transfer? You cant unless you run the daemon and turn the "cold wallet" into a hot wallet. Finding a way to make the view key function work for users should be a top priority. Until then cold wallets are only good if YOU are the one who send the XMR to the cold wallet (from a hot wallet under your control). If I am wrong and there is a way to use the view key to verify payments send to a cold storage address please correct me. Can't correct ya, newb, 'cuz you're right. If you're really sending to a cold cold wallet and have a tx ID (and your viewkey), you can PM me to use a webpage that can verify this stuff (all client-side, obviously). Edit: and Mooo is doing good work on the wallet as well of course. |
|
|
|
Yeah, OpenFreebazaar appears to be a scam at this point (whether originally intended to be or not). You mean FreeBazaar? I doubt OpenBazaar is a scam, with it having just received 1 million dollars.  Oopsie! |
|
|
|
|
Show Posts
