Questions about DHT, cryptography, and security

@jakob.winter That’s a beautiful explanation. Can I share it elsewhere (with credit) when I need to help somebody out in understanding Mutual Credit?

Thanks, Steven. Of course, feel free to use it however you like. After all, we are on a mission here, to convert as many people as possible to the “true belief” :grin:

I would assume so. If you publicly (on the DHT) lock some of your funds, until some condition is met, everyone else can verify your source chain and make sure you keep your promise.
It’s not much different than a normal transaction and should be totally possible.

2 Likes

hey @pauldaoust, so far able to get @artbrock to advice on my query on DHT’s immune system impact on efficiency/performance? If not, i will pose this questions to @artbrock on coming AMA. I am keen to see his answer.

This is the youtube video of May AMA, skipped to the exact timing segment, which i had submitted a qns based on my query in above thread and @artbrock answered:


TLDR:
Most of ans is similar to what @pauldaoust mentioned above. Thanks again!

Additional info:

  1. there is 64 bit data universe which makes it easy for nodes to know who holds what data
  2. In terms if gossip. there are exponential backoff where if frequent changes happens, then more gossip will happen. If activities are lower, then less gossip, until activities picks up again.

However, i am still not sure, if the signature aggregation list of each data is updated frequently as the resiliency factor is constantly maintained? Who maintains the list? The author? Or both the author AND the validating nodes?

1 Like

I have 2 latest questions regarding on Holo org collecting fees for every hosting tx + how centralized exchanges (CEX) are going to handle holo fuel deposits & withdraws when they do list Holo Fuel in future. I have submitted them for AMA. But like to add these qns here on the forum too as a record. Tagging @artbrock and @pauldaoust

Holochain is inherently agent’s centric and it seems to me that it involves lots of manual interactions back and forth between agents before a tx is concluded.

Qns 1) In Holo, Txs between hosts and apps providers will involved multiple steps and Holo Org will take ≤1% of the fees. Many other similar txs will be happening simultaneously and asynchronously between many other hosts & apps providers aw well.

How does Holo org monitor all these hosting txs going on in an agent-centric manner, “inserting” itself in each of the txs and ensures it get part of the fees? It seems to that Holo need to monitor both Holo & Holo Fuel network for this. Don’t sounds too easy at all. Please advice.

Qns 2) If a CEX is listing holo fuel, i can imagine that the CEX will operate a holo fuel node, and they will need to interact with many depositors and withdrawals. Each tx may have “high value” and thus, probably involved a "multiple steps to complete the tx. The CEX’s node may not have a bird’s eye view of all txs. Crawling the DHT to verify txs validity may increase latency. And also are all these done manually?

Did holo team think through clearly how they are going to work with CEX in future on this?

Regarding my 2 qns above, @artbrock have replied to them on AMA. Here’s the youtube link on the exact time it was answered (38:53 - 53:27) . Some thoughts and follow-up qns:

Ans to Qns 1) Regarding about how holo collects tx fee, arthur open up my mind with regards to holo just setting into the validation rules, that the hosts need to pay holo org part of the tx fees (after it accumulate to certain threshold), or else, they cannot continue their next tx! And without holo org, needing to monitor all hosting txs! I think it is quite a clever and resourceful way for Holo org to collect tx fee without expending much resources!

But Art didnt really fully answer what i need to know for my 2nd Qns (45:49 - 53:27) and i hope @artbrock or @pauldaoust can advice further on this:

I get it that the CEX will spilt a high value holo fuel deposit/withdrawal with the counterparty agent into many smaller value txs. And they can process txs with multiple agents simultaneously.

  1. The key qns is CEX doing it MANUALLY or automatically?

  2. If CEX is splitting a high value tx (deposit or withdrawal) into many smaller value txs with the agent counterparty with many back and forth interaction, this means the finality time for each CEX deposit and withdrawal will be very long?

