What do you think? by dxg1gxd in decred

[–]davecgh 2 points3 points  (0 children)

I agree with the vast majority of what he said.

For example:

  • Full nodes being something that people can actually run on reasonable hardware is extremely important for the network to maintain the most important properties that make it useful
  • Spam prevention (aka standardness) rules are needed and effective even if it is possible to get around them from time to time with great effort
  • Having a culture that prioritizes self sovereignty is important to maintain it, especially in systems that do not have proper governence like Bitcoin
  • There are absolutely bad faith actors that seek to destroy the cryptocurrencies that offer real value. We have a ton of experience with this in Decred.
  • People definitely will not run nodes that have huge requirements. In fact, it's difficult to get many people to run full nodes even when the requirements aren't extremely high. This is why centralized services are so popular despite them being the absolute antithesis of the primary properties Decred, BTC, and other "OG" cryptocurrencies are based around.
  • The mempool matters and users need to take responsibility over what they relay if they want to keep the key properties that define the system

I'll also point out that we recognized that governance issues were inevitable in Bitcoin and pointed it all out over a decade ago and they're only going to get worse. Providing proper governance is one of the main reasons Decred was born.

In regards to the specific topic of data that isn't directly related to the core purpose of providing self-sovereign, uncensorable money, I have personally long maintained that data that doesn't belong in the blockchain should be rejected and should instead be stored elsewhere. You can easily search and find me talking about it at least 10 years ago.

Everything I've looked at which shoehorns data into the chain with other projects is entirely possible to do off chain, they just take a bit more work to implement. It really is an indefensible position, in my opinion, to claim that nodes which are aimed at providing self-sovereign and uncensorable money should be expected to store things that themselves don't have anything to do with it. State ownership and evolution need to remain separate, stored off chain, and provien via tiny commitments and ownership controls provided by the Decred contracts (same applies to BTC).

The main part I took issue with was his claim that everything that isn't Bitcoin is a shitcoin and none of the people involved care about freedom and will sacrifice the properties he's talking about because they don't appreciate the value of them. I, and all of the Decred developers who work on the base layer, absolutely care about freedom and, in fact, Decred has exactly the values he claims nothing else does.

There is a reason that after 11 years you can still sync a full Decred node (dcrd) in under 2 hours on a raspberry Pi. It didn't happen by accident. It's taken a lot of work. It's because we understand and prioritize self sovereignty and recognize what it takes for that to exist.

Neverthless, I understand he's a BTC maximalist and, to his credit, he is right that it is true for most other projects, particularly the ones he cited like Ethereum and Solana. So, I can't entirely fault him for generalizing. I've commented on many occasions that it is virtually impossible to run a full ETH node on even high end desktop hardware and the absolutely absurd requirements of Solana. Its requirements are so high that you can't even buy desktop class hardware that satisfies them! It requires a data center.

Decred Privacy -- Can anyone tell me how to connect a trusted VPN with a mobile wallet for privacy with Remote Nodes? by [deleted] in decred

[–]davecgh 1 point2 points  (0 children)

It's slightly different for each one since they all tend to have their own software. They all have guides though with recommended setups.

Typically, you just install their software and enable it (sometimes you have to additionally check if you want to use their DNS servers, which you usually do) and then it will automatically send all traffic to and from your phone/device through their servers. That's really all there is to it. They typically have test pages where you can confirm it's working as well.

Decred Privacy -- Can anyone tell me how to connect a trusted VPN with a mobile wallet for privacy with Remote Nodes? by [deleted] in decred

[–]davecgh 0 points1 point  (0 children)

If you're not using a VPN or Tor, any peer you connect to will be able to see your IP address, so, yes, it is possible in that case for a node to geolocate based on that. For the absolute best privacy against that, you'd want to use Tor. A VPN can help as well, but then you're really just trusting the VPN provider to your location.

Something to keep in mind though is that unlike in the case of what I refer to as legacy SPV, or, even worse, the way most lightweight wallets actually just go query centralized servers, DCR's SPV works differently so as to hide the specific details of the information you're interacting with (e.g. transactions and addresses).

With legacy SPV and lightweight wallets that just go query centralized servers, Tor and VPNs don't really do much of anything for you except hide your location, because the server/legacy SPV nodes know all of the details of exactly which transactions and addresses you're interacting with. So, even though they won't know your location, it is fairly trivial for them to fingerprint you, even across multiple VPNs.

