Topic: [XMR] Monero Improvement Technical Discussion - page 3. (Read 14760 times)

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 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.

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.

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.

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

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.

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).

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

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.

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

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.  

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.

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.

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.

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.

As you digged deeper into the topic and talk about businesses adopting ZC rather than CN... does ZC have the option to be auditable? Real Businesses favor something that can be audited. Can you actually proof you own xxx Amount of ZC without handing over your whole keys? CN got Viewkey for that, what does ZC have? ( besides neither guesses, of what or what not businesses will adopt by us actually hold any fact or argument, as its not up to us but those who run the businesses.

Sorry for the bad english hope you get the points

As you digged deeper into the topic and talk about businesses adopting ZC rather than CN... does ZC have the option to be auditable? Real Businesses favor something that can be audited. Can you actually proof you own xxx Amount of ZC without handing over your whole keys? CN got Viewkey for that, what does ZC have? ( besides neither guesses, of what or what not businesses will adopt by us actually hold any fact or argument, as its not up to us but those who run the businesses.

Sorry for the bad english hope you get the points