Bitcoin Forum
March 07, 2021, 09:47:52 AM *
News: Latest Bitcoin Core release: 0.21.0 [Torrent]
 
   Home   Help Search Login Register More  
Pages: « 1 ... 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 [2018] 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 ... 2103 »
  Print  
Author Topic: [XMR] Monero - A secure, private, untraceable cryptocurrency  (Read 4643337 times)
pönde
Full Member
***
Offline Offline

Activity: 308
Merit: 109


View Profile
January 17, 2019, 11:54:21 AM
 #40341

WE MUST propose mining algo more resistant to both ASICs and FPGAs. Could we embed for example some kind a dependence on UTC time into mining algo? The goal is to enforce FPGAs owners to justify their hardware manually every day. While honest GPU users will use UTC time from central system clock of their main computers?

Any better ideas welcome!

So when they has to manually do something for their FPGAs, the FPGAs has to be close to them, since they cannot every day travel all around? This makes impossible to rent the FPGAs all around the planet? This sounds a good idea.

But how UTC time is dealing with this? Has the manual handling to be done at very same moment for all the FPGAs in the one entity?
1615110472
Hero Member
*
Offline Offline

Posts: 1615110472

View Profile Personal Message (Offline)

Ignore
1615110472
Reply with quote  #2

1615110472
Report to moderator
PLAY NOW
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1615110472
Hero Member
*
Offline Offline

Posts: 1615110472

View Profile Personal Message (Offline)

Ignore
1615110472
Reply with quote  #2

1615110472
Report to moderator
1615110472
Hero Member
*
Offline Offline

Posts: 1615110472

View Profile Personal Message (Offline)

Ignore
1615110472
Reply with quote  #2

1615110472
Report to moderator
florida.haunted
Full Member
***
Offline Offline

Activity: 229
Merit: 125


View Profile
January 17, 2019, 05:58:28 PM
 #40342

There was a proposal from hyc for a revolutionary new algorithm, named RandomJS, that would work best on commodity CPUs. I haven't looked at it too deeply but the little that I saw I liked. Doing ASICs or FPGAs for it would be extremely hard and the results would most probably not be efficient.
I think the downside of RandomJS is that GPUs would be at a significant disadvantage, and there are lots of miners that have invested large sums into GPU rigs.
I don't know what the current status of RandomJS is, but you can contact hyc on reddit and ask him.

RandomJS is obsolete. Its author proposes RandomX. RandomX requires main computer RAM ~ 4Gb, too huge. Furthermore RandomX denies GPU mining de-facto (not only FPGA & ASIC). But almost all our honest CryptoNight V8 miners are GPU miners.
We must save the possibility of GPU mining.

florida.haunted
Full Member
***
Offline Offline

Activity: 229
Merit: 125


View Profile
January 17, 2019, 06:08:39 PM
 #40343

So when they has to manually do something for their FPGAs, the FPGAs has to be close to them, since they cannot every day travel all around? This makes impossible to rent the FPGAs all around the planet? This sounds a good idea.

But how UTC time is dealing with this? Has the manual handling to be done at very same moment for all the FPGAs in the one entity?

Actually I don't know HOW. Just my fantasies to start a discussion...

Now I think my opponents that say there are NO ASICs today despite dramatic hashrate grow - they are right. Even if they aren't - next hardfork and mining algo adjustment WILL BE this April.

My main pain is that new huge hashrate (currently 232 of 547 MH/s) doesn't belong to known pools: imagine they are Ethereum miners that switching to Monero - why they don't use existing well-known pools with good reputation?..

jwinterm
Legendary
*
Offline Offline

Activity: 2548
Merit: 1086



View Profile
January 17, 2019, 06:14:12 PM
 #40344

So when they has to manually do something for their FPGAs, the FPGAs has to be close to them, since they cannot every day travel all around? This makes impossible to rent the FPGAs all around the planet? This sounds a good idea.

But how UTC time is dealing with this? Has the manual handling to be done at very same moment for all the FPGAs in the one entity?

Actually I don't know HOW. Just my fantasies to start a discussion...

Now I think my opponents that say there are NO ASICs today despite dramatic hashrate grow - they are right. Even if they aren't - next hardfork and mining algo adjustment WILL BE this April.

