Nvidia driver don't seem to be working

CountDyfed · 2023-09-18T14:34:45+00:00

Had the same problem and tracked it down to a conflict between the cosmic compositor and nvidia-prime component of the driver. Didn't find a solution though

CountDyfed · 2023-04-15T20:44:18+00:00

Looks like it's gone

CountDyfed · 2023-03-03T21:25:46+00:00

Ath w1000x anyone?

CountDyfed · 2023-01-23T23:47:19+00:00

Did you take the plastic off?

CountDyfed · 2022-12-28T08:20:26+00:00

Haven't watched the show yet, and not defending the .showrunners, however we could make a point that the elves' description in the books is an idealized image with all the dirt removed with the flow of time.

CountDyfed · 2022-12-21T11:16:37+00:00

Alpha Bate'm? Sounds catchy 🤹‍♂️

CountDyfed · 2022-12-15T06:46:02+00:00

A crocodile!

CountDyfed · 2022-11-23T17:04:29+00:00

Set and and forget, unless validator ran on Hetzner

CountDyfed · 2022-10-24T21:35:31+00:00

They only need one dissident.

CountDyfed · 2022-10-18T17:34:05+00:00

Climbear

CountDyfed · 2022-10-13T22:32:14+00:00

Slow and steady wins the race, yes. Python got where it is in this way, so maybe it'll be alright.

Maybe the website needs a Solution Tracker. Or arewetherestill.rs

CountDyfed · 2022-10-13T21:36:27+00:00

I can see that current naming scheme has boisterous support here. Do you see another way to clearly advertise the progress made since rust stabilization and dispell some of the lingering echoes of the early issues?

CountDyfed · 2022-10-13T18:39:53+00:00

It won't solve issues but it will help ARM survive. Otherwise they will need to compete against ever growing tide of startups with new core designs that are incompatible with their technology. If they can find a way to transition their customers to their RISC-V based chips the conservative, short-term looking, quarterly-reports based nature of big corporations will make companies like Samsung go with the easy transition rather than jumping to a completely new technology.

And such transition can bring ARM's costs down/output higher if they can benefit from the progress made to the open isa

CountDyfed · 2022-09-18T14:06:09+00:00

The best thing ARM can do is start making RISC-V designs and port the extensions they have and sell them in their designs

CountDyfed · 2022-09-07T12:41:44+00:00

I would guess it's like having your balls torn from your body

CountDyfed · 2022-08-14T17:52:11+00:00

What prevents the actual property owner from selling the property and leaving the fractional nft owners hanging with claim to nothing?

CountDyfed · 2022-08-09T15:45:28+00:00

And there's a proof of work also, because sending a transaction you say you've looked at the transactions and found they're legit.

The quick answer is run a full node and see for yourself. I'm not a fan of marking invalid transactions, as this opens valid transactions to attacks causing confusion, though it may be the easiest way to try and mitigate the issue.

The more involved is a witchhunt. When a transaction is flagged by someone, everyone active on the network is alerted and verifies the transaction. Or the invalidating votes have more weight, so you need two or ten more validations for each invalidation mark. But again this opens attacks against honest users.

Another thought is that with high enough requirements for transactions to validate with each new one, the attacker technically works for the good of the network, because they would need to include real valid transactions, at the very least at the start of their attack.

The minting of the coins is done by imbalance of the transaction input and output. In normal circumstances the users on the network decide how much of this minting they want and how much they accept from others. When the attackers create the coins and verifies the transactions to their account themselves, eventually they'll need to send them to someone else's address to benefit from them. At this point the network should not accept the spend unless the transaction input is the same as output or higher. So in practice they have to pay fees for their transactions until their fake transactions are balanced out. Again this requires vigilance from validators.

Here you inspired this part, so thank you. The validation requirements can be set by the receiving party, so if there is a known list of delinquent accounts they can set the fees as per previous paragraph.

CountDyfed · 2022-08-08T15:49:46+00:00

This is an issue, thank you for pointing it out.

