The point is you can't distinguish transactions that are from an "attacker" when the underlying signature scheme is broken. The Bitcoin P2P network has some metrics to disconnect from nodes that might be trying to DoS you, but if a transaction has enough fees, is spending unspent coins, and has a valid signature, it's valid.
I did say heuristics, not valid/invalid. You can do all sorts of analytics upon receiving a transaction, and then decide to forward or drop the transaction based on that heuristics. Valid/Invalid could become the minimum requirement for a transaction to be forwarded.
This work is important, and I'm looking forward to forming an opinion on it. Maybe a future post! For those who are interested, this is what I'm aware of:
1) Short markets in Bitcoin don't have unlimited depth, and the centralized ones are KYC'd so there's some risk there
2) What if it doesn't tank the price? One thing people have suggested is just burning all the vulnerable coins[1]; it reduces supply so maybe the price will... go up? The point is there's uncertainty.
I’m pretty sure the hope isn’t that burning some coins tanks the price. The point is that publicly demonstrating that you can crack wallet keys is what tanks the price.
I don't see how 1 is any issue at all. Using a computer to make the intended bitcoin calculations much faster than anyone else possibly can is entirely within the rules of how bitcoin works.
It will also tank the price because by doing it, you have demonstrated you have complete control of bitcoin transfers, you can transfer bitcoins from anywhere to anywhere else at any time, and that there is no way to flag it as illegitimate because mathematically you're just providing the correct numbers.
Sorry I wasn't clear there. Because most of the short-depth is controlled by centralized exchanges, there's a risk you won't be able to actualize your short (withdraw, either in crypto or to a bank account), even if it's successful -- they could just block you from withdrawing and/or report you for fraud.
Thanks for the response and clarification. What's the best way to discover papers on hypothetical US CBDCs? I've seen one international paper and one on US FedAccounts.
> Almost 50 central banks have already launched designs for central bank digital currencies (CBDCs) or prototypes ... The paper discusses ... what they imply for the financial system and the central bank of the future. It sets out the requirements for a “minimally invasive” CBDC design ... digital banknotes that run on “intermediated” or “hybrid” CBDC architectures show promise. Supported with technology to facilitate record-keeping by private sector entities of direct claims on the central bank, their economic design should emphasise the use of the CBDC as medium of exchange.
> Congress should authorize the Federal Reserve to give everyone—individuals, businesses, and institutions—the option to maintain accounts at the central bank. We call these accounts FedAccounts. Unlike the CBDC approaches currently under discussion, which would use complicated and inefficient distributed ledger technology and be walled off from the existing system of money and payments, FedAccounts would be seamlessly interoperable with the mainstream payment system, relying on technologies that the Federal Reserve has used for decades.
No. In serializable mode it simply appears that one thing is happening at a time. You can touch unrelated data concurrently with no performance impact.
serializability != one giant lock around your database.
concurrency and serializability go together great. it's only if transactions actually read/write or write/write the same data that they are done one at a time (and even that's not exactly true, depending on the concurrency control algorithms). MVCC often provides better performance because read-only transactions will not block writers.
and achieving serializability across database nodes is DEFINITELY NOT impossible.
re: materialized views -- you can kind of fake them in PostgreSQL by creating a view, populating it, and then defining triggers on insert, delete, and updates to your source tables.
This -- you have to realize there are two different versions of you. You1 is ambitious and smart and wants to do awesome things. You1 should think things through, actually plan things out, and write things down. At a detailed level!
You2 is super lazy and won't do anything even slightly difficult unless you make it really obvious and clear. You2 needs commit to following You1's plan; this requires discipline, but also a really easy-to-follow plan.
All the lecture notes will be put online, and you are welcome to clone the code and do the labs. If your code passes the tests reliably, you would have gotten full credit.
reply