Let’s not forget Holo fuel is optimized for micro txs. But on CEX like binance (should they list Holo Fuel), we are talking about deposits and withdrawals that can goes into millions or even ten of millions in value!

Really look forward to the answers. Thanks in advance Art and Paul.

Any advice @pauldaoust and @artbrock ? You know i am quite persistent until i get a proper answer. :slight_smile: But it will help deepen my understanding of holochain, which in turns allows me to share this with my friends.

There will be a holo fuel AMA tomorrow, and i hope it can be answered on the AMA too. But will be great, it can be written here as a record for future reference / education for all.

Hello! Sorry we’ve let these questions languish.

Two groups of people maintain the list. This is part of the DHT’s ‘fast push, slow heal’ strategy.

  1. On initial publish (fast push), the author spams the authority neighbourhood of the entry. This means that, if they aren’t in the authority neighbourhood themselves, they need to collect the addresses of at least R authorities from the neighbourhood. Then they contact each of them directly and collect the validation certificates. This becomes the initial ‘validation bundle’, which happens to include the mean validation time from the authorities they contacted (which may be useful for validation of future entries). After that, I’m not sure if the author just keeps the validation bundle or republishes it to all of the authorities. I think republishing isn’t necessary because…
  2. During gossiping between authorities (slow heal), they also share their own validation receipts with each other. Eventual consistency means there’s never guaranteed to be a single, authoritative list of validation receipts, especially in a DHT that’s always changing. But the important thing is that, from the perspective of each authority (and the perspective of each node requesting data from that authority), they’ve collected enough information to convince themselves that the data is indeed valid.

So to answer your question, yes the signature aggregation is updated frequently as a natural result of the DHT adapting to current conditions. Each event that causes an authority to give a new piece of data to a neighbour (either by push or by pull) causes that neighbour to produce a validation receipt, which is then gossiped to the original authority and all the other neighbours. FWIU the author won’t get those follow-up receipts, though I could be wrong!

This isn’t included in the TestFuel design, due out for release as I’m speaking, but in the future the validation rules will also say something like “if an agent has spent x amount of HoloFuel without paying x * current_txn_fee to the infrastructure provider account, subsequent transactions are invalid”. Or something like that; it may just be a simple accrual threshhold. So all honest agents will do the validation for Holo, relieving us of the need to snoop into other people’s lives unduly. Yes, it is possible that the majority of hosts could decide to run a forked version of HoloFuel that doesn’t involve transaction fees, but they’re kind of killing the goose that lays the golden eggs at that point.

For making sure hosts and app providers are actually transacting, the situation is similar but different. Again, Holo doesn’t want to go snooping into others’ business, but it is a party to every HTTP request because we run the proxy/router between hosts and web users. And it does facilitate the initial introduction between host and user, because it has to know who’s hosting what hApp. I don’t think we can snoop the individual requests to see what hApp they’re for, because they pass TLS-encrypted through our router, but we do know which host it’s being routed to. Anyhow, maybe we’ll be able to run periodic fraud detection on initial host allocation and host routing based on the little we do know, combined with public service logs from each host. But I don’t see how we could build this into validation rules without it becoming pretty heavy.

[EDIT] Oh, I see your later message about Art answering your first question in the AMA. Sorry, just working from the top down! :slight_smile: Hopefully others can read this and gain some benefit from it.

This would be up to the CEX’s developers doing the integration. The way I see it, it would be automatic, managed by a script that the CEX has created and run on their server. (A Holochain DNA doesn’t care who’s talking to it – UI or script is fine, as long as it can talk HTTP, is running on the same machine as the DNA, and has the right credentials.) And yes, I imagine finality time would be longer with large-value transactions split between multiple microtransactions. But in my opinion that reflects the risk and value involved. I can’t speak for traders and whether they’d tolerate that, but HF’s main use case is of course regularly cleared, small value transactions.

HoloFuel’s DNA is currently designed to permit the initiation of multiple pending transactions at the same time. Sort of like a credit card authorize/capture, where funds are held but not withdrawn until the merchant confirms. But as Art says, there is a bottleneck in which each transaction has to be finalised sequentially. I don’t know if the final HoloFuel design will still have that feature, but I don’t think it has much of an impact on finality speed, especially in a CEX where this is likely to be handled automatically.

3 Likes

XMSS
https://tools.ietf.org/html/rfc8391

First… Sorry for the delay @Sol… I haven’t been on top of these forums lately. It looks like @pauldaoust has answered most of them.

But I want to respond to something Paul said above:

I’m not sure why a “majority” has any application here – there’s no useful majority attack on Holochain apps such as HoloFuel. It only takes a single honest node to detect a problem and warrant a cheater. Technically (not necessarily easily), anyone could hack their own node to run a different variant of HoloFuel dna, but as soon as they do anything which honest/normal/vanilla nodes won’t validate (such as skip paying transaction fees), they’ll be warranted and have forked themselves into a space where no honest nodes (including Holo and Reserve Accounts) will transact with them.

So while they could theoretically do this to their device, they would no longer be able to receive hosting payments, or redeem HoloFuel via reserves, or transact with anyone who wants to also be able to transact with honest nodes (such as whatever kinds of exchanges emerge). And once a host’s key is warranted, we’ll have to stop the other hosting apps from interacting with them, because their device is compromised, so they can’t continue to be considered “hosts” at all.

So your idea that a majority of “hosts” could run a version of HoloFuel that doesn’t involve tx fees seems doesn’t really fly. When someone commits fraud in HoloFuel, they cease being a host too.

People could create a different currency app that doesn’t have transaction fees, but it wouldn’t be HoloFuel. And they’d need to make sure their security model is up to the task for their use case, so they probably can’t just clone HoloFuel and then gut it of parts of its structural integrity/security (such as KYC, tx size caps, and fees). I mean… they could do that, but the currency wouldn’t be secure, so most wouldn’t want to use their insecure currency.

2 Likes

As though KYC, tx size caps, and fees do make a currency secured! LMAO! Haven’t heard anything as funny as that for years!

Why don’t you(Holo) just stop calling your hosts as your customers; you should rather call them your team (much as AWS calls its data-centers as “ITS OWN DATA-CENTERS”, not its customers of-course. The only difference between you and AWS being that you’re too flexible in hiring hosts, unlike AWS which doesn’t let the everyday people run their servers from their garage! Moreover, Holo-fuel should rather be advertised as a private-currency (https://en.wikipedia.org/wiki/Private_currency), backed by Arthur Brock and the team’s reputation for being trustful enough to do big business with, backed by the hope that it will buy its beholders some hosting-power, nothing more! Period!
Trust me, you’d save yourself much of the scrutiny this way…

Every technology platform has different attack surfaces that can be leveraged to cause problems. KYC and Tx size limits have nothing to do with HoloFuel’s cryptographic security. Holochain already provides that just fine.

However, all Holochain apps should have strategies for dealing with Sybil attacks. KYC is one part of HoloFuel’s strategy for addressing Sybils. It makes it very difficult to manufacture many fake accounts, certainly blocking the ability to spawn millions of accounts to try to dominate validation on the network.

Another aspect of security is how strict your validation requirements are for your currency’s use case. In the case of HoloFuel (which needs to be optimized for high volumes of micro-transactions), we cannot invest massive amounts of computing power into the validation of each transaction. Otherwise, the cost of validation overshoots the size of the transaction you’re validating.

This is where having transaction size caps come in. Splitting a large transaction into a number of small ones means that each transaction and its corresponding headers published by spender and receiver will go to 3 different neighborhoods of validators based on the hash of the Tx and headers. You might be able to pre-image a single large transaction to temporarily get away with sending it to neighborhoods of colluding validators, but there’s no way to do that for so many small transactions. (This kind of high-value / low-validation attack even has a particular name: a Finney Attack, and all cryptocurrencies have to address this issue.)

More specifically, there’s the fundamental cost equation: If you have to spend more to rip off the system (on computing power for pre-image hashes and bribes for trying to get enough nodes through KYC to control neighborhoods of validators) than you can gain from your attack (because of the size limit), then the attack is net loss and not worth the doing.

Because we are making certain trade-offs in deciding to keep HoloFuel validation fast, light, and efficient, KYC and size limits factor into changing the available attack surfaces.

5 Likes

Have we ever claimed HoloFuel is something other than a Private Currency? This is exactly the examples and metaphors we use (like photo-credits on a stock photo site, or ticket-master event tickets).

This is our stance with the regulators as well.

But derivative markets still emerge for private currencies that can be exchanged under the control of the holder – think of ticket scalpers, stamp collectors, frequent flier mile programs.

Have you ever heard anyone from Holo or Holochain claim that HoloFuel is supposed to be some kind of global currency?

Well then be ready for strict regulations by the world governments, censorships (about what ‘happs’ can be hosted on the Holo-network), and hell maybe even taxes (on Holo’s petty little 1%)! Look what happened with XRP, for instance…

It’s delighting to see that you’re transparent about Holo’s potential flaws (of which there are many: mostly being the same regulatory-limitations that the mainstream cloud-providers face); and having Holo’s best interests at heart, it genuinely concerns me knowing that audits and regulations do stifle potential growth over the long run. Private-currencies currently bear the risk of plunging to non-existence almost any-day from its issuance (especially in the centrally-controlled state-dictated societies that the majority of the world lives in at the time being). That being said, such a risk is worth taking only for businesses that have a physical presence in the jurisdictions within which it operates (think of Walmart, for example), but should strictly be avoided by the decentralized hosting platform that Holo is (if possible to avoid, that is to say).

Holochain (as opposed to Holo) should and indeed will be the de-facto choice of conservatives concerned about the concerns pointed above (not to mention the privacy-concerns a Holo user would have regarding his/her private unencrypted data being in someone else’s custody); therefore it should seem paradoxical that an informed user who resolves to only use peer-to-peer Holochain apps would want to do so via. Holo which only removes the two selling-points that Holochain adds, those being data-sovereignty and wider-options (i.e., the ability to consume apps that are not necessarily approved-of by the cloud providers to be deemed adequate to be hosted on their servers; though I’m not entirely sure whether the Holo resolver gets to see the DNA that the Holo-user wishes to be hosted for himself, so further clarification is welcomed on this concern). Hence it seems reasonable to conclude that the customers that Holo as a business is targeting to serve actually don’t exist in the real-world; the only two customer-classes being the informed user, who chooses Holochain, and the uninformed user, who chooses cloud-provided services! Does that mean that Holo as a business is doomed (so being Holofuel as the early investor’s compensation)? Or am I missing something?

good discussion between @artbrock and @The-A-Man

Basically, have you consult any legal experts and any censorship or shutdown implication to holo fuel which ultimately is used as a currency for a distributed hosting network but managed by a centralised company?

1 Like

@artbrock i have asked this question before i think on AMA. But would like your formal reply on this.

HOT (in future, holo fuel) current market cap is 155m. and we have at least 100 holders with at least 100k usd worth of HOT. In future, holo fuel may also be listed on exchanges.

What if we have holders who want to transfer big value holo fuel to exchanges? or direct transfer between agents?

How does holo fuel DNA handle big value holo fuel tx then? I don’t think it is practical to spilt a 100k usd holo fuel to 10s/100s of thousands or millions of micro txs, let alone a tx that could involved millions in usd value (like is trivially done in eth or btc network on a daily basis).

Look forward to your ans. Thanks!

I would also like this question answered

For sake of staying on the subject of security, would you mind making a topic out of this?

I’m excited for the light-weight benefits of Holochain :slight_smile:

@artbrock I am interested in connecting Biometric services to be required for authorization. Who should I talk to / where can I find information? Thanks!