Yes, anything that passes the input registration phase is valid.


It's probably worth a bit of logic in how the coordinator operates, ZKsnacks operates chaumian coinjoin structure, it runs through five main phases which are

Input Registration
Connection Confirmation
Output registration
Signing
Broadcasting

This could be further understood in the CoordinatorRound class

Input Registration: in this phase, the client would sent an input and a blinded output, this is where the "banning" is done.

You can see the old code was


changed to


They added a new dependency called "CoinVerifier" which is called by the "naughty" method you mentioned above, basically the Coinverfier class interacts with ApiResponseItem that gets the ban/approve from an HTTP response.

Now if you check the private asynchronous method called  Task MoveToConnectionConfirmationAsync()



so before moving to the second phase of Connection Confirmation, all the filtering is done, your coins become invalid either due to them being "naughty"  or "Invalid",  let's just assume the input registration is invalidated for no valid reason.

Up to this point, you have only provided input and a blinded output (no Sybil attack is possible) since the coordinator did not receive an output from you, and you are not yet enrolled in a coinjoin, so if they want to Sybil attack you, they would need to sign the blinded output and send it back to you

If you pass this phase, the coordinator will now need to sign the blinded output and send it back to you with a new identity/UniqueId(still no Sybil attack or its detection is possible yet)

So let's just assume it's only me and you trying to coinjoin this round, you got your inputs registered and I got mine, we both got our blinded outputs signed and received our unique-Ids, we would now enter the Connection Confirmation phase, and whereby we both send our uniqeIds to the coordinator and we both know they are valid and the coordinator MUST accept them.