My main pain is that new huge hashrate (currently 232 of 547 MH/s) doesn't belong to known pools: imagine they are Ethereum miners that switching to Monero - why they don't use existing well-known pools with good reputation?..



If you have more than a couple Mh/s it's probably well worth your while to run your own (private) pool, and avoid giving away 1-2% of your rewards as pool fees.
mattcode
Copper Member
Member
**
Offline Offline

Activity: 279
Merit: 25


View Profile
January 17, 2019, 06:53:45 PM
Merited by Hueristic (1)
 #40345

WE MUST propose mining algo more resistant to both ASICs and FPGAs.

There was a proposal from hyc for a revolutionary new algorithm, named RandomJS, that would work best on commodity CPUs. I haven't looked at it too deeply but the little that I saw I liked. Doing ASICs or FPGAs for it would be extremely hard and the results would most probably not be efficient.
I think the downside of RandomJS is that GPUs would be at a significant disadvantage, and there are lots of miners that have invested large sums into GPU rigs.
I don't know what the current status of RandomJS is, but you can contact hyc on reddit and ask him.

There's also SChernykh's CryptonightR.
Hueristic
Legendary
*
Offline Offline

Activity: 2646
Merit: 1948


Doomed to see the future and unable to prevent it


View Profile
January 17, 2019, 07:44:24 PM
Last edit: January 22, 2019, 01:54:04 AM by Hueristic
 #40346

WE MUST propose mining algo more resistant to both ASICs and FPGAs.

There was a proposal from hyc for a revolutionary new algorithm, named RandomJS, that would work best on commodity CPUs. I haven't looked at it too deeply but the little that I saw I liked. Doing ASICs or FPGAs for it would be extremely hard and the results would most probably not be efficient.
I think the downside of RandomJS is that GPUs would be at a significant disadvantage, and there are lots of miners that have invested large sums into GPU rigs.
I don't know what the current status of RandomJS is, but you can contact hyc on reddit and ask him.

There's also SChernykh's CryptonightR.

Looks good. IOU +sM

https://github.com/SChernykh/CryptonightR/issues/5

“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
Gaben.
Newbie
*
Offline Offline

Activity: 41
Merit: 0


View Profile
January 17, 2019, 07:59:49 PM
Last edit: January 17, 2019, 09:53:31 PM by Gaben.
 #40347

Heh I suppose it's out of the realm of supposition that a private cryptocurrency would necessarily draw a majority private mining base, like the kind not keen on packaging all their miners data and sending their mining data to one source or another, right?

I mean speculating on an 'unknown' mining base is the same as looking at the block explorer and trying to make a rich list without a public facing address/viewkey upload registry for the most part imo.

Sure it could be a lot of things, good and bad. Both nature of privacy and the lack of coin in the pocket more often than not inhibit the spread of information, which contrary to many beliefs does come at a cost.

Philosophically you are right. But I don't speak about Philosophy, but rather about a real "ground truth" treat like 51% attack on ETC done few days before.

Usage of unknown "hidden" pools is quite strange practice since there were a lot of ASICs and botnets in the XMR past that've used public "official" pools with great success. There is no need for someone to build "hidden" pool - EXCEPT he want to 51% attack us...



Hey what can I say .. I mean it would be a drop in the bucket if the mining algo wasn't changed and then we'd probably be talking about asics or something instead of 51% attacks but at least we kept our dignities!!1

Realistically I would prepare for the worst and expect a pretty nice re-org myself. But then again this thing forks every six months so worst case is we're down until then, after they unwind a bunch of things and we're all the more broke for it.

Either bend over for asics or get bent over by the people the asics are there to stop, kinda really only two choices when it comes to PoW and not having enough hash rate. I mean, what people are being empowered by a permanently vulnerable chain? But what do I know not enough I guess.

OK thought about it some more and:

Whereby Monero forks every six months, FPGA and ASIC miners have a direct monetary incentive to conceal their identities. Their discovery and persecution being within the scope of the current development teams initiative literally pushes them toward privacy.

This is, of course, making the assumption that they do indeed profit off of mining .. and is likely not the only assumption being made in order to come to this conclusion.

