Hah, did I get to say that first?
Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency - page 241. (Read 4671660 times)
SO, It IS TRUE !
Hah, did I get to say that first?
Hah, did I get to say that first?
Still says it mines Monero on their website from the link above
^^^^
They have already removed Monero from the list of coins that can be mined with this
They have already removed Monero from the list of coins that can be mined with this
ASIC is coming ,XVG and DGB are killed by AISC,obviously，XMR will dump to floor.
Monero's POW algorithm is soon to be changed slightly. This will render any asics useless.
i mean this ASIC,not FPGA.
http://www.baikalminer.com/product12.php
I need some help. Ever since v0.11.1.0 I can not figure out how to send a payment through the CLI wallet feature. I typed help and get this in the wallet help menu but I don't know how to format it correctly.
Ring size does this matter and what values do you use min max? Also what is the minimum mixinn these days? Can someone please place an example of how to transfer here please.
how do you generate a payment ID now has this changed as well?
Ring size does this matter and what values do you use min max? Also what is the minimum mixinn these days? Can someone please place an example of how to transfer here please.
how do you generate a payment ID now has this changed as well?
the minimum and default for ringsize is 5 (that is the same as mixin 4) ring size has replaced mixin as the descriptor. No need to change this.
when you type help you will see "transfer" and that is the format to use. and it describes it as well
transfer [
you don't need to set ring size. If you want to lower priority and therefore the fee use [1] I usually just set the priority before a transfer by "set priority 1" so as not to be concerned with the order of things and then just use "transfer
for the PID, whoever you are sending to will give that to you. If receiving then I am unsure. I have found no need for it
With the new release and hardfork at the end of the month subaddresses can be used instead of PID. They will work better but it will probably take a while before exchanges start using them.
Thank you good sir.
I need some help. Ever since v0.11.1.0 I can not figure out how to send a payment through the CLI wallet feature. I typed help and get this in the wallet help menu but I don't know how to format it correctly.
Ring size does this matter and what values do you use min max? Also what is the minimum mixinn these days? Can someone please place an example of how to transfer here please.
how do you generate a payment ID now has this changed as well?
Ring size does this matter and what values do you use min max? Also what is the minimum mixinn these days? Can someone please place an example of how to transfer here please.
how do you generate a payment ID now has this changed as well?
the minimum and default for ringsize is 5 (that is the same as mixin 4) ring size has replaced mixin as the descriptor. No need to change this.
when you type help you will see "transfer" and that is the format to use. and it describes it as well
transfer [
you don't need to set ring size. If you want to lower priority and therefore the fee use [1] I usually just set the priority before a transfer by "set priority 1" so as not to be concerned with the order of things and then just use "transfer
for the PID, whoever you are sending to will give that to you. If receiving then I am unsure. I have found no need for it
With the new release and hardfork at the end of the month subaddresses can be used instead of PID. They will work better but it will probably take a while before exchanges start using them.
I need some help. Ever since v0.11.1.0 I can not figure out how to send a payment through the CLI wallet feature. I typed help and get this in the wallet help menu but I don't know how to format it correctly.
Ring size does this matter and what values do you use min max? Also what is the minimum mixinn these days? Can someone please place an example of how to transfer here please.
how do you generate a payment ID now has this changed as well?
Ring size does this matter and what values do you use min max? Also what is the minimum mixinn these days? Can someone please place an example of how to transfer here please.
how do you generate a payment ID now has this changed as well?
Waited for Monero to come out of the dip. +10% today! Check out the fluctuations in the charts:https://www.coinranker.net/cryptocurrency/monero
Holy crap you guys. Eureka! I figured it out! Not just a stop gap measure to address the fork ring sig reuse problem. The actual solution! I was just laying in bed trying to fall asleep and it hit me like a tire iron to the face.
It is possable to deterministically derive ring sig partners but in a way that would be functionally random to any outside observer. I'll give an example of one way of doing it. Take
Then make all of the prospective ring signature partners into an ordered numbered set and use the resulting modulus from the pseudo code above to select one. Continue wrapping around the clock face as many times as needed to arrive at the number of ring signature partners desired.
There would be 0 information leak from the outside, the ring signature partners would be functionally random to any outside observer BUT, and here is the beautiful thing, the same ring signature partners would end up being selected on both the main chain AND the fork chain!
Of course what I outlined above almost certainly isn't the best way to achieve this. It was just to outline the concept.
Merits! I deserve all of the merits. Bequeath unto me thine merits! (well, after peer review, and not just if my specific idea is right but if I'm barking up close enough to the right tree to inspire someone smarter than me)
It is possable to deterministically derive ring sig partners but in a way that would be functionally random to any outside observer. I'll give an example of one way of doing it. Take
Code:
sha256([your private key] [transaction hash of most recent input]) mod [number of prospective ring signature partners]
Then make all of the prospective ring signature partners into an ordered numbered set and use the resulting modulus from the pseudo code above to select one. Continue wrapping around the clock face as many times as needed to arrive at the number of ring signature partners desired.
There would be 0 information leak from the outside, the ring signature partners would be functionally random to any outside observer BUT, and here is the beautiful thing, the same ring signature partners would end up being selected on both the main chain AND the fork chain!
Of course what I outlined above almost certainly isn't the best way to achieve this. It was just to outline the concept.
Merits! I deserve all of the merits. Bequeath unto me thine merits! (well, after peer review, and not just if my specific idea is right but if I'm barking up close enough to the right tree to inspire someone smarter than me)
The prospective ring signature partners is a numbered order set consisting of the total number of transactions so what is the benefit of using that as it can easily be determined? Or am I just missing something there?
AFA as the concept itself,I cannot comment on except it sounds doable.
No you aren't missing anything. I was just trying to be as clear as possible. Said differently, one would use the ouput from that algorithm, call it N, to select the Nth valid prospective ring signature partner.
Got ya.
Holy crap you guys. Eureka! I figured it out! Not just a stop gap measure to address the fork ring sig reuse problem. The actual solution! I was just laying in bed trying to fall asleep and it hit me like a tire iron to the face.
It is possable to deterministically derive ring sig partners but in a way that would be functionally random to any outside observer. I'll give an example of one way of doing it. Take
Then make all of the prospective ring signature partners into an ordered numbered set and use the resulting modulus from the pseudo code above to select one. Continue wrapping around the clock face as many times as needed to arrive at the number of ring signature partners desired.
There would be 0 information leak from the outside, the ring signature partners would be functionally random to any outside observer BUT, and here is the beautiful thing, the same ring signature partners would end up being selected on both the main chain AND the fork chain!
Of course what I outlined above almost certainly isn't the best way to achieve this. It was just to outline the concept.
Merits! I deserve all of the merits. Bequeath unto me thine merits! (well, after peer review, and not just if my specific idea is right but if I'm barking up close enough to the right tree to inspire someone smarter than me)
It is possable to deterministically derive ring sig partners but in a way that would be functionally random to any outside observer. I'll give an example of one way of doing it. Take
Code:
sha256([your private key] [transaction hash of most recent input]) mod [number of prospective ring signature partners]
Then make all of the prospective ring signature partners into an ordered numbered set and use the resulting modulus from the pseudo code above to select one. Continue wrapping around the clock face as many times as needed to arrive at the number of ring signature partners desired.
There would be 0 information leak from the outside, the ring signature partners would be functionally random to any outside observer BUT, and here is the beautiful thing, the same ring signature partners would end up being selected on both the main chain AND the fork chain!
Of course what I outlined above almost certainly isn't the best way to achieve this. It was just to outline the concept.
Merits! I deserve all of the merits. Bequeath unto me thine merits! (well, after peer review, and not just if my specific idea is right but if I'm barking up close enough to the right tree to inspire someone smarter than me)
The prospective ring signature partners is a numbered order set consisting of the total number of transactions so what is the benefit of using that as it can easily be determined? Or am I just missing something there?
AFA as the concept itself,I cannot comment on except it sounds doable.
No you aren't missing anything. I was just trying to be as clear as possible. Said differently, one would use the ouput from that algorithm, call it N, to select the Nth valid prospective ring signature partner.
ASIC is coming ,XVG and DGB are killed by AISC,obviously，XMR will dump to floor.
Monero's POW algorithm is soon to be changed slightly. This will render any asics useless.
FPGA (field Grid Programmable Array) is a system that can be programmed to act as an asic but it does not have even close to asic speed because the chips used are much slower than if you had made the asic on die.
Holy crap you guys. Eureka! I figured it out! Not just a stop gap measure to address the fork ring sig reuse problem. The actual solution! I was just laying in bed trying to fall asleep and it hit me like a tire iron to the face.
It is possable to deterministically derive ring sig partners but in a way that would be functionally random to any outside observer. I'll give an example of one way of doing it. Take
Then make all of the prospective ring signature partners into an ordered numbered set and use the resulting modulus from the pseudo code above to select one. Continue wrapping around the clock face as many times as needed to arrive at the number of ring signature partners desired.
There would be 0 information leak from the outside, the ring signature partners would be functionally random to any outside observer BUT, and here is the beautiful thing, the same ring signature partners would end up being selected on both the main chain AND the fork chain!
Of course what I outlined above almost certainly isn't the best way to achieve this. It was just to outline the concept.
Merits! I deserve all of the merits. Bequeath unto me thine merits! (well, after peer review, and not just if my specific idea is right but if I'm barking up close enough to the right tree to inspire someone smarter than me)
It is possable to deterministically derive ring sig partners but in a way that would be functionally random to any outside observer. I'll give an example of one way of doing it. Take
Code:
sha256([your private key] [transaction hash of most recent input]) mod [number of prospective ring signature partners]
Then make all of the prospective ring signature partners into an ordered numbered set and use the resulting modulus from the pseudo code above to select one. Continue wrapping around the clock face as many times as needed to arrive at the number of ring signature partners desired.
There would be 0 information leak from the outside, the ring signature partners would be functionally random to any outside observer BUT, and here is the beautiful thing, the same ring signature partners would end up being selected on both the main chain AND the fork chain!
Of course what I outlined above almost certainly isn't the best way to achieve this. It was just to outline the concept.
Merits! I deserve all of the merits. Bequeath unto me thine merits! (well, after peer review, and not just if my specific idea is right but if I'm barking up close enough to the right tree to inspire someone smarter than me)
The prospective ring signature partners is a numbered order set consisting of the total number of transactions so what is the benefit of using that as it can easily be determined? Or am I just missing something there?
AFA as the concept itself,I cannot comment on except it sounds doable.
What happened to the hoard of reddit supporters? They have no issue funding marketing bullshit so they can line their greedly little pockets but when it comes to the most important core parts of the project they are no where to be found. It's almost as if security is kicked from the back seat into the trunk. I bet if we put up a funder to get some second rate hack actor like Seagal it would be funded in 10 minutes.
https://forum.getmonero.org/8/funding-required/90007/bulletproofs-audit-fundraising
https://forum.getmonero.org/8/funding-required/90007/bulletproofs-audit-fundraising
We want Carlos from bitconnect!
Come on now 170 xmr in 3 days is not bad at all.
It used to be hours tops for this stuff.
All done. 3 days. 240 xmr ain't peanuts anymore either.
120k subs on reddit. Typically 3000-4000+ online at any given time. Ya, not much for community support given the numbers. But we still get it done.
Nice to see you guys still supporting the core ideals over here and I'm glad Fluffy used the Dev fund for the remainder. It's weird with the FFS sometimes I forget that there is a Dev fund that gets a cut of most pools.
Anyone know how much is in the development fund?
Good question, I'm sure there is a view key around somewhere but I have no clue where. It would be nice to see a spreadsheet to see how it's been used over the years. I only disagreed with one thing it was used for (at least that I know) so that's pretty damn good over all as in any organization having that kind of agreement from the community is pretty unheard of.
ASIC is coming ,XVG and DGB are killed by AISC,obviously，XMR will dump to floor.
Monero's POW algorithm is soon to be changed slightly. This will render any asics useless.
A FPGA is not an ASIC. This change will stop ASICs but not FPGAs. I don't think anything can do that except maybe an intentionally developed FPGA resistant algorithm.
ASIC is coming ,XVG and DGB are killed by AISC,obviously，XMR will dump to floor.
Monero's POW algorithm is soon to be changed slightly. This will render any asics useless.
ASIC is coming ,XVG and DGB are killed by AISC,obviously，XMR will dump to floor.
Monero's POW algorithm is soon to be changed slightly. This will render any asics useless.
ASIC is coming ,XVG and DGB are killed by AISC,obviously，XMR will dump to floor.
You deduced well.
And who would ask you to do that?
And who would ask you to do that?
I know! I know!
SCAMMERZ!
You deduced well.
And who would ask you to do that?
And who would ask you to do that?
Well if the fork has been delayed then this makes it a good time to stock up on some more Monero, which exchanges will be issuing the forked coin.
The recent surprise growth in XMR price had got the support from a looming hard fork – which is expected to take place in mid of this month. MoneroV would be the new form of Monero token; investors who hold Monero will obtain 10 coins of MoneroV against each Monero coin.
https://cryptocurrencynews.com/daily-news/altcoins/monero-price-lead/
The recent surprise growth in XMR price had got the support from a looming hard fork – which is expected to take place in mid of this month. MoneroV would be the new form of Monero token; investors who hold Monero will obtain 10 coins of MoneroV against each Monero coin.
https://cryptocurrencynews.com/daily-news/altcoins/monero-price-lead/
Do I need to expose my private keys to get MoneroV?
I doubt it's fine to share your private key to get a fork coin.
CoinGenome listed XMR https://coingenome.com/coin/xmr
3M and 6M chart looks solid.
3M and 6M chart looks solid.
Jump to: