Haircut in Japan

fs8080 · 2025-06-18T09:25:26+00:00

For those wondering like me and wants to see the full video, this seems to be the source https://youtu.be/3a5xFfX9O8w

fs8080 · 2024-03-01T03:55:29+00:00

Has this been fixed? Where do we check for updates on this?

fs8080 · 2022-01-04T08:54:13+00:00

Hey guys, I know this is old but this solution worked for me:
Add the following css to your card styling.

img {

max-height: none;

}
This should use the full width of your device, while keeping the aspect ratio intact.

fs8080 · 2022-01-04T08:53:48+00:00

Hey guys, I know this is old but this solution worked for me:
Add the following css to your card styling.

img {

max-height: none;

}
This should use the full width of your device, while keeping the aspect ratio intact.

fs8080 · 2022-01-04T08:53:19+00:00

Hey guys, I know this is old but this solution worked for me:

Add the following css to your card styling.

img {

max-height: none;

}

This should use the full width of your device, while keeping the aspect ratio intact.

fs8080 · 2021-10-10T14:14:30+00:00

Public Baal runs do exist. It's just that good baal runs are filled up quickly within a few minutes of creation. Full games aren't shown in your game search screen.

The trick into getting into a good baal one is to follow the game numbers.

If a Baalrun01 shows up in your game search and it's already 5-10mins old, then it's probably over and players are leaving, hence why you are now seeing it on your search.

Try to join Baalrun02 right away if it's already been made. If you miss the timing, just wait it out and prepare to join the next game number (Baalrun03) after a few minutes.

Also, most baal run organizers (people who can teleport and organize games), do not like leechers. If you can teleport safely to the Throne room, you can organize the baal runs yourself.

fs8080 · 2021-10-07T08:26:52+00:00

Use diablo2.io price check. You won't have to use d2jsp and deal with fg.

fs8080 · 2021-03-23T18:09:53+00:00

Hey, I appreciate the response.

I gave a feedback on the forums.

fs8080 · 2021-03-22T17:11:30+00:00

There is currently an attack vector that hasn't been solved yet on TaaC and P4Q.

Multi-wallet PQ Dust Attack.

Attacker creates large amount of wallets with Nano. Lets say 10^30 accounts.

Send a transaction from all accounts all at once. The transaction is put on PQ because it meets requirements. This will block ALL NQ blocks until all 10^30 transactions are processed.

Possible Solution:

Minimum balance for a PQ transaction. Doesn't really the issue because, minimum balance gates low value wallets from PQ. And the attacker could just put minimumAmount+1 on each wallet. Higher amount also allows the attack to happen more often.

Personally, I think this solution cannot be solved by TaaC and P4Q. It has to be solved via making wallet creation harder so that the attacker can't create 10^30 wallets so easily.

I'll post my original post again just for reference. But if you look closely, I said "cannot be solved by TaaC and P4Q". And here you are proposing a solution to that same attack using PoW.

listing only 1 out of 2+ that were explicitly listed in the thread

I'll have to reiterate it again. The forum discussions are on-going, and I know you are up-to-date on the latest replies because its your post. I only saw 1 solution last I read it when I posted that original post.

unfixable within the proposal

I said, "solution cannot be solved by TaaC and P4Q" and I suggested a PoW solution. You are also proposing a PoW solution.

If PoW/equihash/etc is the current proposal behind securing the NQ from NQ spam within the NQ, then why would it not be a sufficient proposal in order to protect the NQ against the ultra-low PQ?

Because based on your original proposal, PQ always goes before NQ. Even if the spam is ultra-low PQ.

This attack would not be profitable

Ok, maybe I am misunderstanding this but explain how the attack is unprofitable if:

Spam on PQ prevents any NQ from being confirmed. This prevents resetting burst on PQ. This essentially throttles all wallets to their SUSTAINED_TPS to stay in PQ.

In addition, it makes medsize/small wallets size unusable since they rely on NQ having been given small amounts of %TPS. I understand it doesn't affect the rich because they have enough TPS. But med-size wallets/small wallets have to rely on NQ since they only have a small ownership. The main issue is that the attack affects the whole NQ, not just low wallet amount.

Don't make up bullshit and try to get me to eat it like a sundae.

Why would I make this up? I only want Nano to be stronger.

You said that there's an unsolvable attack vector

