[XMR] Monero Speculation

[Anon136]

Wow. I'm not used to seeing Monero fall more than everyone else. This is depressing. I can handle a downturn but why would our awesome project be the worst of the bunch? Jesus, dark coin is going to over take us if this continues.

[1714858846]

1714858846

[1714858846]

1714858846

[cAPSLOCK]

Wow. I'm not used to seeing Monero fall more than everyone else. This is depressing. I can handle a downturn but why would our awesome project be the worst of the bunch? Jesus, dark coin is going to over take us if this continues.

At least some of it was the forkcoin play.  Recently it was announced that the launch would be postponed.

[Anon136]

Wow. I'm not used to seeing Monero fall more than everyone else. This is depressing. I can handle a downturn but why would our awesome project be the worst of the bunch? Jesus, dark coin is going to over take us if this continues.

At least some of it was the forkcoin play.  Recently it was announced that the launch would be postponed.

Exchanges and custodian services need more time to implement the MoneroV technology for them to support the fork and credit XMR holders with XMV. We are in the process of helping leading exchanges (from the top five Monero trading platforms) to list MoneroV. These services require additional time for implementation and we are positive that postponing the hard-fork date so that more users will be credited with their XMV outweighs the drawbacks.
Monero’s own software update that will occur in March is causing confusion with the initial hard-fork date. This is a common complaint we hear from both the Monero community and our own. Postponing the hard-fork snapshot date will help both Blockchains.
Mining pools are asking for more time to implement MoneroV. We want to help these pools to prepare for the hard-fork split so that MoneroV will be more stable and robust.
Many users have difficulty storing their XMR locally using the Monero GUI wallet due to its large blockchain size. Postponing the hard-fork date will help more users to prepare and be able to claim their XMV’s.
Overall, taking into consideration these reasons, and although MoneroV’s codebase is fully functional, we are positive that it would be best to postpone the snapshot date.

Here is what I think of all of those "reasons".



*edit* I love this gif so much. It's so funny. I could watch it all day.

[denetci]

Having both our team and community grow rapidly, the past few months has positioned the MoneroV project and the upcoming hard-fork as a highly anticipated event. With both great support and enthusiasm, we are dedicated to realizing the vision of a truly decentralized, finite currency to serve the community for years to come.

Due to the growing demand and increasing expectations from users, trading platforms, and large mining pools, we have decided that the Snapshot date will be postponed to ~30th of April block 1564965 

[Anon136]

finite currency to serve the community for years to come.

See gif above.

[KiXiNiT]

Wow. I'm not used to seeing Monero fall more than everyone else. This is depressing. I can handle a downturn but why would our awesome project be the worst of the bunch? Jesus, dark coin is going to over take us if this continues.

Only because the pump was because of MoneroV airdrop, now it's postponed all the cash that flowed in is flowing out.

As much as people in this thread said it was about the "tech" more than the airdrop predictably they were very wrong.

Hardly anyone cares about the tech in crypto, that's why this market doesn't make sense to anybody

[Tavarez]

this coin has a guaranteed use in the future because of it privacy feature. Anonymity will be a demand soon. Now we will see what is going to happen with Monero after fork. Maybe we will see Monero V, but how knows. rising steadily from 2015 and let's hope this trend can continue.

[Anon136]

I'm going to X-post this over here too from the main thread because I think hope it is important.

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

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)

[kurious]

I'm going to X-post this over here too from the main thread because I think hope it is important.

Holy crap you guys. Eurika! 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

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 modulous 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)

You will get some from me if it passes review - if so well done!  In fact, well done anyway - I couldn't hope to even approach the issue.

[phishead]

I'm going to X-post this over here too from the main thread because I think hope it is important.

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

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)

To the average lurker who doesn't understand all the ins and outs of how you could pair up the same ring sigs, it sounds crazy enough to work.  I bequeath you 1 merit, and 1 more if it actually works.  Hopefully enough merits will help you sleep better at night.

Wow. I'm not used to seeing Monero fall more than everyone else. This is depressing. I can handle a downturn but why would our awesome project be the worst of the bunch? Jesus, dark coin is going to over take us if this continues.

Does it affect Monero's functionality?  If not then...

[Anon136]

I'm going to X-post this over here too from the main thread because I think hope it is important.

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

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)