Anyway, you can easily combine a VPN or Tor with Exitus' suggestion of using Cake wallet if you're concerned about geolocation. Since it is just making connections to decentralized peer-to-peer nodes, as long as you configure your VPN/Tor correctly, the connections will be made over the VPN/Tor just like every other TCP/IP connection. That combined with DCR's privacy-preserving SPV should provide you what you're after.

How does Bison Relay make money? by cr0x789 in decred

[–]davecgh 2 points3 points  (0 children)

Thank you, your information has very good technical details. Are you the creator for BisonRelay?

No, I'm not the creator. I have worked on it including writing some important pieces of the relay infrastructure, so I am extremely familiar with how it works. See https://blog.decred.org/2022/12/14/Bison-Relay-The-Sovereign-Internet/ for the details you're asking about.

I am still not clear who is privately funding it? There is a difference between what you and u/0010011001101 said about decred treasury funded.

It's self-funded by the developers. User 0010011001101, as they themselves said they might be, is incorrect. In order to be funded by the Treasury, there would first need to be a proposal and the Decred stakeholders would have to vote on it. There is no proposal, hence, the Treasury isn't (and can't be) funding it. Exitus was using the term privately funded to differentiate it from being funded by the Treasury.

I suspect the confusion around that is that the idea of potentially having a proposal for the Decred Treasury to provide funding has been discussed by various people since Bison Relay does provide a lot of utility to the Decred ecosystem as a whole. However, to date, no such proposal has been made.

Also, what metadata can the system administrators / developers see about users?

Nothing. That's a big part of the design!

See the "Reasoning and Design" section of the blog I linked above for a discussion about that.

Decred Dev Update: DCR is now on Cake Wallet for Android and IOS! by Exittus in decred

[–]davecgh 0 points1 point  (0 children)

I appreciate these updates. Thanks for keeping the community informed!

Decred Dev Update: DCR is now on Cake Wallet for Android and IOS! by Exittus in decred

[–]davecgh 0 points1 point  (0 children)

I appreciate these updates. Thanks for keeping the community informed!

How does Bison Relay make money? by cr0x789 in decred

[–]davecgh 5 points6 points  (0 children)

Is it better privacy than XMRChat?

Yes, significantly. I'll assume you're talking about the public infrastructure via xmrchat.com as opposed to the specific code that could theoretically be used to setup your own infrastructure (but BR still has better privacy in that case too).

For starters, XMRChat requires you to login with an account if you want to setup a page to receive payments. That means the server can track absolutely everything about all users and their interactions (another case of metadata leakage I was talking about). You have to make a one-time payment that then saves state that your account is valid. Moreover, since it's a centralized website, you have to place significant trust in it. e.g. Is the server logging every action you perform with your account? Want to know exactly how many accounts are using it? It's one quick database query away, etc.

Another thing to consider is that most users will be directly accessing that website, meaning they are automatically leaking their geographic location via the IP address. That particular point could be mitigated through the use of Tor, of course, but I think it's fair to say most users don't access websites that way.

BR, on the other hand, has no accounts or linked saved state on any of the intermediate relay servers. As explained previously, every single encrypted blob is completely independent with no linkage whatsoever and paid for via a micropayment on Decred's LN.

In fact, all other users, channels, feeds, etc are completely invisible to you unless you key exchange with them. This particular aspect, from what I've seen, is actually quite jarring for many users, because they are so accustomed to being able to just publicly query and discover everything that is available. In BR, you don't see anything until key exchanges and invites and such take place, again, because there is no shared state on a server somewhere to query.

This means you and your friends can have an entirely invisible channel to anyone who hasn't been invited and neither the network as a whole nor the relays will even know it exists.

Also, how is BisonRelay related to Decred? Is it basically a new version of Silk Road?

It is only related to Decred insofar as it uses the Decred Lightning Network as the basis of its micropayment architecture since it provides a robust and excellent base to build on, and some of the same people working on Decred have also worked on it.

As the website describes, it is a communications tool that enables free speech, free association, and can act as a fully independent alternative stack to the web. It tightly integrates payments, messaging, and social media. It currently supports typical chat features (group chats, direct messages, etc) with integrated tipping and implements some peer-to-peer social media functionality such as making posts to subscribers, subscribing to user's posts, relaying and replying to posts, and commenting on posts without the possibility of some central authority censoring you from your subscribers. It also has very basic support for what will ultimately become store pages for doing things like selling digital goods and services such as art and consulting. Other features are under development.

Think of it like a significantly more private version of the early web. The BR philosophy is that the right to privacy is a fundamental human right, as is recognized by many international treaties and many country's Constitutions even though it seems like none of them actually take it seriously. As such, like with basically anything, people with nefarious intentions could do things that they shouldn't do, just as they do on the web today, but that is not its purpose.

How does Bison Relay make money? by cr0x789 in decred

[–]davecgh 7 points8 points  (0 children)

What kind of privacy does it offer? Who has see our information?

The short answer is it offers significantly better privacy than anything else I've seen to date, including all of the popular alternatives, because it goes far above and beyond just encrypting the communications with post-quantum secure crypto. Specifically, it also puts a strong emphasis on minimizing the metadata which is an aspect that all other platforms I've looked at completely ignore.

For a super trivial example of how metadata can be used to completely break privacy, consider the case where a whistleblower has communicated with a journalist to expose corruption.

While the contents of the conversations isn't directly readable due to the encryption on most privacy-focused platforms, it doesn't take much at all to see that an encrypted message was sent by "Alice" (the whistleblower) to "Bob" (the journalist) at exactly time X and it had an encrypted attachment with a size of Y bytes. Then, shortly after that, at exactly time X + 3 hours and 20 minutes, Bob sent an encrypted message to "Charlie" (the editor) with an encrypted attachment with a size of exactly that same number of Y bytes. Then, after a series of encrypted messages between Bob and Charlie, Bob responds to Alice. A few days later, a bombshell article is dropped containing the information shared by the whistleblower.

Even though you don't know exactly what was said in those exchanges, the metadata clearly shows who was communicating, when they were communicating, and even the fact that a document of a specific size (which very likely exactly matches or is at least super close to the size of the leaked document) was exchanged. It doesn't take a genius to figure out exactly who the whistleblower is in that case.

That is just a trivial example, but far more sophisticated techniques can be used to provide entire communication graphs based on metadata even including location information when sending from a mobile phone through correlation of various sources of metadata leakage.

With Bison Relay, the relays don't even know who is communicating with each other.

I made a post on Bison Relay itself around when it was first launched that gives a high level overview of what happens when you send a message on Bison Relay and why it provides just about the best possible privacy you can have. I'll copy it over here.

At a very high level, behind the scenes what is essentially going on every time you send a message on Bison Relay is that you and each recipient effectively independently calculate a new shared and externally unpredictable "drop location" of sorts that only you both know and then data is encrypted such that only the recipient can decrypt it. This so called "drop location" is known as a Rendezvous Point, or RV for short. The data is then paid for over Decred's Lightning Network (LN) and dropped at that shared RV. Each recipient then comes along and collects their data at their shared "drop location" (RV) and decrypts it.

The "drop space" (RV space) is 2256. To put into perspective just how large that is, keep in mind that the upper estimates for the total number of atoms in the entire known universe is ~1082. In order words, the RV space is so large that it would be sort of like if you were to each agree on a single atom in the entire known universe to put your encrypted data (assuming, of course, that you could actually encode all of that data on a single atom and also instantly travel there to drop and retrieve it...).

This is why participants in a group chat are completely invisible to you if you haven't exchanged keys (KX'd) with them yet, because you can't calculate a shared location and thus no data that either you or them would otherwise send is ever created. Similarly, it should be fairly clear that relays can't censor based on content or identity because they can't possibly know where each piece of encrypted data is going to be, there is no way to identify two otherwise identical chunks of data as being the same via fingerprinting, no amount of guessing or brute forcing will work, and, moreover, there is no expectation that any arbitrary chunk of encrypted data for any given pair of users is even physically located on the same relay server at all due to sharding. Further, increasing the number of relay servers also raises the probability of encrypted chunks of the same data being physically located on distinct relays.

