CSW - Slack Channel
1.1K subscribers
4.21K photos
35 videos
198 files
4.7K links
Download Telegram
A DEX / DeFi liquidity pool is JUST a new way of saying -

Illegal coin mixer

The law of tracing exists.

If 10 of 100 coins are tainted and enter the DEX / "Illegal mixer", then all of the coins are now tainted

The people with 90 "honest coins" obtain 90% of their investment as the mixed coins are ALL tainted

So, if 10 people all add 10 coins and 10 are to be seized, all parties now have 9 coins of the 10 returned

To the person with tainted coins, this is good - it is a cost effective way to launder money

The coins are cleaned at the expense of the "honest" (rubes) owners who become money mules and lose their money invested.

A Dex, DeFi is a coin mixer, renamed. Nothing more, nothing less.

Just another already criminal aspect of all this

CSW
Nov 6, 2021
https://metanet-icu.slack.com/archives/C5131HKFX/p1636210136286800?thread_ts=1636210136.286800&cid=C5131HKFX

https://t.me/CSW_Slack/3333
While I am on the stand, and following before Amanda does my cross several days later, I shall not be answering questions about the case.

I shall discuss bitcoin, but I will not be communicating what I mean or other details of my testimony. You will need to await the conclusion of the case for that and read my transcript.

So, as a heads up, if you ask, I shall not answer.

CSW
Nov 7, 2021
https://metanet-icu.slack.com/archives/C5131HKFX/p1636324085384500?thread_ts=1636324085.384500&cid=C5131HKFX

https://t.me/CSW_Slack/3338
The bitcoin block header.

Proof of work has no relation to congestion. The introduction of a Merkle structure or binary tree structure means that the mining or proof of work function only must process a small header that at any time in any system would be less than 1 kB. The bitcoin block header is just the eighty-byte string. This in total combines:

a 4-byte long Bitcoin version number,

a 32-byte previous block hash,

a 32-byte long Merkle root (Binary tree hash),

a 4-byte long timestamp referencing the block,

4-byte long difficulty target attributed to the block, and

a 4-byte long nonce used by the nodes (miners).

Consequently, it doesn’t matter whether the block size is 1 MB and contains four transactions a second or rather that the block sizes 1 TB and contains millions of transactions every second of use. The mining process is exactly the same.

Equally, if you consider proof of stake, the number of transactions that need to be processed does not change the size of the blocks. To transact and send 1 million transaction still requires 1 million times the transaction size no matter whether you’re using proof of stake or proof of work. The argument against either of these is a non sequitur.

The simple answer is no matter what system, to validate transactions requires that you have a record of those transactions. The alternative that people talk about, layer 2 solutions is really adding a trusted intermediary. An example of a layer 2 solution that already exists and works well is Coinbase. This exchange has a traditional database that allocates amounts of bitcoin. Of course, this completely ignores the purpose of bitcoin.

The cost of mining one transaction is the same as the cost of mining 100 billion transactions from a proof of work perspective.

Miners work on the header.

They do not send the entire block to the PoW process. The validation can be parellelised.

CSW
Nov 8, 2021
https://metanet-icu.slack.com/archives/C5131HKFX/p1636376625426000?thread_ts=1636376625.426000&cid=C5131HKFX

https://t.me/CSW_Slack/3340
One major issue that I see with how people are moving towards big centralized data involves privacy. Still, it’s always because all the data is stored in a unique location that needs to be secured, like Fort Knox. It is not robust, and it is fragile. The methodology of storing everything on a central server has developed as people believe in the model of “never trust the client” (McGraw & Hoglund, 2004; De Francesco, 2019). This leads to centralized servers controlled by individual companies with all aspects of the data being locked down.

When things go well, this has advantages. However, the bunker approach creates an environment that is both inefficient and fragile. If a single compromise occurs on the server, then all the data is compromised. So, the approach I would recommend is to decentralize the data using more complex cryptographic algorithms that allow each individual peer to maintain their own data. This distributes the security and risk profile. Server-based solutions raise the stake and the cost of securing everything. On top of that, you have to trust the cooperation running the server. Next, this requires surveillance and monitoring.

The most significant mistake that people fall into is to assume that cryptographically secure foundations cannot be created that allows for trust at the client computer. Client computers can be trusted. This does require that solid cryptographic algorithms are deployed that guarantee the behaviour of the client. The use of digital signatures creates a powerful methodology and tool that help in defining the behaviour of the client system. This allows the individuals involved to leverage trust and even prevent client software from being modified.

McGraw, G., & Hoglund, G. (2004, August). Exploiting Software: How to break code. In Invited Talk, Usenix Security Symposium, San Diego (pp. 9-13).
De Francesco, G. P. (2019). The General Data Protection Regulation’s Practical Impact on Software Architecture. Computer, 52(4), 32-39.

The use of cryptography and cryptographic algorithms alone lays a foundation; it does not make everything completely secure. For instance, digital signatures require the use of a private key that must be kept secret for other methodologies for protecting identity to ensure that any impersonation can be limited. In any application, it is also important to note that only a certain amount of processing can be delegated to the client, and this needs to be maintained across the distributed systems.

One way to look at this is that machines should be thought of as extensions to the human and not the server. These are tools that aid individuals, and we should not be part of the central systems such as Google and Facebook of the world want to create.

The software on the user’s machine should be handling tasks on that person’s behalf. In this, if an individual instance wants to trade goods or items or ownership certificates (NFTs done correctly, for instance, that relate to real-world goods), then this should not need to occur through a central exchange and server. The use of cryptographic primitives and the distributed ledger that has been designed in bitcoin to ensure that double spending doesn’t happen and that all records are auditable is sufficient in most occurrences to ensure that people cannot cheat each other. However, this does not completely remove fraud. The real-world goods may not be the same as people have promised, but other methodologies for handling that.

CSW
Nov 9, 2021
https://metanet-icu.slack.com/archives/C5131HKFX/p1636461530003700?thread_ts=1636461530.003700&cid=C5131HKFX

https://t.me/CSW_Slack/3343
Bitcoin as I designed it (BSV) IS the only thing working correctly in this entire industry.

CSW
Nov 9, 2021
https://metanet-icu.slack.com/archives/C5131HKFX/p1636475413036600?thread_ts=1636475413.036600&cid=C5131HKFX

https://t.me/CSW_Slack/3345
No, Satoshi was Me.

Not a partnership. I own my role.

Ps... Dave never coded a line in his life, and documentation is not code.

CSW
Nov 10, 2021
https://metanet-icu.slack.com/archives/C5131HKFX/p1636500014074100?thread_ts=1636500014.074100&cid=C5131HKFX

https://t.me/CSW_Slack/3346