Just as an aside, I had always assumed your ... err ... peculiar dialect was intentional. While your spelling and grammar are typically atrocious, you are obviously capable of reason.

Whatevs.

I still am waiting for anyone to explain to me how any aspect of the hard fork of the-coin-that-shall-not-be-named was in any way negative.

Forkers got what they wanted, stayers got what they wanted, aggregate market cap greater than ever. And there is now another leveraged trading vehicle for Bitcoin price arbitration. What's not to love?

I don't. While I do not know how many years would transpire for the world to adopt some mythical 'limitless bitcoin' as the default transaction mechanism, let us posit that it would be at least several years.

A three order of magnitude improvement is all it would take for us to hit Visa levels.

HDD capacity has increased more than three orders of magnitude in the last two decades.
It only took one decade (1997 to 2007) for internet aggregate throughput to do 1000x.
Single-chip MIPS did 10^3 from 1986 to 2006.

We can quibble over recent figures and such, but the trend is clear. Bitcoin can indeed scale to encompass the role of a worldwide default transaction medium. Are trends decelerating? Maybe, maybe not. Is the world wanting to adopt fully in two decades? Maybe, maybe not. But technology will at some time enable such.

I don't know what your talk of a secret meeting has to do with the quoted article, but the latter is intriguing. The idea that each transaction include an indication of the transferrer's 'best chain' -- as a 'user voting' mechanism -- might conceivably give some measure of power to non-mining nodes. (As they have none today, but that's a different convo.)

vim is one thing. But EDLIN does not buy additional geek cred. Merely pity. And disdain. Pity and disdain. Well, mostly disdain.

Not that I think that is implausible. After all, I am just parroting what I had heard. But... What are the figures?

How many gamers run dozens of GPUs at the same time?

First hit in a huge list returned by google: http://www.extremetech.com/computing/172381-massive-surge-in-litecoin-mining-leads-to-radeon-shortage

While it is admittedly a peripheral point:


I seem to recall reputable reports that for a time, Bitcoin mining was driving more than half of high-end graphics cards sales.

Understood. While it has been some time since I've been to a major Bitcoin symposium, who knows when our paths may cross. I'll leave the offer open.


Well, I can discuss write amp in generalities. But given that the command layer protocols abstract away the low-level physical mapping from upper layers, there is not much to be done by system software. As stated above, the techniques available above the device interface consist of the same things that have been known to benefit HDDs as well for quite some time.

Interestingly, HDDs are becoming more complex internally as well, with essentially the equivalent of SSD's FTL (Flash Translation Layer) handling fully indirected logical to physical block mapping. This is the case for several HDDs today, and this will be more prevalent as time goes on.

I don't know. If they are required to fully back all investment euros with actual Bitcoin at 1:1 ratio, then it's bullish. If regs allow them to do partial reserve, not so much.

While it is true that current NAND Flash based SSDs do indeed have the same fundamental issue you describe*, that complexity is completely abstracted from the user interface. There are no user accessible 'knobs or switches' which allow any layer above the native SCSI, ATA, or NVMe interface to dictate the physical placement of any logical block of data***.

* (incidentally, the issue you initially implied - erased flash is in a '1' state, while it takes a write to flip a bit to '0', thereby one might ensure subsequent writes to a given block only flip '1s' to '0s', is completely orthogonal to the (substitute) issue that NAND is written in pages, and multiple pages make up an erase block)


Sure, you can coalesce writes. You can do large writes. You can do sequential writes. These are things that work on HDD too, and have been known for roughly a half-century. But you cannot reach into the drive through the interface and dictate physical placement. At least not with any volume-shipping SSD.


No, I assure you that I am completely up to date - both with respect to shipping product, and well into things on the horizon for a good portion of the storage industry.

When a logical block is written, there is no way to dictate that it be written to a previously-written page that would require only 1>0 changes, due to the 0-bitmask of the new data being a proper superset of the 0-bitmask of the old data. Other than devices that do internal data reduction**, each written logical block is written to a physical block (part of a page) that has never been written since the last time that erase block has been erased.

**As for the case of controllers that perform data reduction, such a write ends up being a nop, as the data in the logical block already exists in entirety (in logical form) elsewhere in storage. The device merely creates a pointer to the existing data. Nevertheless, such controllers do not expose any interface by which some layer above the device might affect this behavior.

***Command standards have recently added Logical Block Markup Descriptors -- hints that certain logical blocks 'belong together' -- but these are hints, not directives, and are not yet supported by IO stacks in any OS likely to be employed as a Bitcoin node.

While I am not an SSD salesman, nor part of any Charles Hoskinson organization, I am a senior technologist in the research division of the largest developer of storage devices on the planet. Will you be at Flash Memory Summit week after next? I'd like to buy you a beer or coffee for more in-depth discussion.

Not according to gmaxwell. He has stated that Core does NOT verify all transactions since genesis.

I'll not editorialize about what you might want to think about that.

I'm guessing it is still here because it is a thread comparing two alt coins, in a sub dedicated to the discussion of such?

Way to go. A good mayor needs to set an example.

While this is true at a storage cell level, contemporary system architectures employ such NAND Flash not as raw devices, but within subsystems known as SSDs. SSDs maintain the same semantics at the interface as hard disk drives. These are block-access devices, where some larger construct - the logical block (typically 4096 or 512 bytes of user data) are read or written at one time (i.e., as an atomic unit). Such SSDs already manage all the writing internally, so as to make write behavior indistinguishable regardless of data pattern.

Some NAND and NOR Flash is sometimes included within a system, to be accessed directly via the pins of the chip package. These indeed can benefit from optimized flash file systems. However, these are typically small in size, and meant to save boot Firmware, BIOS settings and other non-user data items related to the management of the computer system itself. I am unaware of any typical commercially available system that employs such raw flash for general data storage suitable for the filesystem upon which one would store a blockchain database.

TL;DR, In today's environment, there is no benefit to application SW (e.g. a database system) managing writes to storage in a manner aware of bit polarity in relation to previous writes to same location. This, and other complications, are abstracted away by mechanisms within the underlying storage devices.

Somewhere between 25 and 50 MB... not that we need to match PayPal transaction volume today. 


Somewhere around 600MB-1GB ... not that we need to match Visa transaction volume today.

Why do you ask? Are these relevant targets for the foreseeable future? Would we not need a lot more users to create demand for that scale of transaction volume?

Cool! At first glance, this seems to have worked. Attached to the email was a 'wallet-dump-<<inscrutableinteger>>.txt', which looks promising as to being a repository containing all transactions. That sound correct?

I thought that in posting my query on the sub-forum dedicated to the Bitcoin Wallet for Android (i.e. Schildbach) wallet, it would like be clear that I am asking about the Bitcoin Wallet for Android (i.e. Schildbach) wallet.

But maybe it wasn't clear.

I am trying to do this regarding an existing installation of the Bitcoin Wallet for Android (i.e. Schildbach) wallet, which is installed on a phone I am decommissioning.

Haha. Man, I'm so not with the kul-cha. How long has that Shia LaBeouf thing been circling the innertubez? Brilliant!

AAR, Yes. Just Do It. I've been running BU for about a half-year, configured large. Ready for the day that the miners wake & make their move.

Just Do It!

Thanks Andreas. I'm not, however, looking to move it to a new phone (I've jumped to iOS). I am just looking to capture a transaction history in human-readable format, so I can handle capital gains tax at end of tax year.

Sounds like I am out of luck?