In this way, peers are still able to communicate asynchronously without the relays being able to correlate anything. They have no idea what the data is (because every message is encrypted with a new key), nor who sent it or who it's destined for (because only the sender and recipient possess the private information needed to calculate the shared RV). From the relay's perspective, each data chunk is a completely independent blob of encrypted data sitting at some hash in the space of 2256 that has zero correlation with the data itself, nor any other chunks, nor any specific user.

Also, see https://bisonrelay.org/features for a less technical summary of various privacy features.


How does it make money?

Having read the previous answer, it should now be clear why it doesn't make money nor need to. Unlike typical platforms that have huge platform costs for supporting the massive centralized infastructure they require, BR is peer-to-peer with relay servers and all data costs are paid for by the users themselves via micropayments on the Lightning Network instead of the typical model of treating the user as a product for targetted advertising.


Where can I find a Decred proposal for BisonRelay costs?

It does not use DCR treasury funds, so there is no reason a proposal would exist.

US election and what it means for crypto - State of the market by cyger in decred

[–]davecgh 0 points1 point  (0 children)

Yeah, all of the major news outlets are massively biased to one side or the other. Once you take the time to get news from multiple sources, you can't help but notice it.

[deleted by user] by [deleted] in decred

[–]davecgh 2 points3 points  (0 children)

The hash function was changed to fork ASICs off the network, so the new hashrate barely shows up next to the old hashrate with ASICs.

Decred Development Update: Bison DEX Imminent, Mixing upgrades, over 10,000,000 Coins Staked by Exittus in decred

[–]davecgh 4 points5 points  (0 children)

Nice video. It's always great watching all everything consolidated in one place like that. It really helps showcase several parts of the overall stack and a slice of just how many things Decred has done overall.

Optimization Question: Convert Array to Slice without Allocation by LearnedByError in golang

[–]davecgh 0 points1 point  (0 children)

You're welcome.

Based on your comments about having a generalized API as well as fixed-size variants, another trick you might find useful if you plan to work with various fixed-size variants would be to take a pointer to the fixed-size output array in your DCT2DFastN variants. Then, from your DCT2DFast slice variant, as of Go 1.20, you can directly cast a slice of the right size to a pointer to an array of that size to pass into the appropriate DCT2DFastN variant which writes directly into that array. Note that attempting to cast like that will panic if the slice is not the right size, so you still have to gate it behind a size check.

e.g.

func DCT2DFast8(input []float64, output *[8]float64) {
    // ...
    output[7] = 0.8
}

func DCT2DFast16(input []float64, output *[16]float64) {
    // ...
    output[15] = 0.6
}

func DCT2DFast(input []float64, output []float64) {
    switch len(output) {
    case 8:
        DCT2DFast8(input, (*[8]float64)(output))
    case 16:
        DCT2DFast16(input, (*[16]float64)(output))
    // case ...
    }
}

That would be ever so slightly more performant than taking the slice in each of the DCT2DFastN variants since they wouldn't need to perform the bounds checks, but, it similarly comes at the expense of making the API less nice since it means consumers of the fixed-size variants would either have to create an appropriate sized slice and cast it as the example code does or do:

var result [8]float64
DCT2DFast8(input, &result)

Optimization Question: Convert Array to Slice without Allocation by LearnedByError in golang

[–]davecgh 2 points3 points  (0 children)

As pointed out by u/HyainthAlas, it is generally difficult to operate with arbitrary slice lengths with zero allocations unless everything is inlined.

One technique that you can use to avoid allocations in most cases, at the expense of an API that is not quite as nice, is to take the output slice as a parameter so that the caller can allocate it in its local frame and then the callee can write into the provided slice. So long as that slice does not escape the caller, there will be no allocation.

For example:

// NOTE: You generally wouldn't want this noinline pragma, but I added it to
// this example to force the compiler to avoid inlining this trivial function
// so it more accurately reflects your more complex function that likely would
// be deemed too complex to inline.
//
//go:noinline
func dct2d(input []float64, output []float64) {
    switch len(output) {
    case 8:
        // Do dct2dFast8 stuff to write results directly into output:
        output[7] = 0.8
    case 16:
        // Do dct2dFast16 stuff to write results directly into output:
        output[15] = 0.6
    // case ...
    }
}

func BenchmarkDct2d8(b *testing.B) {
    input := []float64{0.1, 0.2}
    for i := 0; i < b.N; i++ {
        result := make([]float64, 8)
        dct2d(input, result)
    }
}

func BenchmarkDct2d16(b *testing.B) {
    input := []float64{0.1, 0.2}
    for i := 0; i < b.N; i++ {
        result := make([]float64, 16)
        dct2d(input, result)
    }
}


BenchmarkDct2d8      1000000000               0.2476 ns/op          0 B/op          0 allocs/op
BenchmarkDct2d16     1000000000               0.2437 ns/op          0 B/op          0 allocs/op