So rather than philosophically, there are tangible, real and measurable benefits to these 'non-approved' miners profiting off of the mining that would otherwise be taking place by the smaller miners.

In much the same way monero users would tend toward utilizing privacy in order to express their freedom to conduct business freely, asic and fpga miners are very likely utilizing privacy to exercise their freedom to mine profitably. Taking their mining nodes offline by [ddos, etc..] due to constant exposing of their personal data and ip addresses to the 'monero-approved network' risks for them a direct monetary penalty and a real thing that has happened before in eliminating the competition.

Still, methinks it's just the beginning of this type escalation if indeed it is FPGA's and ASIC's (which i suspect it is).

RealisticallyIdeally, the best case, in my own opinion, is to hope that it's just some hungry non-approved FPGA's and ASIC's looking for a meal.

Also the ethereum bleedover was a good point.
bobabouey2
Sr. Member
****
Offline Offline

Activity: 248
Merit: 250


View Profile
January 18, 2019, 08:09:42 PM
 #40348

Checking back into this board after a long absence...

Anyone ever hear any update on rpietila?  Despite all the problems with cryptokingdom, he was a colorful guy and pretty important to the early days of Monero.
owlcatz
Legendary
*
Offline Offline

Activity: 2478
Merit: 1465


https://1inch.exchange/#/


View Profile WWW
January 18, 2019, 08:51:36 PM
 #40349

Checking back into this board after a long absence...

Anyone ever hear any update on rpietila?  Despite all the problems with cryptokingdom, he was a colorful guy and pretty important to the early days of Monero.

His castle burnt down - https://btcmanager.com/burning-long-term-holders-bitcoin-castle-marks-beginning-new-era/

I hear he's still insane. Other than that, IDK....  🤷

Hueristic
Legendary
*
Offline Offline

Activity: 2646
Merit: 1948


Doomed to see the future and unable to prevent it


View Profile
January 18, 2019, 11:07:22 PM
 #40350

Checking back into this board after a long absence...

Anyone ever hear any update on rpietila?  Despite all the problems with cryptokingdom, he was a colorful guy and pretty important to the early days of Monero.

I think this was him.

https://www.youtube.com/watch?v=RHg8qIKJo1I

“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
kepas
Member
**
Offline Offline

Activity: 426
Merit: 11


View Profile
January 19, 2019, 10:31:17 AM
 #40351

https://miningpoolstats.stream/monero

and for now - there are more 300 MH unknown hashrate, and this is almost 50% of all hashrate

it seems that bitmain testing new CN8 asics
florida.haunted
Full Member
***
Offline Offline

Activity: 229
Merit: 125


View Profile
January 19, 2019, 10:59:18 AM
Last edit: January 19, 2019, 11:26:47 AM by florida.haunted
 #40352

https://miningpoolstats.stream/monero

and for now - there are more 300 MH unknown hashrate, and this is almost 50% of all hashrate

it seems that bitmain testing new CN8 asics

Right now : 614 - 311 unknown vs 313 known = 303 UNKNOWN vs 311 known.
-----------------------------------------------------------------------------------------
608..614..617 it is increasing every single minute...

51% ATTACK is ongoing. Summarizing all the discussion above:
Unknown hashrate ARE ASICs for almost SURE, because The Community fights against ASICs thus forces them to use hidden, unknown pools.

Honest miners are becoming bankrupts right now: The Ratio Hashrate / Price = 608 MH/s / $46 = 13.2 Mh/s/$,
BUT A YEAR AGO:
https://bitinfocharts.com/comparison/monero-hashrate.html#1y
https://bitinfocharts.com/comparison/monero-price.html#1y
The Ratio Hashrate / Price was ~650 MH/s / ~$350 =~ 1.8 Mh/s/$, and that time ASICs were NOT on the scene yet - they came in February 2018 increasing the hashrate by factor ~2 to 1GH/s (and now we observe the same factor ~2 from ~300 to ~600).

I VOTE FOR IMMEDIATE HARDFORK WITH ALTERED MINING ALGO LIKE THIS ONE:
https://github.com/SChernykh/CryptonightR