If the coordinator were to reject my connection confirmation it would be safe to assume that they are launching a Sybil attack against you (of course I don't know whom they are launching the attack against but having refused my connection while I have a valid unique id the proves that I have registered x input means they are doing the attack), there is no VALID reason for them to refuse my conn-conf, it should be accepted and after the timeout we need to move OutputRegistration phase, you can check the code to find that       Phase = RoundPhase.OutputRegistration; doesn't have any valid conditions of which they can reject you for "no reason".

This applies to the rest of the phases, if the coordinator accepted your input registration -- there is no valid for reason them to stop you from going forward, I am not saying they "can't" of course they can reject your connection confirmation or even claim that your output registration was invalid, they can even claim that you did not register your input to start with, but given that the code is open-source it MUST act as it says it does, otherwise, people/observers would see that they are being refused for no reason which means the code which is run by the coordinator isn't exactly what they say it is and/or, they are trying out some attacks.



Note that I am talking about the possibility of the coordinator using the power that other attackers don't have to perform sybil attack, what you described in your previous post could be achieved by anyone, I know the maximum number of inputs in each round is x, I can register x inputs and perform the same attack, in other words, this could probably be applied to all conjoins coordinators not just ZKsnacks, so not sure why is this an exclusive criticism for Wasabi?



Round ID, Input count, current phase, time to next phase are all publically available, your claim would be valid if you register two inputs to the same round and they end up in different rounds, otherwise, how do you suggest doing that without anyone noticing? obviously, most users don't check all this info and just use the next GUI and set their auto-conjoin, but don't you think there are enough people (Wasabi rivals for example) logging every round detail to showcase how Wasabi is doing all of these claims? besides, whatever you suggested could be applied to all other Coinjoins that use a centralized coordinator, which is why I said "let's keep criticism" fair.

My main issue with Wasabi is the fact that their default coordinator and funding firm ZKsnacks censors transactions for no valid reasons.

Source: https://blog.wasabiwallet.io/zksnacks-blacklisting-update/

It's similar to banning mixers on this forum, except that banning mixers doesn't fuck with Bitcoin fungibility.



It's always doable, I am just not sure about how feasible if enough people are observing these rounds and actually are spending time and money to detect such attacks (mainly their competitors), if you see all the research Samourai Wallet team does on Wasabi, you would probably guess that there are enough people watching them, of course tho, just because nobody caught them -- doesn't mean they have never done it.

if the number of inputs exceeds the maximum number set by the coordinator which I think is 400 for their new protocol, the coordinator would automatically arrange another round.

But then we really need to reach some ground on defining the purpose of sybil attacks, be it those done by outside attackers or the coordinator itself, the point of sybil attacks in a coinjoin is to bring the anonymity set for the victim to 1, it's the only possible way to link x input to y output -- otherwise, the attack would only reduce the anonymity set/score.

The coordinator could certainly force you into a conjoin that has 399 inputs it owns and 1 is yours, but that means, there will be a coinjoin for every "real" participant, while that is doable in theory, it would certainly raise the flag (you can register 2 different inputs and see if they end up in different rounds every time you do that).


Also, round status is publically available through Wasabi API, you can acquire the current input count, if the current round is at the input registering phase and has 50 registered inputs, and then you try to register 2 different valid inputs and they end up in a different round, you know they are doing something fishy.

Obviously, if they have a targeted input (or a few of them) to which they want to link -- then that would make sense, and they could be doing that already and manage to hide it but a full-scale Sybil attack is just not feasible IMO.



timestamped proof? not sure,  A proof, yes, the coordinator creates Tor identity at input registration, obviously the person who receives it knows the time at which they received the credential, I don't think they can prove it to someone else.

With that said, I am not claiming Wasabi don't/won't do any of that, I am just stating that it would be very difficult to hide a sybil attack, besides, Wasabi doesn't need any more criticism, you make chain analysis scums richer every time you use it.

I feel like we are talking about different things, sybil attacks in Coinjoins are pretty useless if you are not the coordinator, if you want to attack me you need to guess the exact round that i would be joining + stop others from joining the same round or in other words make every other participant (you) which I can't think how would it be possible.

If you are indeed the coordinator then you have got an edge, you could simply reject all other users in the round I am joining and the attack will work, but again, doing that would be obvious because other users who have valid inputs will be rejected for no good reason and that would indicate the coordinator is attempting the attack.

Sybil attacks on the p2p network are different, since other nodes won't care if your node is rejecting them or has gone offline, since there is no central coordinator the whole thing is different.  

That would also be detectable, the minimum number of participants is 100 in a single round, and the timeout IIRC is 60 mins, unless the max figure is reached, I can't recall all the details but to make a long story short; the number of coinjoin rounds are guessable, a scenario like the one you described would make the number of successful rounds exponentially large.

Furthermore, you could use two identities at the same time and see if they end up in the same round or a different one, it would be pretty obvious for anyone observing wasabi to spot such an attack.

Besides, depending on your anonymity set target (they changed the name and the math behind the score but logic still applies) the coordinator would need to prepare all kinds of different input sizes to attack everyone, it is not feasible.

One way they might attack you is by signing the blinded outputs using a different private key, of which then they can brute force the number of unblinded outputs to figure out which input belongs to what output, I am not sure how Wasabi/GovSnacks prevents such attacks.

Just to keep fair criticism here, sybil attacks in coinjoins are easily detectable, in order for the attack to work efficiently in deanonymizing a certain input -- the coordinator needs to refuse connection confirmations from all other participants, so if your input has not been spent before and the coordinator rejects your connection it's safe to assume that it's preparing for a Sybil attack on an input it identified earlier in the current round.

Obviously, at this stage, it's hard to tell if enough adequate users still use Wasabi to spot sybil attacks.

doge would be used by the broke folks; the rich ones will stick to BTC. Also, ordinals on BTC are somewhat different since they are associated with a particular Satoshi that is thought to have some intrinsic value that most people don't see  . I think these folks will come back again to BTC to pay another visit when a new wave of madness forms up. Ordinals on BTC will be like TikTok trends; they would be most active during bull markets when BTC is making new highs and is getting more attention in the news. Then they fade, wait for another wave, scam a few dozen greedy folks, and fade. Rinse and repeat until people find a new way to make value out of thin air.

It's great that you acknowledged your mistake instead of denying it. I don't like to discourage newbies, but I understand why ABCbits or anyone else might be annoyed by this. Bad advice is worse than no advice, especially when it could potentially lead someone to lose money.

If you want to help others, it's important to first acquire knowledge and once you have mastered a particular topic -- feel free to offer help. Additionally, I personally don't think using AI is inherently a terrible thing to do. It's how people use it that determines the outcome. If your English isn't the best or you struggle with constructing proper sentences and simply want AI to assist you in that regard, I believe it's entirely normal. Tools like Grammarly serve the exact purpose, however, what is not acceptable is copying someone's question into an AI website and then blindly copying and pasting the answer.

Well, that is the normal behavior at certain times, the power won't feed into the chips unless commanded by the control board, which is why you can't do the voltage testing using just the stock control/firmware, the fixture tools do that for you, they sent continues voltage so you can test the voltage without a rush, otherwise, the stock control board would only feed the voltage in the initial test and then stops, the official Bitmain fixture tool sold by Zeusbtc isn't that great in that aspect too, you only get a few seconds to test (better than stock of course), there is another tool that ships from Russia (or at least used to) I think the official website is https://tester.asic.repair/en, this one is a lot easier to use and gives you all the time you need to test the voltage.

With that said, I think this goes beyond just understanding how to use the tool, fixing hashboards needs some general understanding about electronics, if you don't have that -- it would be hard to fix them.

I want to be fair to BraiinsOS+, personally, I have not tried to mix and match 17 series hashboards using their firmware, I see people claiming that it's the case and that BraiinsOS doesn't even read the EEPROM but I can't confirm it, however, I have personally tried Vnish to overcome this mix-match issue and I can personally confirmed that it worked.

With that said, how are you sure that it is not fixing the compatibility issue, for all we know, the ones that don't work, might just be dead, to confirm that this isn't the case you are going to have to run them individually, i.e a single hashboard plugged, the only way you can come to a conclusion that the firmware isn't fixing the compatibility issue would be to have 2 (working) hash boards running together, if they don't work smoothly then you know it's a compatibility issue, of course, provided that you know the PSU is good and is capable of running more than 1 hahsboard.

Also, it would be great to comment on their topic, they have a representative here who is very knowledgable in that firmware aspect, and should confirm wether their firmware indeed fixes the issue, if I had to guess, I'd guess it does fix the problem and whatever results you are getting are caused by other issues.

Unless they intentionally mixed them to brick them -- the above makes no sense, he is not being honest, chances are the majority of them are dead due to bad solder.

With that said, if you are going to buy 100+ of them you should buy the zeusbtc tool to write the same file in the EEPROM.

My personal advice to you is; unless they are dirt cheap and you have someone to fix them for cheap at your local area, do not buy them.

The forum has thrived for years without signature campaigns, and it will continue to thrive; the use of the word "die" is an exaggeration.

That being said, forum activity will indeed be affected. Think of the forum as the final blend of several ingredients, including:

-Content
-Signature Campaigns
-Marketplace
-Bored individuals
-People eager to learn
-Individuals showcasing their knowledge
-Boosting self-esteem through ranking up or earning merit

These ingredients contribute to the overall forum experience. When you add, reduce, or remove any ingredient, the forum's overall dynamics are certain to change. The perception of whether the forum has changed for the better or worse depends on individual views.

Personally, I believe signature campaigns are a vital component of the forum's overall performance, especially for high-quality members. If someone excels in a particular area, they may prefer not to contribute for free. Instead of starting their own blog or YouTube channel, they might choose to share their expertise here. Without the incentive of earning something for their valuable contributions, the forum risks losing not only traffic but also valuable content.

Your miner status page is your company portal, where you log in and they tell you, your salary is going to x, the pool page is your bank account, it's the actual $$ you are going to get, It's a funny analogy but whom would you trust more?

It's possible that the status page on that firmware is broken, but it doesn't matter, always check the status on the pool page, if your daily hashrate is within a reasonable range of 1-2% in the span of a few days then you are good.

if your hashrate is 100th, idealy it would show as 98th on the pool (- the 2% fee of BOs+) so anything in that 98th range +-1-2% would indicate an overall "healthy" mining.

It's doable but it would cost a lot, all modern miners (Whatsminer and Antminer) consume roughly 3000w, running them with a single hash board on stock speed gets you down to 1000w, and with some underclocking you get to 600w pretty easily, on Whatsminer you would set your power limit to 1500w, this will allow each board to use nearly 500w, removing two boards gets you down to 500w, if we talking M30s+ 1500w would get you down to roughly 55TH, you take two boards out you end up with 500w and 18-19th.

Using M60 would get you nearly double that hashrate with the same power consumption, the only issue with this approach is you are going to have to pay for the whole miner, i.e the total hashrate, M60 would be roughly 4.5k M30 would be in the 1k range, maybe 1.2k including shipping, so you are going to buy 18TH for 1.2K which is certainly isn't great if you ask me.

The same 3 years old answer still stands, you can't mix and match different hash boards from different 17 series models unless you get very lucky, you either flash the eeprom or use firmware that doesn't read it all, if you are having trouble installing BO+ then visit their support thread or use another custom firmware.

STOP! Don't get those servo voltage stabilizers; they will most likely not work with your electricity. More on that later, but before I go there, I need to explain something that the "seller" did not.


He is lying or knows nothing about what he sells. There is no way in hell you would get 20KW from a 20KVA transformer; you need to break physics to achieve this. So don't listen to him and always assume a power factor of 0.8 to 0.9, which is a loss of 10-20%. The best this thing would give you would be 18KW, although I doubt that.

The second point is when you see a regulator/stabilizer rated at 20KVA, it means that is the possible output when the input voltage is at whatever the device is rated. So if it outputs 220v, then you must supply it with 220v for it to achieve the maximum capacity. Going under 220v on the input will decrease its capacity. This, of course, depends on the make of every stabilizer, but here are some average figures from a top Vitmeness brand that probably beats whatever you found.

For a 220v rated device, you get 100% capacity down to 200v.
At 175v input, you get 75% of the rated capacity.
At 150v input, you get 50% of the rated capacity.

So going with the assumption that your input voltage would drop to 150v, then to be safe, you would need to do the following calculations:

20KVA to KW = 16KW (PF of 0.8, which is probably what it is for whatever brand you posted above).
At 150v, a loss of 50% gives you 8KW total, and that would be fully exhausting it. So you might want to drop another 10-20%, and that gets you down to 7KW max.

Now back to why "not" use a servo voltage stabilizer:

This type of voltage stabilizer is "slow to react," and it's best suited for places where input voltage is low and is always low, i.e., not variable, doesn't change every minute or so. Given that every time it reacts to a voltage drop, it will likely cut the power to your miner.

Key word is: steady input voltage

If your power is not stable and constantly changes, you will have to get a static stabilizer. Without going into much info, I would just share this video for you to learn the differences:https://www.youtube.com/watch?v=xbf_nQYZhbs.

@phill, thanks for recommending me; it's always a great pleasure doing business with you.

I believe this test is inaccurate, setting your clock forward into the future would not affect how your node verifies new blocks since all those blocks are still in the current time,  however, if you use getblocktemplate to create a new block with nTime = 4419702898 which corresponds to Monday, January 20, 2110 11:14:58 PM and is 33 bits, other nodes will reject your block.

Setting it to 2040 would also fail but not because of the UNIX time since nTime in block.f is declared as unsigned int which won't overflow post-year 2038, but because the block timestamp will be greater than 2 hours of the median time from the network-adjusted time, but then you may go around this by broadcasting the block to another node you have after changeing the MAX_FUTURE_BLOCK_TIME to some large value that would make a 2040 block valid.

Pull #26259 contains a test for 2106 block timestamps, have you tried it?

Not sure what miners have to do with this, miners gained nothing out of the ordinary with this inscription, that person paid the average fee rate of 40~ sats/Vbyte, the data he inscribed was large and thus he had to pay a lot.



It's really funny how everyone views things from a different angle, but tracing this output back to this origin you can see that it goes back to this Coinbase transaction


This dates back to 2010-04-16, and for some reason, some people think that the coins that were created back then are somewhat special, it's like those coin collectors who pay a premium to get an ancient coin from the Roman era or something like that.

The person who inscribed this ugly image is probably pretty smart and business-oriented, he got his hand on an old "satoshi", attached an ugly image to it and will probably sell it for a few 10x profit to some greedy person who thinks they would be able to sell it for 5x to the next person and the chain keeps on building until the last person realizes that nobody wants to buy his expensive shit, or maybe not!.

Why are you addressing your own wallet as "Bitcoin"?

I have followed the debate very closely, and have read most of your posts and Leo's, he never criticized Bitcoin or Coinjoin privacy, and he explicitly criticized your wallet's address reuse and its association with chain analysis, since you can't be a gentleman and show sympathy to someone who is very sick, the least you could do is not accuse them of something they never did.

I was here before the new trust system was introduced, but true, not for too long. However, I witnessed the current trust system long enough to see how it isn't working as intended. There is a distinct difference between "working" and "working as intended," and I explicitly stated that I disagree with "working as intended."

Reading various comments and posts from Theymos, it's evident to me that he expected the majority of members to participate in the voting so that the default trust list would be a good representation of what the majority of members would agree on. Obviously, this isn't the case now because only a small minority of "active" members participate in the voting. What's even worse is that the vast majority of DT members prefer to walk in the shadows and not exercise their votes to exclude bad actors because they fear retaliation.


It depends on who is looking at it, to someone who had to delete a post they made in the P&S board to get a tag removed by a DT member -- it's certainly terrible (real story).


I don't think theymos takes our opinions too seriously . He does what he has to do even if the majority were to disagree. I think that at some point in the future, we could wake up to a new trust system. But until then, everybody's best weapon to fight abuse is to get involved in the trust system and, obviously, grow some balls.

This is what I love about Theymos. Once he establishes the rules, he abides by them. He's like the guy who brings the football to the street game but doesn't insist on being the team captain; he plays just like everyone else. I still remember his "clash" with Lauda and how they both utilized the exact same tools to battle each other -- lobbying and persuading other DT members to exclude the other person (anyone who was a DT member at that time probably still has those PMs).

Theymos could have easily wiped Lauda's forum history in 5 seconds, but he chose to use only the tools Lauda had access to as well. Can you find a better or fairer administrator? Probably not.

The issue here, however, is this:


I disagree, however, that the system is working as intended. It's evident that he expected too much from the community -- a system where the majority of members would participate, and thus the end result of the DT status would reflect what the majority of people want. However, after all these years, it seems like only 1% of the forum members participated in the system. This resulted in a small minority of people obtaining the DT status, turning it into more of a privilege than a responsibility. It's the "cool guys club." Eventually, some people started abusing it, and because only that small minority of people engage in the voting, it became close to impossible to stop anyone from abusing the system. Hence, we have all these complaints. Of course, I wouldn't say it's completely useless, the trust system itself is a great tool. I just think the DT list shouldn't be there, and everyone must create their own list.

Obviously, Theymos doesn't think that the current level of abuse is significant enough for him to change the rules. But eventually, as more people start complaining about the unjust use of the trust system, he will likely come up with a different plan, or at least, that's what he usually does, fix things.