[Cryptography] Standards Trolls: Re: Bitcoin is a disaster.

[bear]

On 2021-01-13 02:18, jrzx wrote:

>> For a single transaction you need consensus that the coins you're
>> getting actually exist and actually belong to the person you're getting
>> them from. You don't need a history of the universe for that; you need
>> a history of those particular coins and evidence that the act of
>> minting them was valid according to protocol.
> 
> But you want your coins to be spendable too and from anywhere on planet earth. 
> 
> Right. after the transaction where the coins are transferred to you, 
> you have a token whose latest 'chain link' contains cryptographic 
> evidence that it was actually transferred to you. Likewise you checked 
> the token before you got it to make sure that the previous 'chain link' 
> contained cryptographic evidence that it had actually been legitimately 
> transferred to the previous holder.
> 
>> If the tokens themselves are temporary - that is, if they are minted,
>> they go through some number of transactions, and then they are melted -
>> then the history of a given token can be short and require
>> communicating about only a few transactions. A $20 bill, for example,
>> only changes hands about 600 times before it is removed from
>> circulation and destroyed. Agreeing about a few hundred transactions
>> seems a lot more reasonable than agreeing about TheWholeDamnUniverseTM.
> 
> To prevent doubles spending, some trusted authority has to know the current
> ownership of each token. 
> 
> Each token needs an authority trusted for that token. Ultimately, that's 
> the node that minted the token.  In a more immediate sense, that node 
> probably designates a half-dozen backups that can be checked whenever it's 
> offline.  So your software dials up one of these authorities, which is given 
> in the token's header, and inquires whether the last observed hash for the 
> token's transaction chain matches the one you're seeing.  
> 
> You have evidence that the token was minted according to protocol and 
> came to you through a series of legitimate transactions.  That's all 
> part of the token itself.  You turn to external authorities to check 
> that there is no *other* series of legitimate transactions for the same 
> token. (ie, that a double spend has not taken place). 
> 
> If you find that a double spend has taken place, you can identify the 
> certificate of the double spender.  We call the proof a certificate 
> revocation.  If no double spend has taken place, then you cannot tell 
> which certificates were used (who the parties to the transaction were) 
> in any transaction in the token's chain - save for your own and your 
> counterparty's certs, of course. 
> 
> So this is a bunch of small blockchains, which from time to time
> disappear, and new ones appear.  But, conservation of money.  When
> one disappears, the money has to go into a bigger blockchain,
> and when one appears, the money has to come out of a bigger
> blockchain.  So this is the sidechain solution.
> 
> Sort of.  What everybody knows - the shared information that has to be 
> updated - is the database of certificates.  Each certificate is given 
> "income" of one coin per day (creating "inflation" that drops toward 
> zero the more coins there already are). Because you know how many 
> certificates there are and when they were issued, you know how many 
> coins exist total and how much each user is authorized to have minted. 
> The token asserts which hours and days 'minting authority' the token 
> is supposed to represent.  You check that that's not in the future and 
> check that the same hours and days from the same certificate are not 
> represented by another token issued later. 
> 
> If another such token is discovered, either at the time, or later, 
> you have a proof of a double minting protocol break, which, again, 
> functions as a certificate revocation against the mint. 
> 
> So your 'wallet' consists of two things:  Tokens minted by others 
> which you hold and can spend onward, and a 'bullion' balance representing 
> the current extent of your own minting authority.  When you want to make a 
> transaction, you can transfer some of the tokens you hold, or you can 
> 'mint' a new token.  As the token wanders around, you'll get occasional 
> calls to verify its history chain, but you won't learn from these calls 
> which users it's being transferred between. Some number of other nodes 
> will also be keeping track of it or answering these queries.  If you 
> receive a token that you minted in a transaction, you 'melt' it adding 
> those coins back to your 'bullion'.  (And people will want you to melt  
> it and swap them a new token for it, if it gets big enough to be annoying). 
> 
> Well, if you have a lot of tokens, you will have a lot of sidechains.
> Why should you trust the sidechain? 
> 
> Ultimately, the scheme gives up any kind of real guarantee that a double 
> spend is detected in realtime, replacing it with (A) means of detecting it 
> in realtime that will work 99% of the time, (B)the power to opt out of a 
> transaction (or use a different token) if those means are not available, 
> and (C) a real guarantee that if a double spend is made or if those means 
> are deliberately falsified, then the certificate used to perpetrate  
> this will be revealed and revoked.  Not necessarily in real time, but 
> with a high degree of certainty.  In order for (C) to be meaningful, 
> the certificates can't be anonymous and therefore there has to be a 
> certificate authority. 
> 
> In exchange for those downgrades, you get scalability - real scalability, 
> where there is no central ledger of the history of TheWholeDamnUniverseTM 
> that bottlenecks the transaction volume and which every node must keep 
> updating.  There are 'ledgers' for individual tokens, each attached to 
> its respective token. The ultimate authority for those ledgers is not 
> centralized; it is distributed around the network to everybody, along 
> with everybody's minting power.  If you are willing to trust someone 
> without realtime checks, you can even do transactions entirely offline, 
> producing a transformed token (same head, and a history chain one link 
> longer) that your counterparty can use, in the certain knowledge that 
> if you try to spend the same token again, spending your copy of it will 
> result in a revocation of your certificate. 
> 
> The idea is to provide slightly looser guarantees than a realtime 
> block chain, in exchange for NOT having to have a great big pile of data 
> that a lot of people must repetitiously store and track, and in exchange 
> for NOT ever gathering together a great big, highly visible, invasively 
> analyzable, central repository of every transaction that has ever happened. 
> 
> What has to be tracked is just the certificate database of users.  A few 
> more parts of the protocol (like where the 'minting balance' associated 
> with a key goes when a cert is revoked or transferred, etc) come out as 
> part of that database, and as with the other things, you can check to 
> make sure they're according to protocol. That would be your "central 
> chain" but would contain no actual transactions - only certificate 
> information.  You wouldn't need more than one block a day to keep it 
> updated. 
> 
> From any circulating token, you would know: 
> (A) what certificate (which user) minted the token 
> (B) How many transactions the token has been transferred in 
> (C) A time before which the token could not have been legitimately created. 
> 
> From the certificate database you would know: 
> 
> (A) What certificates exist and who (real-world ID) each belongs to 
> (B) When the certificate was issued 
> (C) Who else is supposed to know about these tokens in case the 
> certificate holder is offline        (D) Any revoked keys that this certificate is now the primary authority 
> for (example: Alice discovers evidence that Bob cheated, and now 
> Bob's key has been revoked.  Alice becomes the primary authority for 
> tokens issued by Bob, and can 'melt' Bob's tokens.) 
> (E) Any additional minting authority available to this key (example: Carol's 
> grandfather Daniel died and left his account to Carol.  His cert is 
> revoked when he dies and his bullion appears on Carol's updated 
> certificate.  Carol will be able to spend tokens most recently 
> transferred to Daniel, will be able to mint out of Daniel's bullion, 
> and will be able to melt Daniel's tokens. 
> 
> Bear

> (accessing through webmail at the moment while I sort a new installation here; Apologies if this

> doesn't come through with correct formatting for quotes).
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://www.metzdowd.com/pipermail/cryptography/attachments/20210115/603f1ea0/attachment.htm>