CryptonightR is normalized in hashrate as our current cn/2 and is efficient with GPUs (but much not as well with ASICs/FPGAs).

------------------

Alternative/additional way I proposed: each pool should register in XMR blockchain its signature. Each block mined should be signed by pool's signature. Unsigned or mal-signed blocks should be rejected by the XMR consensus.

This way can also count hashrate distribution among pools exactly, so the consensus may reject a block mined by a pool close to 51% hashrate.

This proposal doesn't violate an anonymity of a pool owner: just pool as web-site must be public, https certificates may be done by "Let's Encrypt" for example.
Gaben.
Newbie
*
Offline Offline

Activity: 41
Merit: 0


View Profile
January 19, 2019, 01:53:26 PM
Last edit: January 19, 2019, 02:11:45 PM by Gaben.
 #40353

Currently it's becoming more apparent by the day that there is a very well established and constantly growing movement within the community to 'keep the small miners in the mining game'. Specifically that this initiative appears to be growing faster socially than the initiative to cater toward a larger mining network is most concerning to me. This is because, while goals like keeping small miners in the game sound quite 'equalitiarian' .. or 'fair' .. in this particular instance extreme caution should be utilized. I am advising this because those who would work actively toward keeping Monero permanently vulnerable, would also share these exact same goals.

I see measures like: Only cerified pools should be allowed to submit blocks. But which pools are these? Doesn't this proposition in particular entirely ruin the prospect of an individual miner, why was this propsed?

Or like: Make a surprise fork. But using which algorithm for mining going forward? The one that appeared two months ago directly before the hashrate increase? They can't all be infinitely secure, and making too small of a change can be designed/accomodated well in advance.

Or even: Let the community vote for a surprise fork. But which community? And by which form of vote? Hashrate? The .. increasingly vociferous 'small miner' community of late?

Why, with an already aggressive forking schedule, are we hearing calls for more forks?

I just want to make the point that Monero can likely survive a (short-lived) 51% attack. But seeding the community with malicious actors speaking for the 'small miners' and having actual responses being made to protect these people by means of a social engineering attack is a very real and dangerous threat that will kill just about anything. (This applies from the top to the bottom of the 'community')

Just a few weeks ago I had to request coinmarketcap.com to change their main landing page to getmonero.org from monero.cc operating under this very hallucination.

Regardless, I don't have a miner in the game that I'd care to vouch for. Just wanted to state the obvious.

Look there's really just a few choices here that I see at this moment: Do nothing about the algorithm, Change the algorithm to avoid asics, Change the algorithm one final time. Whatever it is I don't necessarily care one way or the other just be very wary of ongoing social engineering attacks that appear to be taking root (yet again) in this community, IMO.
Hueristic
Legendary
*
Offline Offline

Activity: 2646
Merit: 1948


Doomed to see the future and unable to prevent it


View Profile
January 19, 2019, 04:47:33 PM
 #40354

Off hand and on first thought a surprise fork does not sound like a bad idea as it will once again de-incentify asic development but forced registering of pools/miners is against all crypto stands for.

“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
jwinterm
Legendary
*
Offline Offline

Activity: 2548
Merit: 1086



View Profile
January 19, 2019, 04:55:14 PM
 #40355

Off hand and on first thought a surprise fork does not sound like a bad idea as it will once again de-incentify asic development but forced registering of pools/miners is against all crypto stands for.

Surprise fork sounds like a cluster fuck for exchanges, pools, and users. Unless you tell everyone, but then it's not a surprise.
Hueristic
Legendary
*
Offline Offline

Activity: 2646
Merit: 1948


Doomed to see the future and unable to prevent it


View Profile
January 19, 2019, 04:58:49 PM
 #40356

Off hand and on first thought a surprise fork does not sound like a bad idea as it will once again de-incentify asic development but forced registering of pools/miners is against all crypto stands for.

Surprise fork sounds like a cluster fuck for exchanges, pools, and users. Unless you tell everyone, but then it's not a surprise.

I argued this plan should have been in place years ago and if it isn't already then it should be. It's not like this is a surprise, there should be a dev with the assignment of notifying all those places for just such an occurrence. It's not a cluster fuck if you are prepared. Basic security shit here, be prepared. I think they teach that to kids somewhere, oh yeah, boy scouts.

