[XMR] Monero Improvement Technical Discussion

[smooth]

What is missing from your analysis smooth is that at what level of featureness are businesses willing to embrace block chains. I argue CN/RingCT is below the acceptable level and can not be raised to that level because the fundamentals are not End-to-End principled (also because can only make the payers, payees, and values obscured and not any type of script and other aspects of the block chain data). Business will prefer private databases where they can hide all the data until public block chains mature enough to do so. Public block chains promise more interoption and network effects, once we can make them truly private.

There is no feasible technology to do non-trivial scripts using zksnarks at this time. It doesn't exist. Zerocash is pushing the limits already.

While there may be a market for zero knowledge smart contracts on a blockchain, that doesn't even matter because it can't be implemented.

Perhaps if you think that is the only market that exists you should just take a break and come back to the space in a few years and reevaluate.

[1714884955]

1714884955

[1714884955]

1714884955

[TPTB_need_war]

What is missing from your analysis smooth is that at what level of featureness are businesses willing to embrace block chains. I argue CN/RingCT is below the acceptable level and can not be raised to that level because the fundamentals are not End-to-End principled (also because can only make the payers, payees, and values obscured and not any type of script and other aspects of the block chain data). Business will prefer private databases where they can hide all the data until public block chains mature enough to do so. Public block chains promise more interoption and network effects, once we can make them truly private.

There is no feasible technology to do non-trivial scripts using zksnarks at this time. It doesn't exist. Zerocash is pushing the limits already.

While there may be a market for zero knowledge smart contracts on a blockchain, that doesn't even matter because it can't be implemented.

Perhaps if you think that is the only market that exists you should just take a break and come back to the space in a few years and reevaluate.

You are cherry picking points. zk-snarks scripts wasn't my only nor even my main justification.

Afaik, zk-snarks can implement any circuit if one accepts the proving time and verification time (there might also be some other resource constraint such as RAM but I think not), with proving time being much worse than verification time. And one would expect that it can be radically sped up with ASICs to enable more complex circuits to be verified in realistic time!

The point is there are very likely some simple scripts that can surely be done with zk-snarks in realistic times, and which are very useful for businesses interopting on the block chain. IoT is one likely candidate and probably many more.

"build it and they will come after 5 years" is a nice pitch to speculators, but in my line of work I had to produce a marketed product to earn an income. You worked in (programming for) finance (something you acknowledged recently in public post) thus  I assume you never had to do this. So I understand that in for-profit software the mantra is "ship it, sell it", otherwise projects go on and on and on and are never finished.

[smooth]

What is missing from your analysis smooth is that at what level of featureness are businesses willing to embrace block chains. I argue CN/RingCT is below the acceptable level and can not be raised to that level because the fundamentals are not End-to-End principled (also because can only make the payers, payees, and values obscured and not any type of script and other aspects of the block chain data). Business will prefer private databases where they can hide all the data until public block chains mature enough to do so. Public block chains promise more interoption and network effects, once we can make them truly private.

There is no feasible technology to do non-trivial scripts using zksnarks at this time. It doesn't exist. Zerocash is pushing the limits already.

While there may be a market for zero knowledge smart contracts on a blockchain, that doesn't even matter because it can't be implemented.

Perhaps if you think that is the only market that exists you should just take a break and come back to the space in a few years and reevaluate.

You are cherry picking points. zk-snarks scripts wasn't my only nor even my main justification.

Afaik, zk-snarks can implement any circuit if one accepts the proving time and verification time (there might also be some other resource constraint such as RAM but I think not), with proving time being much worse than verification time. And one would expect that it can be radically sped up with ASICs to enable more complex circuits to be verified in realistic time!

All of this is entirely consistent with what I said about coming back in a few years. The proving and verification times for Zerocash, with the most simple scripts possible, are barely feasible to use, and even that might be disputed.

The point is there are very likely some simple scripts that can surely be done with zk-snarks in realistic times, and which are very useful for businesses interopting on the block chain. IoT is one likely candidate and probably many more.

Implementing custom scripts for specific use cases is way out of scope for Monero as I understand the project. But it is open source after all, so if interesting pull requests are submitted they would probably be merged (after sufficient testing and review). That could include "useful" scripts along with an open source zksnark library.

