News for hackers. Stuff that matters.
Re:Blockchains from a Distributed Computing Perspective [pdf] by hyperion2010 on Friday January 19, 2018 @11:46PM (#16192110)
This seems an appropriate place to dump a thought I had while explaining the failures of all existing blockchains to a layman.

1) The problems with merkle trees & co. aren't the computational complexity, they are the space complexity. 1a) I can screw a current blockchain for all eternity by buying some token and then burning by keys. No one will ever know and they will have to keep track of those dead tokens until the heat death of the universe. 2) To solve space complexity you need a time tax. I propose 1 year, because it is convenient. 3) Any tokens (or fractions of a token) [0] that have not moved for more than a year (rolling) are returned to the common pot. (sort of a non-usage tax)

This means that you can limit the space complexity of the whole chain as a function of the number of transactions per 'tax interval.' This, or maybe a similar approach could make the space complexity problem tractable for normal users. (The blithe acceptance of a 1-2Tb (or is it 3 now?) space requirement for the full blockchain by members of the community is so wildly out of touch with reality it is laughable)

0. There are a number of other 'units' that could be considered for tax-interval retirement, such as the wallet. The nice thing about taxing fractions of tokens is that the network can set the rate of the tax for investing over the long term based on the cost of a single transaction fee. The day before a fraction of a token would be dumped back into the pool the owner would just have to send the token to another wallet they control and pay the relevant transaction fee.