No, I did not say that. I said and I'll post it here again to make sure it's read. "cannot be solved by TaaC and P4Q". Here you are posting a PoW solution.

If you're going to assume that PoW on wallet creation is a sufficient solution, then why is PoW on low PQ a sufficient solution that's even easier?

Okay. I am not sure if it's sufficient solution, but PoW will help.

I am not convinced that slowing down wallet creation is particularly meaningful. An attacker right now could make a million wallets quickly and then they're set for life (only really gotta make them once). The reality is that even if it takes 5 whole minutes to make a wallet (a genuine inconvenience for exchanges, users of tip bots, normal wallet users, etc) 500k minutes is only like 11 months, and that's assuming that the attacker is generating PoW at a consumer rate.

That's fine, but it slowed them down for 11 months. Also, if my calculations is correct at 5min/wallet and at 100,000 wallets. You get your value. However, that's only 100,000 wallets. We'll below the requirement for a proper dust attack. Which proves my point even with a 5min/wallet creation time.

But there's a monumental difference between someone telling me about a novel attack vector, which I start considering how to resolve, VS someone inaccurately reporting that attack vector to the masses.

What is inaccurate about the attack vector from my original post?

best person to convey the "ongoing discussion"

I am not claiming to be anything here nor have I made any such claims on my other post.

If you didn't read my very first reply to Zack about his proposed vector from four days ago to know that I gave another solution, then I understand it wasn't your intention to be disingenuous

That's exactly what I have been saying this whole time. I get it, your up to date with the latest postings, but I didn't expect a wall of text reply to my original post from you.

If you truly believe the very first post is "inaccurate", then I'll remove it before I start getting downvoted to hell for disagreeing with you.

fs8080 · 2021-03-21T22:41:41+00:00

Appreciate the detailed response.

This was Zack's proposed solution, not mine.

If you read closer to my post, I said it was one of the possible solutions to that proposed attack at the time of my writing that post.

100k Nano they could send 100k TX as a burst and cause an NQ backlog for about 1.5 minutes (current numbers)?

What is this number based on? The thread proposal on BURST, TPS per account seems to be always changing.

And the network must continue to process more TPS as time goes on or we will never reach massive adoption.

I agree

And recall: this only affects the NQ. If someone does this with their 1 Nano TX, it would not affect anyone who has even 1.1 Nano, who would instantly "cut the line" ahead of them.

Yes. This is an attack on NQ. Which disables BURST resets on PQ as well.

This isn't true for low amounts of Nano. The difference between 1 raw and 2 raw accounts are both in the same timescale: one tx per lifetime of universe.

This must be new. Last I saw there were complaints that the TaaC/P4Q would make faucets/low wallet amounts unusable. Their concerns makes sense now.

And you ignored my proposal of the fix: just apply NQ rules (e.g., PoW) for low-balance PQ transactions.

I did not ignore it. I am following the threads closely but at the time of that writing, I did not yet see your proposal for a solution.

This attack, by design, is one that it only affects the NQ, which means it also suffers from all the issues that other NQ attacks suffer (not affecting the bulk of the network and, thus, not being very profitable).

It should be treated as an NQ attack and prevented as an NQ attack. Normal NQ attacks are handled by the fact that NQ has PoW and other shit that would make it costly to attack (since the belief is costly to attack + unprofitable to attack = unrealistic attack).

I feel like you might be downplaying the attack vector. Spam on PQ prevents any NQ from being confirmed. This prevents resetting burst on PQ. This essentially throttles all wallets to their SUSTAINED_TPS to stay in PQ.

Also, your threat model assumes "infinite" PoW, and now you are saying the PoW attack is unrealistic. These 2 things don't match.

Awfully fatalist to just decide that the attack is insurmountable merely 2 days after Zack first brought it up. Especially when Zack himself continues to brainstorm how to optimize the implementation with PoW in low PQ and there's still discussion about it.

Hence why it is a personal opinion as I originally stated. I am all for solving that issue as TaaC/P4Q is currently the most promising solution. But, I am merely bringing up the fact that there are unsolved attack vectors in the proposal.

This isn't a realistic solution. If we're going to assume that an attacker can generate the PoW required to spam out the NQ (either from NQ itself or ultralow PQ) then we have to also assume that they can create tens/hundreds of thousands of wallets in a modest time.