"build it and they will come after 5 years" is a nice pitch to speculators, but in my line of work I had to produce a marketed product to earn an income. You worked in (programming for) finance (something you acknowledged recently in public post) thus  I assume you never had to do this. So I understand that in for-profit software the mantra is "ship it, sell it", otherwise projects go on and on and on and are never finished.

Again consistent with take a break and come back when the technology is ready for a "build it, ship it, sell it" approach.

Also this is entirely irrelevant to Monero since Monero is an open source project not a product. So off topic for the thread. Please respect the thread starter, the forum, and the community and try to stay on topic.

[TPTB_need_war]

You say that zk-snarks can't do any worthwhile scripts, yet an entirely anonymous coin has been implemented it that is superior anonymity than CN/RingCT.

Your stubbornness is the main reason I can't work with you. Leadership requires symbiosis of ideas and directions. It requires vision.

Smooth it is quite evident that open source needs leadership. Direction is not likely to be driven by random contributor (if he was that capable, he would fork or otherwise start his own than battle against the leadership which is not that focused on the direction the contributor wants to go).

Edit: you apparently haven't even yet quantified the metrics, which is pretty lame for a competitor not to do.

Edit#2: perhaps if you all spent less time talking about market movements on the exchanges, and more time doing technical research and marketing research...

[FreeTrade]

Wondering if anyone has looked at the possibility of using the iPhone as a mining device. I understand that since the 5S, AES has been present in the hardware, AES hardware being essential for efficient cryptonight mining. A combined wallet/miner app could be very compelling. I'm thinking mining while charging overnight. Certainly require jailbreaking the device if it's possible at all.

[ArticMine]

There was nothing on-topic ("Improvement Technical Discussion") in your last post, thus no need for any further response. Please stay on topic.

Yeah I didn't want to delete things because I just figured this would run its course eventually so might as well. Are we done?

So five pages ago I posted this


So I was reading this
http://www.scribd.com/doc/273443462/A-Transaction-Fee-Market-Exists-Without-a-Block-Size-Limit#scribd

and my thoughts started to drift when I encountered the concept that orphanization is one of the impediments to picking what to mine and the whole block size fee market debate etc...

Is there any work in this space regarding what could be called sister blocks, or fusion blocks?

Basically, the way I understand it (and granted, my assumptions could be flawed) is that there exists a set of transactions in the mempool. We'll just use 5 here

Trans1
Trans2
Trans3
Trans4
Trans5

If miner A decides to put 1,2,3 in his block (block A), and miner B decides to put 3,4,5 in his block (block B), they are both technically valid blocks (they both have the previous block's hash and contain valid transactions from the mempool). However, due to the nature of satoshi consensus, if block A makes it into the chain first, block B becomes orphan - even though it is entirely valid.

It's even easier to understand the inefficiency of satoshi consensus if block A has 1,2,3 and block B has 4,5. In this case, there's really no reason both blocks aren't valid.

I see now as I continue to think about this the problem lies in the transaction fees associated with each transaction, for if they exist in two blocks, which block finder gets the reward? But this isn't an intractable problem.

Essentially what I'm thinking is that you can imagine these two blocks existing as blebs on the chain.
                             .
._._._._._._._._._./
                            \,

each dot is a block, and the comma indicates a sister block
in current protocol, this would happen
                             ._._._
._._._._._._._._._./
                            \,_,

And eventually one chain would grow longer (which is ultimately influenced by bandwidth) and the entire sister chain would be dropped, and if your node was on that chain you'd experience a reorg (right?).

why couldn't something be implemented where the above fork turns into a bleb

                            .
._._._._._._._._._./\.
                            \,/

which is eventually resolved to a fusion block

._._._._._._._._._._!_._


where the ! indicates a fusion block. When encountering a potential orphan scenario (daemon receives two blocks in close proximity, or already has added a block but then receives a similar block for the same block height) instead of the daemon rejecting one as orphan, it scans the sister block as a candidate for fusion. There would be some parameters (X% of transactions overlap, only concurrent block height are candidates (this is effectively the time window)). As part of this, the system would somehow need to be able to send transaction fees to different blockfinders, but again this seems tractable (though I await to be schooled as to why its not possible). In addition, the block reward itself would need to be apportioned.

Or is this what a reorg does? The way I understand reorgs, this is different than a reorg.

Though upon creation of the fusion block a reorganization would have to occur. So at the cost of overall bandwidth we provide a countermeasure for the loss of economic incentive for large blocks.

And one problem to address is that you would need a new block header for the fusion block, but this could really just be the hash of the two sister blocks. Both sisters are valid, therefore the hash of those valid blocks is valid.

Ok back to work.


Is the above possible or am I crazy?

Edited to add: I will be enforcing the moderation again. Please talk technical improvements to monero.

First here is a link to Peter R's paper without all the marketing clutter generated by Scribd http://www.bitcoinunlimited.info/downloads/feemarket.pdf.

My take is that the solution to this issue is to mitigate it by creating a proper fee market in Monero. This is something I am actually very interested in working on. In such a scenario the blocks in the memory pool would have an order of fees per KB and a rational miner would prioritize blocks in order of return while the sender would pay a fee depending on the priority desired for a transaction. The existing penalty function for oversize blocks in Monero provides a start but it and the fee structure will likely, have to be optimized in such a way that minimizes the cost to legitimate users while maximizing the cost of spam and attacks.  

[GingerAle]

There was nothing on-topic ("Improvement Technical Discussion") in your last post, thus no need for any further response. Please stay on topic.

(snipped fusion block concept, left the meat of it)

why couldn't something be implemented where the above fork turns into a bleb

                            .
._._._._._._._._._./\.
                          \,/

which is eventually resolved to a fusion block

._._._._._._._._._._!_._

First here is a link to Peter R's paper without all the marketing clutter generated by Scribd http://www.bitcoinunlimited.info/downloads/feemarket.pdf.

My take is that the solution to this issue is to mitigate it by creating a proper fee market in Monero. This is something I am actually very interested in working on. In such a scenario the blocks in the memory pool would have an order of fees per KB and a rational miner would prioritize blocks in order of return while the sender would pay a fee depending on the priority desired for a transaction. The existing penalty function for oversize blocks in Monero provides a start but it and the fee structure will likely, have to be optimized in such a way that minimizes the cost to legitimate users while maximizing the cost of spam and attacks.  

I don't know if we're talking about the same issue.  I'f I'm not mistaken the bolded above is actually quite possible and could already be implemented with the existing code. My question revolves around this: In a world where monero is the blockchain and has very high activity, these large blocks that will be created will probably cause centralization to occur on infrastructure that has high bandwidth. This is simply because those nodes connected to each other on wide pipes will be able to sling 200 MB blocks to each other. The first miner to get a new 200 MB block has the best chance of making the next block. Thats satoshi consensus, right?

To keep it decentralized, we need to find a way to keep the narrow-pipe miners in the game. The fusion block concept above may do that. Actually, the fusion block with the light block concept would really do the trick.

So ultimately, yes, the fee market will exist. But even with a fee market we still run into the centralization problem. Thus, instead of slinging 200 MB blocks around, a blocksolver can send the blockindex in advance (I've described this concept in the lightblock thing) which is significantly smaller, and a miner having received this blockindex can immediately create an alternative block that doesn't include these transactions, and either attempt to create a fusion block or the next block.

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

[smooth]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

[GingerAle]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

Okay. So it would be a completely different approach / context than merged mining? I was thinking merged mining might be possible with self.

[smooth]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

Okay. So it would be a completely different approach / context than merged mining? I was thinking merged mining might be possible with self.

I suppose you could possibly do that but I don't understand the purpose. Merged mining doesn't really add any security unless there are added rewards to mining (which would then increase the hash rate).

[GingerAle]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

Okay. So it would be a completely different approach / context than merged mining? I was thinking merged mining might be possible with self.

I suppose you could possibly do that but I don't understand the purpose. Merged mining doesn't really add any security unless there are added rewards to mining (which would then increase the hash rate).

The goal of fusion blocks (and any offshoot) isn't to explicitly increase security, it is a countermeasure for orphanization, which I think is the primary reason large blocks are feared to cause centralization. You fix the orphanization problem, you fix the largeblock decentralization problem.

As detailed above, if there are 10 transactions in the pool, you could (with the right software and protocol mods) simultaneously make 2 blocks - 1 block has transactions 1 through 5, the second block has transactions 6 - 10. If you find a solution for 6-10, you broadcast the block, add it to the chain etc. However, it turns out your on a high-lag part of the network, so while you found your 6-10 block solution, someone else found a solution for 1-5. What I'm calling for is a protocol mod that would allow the daemon to recognize that two blocks are competing for the same blockheight but both are valid so they should be fused.

Merged mining of self is just a piece of this.

[smooth]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

Okay. So it would be a completely different approach / context than merged mining? I was thinking merged mining might be possible with self.

I suppose you could possibly do that but I don't understand the purpose. Merged mining doesn't really add any security unless there are added rewards to mining (which would then increase the hash rate).

The goal of fusion blocks (and any offshoot) isn't to explicitly increase security, it is a countermeasure for orphanization, which I think is the primary reason large blocks are feared to cause centralization. You fix the orphanization problem, you fix the largeblock decentralization problem.

As detailed above, if there are 10 transactions in the pool, you could (with the right software and protocol mods) simultaneously make 2 blocks - 1 block has transactions 1 through 5, the second block has transactions 6 - 10. If you find a solution for 6-10, you broadcast the block, add it to the chain etc. However, it turns out your on a high-lag part of the network, so while you found your 6-10 block solution, someone else found a solution for 1-5. What I'm calling for is a protocol mod that would allow the daemon to recognize that two blocks are competing for the same blockheight but both are valid so they should be fused.

It is also the case that if one block includes transactions 1,2,3,4, and 5, while another block includes 3,4,5,6, and 7, they can still be merged as long as transactions 3,4, and 5 are identical. So with this observation you can just pick any subset of transactions you want.

There is an issue that such blocks can be incompatible if they include incompatible (double spend) transactions. Then you get into what sort of rules to use to resolve the conflict and what sorts of attacks that allows.

There are various people working on ideas like that.

See "Breaking the chains of blockchain protocols" and "Braiding the chain" here: https://scalingbitcoin.org/hongkong2015/#presentations

[GingerAle]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

Okay. So it would be a completely different approach / context than merged mining? I was thinking merged mining might be possible with self.

I suppose you could possibly do that but I don't understand the purpose. Merged mining doesn't really add any security unless there are added rewards to mining (which would then increase the hash rate).

The goal of fusion blocks (and any offshoot) isn't to explicitly increase security, it is a countermeasure for orphanization, which I think is the primary reason large blocks are feared to cause centralization. You fix the orphanization problem, you fix the largeblock decentralization problem.

As detailed above, if there are 10 transactions in the pool, you could (with the right software and protocol mods) simultaneously make 2 blocks - 1 block has transactions 1 through 5, the second block has transactions 6 - 10. If you find a solution for 6-10, you broadcast the block, add it to the chain etc. However, it turns out your on a high-lag part of the network, so while you found your 6-10 block solution, someone else found a solution for 1-5. What I'm calling for is a protocol mod that would allow the daemon to recognize that two blocks are competing for the same blockheight but both are valid so they should be fused.

It is also the case that if one block includes transactions 1,2,3,4, and 5, while another block includes 3,4,5,6, and 7, they can still be merged as long as transactions 3,4, and 5 are identical. So with this observation you can just pick any subset of transactions you want.

There is an issue that such blocks can be incompatible if they include incompatible (double spend) transactions. Then you get into what sort of rules to use to resolve the conflict and what sorts of attacks that allows.

There are various people working on ideas like that.

See "Breaking the chains of blockchain protocols" and "Braiding the chain" here: https://scalingbitcoin.org/hongkong2015/#presentations

marvelous, thanks for the leads.

I think in general, for the bolded, it would be kept as simple as possible. That braid paper seems to have really taken this to an extreme. Ultimately, I think orphanization should still be possible, it should just be less likely to occur. Braiding, or fusion, or whatver its called, should only be allowed to happen at fresh blockheights. Not deep. Cohorts / siblings? too much. Or thats an eventuality that can be figured out later.

[smooth]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

Okay. So it would be a completely different approach / context than merged mining? I was thinking merged mining might be possible with self.

I suppose you could possibly do that but I don't understand the purpose. Merged mining doesn't really add any security unless there are added rewards to mining (which would then increase the hash rate).

The goal of fusion blocks (and any offshoot) isn't to explicitly increase security, it is a countermeasure for orphanization, which I think is the primary reason large blocks are feared to cause centralization. You fix the orphanization problem, you fix the largeblock decentralization problem.

As detailed above, if there are 10 transactions in the pool, you could (with the right software and protocol mods) simultaneously make 2 blocks - 1 block has transactions 1 through 5, the second block has transactions 6 - 10. If you find a solution for 6-10, you broadcast the block, add it to the chain etc. However, it turns out your on a high-lag part of the network, so while you found your 6-10 block solution, someone else found a solution for 1-5. What I'm calling for is a protocol mod that would allow the daemon to recognize that two blocks are competing for the same blockheight but both are valid so they should be fused.

It is also the case that if one block includes transactions 1,2,3,4, and 5, while another block includes 3,4,5,6, and 7, they can still be merged as long as transactions 3,4, and 5 are identical. So with this observation you can just pick any subset of transactions you want.

There is an issue that such blocks can be incompatible if they include incompatible (double spend) transactions. Then you get into what sort of rules to use to resolve the conflict and what sorts of attacks that allows.

There are various people working on ideas like that.

See "Breaking the chains of blockchain protocols" and "Braiding the chain" here: https://scalingbitcoin.org/hongkong2015/#presentations

marvelous, thanks for the leads.

I think in general, for the bolded, it would be kept as simple as possible. That braid paper seems to have really taken this to an extreme. Ultimately, I think orphanization should still be possible, it should just be less likely to occur. Braiding, or fusion, or whatver its called, should only be allowed to happen at fresh blockheights. Not deep. Cohorts / siblings? too much. Or thats an eventuality that can be figured out later.

I think you will find that the added complexity is needed to prevent various attacks where miners can get extra credit beyond what they deserve based on work done, or get more control of the chain with less hash power.

[GingerAle]

And finally, is there any reason why a miner can't be working on different blocks simultaneously?

Yes, the nature of proof of work is such that you can only work on one block at a time. Of course you can multitask, but the hash rate would just be lower on each one, so I'm not sure why you would want to do that.

Okay. So it would be a completely different approach / context than merged mining? I was thinking merged mining might be possible with self.

I suppose you could possibly do that but I don't understand the purpose. Merged mining doesn't really add any security unless there are added rewards to mining (which would then increase the hash rate).

The goal of fusion blocks (and any offshoot) isn't to explicitly increase security, it is a countermeasure for orphanization, which I think is the primary reason large blocks are feared to cause centralization. You fix the orphanization problem, you fix the largeblock decentralization problem.

As detailed above, if there are 10 transactions in the pool, you could (with the right software and protocol mods) simultaneously make 2 blocks - 1 block has transactions 1 through 5, the second block has transactions 6 - 10. If you find a solution for 6-10, you broadcast the block, add it to the chain etc. However, it turns out your on a high-lag part of the network, so while you found your 6-10 block solution, someone else found a solution for 1-5. What I'm calling for is a protocol mod that would allow the daemon to recognize that two blocks are competing for the same blockheight but both are valid so they should be fused.

It is also the case that if one block includes transactions 1,2,3,4, and 5, while another block includes 3,4,5,6, and 7, they can still be merged as long as transactions 3,4, and 5 are identical. So with this observation you can just pick any subset of transactions you want.

There is an issue that such blocks can be incompatible if they include incompatible (double spend) transactions. Then you get into what sort of rules to use to resolve the conflict and what sorts of attacks that allows.

There are various people working on ideas like that.

See "Breaking the chains of blockchain protocols" and "Braiding the chain" here: https://scalingbitcoin.org/hongkong2015/#presentations

marvelous, thanks for the leads.

I think in general, for the bolded, it would be kept as simple as possible. That braid paper seems to have really taken this to an extreme. Ultimately, I think orphanization should still be possible, it should just be less likely to occur. Braiding, or fusion, or whatver its called, should only be allowed to happen at fresh blockheights. Not deep. Cohorts / siblings? too much. Or thats an eventuality that can be figured out later.

I think you will find that the added complexity is needed to prevent various attacks where miners can get extra credit beyond what they deserve based on work done, or get more control of the chain with less hash power.

Very likely. I doubt in my random musings I'm going to stumble into obvious answers. In general though its good to see people working on this in bitcoin. Should be easy to integrate into other cryptocurrencies, especially those where network latency will really cause problems (e.g., adaptive blocksize like ours).

Is the bolded related to an instance where A is transaction 1,2,3,4,5 and A' is 5,6?

And blocks don't need to have multiple parents to get rid of orphans. What this whole thing depends on is the frequency of orphanization, and I don't know what it is, but I doubt its 100%. These two papers seek to replace blocks with something else. I think something can be made that coexists with blocks. I.e., you have A and A'. Both are valid. So you then add a meta-block (hashes those two blocks) that describes the details "block A and A' are both ok. treat the union set as single transactions, treat those outside the union set as single single transactions". All of this might actually be done at the re-org level.

I guess what you might be getting at is the problem of "well if A' is found, and then that propagates, and then A'+1 is found before A and A' are sewn together into a fusion block, then what?" I think the simple answer is that A'+1 then gets orphaned.

[GingerAle]

There are ways around this, such as out-of-band signaling, or recipient-provided keys. There are different trade-offs, though, and I haven't yet found the "perfect" one.

I figured you could just scan the blockchain without saving it. So basically find a way to get the daemon to synchronize with the network without saving the blockchain, and get simplewallet to scan those dloaded blocks as the daemon synchronizes.

Of course you can do that but (with some recognition of MKN's laws) does it really make sense to expect someone on a cell phone to receive and scan every transaction being generated by millions or billions of people? Probably not.

My personal favorite for in-person transactions is that the sender signs the transaction, transmits it locally to the recipient via QR/NFC/BT/etc., and the recipient transmits it to the blockchain. In doing so the recipient now knows which transactions require confirmation and scanning. The rest can be ignored. As luigi said though, there are multiple approaches that can work for different use cases.

In the original post, he didn't explicitly mention the user would be on a phone. I'm imagining a scenario where the blockchain is 600 gigs.. you surely don't need to keep all of it on your home PC. I think this has all been hashed out here: ... well, I can't find it on the forum.getmonero.org site. Basically some thread discussed different node setups - archival nodes (whole blockchain) vs. light nodes (part of the blockchain).

The in-person thing is a different boat with similar problems.

[smooth]

There are ways around this, such as out-of-band signaling, or recipient-provided keys. There are different trade-offs, though, and I haven't yet found the "perfect" one.

I figured you could just scan the blockchain without saving it. So basically find a way to get the daemon to synchronize with the network without saving the blockchain, and get simplewallet to scan those dloaded blocks as the daemon synchronizes.

Of course you can do that but (with some recognition of MKN's laws) does it really make sense to expect someone on a cell phone to receive and scan every transaction being generated by millions or billions of people? Probably not.

My personal favorite for in-person transactions is that the sender signs the transaction, transmits it locally to the recipient via QR/NFC/BT/etc., and the recipient transmits it to the blockchain. In doing so the recipient now knows which transactions require confirmation and scanning. The rest can be ignored. As luigi said though, there are multiple approaches that can work for different use cases.

In the original post, he didn't explicitly mention the user would be on a phone. I'm imagining a scenario where the blockchain is 600 gigs.. you surely don't need to keep all of it on your home PC. I think this has all been hashed out here: ... well, I can't find it on the forum.getmonero.org site. Basically some thread discussed different node setups - archival nodes (whole blockchain) vs. light nodes (part of the blockchain).

The in-person thing is a different boat with similar problems.

Of course you don't have to keep the whole blockchain. Pruning is fine, but it only addresses the storage component and doesn't help with the bandwidth and scanning (or more generally "processing") issues at all.

[TPTB_need_war]

I didn't intend to post in this thread again, but seems I remember Monero would soon add multi-sig, and I wanted to make you aware of a potential 51% attack hole enabled by multi-sig:

https://bitcointalk.org/index.php?topic=1364951.msg14002317#msg14002317

[ArticMine]

I didn't intend to post in this thread again, but seems I remember Monero would soon add multi-sig, and I wanted to make you aware of a potential 51% attack hole enabled by multi-sig:

https://bitcointalk.org/index.php?topic=1364951.msg14002317#msg14002317

Thanks

[GingerAle]

I was doing some research on long term storage solutions for work and came across the notion that the factor that limits a SSD's life is the number of writes performed. Reading from a cell doesn't really kill the cell, its the need to write to a cell that will eventually kill it.

So, my question is whether LMDB currently (or can be modified to) only write to the database once for a given entry.

My gut tells me that - yeah - because the blockchain is just a database, then once your node is sync'd up, everything is written. However, the innerworkings of LMDB are unknown to me - so perhaps it has to rewrite certain locations?