Re:Blockchains from a Distributed Computing Perspective [pdf] by mbrock on Saturday January 20, 2018 @03:03AM (#16192563)
It seems that in any real world blockchain, the space growth from actual transactions will be much larger than the space wasted on inactive wallets.

And the notion of a secure financial system where if you don't move your money for a year your whole account is confiscated seems rather unappealing!

One thing I really want to be able to do with a blockchain system is to put my wallet in cold storage—like, in a safe. I don't want some arbitrary rule that I need to mark my calendar every year to retrieve all my keys from cold storage and do a meaningless transaction!

Re:Blockchains from a Distributed Computing Perspective [pdf] by BraveNewCurency on Saturday January 20, 2018 @02:38PM (#16195006)
> my calendar every year to retrieve all my keys from cold storage and do a meaningless transaction

No, you don't need to retrieve your keys each year. Before storage, create N transactions moving all your coins to the next derived address. Sign all your transactions at once. Then put it in the safe.

Store the transactions unencrypted on your computer. Send one each year. An attacker can't do anything with them except send them early (and force you to open your safe "sometime within the next year".)

Re:Blockchains from a Distributed Computing Perspective [pdf] by mbrock on Sunday January 21, 2018 @02:29AM (#16197204)
That's a good point, I didn't think about that. It does add some extra complexity though—like, if I do want to make a real transaction, I have to re-make the subsequent "keep-alive" transactions.
Re:Blockchains from a Distributed Computing Perspective [pdf] by GordonS on Saturday January 20, 2018 @12:58PM (#16194426)
> One thing I really want to be able to do with a blockchain system is to put my wallet in cold storage—like, in a safe

AFAIK, you can generate a paper wallet with any blockchain system. You're keys are rendered as a QR code and/or series of words (there is a name for this protocol that hopefully someone else can remember!), and you can then print and store it.

Hardware wallets are also a thing for some systems, such as Bitcoin.

Re:Blockchains from a Distributed Computing Perspective [pdf] by mbrock on Saturday January 20, 2018 @01:18PM (#16194548)
Yeah, exactly. BIP39 is a common protocol for mnemonic keys also supporting subkeys. Hardware wallets like the Ledger Nano S have support for Bitcoin, Litecoin, and Ethereum, and they let you sign transactions without ever exposing your private keys to a general purpose computer. And yeah, you can always just keep your private key in any way you want—it's just an n-bit number.
Re:Blockchains from a Distributed Computing Perspective [pdf] by gwbas1c on Saturday January 20, 2018 @04:36PM (#16195549)
> And the notion of a secure financial system where if you don't move your money for a year your whole account is confiscated seems rather unappealing!

This is why conventional money has a low amount of inflation. It incentives you to invest your money instead of putting it under a mattress.

Re:Blockchains from a Distributed Computing Perspective [pdf] by mbrock on Sunday January 21, 2018 @02:33AM (#16197208)
That is indeed a more conventionally appealing way to encourage circulation—a gradual inflation in prices rather than sudden account confiscation!
Re:Blockchains from a Distributed Computing Perspective [pdf] by otoburb on Saturday January 20, 2018 @12:08AM (#16192171)
Demurrage[1] money acts in a similar manner to encourage usage of a currency. Freicoin[2] implemented a demurrage fee mechanism of 5% per year, which would have the effect of eventually clearing out burned "dead" tokens, although the transaction history would still need to be stored until the end of time if you ran a full node that long.

[1] https://en.wikipedia.org/wiki/Demurrage_(currency)

[2] http://freico.in/about/

Re:Blockchains from a Distributed Computing Perspective [pdf] by hyperion2010 on Saturday January 20, 2018 @12:21AM (#16192202)
If you have a complete account of the location of every fractional token at time t and a time t + d then we should be able to get rid of all logs for transactions with time < t + d. Is there something that prevents freicoin from doing this?
Re:Blockchains from a Distributed Computing Perspective [pdf] by icelancer on Saturday January 20, 2018 @12:01AM (#16192147)
>>No one will ever know and they will have to keep track of those dead tokens until the heat death of the universe

Why does it matter? If the address never moves the tokens... it's not really a lot of computation required.

Re:Blockchains from a Distributed Computing Perspective [pdf] by hyperion2010 on Saturday January 20, 2018 @12:16AM (#16192194)
The point is that it requires space. We have to keep a record of the pointer.
Re:Blockchains from a Distributed Computing Perspective [pdf] by ulrikrasmussen on Saturday January 20, 2018 @12:30AM (#16192225)
But also any transactions pertaining to a "dead" account has to be verified whenever a new node boots the chain from scratch, in all future. The aggregated cost in power will, in time, surpass the initial cost of buying those coins.
Re:Blockchains from a Distributed Computing Perspective [pdf] by hyperion2010 on Saturday January 20, 2018 @12:36AM (#16192239)
I don't think so, though maybe I am misunderstanding. In the pathological case, imagine that a node has made no transactions at all for a year. The owner will have to go to look up how much money they have in the ledger before they can complete a transaction and discover they have no money. The space complexity of maintaining accounts is extremely small compared to maintaining transactions. All transactions that were associated with that account have been wiped from the public ledger. An archival ledger may keep a record of retired transactions, but the archival is not required to settle all accounts.
Re:Blockchains from a Distributed Computing Perspective [pdf] by ulrikrasmussen on Saturday January 20, 2018 @01:23AM (#16192339)
But that assumes that there is a trusted archival party that can verify account balances with authority. It may be technically possible to devise such a system, but as far as I understand, current decentralized blockchains require that you replay all previous transactions in order to learn the current state of the system.
Re:Blockchains from a Distributed Computing Perspective [pdf] by builditand on Saturday January 20, 2018 @03:50AM (#16192657)
I'm new to blockchains so I'm sorry if this is stupid, maybe somebody can explain to me.

Why do everybody needs to keep everything? The chain will be much smaller with just the id and the hash of the block. The payloads could be kept only by the interested parties and could be validated when needed with the chain.

Re:Blockchains from a Distributed Computing Perspective [pdf] by bringtheaction on Saturday January 20, 2018 @05:18AM (#16192845)
> Why do everybody needs to keep everything?

Because every node in the network must be able to verify all transactions all the way from the genesis block. In order to ensure that this is possible, everyone who keeps the history must keep the full history.

Re:Blockchains from a Distributed Computing Perspective [pdf] by tromp on Saturday January 20, 2018 @07:02AM (#16193064)
With the MimbleWimble design [1] [2], inputs may be cancelled against the outputs they spend, with no loss of security. Essentially, the entire blockchain history may be collapsed to a single mega transaction, with all coinbases as inputs and the UTXO set as outputs.

[1] http://mimblewimble.cash/20160719-OriginalWhitePaper.txt

[2] https://www.youtube.com/watch?v=ovCBT1gyk9c

Re:Blockchains from a Distributed Computing Perspective [pdf] by masterbit on Saturday January 20, 2018 @04:52AM (#16192795)
Look at R3 Corda, transactions only shared and stored between parties involved, not the rest of the network.
Re:Blockchains from a Distributed Computing Perspective [pdf] by drdrey on Saturday January 20, 2018 @01:28AM (#16192348)
> 1-2Tb

What blockchain are you talking about? The Bitcoin blockchain is between 150 and 160 GB

Re:Blockchains from a Distributed Computing Perspective [pdf] by garmaine on Saturday January 20, 2018 @03:06AM (#16192568)
Maybe he meant the UTXO set? Even that is off by a factor of 2 though.
Re:Blockchains from a Distributed Computing Perspective [pdf] by hyperion2010 on Saturday January 20, 2018 @06:04AM (#16192956)
Ya sorry, a bit of an exaggeration there. I was recalling the size of the hard disks that some folks routinely kept around just for storing crypto blockchains. That said, the actual numbers are already out of the rang for storage on the vast majority of commercially available mobile devices which basically relegates cryptos to enthusiasts. If we could fit a year worth of transactions in to on the order of 10 gigs, or at least provide a constant size estimate per unit time as a function of the number of transactions then we might be able to get adoption.
Re:Blockchains from a Distributed Computing Perspective [pdf] by garmaine on Saturday January 20, 2018 @06:45AM (#16193036)
Well a full node doesn't need to keep the full block chain around, just the UTXO set. But you're not going to be able to handle the bandwidth of a full block chain on a mobile device anyway (~1TB/mo).
Re:Blockchains from a Distributed Computing Perspective [pdf] by drdrey on Saturday January 20, 2018 @11:30AM (#16193935)
The blockchain grows at a constant linear rate, 1MB every 10 min or 144MB per day. Isn't that what you mean by "constant size estimate per unit time"?
Re:Blockchains from a Distributed Computing Perspective [pdf] by hyperion2010 on Saturday January 20, 2018 @05:36PM (#16195812)
The number you describe is a constant "change in size." What I describe is a constant maximum worst case "size." Yours would be velocity, mine would be position, function, derivative, etc.