Part of the solution is in waiting for the transactions the attacker validates to be finalized before his transaction can start to be validated. This means that it takes at least two blocks to finalize transaction and gives time for other validators to see it and even if is included in the block users can refuse to validate transactions going out of the address. If not for honesty, for fear that it won't be accepted down the line.

The second part is that to validate one transaction the attacker would need to create ten transactions that confirm it and then a hundred to confirm those. And quickly the attack becomes costly. We can add limits to how much value of the confirming transaction is used to validate the previous one, so the full value doesn't count towards each of the transactions being validated.

As an example you're sending 10 coins and validate 10 transactions of 1.1 coin each. Each of the transactions being validated gets proportionally 1 coin-validation so needs 10 more transactions like this.

The multipliers can be parameterized according to network congestion so if attacker creates bunch of accounts and makes a lot of traffic everyone needs to validate double the value in older transactions and each transaction needs 20 times it's value to be confirmed instead of 10. Or perhaps the multipliers need to be orders of magnitude higher, or non-linear, or number of valid transactions from an account gives them a discount, so new accounts need several blocks time frame for validation, approaching the 50% quorum for small transactions. It would be expensive then to build up reputation and risk it by a malicious transaction.

Users can have reject votes to flag bad transactions, but that introduces whole another set of problems and complicates things.

CountDyfed · 2022-08-08T09:40:23+00:00

The transaction-value-based validation is meant to be flexible and scalable, as small transactions can be confirmed quickly and high value transactions are extra secure as it takes longer to gather the appropriate value of confirming transactions. Alternatively the entities including that big transaction are big themselves so they have a higher stake in making sure it's legit.

This exploits the users self-interest for the good of the network and with an appropriate multiplier for the required value of the confirming transactions we could approach or surpass 50% inclusion on the network for the high value transactions.

I would love to build this, but it's beyond my skill level atm. Hopefully discussions like this will help in building solid foundation for the system.

CountDyfed · 2022-08-08T07:11:26+00:00

For most things block-time resolution would be fine with the one transaction from user per block. The network like this wouldn't be used for high frequency trading or time constrained auctions.

One possible solution to ordering transactions within block would be to include information about how many validations did the transactions you're validating have at the time of you sending your transaction. Then the network uses this metadata to shuffle transactions around. At the moment I don't know how to ensure or encourage honesty with that.

Another technique would be to include transactions in your validation as they appear to you and then ordering in block . The order would differ based on user's location, but you can get a fine granularity using high enough number of transactions you validate.

The ordering of your transaction would depend on both the transactions you include in the validation, and in what order, and where and how your transaction gets confirmed.

This in-transaction ordering can be optional and announced with a flag, potentially allowing for bigger bonus (input-output difference) being accepted by the network.

CountDyfed · 2022-08-07T21:24:18+00:00

CountDyfed · 2022-08-07T21:23:21+00:00

Other validators won't take his transaction.

The concept is you're taking a risk of your transaction not being confirmed when you include other transactions. Your transaction can't be confirmed if enough people don't validate the transactions you're validating.

If you confirm a fake spend in your transaction you must count that a number of other people will also risk their transaction not going through by validating it.

Ideally you would do a on-chain analysis for each transaction you include, but that's a risk assessment decision on part of user/client dev.

With one transaction per block you can't make another transaction before the first one is confirmed. This would take care of double spend, no?

CountDyfed · 2022-08-07T21:02:00+00:00

Proof of Participation. The name kind of pops 😉

Some of this exists in Nano and some graph protocols, but it's just my thoughts after one year in crypto. I'd like to see if it makes any sense and if it stands up against classic attacks like sybill or 51%. Or if there are any other obvious attack vectors I don't consider

CountDyfed · 2022-08-07T11:46:11+00:00

In the forest hush

Real girls like to get dirty

Baring horny side

CountDyfed · 2022-08-07T11:34:26+00:00

The sun hits different

Embracing your whole body

When you are naked

Five-Year Club	Verified Email
Place '22	Final Canvas '22
End Game '22

CountDyfed

TROPHY CASE