To the average lurker who doesn't understand all the ins and outs of how you could pair up the same ring sigs, it sounds crazy enough to work.  I bequeath you 1 merit, and 1 more if it actually works.  Hopefully enough merits will help you sleep better at night.

I had some more time to think about it. It does have one flaw that I have thought of so far.

There is no way for an outside observer to verify that this method of ring sig partner selection had been used. So someone could run their own custom modified software that selected ring signature partners truely randomly their transactions would still be accepted by the network (though I don't know who would do that or why). Or if a fork chain was purposely malicious they could always delete this little bit of code roll that part of the software back to the way it is now. However if they did change that bit of code their motives would immediately become highly suspect, if not beyond reasonable doubt level incriminating, and this would severely damage if not ruin the reputation of their project (one hopes ).

Also I think the current ring sig partner selection weights newer transactions. So talking about random all the time like I was I don't think is technically completely accurate. But it helped to simplify the point I was trying to make and I think it was ok because a very similar weighting could be incorporated into the scheme I laid out with only minor modifications.

[Moon_Man]

monero is life

[mambamanagement]

monero is life

a very important project

[Globb0]

Monero is a very sensitive subject


From the moment that I saw you
I knew that I'd be safe, cuz I'd never be alone
Run da buisness of the family
Have an evil empire just like my dear old Dad
Be Eviiiiil, but have my feelings too
Change my love wit Oprah and Maya Angeloo
But Monerov rejected me, c'est la vie
Life is cruel, treats you unfairly
Even so, a God there must be
Monero, you complete me


 

[Veseloff]

Hello! Do you think it's worth keeping Monero a couple more years? Does he have great prospects? It seems to me that a coin can bring a good profit.

[Moon_Man]

Hello! Do you think it's worth keeping Monero a couple more years? Does he have great prospects? It seems to me that a coin can bring a good profit.

For sure. Monero is king of privacy coins

[bubaba]

Fresh from the press
https://smartereum.com/3457/monero-price-predictions-2018-significant-appreciation-is-possible-i-usd-xmr-monero-xmr-monero-price-news-today-march-11-2018-price-news/

and this Baikal Miners + the monero pool pie
https://bitinfocharts.com/comparison/monero-difficulty.html
http://preview.moneropools.com/#/pie

I wonder if the "78% Unknown" will drop heavily after the first batches will be delivered.

Shamed be he who thinks evil of it 

[Febo]

Fresh from the press
https://smartereum.com/3457/monero-price-predictions-2018-significant-appreciation-is-possible-i-usd-xmr-monero-xmr-monero-price-news-today-march-11-2018-price-news/

and this Baikal Miners + the monero pool pie
https://bitinfocharts.com/comparison/monero-difficulty.html
http://preview.moneropools.com/#/pie

I wonder if the "78% Unknown" will drop heavily after the first batches will be delivered.

Shamed be he who thinks evil of it  

Why should unknown change?  you can have asic miner in any known pool.  I don understand why are people so obsessed with this unknown part of mining pie.  Those unknown are miners as all others.  There can be miners with bad intentions on any known pool and  on any coin there is.

[bubaba]

Why should unknown change?  you can have asic miner in any known pool.  I don understand why are people so obsessed with this unknown part of mining pie.  Those unknown are miners as all others.  There can be miners with bad intentions on any known pool and  on any coin there is.

I thought when u have such a big hashrate like Baikal had(assuming they ran their miners for themselves a while) you wont join a official pool to mine with fees. Its better to make his own pool then i guess. But most of the "small" miners who are willing to buy such asic miner wont create an own pool and just join one of the popular ones, which will result in a smaller "unkown" percentage.

But this is just theory crafting ^^

[Febo]

Why should unknown change?  you can have asic miner in any known pool.  I don understand why are people so obsessed with this unknown part of mining pie.  Those unknown are miners as all others.  There can be miners with bad intentions on any known pool and  on any coin there is.

I thought when u have such a big hashrate like Baikal had(assuming they ran their miners for themselves a while) you wont join a official pool to mine with fees. Its better to make his own pool then i guess. But most of the "small" miners who are willing to buy such asic miner wont create an own pool and just join one of the popular ones, which will result in a smaller "unkown" percentage.

But this is just theory crafting ^^

oh I misunderstood. Monero will  modify mining algorithm tiny bit to confuse all that made or plan to make ASIC miners. It will happen only few weeks from now.

https://getmonero.org/2018/02/11/PoW-change-and-key-reuse.html