On Mon, 2 Jul 2018 06:49:04 -0700 Steven Schear wrote:

In 2013, a paper I contributed to offered a solution to the ever growing blockchain delema: a finite epoch. The solution is similar the one Chaum used on Digicash. It would fix, temporally, the blockchain to include only transactions for the past 2 years,

and what happens to funds older than 2 years? "Any money still held from transactions in these blocks would be freed up, and released back to the network in the form of a lottery." lolwut - that's trolling, right? =)

for example, thus creating a blockchain of tractable and predictable size for affordable full nodes.

https://www.coindesk.com/bitcoin-activists-suggest-hard-fork-to-bitcoin-to-k...

More recently, I've co-written a paper proposing a distributed service solution that could solve thin wallet privacy and security issues without needing to trust individual full nodes under the control of others.

On Mon, 2 Jul 2018 17:59:30 -0400 grarpamp wrote:

...

lolwut - that's trolling, right? =)

The beauty of cryptocurrency is that it's new, not some tired old govenment fiat money

yeah well - not even the most fucked up government wants to wipe out savers every two years. Here in argentina that happens every 10 years or so, and only if you are using banks. I'm not sure how robbing everybody blind is a 'new experiment' by the way.

same game since thousands of years. So all manner of new models can now be tried, new expectations, thought, training, usage parameters, flag days, morphing, etc... so many possibilities... eventually a handful reaching adoption.

oh of course that principle is fine.

Cryptocurrency isn't trolling... it's time.

yeah - and you better come up with something which is at least as untraceable as government cash. Otherwise, we'll have to conclude that yes, this is cryptocurrency's time because crypto will allow highly increseased levels of totalitarianism in line with current, highly totalitarian trends.

On Mon, 2 Jul 2018 16:29:15 -0700 Steven Schear wrote:

A rolling epoch, as suggested in the paper, not only helps keep the blockchain length tractable it also prevents "submarining" from assets which haven't moved since the early days of a blockchain (e.g., Satochi/Finney and new blockchain pre-mining).

So let me be as clear as possible. You are barefacedly proposing to EXPROPRIATE all savers every 2 years. I assumed you were some sort of right winger(you linked 'anarcho' fascist site mises.org in the past) but you are actually a radical commie? oh well....Sorry, are you really really sure you are not trolling?

On Sunday, July 1, 2018, 11:09:34 PM PDT, juan wrote: On Mon, 2 Jul 2018 00:22:03 -0400 grarpamp wrote:  "   as you know grarpamp (or maybe you dont know?) the size of bitcoins ledger is ~200 gbytes at the moment. " On Amazon, I see a 200 GB micro SD card being sold for $71.  A 256 GB micro SD card is sold for $120.  Rather spendy, but within the realm of possibility. About "a Gigabyte::  In my college days, 1978, we had a comedic, fictional dormitory organization called "TWePOE"  ("Third West Power Elite").   I, the only one with a functional personal computer on my hallway (my own homebrew "Bellyache I", a comedic take on the famous "ILLIAC 4), my room became the "GBDSC", short for "Gigabyte Data Storage Center", a subsidiary of the organization "MOIA", short for "Ministry of Information Abuse", whose ominous motto was, "We've got a file on YOU!" I chose "Gigabyte" because, at that time, it was such an inconceivably fantasticly large amount of data storage so as to be awe-inspiring.  (An 8 inch SSSD floppy disk stored a grand 240 kilobytes of data, so it would have taken more than 4100 of them to house a full gigabyte.)  Today, the idea that I could buy 1 million times the storage of one of those 240 kilobyte floppies, held in a wafer smaller than my pinky-fingernail, remains amazing to me.           Jim Bell        

I guess for you the article is a TL;DR. There was NOT a suggestion of simple confiscation. All one had to do, to prevent "reclamation", is to periodically move assets on the blockchain. On Jul 2, 2018 5:19 PM, "juan" wrote: On Mon, 2 Jul 2018 22:37:15 +0000 (UTC) jim bell wrote:

On Sunday, July 1, 2018, 11:09:34 PM PDT, juan

wrote:

On Mon, 2 Jul 2018 00:22:03 -0400 grarpamp wrote:

" as you know grarpamp (or maybe you dont know?) the size of bitcoins

ledger is ~200 gbytes at the moment. "

On Amazon, I see a 200 GB micro SD card being sold for $71. A 256 GB

micro SD card is sold for $120. Rather spendy, but within the realm of possibility. And? You can buy a 2 terabytes HD for $50 or so(or less?). I suggest you do that if you want to store the blockchain, SD cards aren't reliable - HDs are cheaper and better. But guess what? Storage isn't the problem anyway. The problem is that peers have to transmit and process the whole ledger. And the answer "so called moore's law will magically solve everything" isn't too convincing.

About "a Gigabyte:: In my college days, 1978, we had a comedic,

fictional dormitory organization called "TWePOE" ("Third West Power Elite"). I, the only one with a functional personal computer on my hallway (my own homebrew "Bellyache I", a comedic take on the famous "ILLIAC 4), my room became the "GBDSC", short for "Gigabyte Data Storage Center", a subsidiary of the organization "MOIA", short for "Ministry of Information Abuse", whose ominous motto was, "We've got a file on YOU!"

I chose "Gigabyte" because, at that time, it was such an inconceivably

Today, the idea that I could buy 1 million times the storage of one of

fantasticly large amount of data storage so as to be awe-inspiring. (An 8 inch SSSD floppy disk stored a grand 240 kilobytes of data, so it would have taken more than 4100 of them to house a full gigabyte.) those 240 kilobyte floppies, held in a wafer smaller than my pinky-fingernail, remains amazing to me.

Jim Bell

Couldn’t we just prune the old spent transactions in the blockchain and keep the chain and dB smaller

On Jul 3, 2018 at 6:58 AM, wrote:

On Mon, 2 Jul 2018 17:50:02 -0700 Steven Schear wrote:

...

I guess for you the article is a TL;DR. There was NOT a suggestion of simple confiscation. All one had to do, to prevent "reclamation", is to periodically move assets on the blockchain.

I know. So if you for whatever reason fail to move your funds they are stolen. Doesn't seem like a sensible protocol. Also, moving funds every a fixed period seems like a good way to make tracking easier?

Last but not least what do you gain by forcing people to create new UTXOs from existing UTXOs?? Most of the data in the ledger is old spent transactions which are mostly useless*, except they are needed to make sure the supply hasn't been tampered with.

*except for spying that is.

This "reclamation", on a blockchain such as implemented BTC currently, has no privkeys and cannot "reclaim" or "steal" any coin to any address, it can just erases them from the chain without further issuance. Call it erasing instead, a dick move since... The expectation of BTC and most other schemes of blockchains to date from their inception is that you don't need to in any way mark current, refresh, or forward activity spend any transaction, and that old contracts multisig txs etc always remain valid over time. Users with value on those chains, whether bound in contracts or owned, will refuse and revolt against any such invalidation attempts, or migrate value through exchange to other coins when that is the only cheaper option to such an attack. The time to invent such lossy or activity requirements is in new coins that set such expectations of dynamism to their users at launch. Storage... though density and compute may continue "Moore's", preparing for if it doesn't, or simply to optimize and reduce consumption and carriage, seems prudent where available and sensible regardless. Technically only the UTXO set... past a certain window count of confirmations sufficient to discourage all future spending / mining attacks upon any shorter windows of it... is relavant to most BTC style and other blockchains. The window size is some estimate of excess of future computing power and other attack methods and surfaces, converted to a block height. For example, one year to six months of confirmations might be sufficiently immune, perhaps even approaching applied real world difficulty of compromising a / many signing key[s] eg: UTXO's. History beyond that window count is irrelavant to determining real world validity of a UTXO. History's only use thereafter is for anti-privacy dataminers trying to regulate control blackmail censor tax terminate etc, both you and cryptocurrency. These anti's are secretly embedded in every cryptocurrency project, and abound in the rest of the world, and will resist proposals to create history free coins and operation. They'll datamine anyway the stupid non-private coins like BTC, but they can't do that with strong cryptographic privacy coins, like ZEC, that use ZKP's. Users simply do not need that history on disk, nor do nodes need to be passing it around as bootstrap. Users can set a flag to listen for and retain their own histories if they need some blockchain style proofs for whatever purposes. And just as users might pay for their own disk / bandwidth to maintain history since Genesis, they can just as easily pay the dataminers instead, up until even the dataminers possibly cannot afford to keep it, or the irrelavance of age hits. To do this the software upgrades to a protocol that not only mines the UTXO set into a form of current meta transaction blocks like BTCP did to bootstrap ZCL + BTC = BTCP into its launch... but also does this checkpointing periodically at programmed heights, adding confirmations to the latest UTXO meta tx block sets. Everyone holds at least one sufficiently confirmed set which is then used as bootstrap for clients similar to BTCP. Clients refer to the recent set and the confs over it to validate received value. Clients will scan forward from a well confirmed set to see if something was subsequently spent in the usual fashion, thus avoiding race and poorly confirmed status of newly published sets. They might also consider the embedded signatures of some plurality of miners over UTXO sets for bootstrap purposes, or some live network method, including referring to the dataminers, to serve any need to fill in for now missing genesis path. Thus the impact of natural tx growth on storage space and validity referencing CPU time becomes smaller, now expressed in terms of size of the few UTXO sets needed (perhaps no more than two or three) and their window sizes. That's one of the ideas that has been out there for existing blockchains. Another one is splitting and distributing the data storage for reference across the p2p nodes via DHT indexes. ie: 100000 nodes, 10 levels redundant... a million nodes, smaller than even the bittorrent cloud. The ideas seem more like underhood scaling optimizations, than being "sidechains / lightning / forks / alt / shit / central" solutions (as some say now affect BTC) away from further exploring closer to original "Satoshi' architechtures. A lot of people are now looking closely at BCH with its rising adoption (even now surpassing BTC in areas), and others, to be shining examples of that exploration. Who knows, it's still early days for all things cryptocurrency. The right combination of factors leading to long term adoption of say a max of five leading coins covering the range of blockchain use cases probably hasn't been found yet. Stay nimble my friends.

On Sat, 21 Jul 2018 23:19:11 -0400 grarpamp wrote:

"a few servers in a datacenter"... sounds fatally cerntralized.

I was paraphrasing =P - here's the 1000% 'authentic' quote : https://www.mail-archive.com/cryptography@metzdowd.com/msg09964.html " Long before the network gets anywhere near as large as that, it would be safe for users to use Simplified Payment Verification (section 8) to check for double spending, which only requires having the chain of block headers, or about 12KB per day. Only people trying to create new coins would need to run network nodes. At first, most users would run network nodes, but as the network grows beyond a certain point, it would be left more and more to specialists with server farms of specialized hardware. A server farm would only need to have one node on the network and the rest of the LAN connects with that one node. The bandwidth might not be as prohibitive as you think. A typical transaction would be about 400 bytes (ECC is nicely compact). Each transaction has to be broadcast twice, so lets say 1KB per transaction. Visa processed 37 billion transactions in FY2008, or an average of 100 million transactions per day. That many transactions would take 100GB of bandwidth, or the size of 12 DVD or 2 HD quality movies, or about $18 worth of bandwidth at current prices. If the network were to get that big, it would take several years, and by then, sending 2 HD movies over the Internet would probably not seem like a big deal. Satoshi Nakamoto "