“Bad men need nothing more to compass their ends, than that good men should look on and do nothing.”
bobabouey2
Sr. Member
****
Offline Offline

Activity: 248
Merit: 250


View Profile
January 19, 2019, 08:22:15 PM
 #40357

Checking back into this board after a long absence...

Anyone ever hear any update on rpietila?  Despite all the problems with cryptokingdom, he was a colorful guy and pretty important to the early days of Monero.

His castle burnt down - https://btcmanager.com/burning-long-term-holders-bitcoin-castle-marks-beginning-new-era/

I hear he's still insane. Other than that, IDK....  🤷

Thanks.

Man, that castle went through a lot of drama, I recall an earlier robbery / water damage situation as well.  Surprised he didn't have a boat that sank as well ;-)

But I guess it is best to let sleeping dogs lie.
florida.haunted
Full Member
***
Offline Offline

Activity: 229
Merit: 125


View Profile
January 20, 2019, 09:21:56 AM
 #40358

Checking back into this board after a long absence...

Anyone ever hear any update on rpietila?  Despite all the problems with cryptokingdom, he was a colorful guy and pretty important to the early days of Monero.

His castle burnt down - https://btcmanager.com/burning-long-term-holders-bitcoin-castle-marks-beginning-new-era/

I hear he's still insane. Other than that, IDK....  🤷

Thanks.

Man, that castle went through a lot of drama, I recall an earlier robbery / water damage situation as well.  Surprised he didn't have a boat that sank as well ;-)

But I guess it is best to let sleeping dogs lie.

Sad news if Rpietila is still insane... I remember his great contribution in the community life. There was a discussion when Rpietila want to make a Monero real-world meeting in his castle... or a meeting had been done indeed?.. my memories about that discussion are dim now...
florida.haunted
Full Member
***
Offline Offline

Activity: 229
Merit: 125


View Profile
January 20, 2019, 09:48:23 AM
 #40359

Off hand and on first thought a surprise fork does not sound like a bad idea as it will once again de-incentify asic development but forced registering of pools/miners is against all crypto stands for.

I don't persist on the idea of forced registering of pools/miners. I accept any better idea with great enthusiasm.

What our practical experience show today:
1. Hard fork twice a year to alter the mining algo don't kill ASICs - they evolve faster than we think. Just 3 of 6 months passed since previous fork - and ASICs are on the scene again. Note cn/2 was designed ESPECIALLY to be ASIC-resistant compared to cn/1.
2. It is obviously a difficult task to distinguish CPU/GPUs and ASICs in terms of mining efficacy: new algo should preserve the CPU/GPU mining efficacy while be violent against ASIC mining efficacy.

I've just read about CryptonightR in more depth and I like it. It meets the 2. requirement above. Let's CryptonightR will be our first step to fight against ASICs:
https://github.com/SChernykh/CryptonightR

Any thoughts? May be somebody sees hidden disadvantages in CryptonightR?
asder250
Full Member
***
Offline Offline

Activity: 708
Merit: 103


Empowering crypto w/ sustainable energy


View Profile
January 23, 2019, 08:31:30 AM
 #40360

I am not expert about privacy coins, but many people are talking about the revolutionary mimblewimble protocol. Is Monero going to support this protocol?

Pages: « 1 ... 1968 1969 1970 1971 1972 1973 1974 1975 1976 1977 1978 1979 1980 1981 1982 1983 1984 1985 1986 1987 1988 1989 1990 1991 1992 1993 1994 1995 1996 1997 1998 1999 2000 2001 2002 2003 2004 2005 2006 2007 2008 2009 2010 2011 2012 2013 2014 2015 2016 2017 [2018] 2019 2020 2021 2022 2023 2024 2025 2026 2027 2028 2029 2030 2031 2032 2033 2034 2035 2036 2037 2038 2039 2040 2041 2042 2043 2044 2045 2046 2047 2048 2049 2050 2051 2052 2053 2054 2055 2056 2057 2058 2059 2060 2061 2062 2063 2064 2065 2066 2067 2068 ... 2103 »
  Print  
 
Jump to:  

Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!