That bastard liar. He says he doesn't know about MRL-0004, yet you fucking linked it. God damned idiots!
Counter-troll troll?
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 1010. (Read 4670673 times)
Counter-troll troll?
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
If I recall correctly, mixing will be at minimum 3. I think he said it, because he already stated that you should read MRL-0004, you shouldn't feel attacked though :-)
I'm not. What I've meant is before I started this, I had no way of knowing about MRL-0004. You should put it on the OP. I think it's very important to know this.
Ok, didn't go through the full document, if 3 is the way, I assume you did the math, 1 just didn't seem good.
My suggestion will be then just: default 10 mixins, and no dust allowed.
Hope that we'll see it fixed soon. And thanks for explaining this to me, and for your patience!
We've known about this issue forever.
https://bitcointalksearch.org/topic/m.8904862
This looks like aggressive posturing from a competitor, but as always, we'll have a solution out soon to fix this.
I'm not even sure "fix" is the right word. As far as I can tell it just involves a lot of guessing. Sometimes you guess right, sometimes wrong. Using some of the methods we've already published (and will be addressed) you can improve your odds of guessing somewhat, but it still comes down to a guess, and there is no way for you or anyone else to know you got it right. It seems a lot of the guesses are terribly inaccurate too. Fluffypony said he had to run through 21 transactions to find even one they got right. Although I haven't seen the details of that test, it sounds pretty worthless to me based on that.
I see no reason to go all Chicken Little about any of it.
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
No, you know it exists, because I linked you to it: https://bitcointalksearch.org/topic/m.10982006
That bastard liar. He says he doesn't know about MRL-0004, yet you fucking linked it. God damned idiots!
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
If I recall correctly, mixing will be at minimum 3. I think he said it, because he already stated that you should read MRL-0004, you shouldn't feel attacked though :-)
I'm not. What I've meant is before I started this, I had no way of knowing about MRL-0004. You should put it on the OP. I think it's very important to know this.
Ok, didn't go through the full document, if 3 is the way, I assume you did the math, 1 just didn't seem good.
My suggestion will be then just: default 10 mixins, and no dust allowed.
Hope that we'll see it fixed soon. And thanks for explaining this to me, and for your patience!
We've known about this issue forever.
https://bitcointalksearch.org/topic/m.8904862
This looks like aggressive posturing from a competitor, but as always, we'll have a solution out soon to fix this.
So when are we getting that shiny db
It is around the corner.
strange... i am using monero with lmdb for weeks... ?
^That's your change from the transaction and it's not confirmed yet and it's locked in simplewallet for 6 confirmations. In a few minutes it'll be unlocked.
How long before a balance becomes unlocked after sending coins? I sent 200 with mixin 1. My balance is -200, but another 273 have also become locked currently. I assume this is just how it works (excuse my ignorance), but I'm curious when I'll have those coins unlocked for use again.
Also, if for example, I had only 200XMR, would I even be able to send them all to another address? From this previous transaction I've done, it would seem I'd need extra coins available in my wallet (i.e. the 273 I mentioned before).
Also, if for example, I had only 200XMR, would I even be able to send them all to another address? From this previous transaction I've done, it would seem I'd need extra coins available in my wallet (i.e. the 273 I mentioned before).
So when are we getting that shiny db
It is around the corner.
So when are we getting that shiny db
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
No, you know it exists, because I linked you to it: https://bitcointalksearch.org/topic/m.10982006
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
If I recall correctly, mixing will be at minimum 3. I think he said it, because he already stated that you should read MRL-0004, you shouldn't feel attacked though :-)
I'm not. What I've meant is before I started this, I had no way of knowing about MRL-0004. You should put it on the OP. I think it's very important to know this.
Ok, didn't go through the full document, if 3 is the way, I assume you did the math, 1 just didn't seem good.
My suggestion will be then just: default 10 mixins, and no dust allowed.
Hope that we'll see it fixed soon. And thanks for explaining this to me, and for your patience!
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
The minimum is going to be 2 (meaning real+2, or what chainradar calls 3), which is the smallest number that doesn't fail catastrophically as explained in MRL-0001 (and somewhat in MRL-0004). The default of 3 (one higher than the minimum, but good for typical uses) is already implemented in simplewallet. If you use the simplewallet from master and don't specify a mixin it uses 3.
The minimum will be increased to 4 in a few years, and that will be programmed into the code according to some block height tbd
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
If I recall correctly, mixing will be at minimum 3. I think he said it, because he already stated that you should read MRL-0004, you shouldn't feel attacked though :-)
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
Hey! You don't have a "Warning: Read MRL-0004" anywhere. How was I to know? that's why I asked. It's good that chainradar exposed it then.
I erased my other posts. It's obvious that MRL-0004 is the issue. Minimum mix in requirements is the solution. So, I hope you will make that hardfork soon.
If I can make a suggestion: You could make it minimum 5 mix ins, not just 1, to avoid any further problems. And make it 10 by default. And don't allow dust amounts. Privacy is the main feature of monero, it can't be overlooked.
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
first 2 tx were 150 and 70 mixin. didn't help
the others I tried to make identical ones at the same time.
but should have made the following txes in reverse order. I'll try that later. If that doesn't work, I'm out of ideas
Posting guesses and suppositions on this thread 10 times in a row is counter-productive. Go read MRL-0004, and you'll see how we've addressed this.
I think chainradar are using all the 0 mixin transactions from exchanges and pools in order to guess - the things in https://lab.getmonero.org/pubs/MRL-0004.pdf. I tried some transactions with mixing 7 and 5 between my wallets and they are successfully guessing most of them. This issue is already addressed in the MRL-0004 and we knew that, but it's scary seeing it in chainradar. Everybody should stop using mixing of 0 until this is enforced in the protocol - including pools and exchanges. I suppose some mixings between your own wallets with high mixing should resolve the issue for now. Trollfest incoming 
.
. 
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
If the ring signature involves n outputs, then you can guess with 1/n probability -- no fancy analysis needed. Try your tests with higher mixin and see how often it gets it right. Over enough tests it should converge to 1/n. Basically, chainradar is just bullshitting but it looks like it succeeds occasionally because its random guess lands on the right one. Dart-throwing monkeys can pull off the very same.
https://github.com/suthernfriend/blockchaindb ??
this seems to be for satoshi.
which one are you using?
I prefer to do it locally, since I'll be making many queries and websites might eventually block me.
I could look through the sources, but if it's already done, why rewrite it.
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
this seems to be for satoshi.
which one are you using?
I prefer to do it locally, since I'll be making many queries and websites might eventually block me.
I could look through the sources, but if it's already done, why rewrite it.
chainradar seems to be doing more of an educated guess, it kinda gets it right. so let's figure out why and how to avoid it
https://github.com/tewinget/bitmonero/tree/blockchain
They could be guessing based on one of the temporal association attacks we identified in MRL-0004, but given that they're 0/20 for me I don't know how "educated" the guess is (although 20 is still a small sample size). MLR-0004 can be found here: https://lab.getmonero.org/pubs/MRL-0004.pdf
thanks for the clarification.
any ideas how it's guessing the right one most of the time then?
edit:
Do you have a link to the daemon api, or is there an open source block explorer? I want to analyse the blockchain myself, not sure where to start. Thanks
any ideas how it's guessing the right one most of the time then?
edit:
Do you have a link to the daemon api, or is there an open source block explorer? I want to analyse the blockchain myself, not sure where to start. Thanks
In my tests (20 transactions) they haven't correctly guessed any of them:)
You can try the MoneroBlocks API (not sure if it'll give you enough info for these queries), or use the blockchainDB branch and query the LMDB data (this is probably harder, but closer to what I'm doing).
Jump to: