Author

Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1603. (Read 4670972 times)

legendary
Activity: 1722
Merit: 1217
Tell me where im wrong here smart guys. Or if i right.

So you shouldn't need to actually use ring signatures very often. Say that we have 3 inputs in our wallet of 2, 4, 5  and  monero. Say that we need to pay alice 10 monero.

We use alices public address plus nonce_a to generate 1_time_address_a and send our 5 monero input to it.

We use alices public address plus nonce_b to generate 1_time_address_b and send our 4 monero input to it.

We use alices public address plus nonce_c to generate 1_time_address_c and our own public address plus nonce_d to generate 1_time_address_d and send 1 monero from our 2 monero input to 1 _time_address_c and 1 monero from our 2 monero input to 1_time_address_d.

Nothing has been revealed about any parties involves. No ring signatures have been used. The only problem here is that transactions, over time, are becoming more and more dusty. So inorder to avoid creating more dust on the network, the only ring signature you would need to use is to send that 1 monero back to an address you already control instead of a new one that you have just created for yourself.

I think you still need ring signatures.

The one time addresses provide unlinkability so that the three payments made by Alice are not known to be sent to the same person receiving.

But the payments don't have untraceability since you can still see that Alice sent all three payments. If ring signatures were used (and assuming you used mixin > 0) then you have the case where an observer can't tell if Alice sent it or another party did.

Yea sure they would be linked if you made them all part of the same transaction. But you could do 3 separate transactions. That way you have unlinkability, untraceability, and no ring signatures (though still the aforementioned problem of creating dust).
full member
Activity: 133
Merit: 100
Tell me where im wrong here smart guys. Or if i right.

So you shouldn't need to actually use ring signatures very often. Say that we have 3 inputs in our wallet of 2, 4, 5  and  monero. Say that we need to pay alice 10 monero.

We use alices public address plus nonce_a to generate 1_time_address_a and send our 5 monero input to it.

We use alices public address plus nonce_b to generate 1_time_address_b and send our 4 monero input to it.

We use alices public address plus nonce_c to generate 1_time_address_c and our own public address plus nonce_d to generate 1_time_address_d and send 1 monero from our 2 monero input to 1 _time_address_c and 1 monero from our 2 monero input to 1_time_address_d.

Nothing has been revealed about any parties involves. No ring signatures have been used. The only problem here is that transactions, over time, are becoming more and more dusty. So inorder to avoid creating more dust on the network, the only ring signature you would need to use is to send that 1 monero back to an address you already control instead of a new one that you have just created for yourself.

I think you still need ring signatures.

The one time addresses provide unlinkability so that the three payments made by Alice are not known to be sent to the same person receiving.

But the payments don't have untraceability since you can still see that Alice sent all three payments. If ring signatures were used (and assuming you used mixin > 0) then you have the case where an observer can't tell if Alice sent it or another party did.
legendary
Activity: 2730
Merit: 1288
It's wonderful to see how Monero PR team works. Everytime there's a painful topic in this thread, some new members arrive and start posting irrelevant bullshit. You're doing great guys!


There are 10k HODLers, some of them join the chat here.  I did not see anything painful in thing that was solved yesterday. It related exchanges. And i am sure they put attention to solve it perfectly, to not lose clients.

Monero have 10k members in PR. Every coin should have them. Everyone needs to get at least one new investor till end of the year.  Grin




This is big, but Monero was 60-70% of Poloniex trades.
Rias you could ask Poloniex to add your coin in Monero exchange. Will prosper for sure.
legendary
Activity: 1722
Merit: 1217
Tell me where im wrong here smart guys. Or if i right.

So you shouldn't need to actually use ring signatures very often. Say that we have 3 inputs in our wallet of 2, 4, 5  and  monero. Say that we need to pay alice 10 monero.

We use alices public address plus nonce_a to generate 1_time_address_a and send our 5 monero input to it.

We use alices public address plus nonce_b to generate 1_time_address_b and send our 4 monero input to it.

We use alices public address plus nonce_c to generate 1_time_address_c and our own public address plus nonce_d to generate 1_time_address_d and send 1 monero from our 2 monero input to 1 _time_address_c and 1 monero from our 2 monero input to 1_time_address_d.

Nothing has been revealed about any parties involves. No ring signatures have been used. The only problem here is that transactions, over time, are becoming more and more dusty. So inorder to avoid creating more dust on the network, the only ring signature you would need to use is to send that 1 monero back to an address you already control instead of a new one that you have just created for yourself.
legendary
Activity: 3766
Merit: 5146
Note the unconventional cAPITALIZATION!
Going on 16 hours withdrawal from Poloniex to BTER...anyone else having similar issues?

I have now sent support tickets to both exchanges   Huh

Yes.  There was  bug with payment IDs for a while.  See this post from hitBTC for some info.
https://bitcointalksearch.org/topic/m.7987831

It really sucks to have money in limbo.  I do too.
newbie
Activity: 22
Merit: 4
It's wonderful to see how Monero PR team works. Everytime there's a painful topic in this thread, some new members arrive and start posting irrelevant bullshit. You're doing great guys!

Come on, proof-of-haiku, really? The "core team" failed for several weeks and potentially exposed every XMR user with a bug leading to money loss. Could you make a haiku on that? Smiley

I have been able to fine tune my PoH discovery code to include merged mining with other cryptonote coins.  I would also like to point out I am the first to accomplish this.  Here is the first block discovered with Ducknote and Bytecoin merged mining.

acting like a child
you just come to gloat and mock
sour grapes for lunch?
donator
Activity: 1274
Merit: 1060
GetMonero.org / MyMonero.com
Making a mistake is not childish.  It's human, and it happens to everyone.  Casting the first stone and all that.  It doesn't matter if the mistake is apparently simple or not.

The test in this is whether the Monero team addresses it in an adult way:  Will they add tests and/or procedures to *prevent this same kind of error* from getting introduced again?  Will they communicate that they've done so?

I suggest taking a chill pill and checking back after the dust has settled instead of pointing fingers and calling people names.

Here's a nice bitcoin bug from last year to ponder:  http://ecurrency.ec/2013/03/bitcoin-bug-resolved/

If there aren't improvements made to, e.g., regression and acceptance testing, as a result of this, then make noise.  But adding that and doing an adult post-mortem of what went wrong takes longer than a few hours when your development team is small and scattered around the world.

Incidentally, this was spotted in regression and testing and fixed: https://github.com/tewinget/bitmonero/commit/e7a3bd19f61d047f3daa49910e0d7da41ef47a8b

The mistake was not realising that it wasn't rpcwallet-specific and needed to be fixed in master as well.

A formal test suite is lacking for RPC calls. There are some tests for the daemon, but not what we'd expect to see, so this is something that needs to be brought up to scratch in a big way.
legendary
Activity: 1218
Merit: 1000
Going on 16 hours withdrawal from Poloniex to BTER...anyone else having similar issues?

I have now sent support tickets to both exchanges   Huh
kbm
member
Activity: 84
Merit: 10

Wow! That's going to be pretty fun to play with. Guess they really were planning on going ahead with this. They were hinting at it for a while when they took down most of the LTC markets, and everyone kept asking what was up.

I wonder if it will help with daily stability. It's a big step, and I'm happy to see that, of all exchanges still offering XMR trading, Poloniex is again willing to make the first move to support this project in large ways.

They've really been making some big improvements -- you can see the entire market depth now, and you can also see the market movements/trollbox without needing to log in now.
jr. member
Activity: 54
Merit: 257
Monero Missives

July 23rd, 2014

Hello, and welcome to our eighth Monero Missive!

Major Updates

1. We're extremely pleased to announce that Poloniex has, once again, proven their class-leading initiative by being the first major exchange to add Monero trading pairs. This has been coming for a while, given Monero's large trade volume on Poloniex, and we are certainly grateful to Poloniex for their forward-thinking approach. The markets that have been added are: BCN/XMR, DIEM/XMR, DRK/XMR, IFC/XMR, MAID/XMR, NXT/XMR, and QORA/XMR. The Poloniex press release can be found here.

2. A major change that has been made concerns the license Monero currently uses. We inherited the MIT / X11 license from CryptoNote, which is a very permissive license that explicitly allows re-licensing with compatible licenses. We have thus decided to move to the BSD 3-clause license, which is equally permissive, enforces attribution, and has a clause that prevents "the name of the copyright holder nor the names of its contributors" from being used to promote or endorse products. The epee library that is part of Monero was already under a BSD 3-clause license, so all we have done is just replaced it with the standard formatting we're using, and have included the original in the /contrib/epee/LICENSE.txt, noted as being the original license as it appeared. We have taken great care to preserve ALL copyrights for the original code, which are attributed to "the Cryptonote developers" for most of it, and "Andrey N. Sabelnikov" for epee. Our copyright appears above that so that we are the copyright holders for any new code. Any brand new files that are added by us will not get any copyright attribution except ours (eg. electrum-words.h and .cpp that have been added by us).

   For public domain code we have left the license as is (much of the crypto hashing code, for instance). If you spot ANY code where the original author has not been credited or copyright has not been retained, please let us know by opening an issue on Github or messaging or emailing us.

3. Along with this change is a new README, that should be a little better at giving the correct build instructions, as well as explaining the development rationale and a more formal staging -> tagged release methodology we will be using moving forward.

4. Since git (and, by extension, github) can be confusing to developers that are working on Monero code (or on any git repositories, really), one of the Monero key contributors, tewinget, will be hosting a Git Crash Course next week Wednesday, July 30th. He will be joined by fluffypony, and all interested are invited to attend. It will be broadcast through Twitch, and questions and discussions will happen in #monero-dev on Freenode during the course. It's going to be relaxed and informal, so if you want to know how to use git properly it's well worth tuning in. It will start at 2pm EST (6pm UCT). Feel free to invite anyone that you think will benefit from it!

Dev Diary

RPC: a new RPC call has been added to the daemon, get_info. This returns information on the current state of the daemon and the network, including the current block height.

RPC: the new get_bulk_payments RPC call is complete and available. Apart from being able to pass thousands of payment IDs to this function, you can optionally pass a block height, and it will scan from the block height up. To give you an indication: Poloniex went from taking nearly 45 minutes to scan all of their payment IDs with get_payments, to it taking around 17 seconds with get_bulk_payments.

Core: the major change of introducing rpcwallet, as well as proper daemonization / service mode (on *nix or Windows respectively) is ready for testing. If you are able to, please compile and test this branch so we can finalise it and merge it in: https://github.com/mikezackles/bitmonero/tree/daemonize_wip

Until next week!

- updated by fluffypony
hero member
Activity: 723
Merit: 503
sr. member
Activity: 280
Merit: 250
Not sure I understand 3. I was the miner for some transactions (through a pool), and the purchaser on polo for the bigger transactions. I thought the transaction fees were going to the devs.
Transaction fees are going to the miners - when you are mining for a pool it's distributed to all the pool miners depending on their hash power (when the pool fee is subtracted).

I understand that for the transactions from a pool to my local wallet, but not for a transfer between two of my own wallets. Thanks for the help.

Quote
Why don't you just copy wallet.dat or import private keys than transferring it? Roll Eyes
Kindly,
        MZ

The idea is to at some point move to a much newer wallet with deterministic seed and new password, and clean up dusty transactions along the way. If that's achievable without a transfer I'm open to alternatives.  Smiley
legendary
Activity: 1484
Merit: 1005

We did already, but I didn't like the way that was implemented (it looks like it spins up internal testnets more akin to regression testing). I already wrote up some specifications for a Bitcoin-style testnet, so we have something operational for lots of people to play with along the lines of bitcoin testnet3.

In the testing suite there already is something very similar to a regression test anyway, that just needs to be fixed.
sr. member
Activity: 373
Merit: 250
The test in this is whether the Monero team addresses it in an adult way:  Will they add tests and/or procedures to *prevent this same kind of error* from getting introduced again?  Will they communicate that they've done so?