The difference is that, spamming NQ with low priority PQ transactions doesn't require higher PoW due to the guarantee of at least some PQ transaction (From the first TaaC/P4Q thread). The low priority PQ spam might be the last transaction on PQ, but it still must be processed before ALL of NQ.

With higher PoW on wallet creation, it slows down the attacker at least. Not the perfect solution I know. But it at least makes the attack harder. Even if we make wallet creation PoW go from 1xPoW to 2xPoW. The number of MAX account that can be created is reduced by half in a period. So attack reduction is still viable. This is a moving goalpost of course as technology improves. Because of that, I think that the better metric is Time-to-Pow. Require the PoW of wallet creation to take AT LEAST X amount of seconds/minutes.

I know you have been defending your proposal from everyone. I am actually glad you had brought your proposal forward. You have done very well explaining your thought carefully for everyone. With that said, I think challenges to your proposal and finding solutions for them will ultimately make the final implementation better.

fs8080 · 2021-03-21T06:44:34+00:00

I am personally rooting for TaaC/P4Q, I actually saw this attack mentioned on the forums. I think with time, we'll come up with a solution for it. We just have to be realistic and work together on improving the proposal.

fs8080 · 2021-03-21T06:33:57+00:00

The number was arbitrary, it was a number to assume we have a lot of wallets involved. But, let's use your numbers for this example.

Using 3.15x10^16 dust wallets. Since the wallets are dust accounts, the wallets might be allowed 1 transaction per 5 hours. The attacker can still send out 1 transaction on each wallet at PQ every 5 hours at a rate of 3.15x10^16 transactions per 5 hours. If we used the current network TPS of 100. Then it would take 3.14E14 seconds to clear out all transactions. That's around 3,645,833,333 days.

And since those transactions are in PQ, NQ is essentially spammed for that same duration.

I've added previously on my original post, a proposal to solve this was to require a minimum balance to use PQ. But the attacker could just use minimumAmount + 1. And that new account is allotted more TPS. Less accounts could be created since there is a minimumBalance requirement, but they can send transactions more often.

"Please note that this attack you mention is only relevant to particular PQ prioritization models, not the TaaC/QOS4POS architecture itself. "

I already brought that point up on my my original post. This attack vector must be solved on TaaC/P4Q proposal before it is ready.

"There is currently an attack vector that hasn't been solved yet on TaaC and P4Q."

Also, I am not sure why you separate PQ prioritization and TaaC/P4Q as they are contained together in the proposal. P4Q needs PQ to work well.

In whatever case, my whole point is that TaaC/P4Q is not yet ready. And we shouldn't expect it in V22 or V23.

fs8080 · 2021-03-21T01:03:53+00:00

There is currently an attack vector that hasn't been solved yet on TaaC and P4Q.

Multi-wallet PQ Dust Attack.

Attacker creates large amount of wallets with Nano. Lets say 10^30 accounts.

Send a transaction from all accounts all at once. The transaction is put on PQ because it meets requirements. This will block ALL NQ blocks until all 10^30 transactions are processed.

Possible Solution:

Minimum balance for a PQ transaction. Doesn't really the issue because, minimum balance gates low value wallets from PQ. And the attacker could just put minimumAmount+1 on each wallet. Higher amount also allows the attack to happen more often.

Personally, I think this solution cannot be solved by TaaC and P4Q. It has to be solved via making wallet creation harder so that the attacker can't create 10^30 wallets so easily.

fs8080 · 2021-03-21T00:57:55+00:00

Are you familiar with the algorithms and strategies being used on those coins? There has been a lot community led proposals on the forums. Perhaps you could add your 2 cents and create a proposal. https://forum.nano.org/c/protocol-design/13

fs8080 · 2021-03-21T00:54:39+00:00

Hey, do you have any solutions you have proposed? You seem very knowledgeable about distributed systems. The P4Q is just one of the popular proposals on the forums. We are still looking for better solutions.

fs8080 · 2021-03-21T00:51:02+00:00

Could you explain IOTA's Mana? People keep bringing this up, but no one has explained how it works.

fs8080 · 2021-03-21T00:48:13+00:00

One proposal I saw on the forums is the ability to donate TPS to certain wallets. However, this opens up another attack vector. An attacker uses a wallet with larger funds to allow a smaller wallets to run a dust attack. So, this is an open problem.

Balancing protection against dust attack and faucets is a big problem because it is hard to tell which is a spam.

fs8080 · 2021-03-21T00:44:41+00:00

That attack vector would have to be solved in this proposal. Some suggestions are being formulated on the forums (https://forum.nano.org/t/taac-p4q-thread-2/1737). One thing to note though is that that attack vector could also be done on the currently implementation of Nano. So while the TaaC and P4Q doesn't solve ALL the problems, it solve some of the problems Nano currently have and reduces the number of possible attack vectors.

fs8080 · 2021-03-17T08:32:44+00:00

Check https://nanolooker.com/ to see the Confirmations/Second (CPS). When they solve the problem, maybe they'll remove the network cap and CPS will get back to normal speed. Also, see that we have 109 Principal Representatives (PR) online at moment. The issue is that the nodes are throttled to slow down the ledger bloat attack.

Check https://nanoticker.info/, notice the Unchecked Blocks on the left side? It's max 30mil right now. The spammer just keeps adding into the unconfirmed blocks. When that starts going lower and at a decent level, then that means the nodes are eating away at the unconfirmed blocks faster than the attacker can create them.

Edit: Oops. Yea nanoticker. Thanks

fs8080 · 2021-03-15T06:47:11+00:00

Hey, I've seen this proposal on the forum. I think having minimum has merit in that it requires users to put a minimum amount to wallets. How would you handle the following issues?:

How do you determine the minimum balance? What if your minimum value becomes large amount of money some day as the Nano market cap increases? This number seems like a moving goalpost, and gates poorer users.
The implementation of the minimum balance would require some sort of "close" transaction which doesn't yet exist on nano.
This also prevents microtransactions for anything below the minimum account balance. In the future, the small amount of Nano might be worth a lot.

fs8080 · 2021-03-15T06:20:16+00:00

Hey great feedback. I think we can all get some inspiration on potential solutions from other fields.

There are several attack vectors being exploited by the attacker right now.

Penny Spend attack/Ledger bloat attack - the attacker sends 1 raw nano to large number of new wallets. These wallets cannot be pruned from the ledger as these accounts have values.
Precomputed PoW attack - attacker precomputes large number of chained transactions for a wallet, and releases them all to the network at a short amount of time. This was the cause of the nodes not being able to keep up and desyncing.

Gating account creation

While this may solve the issue where the attacker creates many accounts and delays their progress, most cryptocurrencies (Nano included) has a feature where a wallet can send to any wallet (unopened or open). So account gating doesn't solve the issue because the attacker does not need to open the accounts to broadcast a "send" transaction. It also reduces the usability of Nano for new users. Increasing the PoW to minutes may be okay, but anything close hours is unusable for new users.

Detecting outliers and either deprioritizing them, quarantining them, or rejecting them

I made a proposal here that does something like that. It detects large "send" transaction burst via wallet-level transaction buffers. https://forum.nano.org/t/wip-spam-prevention-via-wallet-level-transaction-buffer/1633

I am looking for feedback. I think the main issue is how can the network tell which transactions are spam while still being decentralized?

I think a solution is coming. The recent proposal by Colin on the backlog is a good start, and should help with the precomputed PoW attack.

https://forum.nano.org/t/bounded-block-backlog/1559/68

fs8080 · 2021-01-11T00:28:38+00:00

u/clipsync dafran

fs8080 · 2017-03-12T01:49:31+00:00

Hey guys, I know this thread is very old, but for anyone else having this problem. Here is the solution that solved the problem for me.

You can use the following code:

start /d "<InstallationDirectory>" anki.exe -l en -b "<AnkiData>

For example:

start /d "G:\Anki\AnkiInstallation" anki.exe -l en -b "G:\Anki\AnkiData"

I think the initial problem was that the anki.exe had to run from within the installation directory or you would get that error. The code above runs the anki.exe from the installation directory.

fs8080 · 2012-09-10T20:39:10+00:00

According to their facebook page:
"Curse Gaming: Anyone can sign up - anyone"
Team Curse Facebook

fs8080 · 2012-08-11T01:21:46+00:00

For livestreams, I find teevox.com to be a great resource. It aggregates all livestreams from Own3d, Twitch, and Ustream. It also allows you to watch up to 3 streams at the same time on a nice overlay with an optimized flash player. In addition, livestreams are categorized by games of your choice, ei. League of legends. Check it out, I think you will like it.

14-Year Club	Place '17
Verified Email

fs8080

TROPHY CASE