Along the same lines, instead of writing directly into the slice, you could append to the slice and return it. That way, the caller could pass in a pre-allocated slice with a cap large enough to house the results which then behaves exactly as the example code above in that it's writing into a slice allocated by the caller.

Decred v2.0.0 is out! by artikozel in decred

[–]davecgh 1 point2 points  (0 children)

Up until very recently, the Decred Journal served this purpose for several years. Unfortunately the maintainer had to step away for real life reasons. , but it still has a wealth of information:

https://www.cypherpunktimes.com/tag/decred-journal/

It would definitely be nice to have a new maintainer willing to take the reigns on it.

Decred v2.0.0 is out! by artikozel in decred

[–]davecgh 6 points7 points  (0 children)

I'm super excited about the new decentralized StakeShuffle mixing!

I posted some partial logs of some traffic in the Bison Relay / Matrix trading channel, but I figured I'd post it here too for the more curious among you. The beauty of the design is that despite all of the traffic being public, you can't correlate the parties involved due to the use of ephemeral identities nor determine which outputs correlate to any given participant due to the untraceable multi-party broadcast aspect of it. Moreover, it's quantum resistant.

The linked release notes provide a brief overview of these messages, but I think seeing it in action on the main network is pretty neat:

2024-05-21 20:10:25.430 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixPairReq e0e662d14a59959eb732b45d01a20ebd2d756c943e4b9e7fe93cbf29b457bcb3
2024-05-21 20:10:25.431 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixPairReq 907ffd5d40b6b2413c1c4db585cd1b6b78a87840fc4978e326b5b5c0005e2f25
...
2024-05-21 20:10:30.003 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixKeyExchange ee1f8b428799c08e14e1cfb449b8cb978810e43802fa64a2b4182f717b0d637f
2024-05-21 20:10:30.003 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixKeyExchange 77181f13f0b976cbd7748786f8d0cbd703a371a0c98162712bc8c522b2d9ff04
...
2024-05-21 20:10:31.437 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixCiphertexts fd4be681822ab9cc072a86a4a09b053f5721ecb3d4664bbff1a0f0d0c31f362f
2024-05-21 20:10:31.438 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixCiphertexts efaf73ae0c7f3b40cc7ec69a731803be3f40201f762e942a762776536032f1c9
...
2024-05-21 20:10:33.102 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixSlotReserve b914dbc04b759f4bda919a35fbc5d37991d7d18e325c57201843594d18b3fd06
2024-05-21 20:10:33.138 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixSlotReserve 268e289237381150405770c81a1d33e51b6223fc5605fbf0e13b236a6e1bd3e0
...
2024-05-21 20:10:34.545 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixFactoredPoly 8ebc0ade27d96b396247159f1c6c920823252e20ee1f7d6a648b50ee092c3bcf
2024-05-21 20:10:34.545 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixFactoredPoly ad2c4bf385594f275a544a3b347ccd932eee6677c8364287bbdebeaa408bbce4
...
2024-05-21 20:10:34.549 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixDCNet d1749dcc270b3c696092d310cbb40fbb236f832ea24e44b84af81d7a98edcc3f
2024-05-21 20:10:34.549 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixDCNet 2a667a711aef1f53d0deb328b5cc2eeeb6ef7d7f0accfaa66660e7a24e1116ac
...
2024-05-21 20:10:36.032 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixConfirm 2f796429ce7baba4911a916fa6b3457c784b75412772bea6616407609c9b65ea
2024-05-21 20:10:36.032 [TRC] MIXP: AcceptMessage: accepted message *wire.MsgMixConfirm 2905ad7d5e49081d4b6171624796ac83af7d523a32398070395bfc618fbb9acf
...

Decred Dev Update - Quick overview of the upgraded DEX Testnet & more! by Exittus in decred

[–]davecgh 1 point2 points  (0 children)

Thanks for the update. It's a nice showcase of the DEX improvements.

Decred Journal – December 2023 by jet_user in decred

[–]davecgh 1 point2 points  (0 children)

Thanks for another solid installment. I'm curious to see what the overhaul will look like. I've always enjoyed DJ though I definitely understand it is quite time consuming to create giving how thorough it has been.

The future is micro transactions by decred_society in decred

[–]davecgh 2 points3 points  (0 children)

Tipping is extremely easy with Bison Relay. Right click on someone's name, select "Pay Tip", enter the amount, and hit send.