We are trying to. We don't even have a proper testnet functioning, which makes things difficult. I added a note to the repo in issues a while ago for the addition of a testnet and the fixing of the test cases from the original ByteCoin code (most of which are now broken).

Why don't you plagiarire testnet from CryptoNote?
https://github.com/cryptonotefoundation/cryptonote/commit/f4769d87ad606b63484ef76ef57f50b5ac117d0a
legendary
Activity: 1484
Merit: 1005
The test in this is whether the Monero team addresses it in an adult way:  Will they add tests and/or procedures to *prevent this same kind of error* from getting introduced again?  Will they communicate that they've done so?

We are trying to. We don't even have a proper testnet functioning, which makes things difficult. I added a note to the repo in issues a while ago for the addition of a testnet and the fixing of the test cases from the original ByteCoin code (most of which are now broken).

It's difficult. I code full time on another project, we only have a few dedicated, paid f/t devs at this point, and we're constantly trying to implement new things that have been requested by exchanges and others. I'm around to talk to if people want to hack on the project and have been working with the f/t devs to try to get out majorly needed features like an actual database, and I've been emphasizing fixing the testing suite for a while now.
sr. member
Activity: 373
Merit: 250

This is true. Today we at MinerGate updated our XMR daemons and wallets to the latest github version, but fortunately the wallet didn't pass our sanity check tests, because of PaymentID being skipped for every tx.

I've created a pull request with a fix, please take a look.
https://github.com/monero-project/bitmonero/pull/69

UPD: fluffypony accepts my request, thanks!

Thank you Minergate for helping out incompetent XMR developers. They should be very grateful this was fixed so fast, could've been much worse.

Imagine what would happen if this went unnoticed - a lot of people with a lot of lost funds all due to a childish mistake.

Making a mistake is not childish.  It's human, and it happens to everyone.  Casting the first stone and all that.  It doesn't matter if the mistake is apparently simple or not.

The test in this is whether the Monero team addresses it in an adult way:  Will they add tests and/or procedures to *prevent this same kind of error* from getting introduced again?  Will they communicate that they've done so?

I suggest taking a chill pill and checking back after the dust has settled instead of pointing fingers and calling people names.

Here's a nice bitcoin bug from last year to ponder:  http://ecurrency.ec/2013/03/bitcoin-bug-resolved/

If there aren't improvements made to, e.g., regression and acceptance testing, as a result of this, then make noise.  But adding that and doing an adult post-mortem of what went wrong takes longer than a few hours when your development team is small and scattered around the world.

Nicely said. It just makes me sick when some devs claim to be superior but can't deliver and make silly but fatal bugs. Hopefully, this story will end up with the right conclusions for the core team.
dga
hero member
Activity: 737
Merit: 511

This is true. Today we at MinerGate updated our XMR daemons and wallets to the latest github version, but fortunately the wallet didn't pass our sanity check tests, because of PaymentID being skipped for every tx.

I've created a pull request with a fix, please take a look.
https://github.com/monero-project/bitmonero/pull/69

UPD: fluffypony accepts my request, thanks!

Thank you Minergate for helping out incompetent XMR developers. They should be very grateful this was fixed so fast, could've been much worse.

Imagine what would happen if this went unnoticed - a lot of people with a lot of lost funds all due to a childish mistake.

Making a mistake is not childish.  It's human, and it happens to everyone.  Casting the first stone and all that.  It doesn't matter if the mistake is apparently simple or not.

The test in this is whether the Monero team addresses it in an adult way:  Will they add tests and/or procedures to *prevent this same kind of error* from getting introduced again?  Will they communicate that they've done so?

I suggest taking a chill pill and checking back after the dust has settled instead of pointing fingers and calling people names.

Here's a nice bitcoin bug from last year to ponder:  http://ecurrency.ec/2013/03/bitcoin-bug-resolved/

If there aren't improvements made to, e.g., regression and acceptance testing, as a result of this, then make noise.  But adding that and doing an adult post-mortem of what went wrong takes longer than a few hours when your development team is small and scattered around the world.
Jump to: