Topic: Pledging coins for ultimate blockchain compression - page 2. (Read 14786 times)

All you've done in the second paragraph is describe how the Bitcoin-Qt app currently works. If you're maintaining a full copy of the UTXO set and verifying signatures, etc, then you're a full node by definition because you aren't relying on the majority consensus for anything except ordering.

It isn't feasible to do this in the places lightweight clients are currently used. It doesn't make sense to run a full node on a phone, for example, and as traffic ramps up it'll stop making sense to do it on laptops as well.

This is why I don't understand the proposal. The only reasonable way I've seen to get something in between SPV and full mode is d'aniels suggestions for various kinds of fraud proofs, but the whole point of a fraud proof is that you get one when the best chain is no longer following the rules .... making fraud proofs that rely on trusted commitments to the state of the UTXO set pointless (they would be a part of the fraud).

Does gmaxwell still think this?  I've noticed lately he seems keen on the idea:
https://bitcointalksearch.org/topic/m.1599126
https://bitcointalksearch.org/topic/m.1599093

It's also in his alt-coin wishlist: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas

I'm thinking he may have changed his mind because of its application to partial verification and fraud proofs.  Essentially this can be seen as part of an overall SPV trust model upgrade.  He explains this well in this post: https://bitcointalksearch.org/topic/m.1596626

The goal of UBC is to remove the requirement to choose between running a light node and acting as a first class network citizen.

The minimum amount of data needed to verify blocks and transactions is the UTXO set. The thread linked in the OP is a discussion about the best data structure for storing the UTXO set, with the goal of eventually including it into the block definition. If this is accomplished nodes could discard all prunable data, except for enough recent history to handle reorgs, but could still perform the network functions a reference node can perform now (except a full blockchain download).

The benefit that I was seeing in this was that SPV nodes could do partial verification of blocks, helping to find and broadcast fraud proofs.  This seems important for scaling.

As far as I understand it, one can with a header chain, most recent "unspent-tx tree" and all full blocks since the last unspent-tx block also emulate the behaviour of a full client.

Maybe call it a "semi slim" client, that discards all block contents once a new merge-mined superblock comes in? This would be good enough for a lot of people who don't want to do blockchain analysis, but for example want to offer bloom filters to lightweight clients.

The benefit would be that there is only the very small growing block header files, a few (depending on miner adoption) full blocks + a huge unspent-tx block to be stored to provide services to lightweight clients or to even mine, not all full blocks.

Edit: There would be 2 header chains to be stored as far as I understand, one for Bitcoin and one for unspent-tx-treecoin.

The final step of this project is "integrate with lightweight clients", but this is vague - what does it mean? Which clients?

I don't think I'd be interested in accepting code for it into bitcoinj, because I'm actually not sure what the goal of this is. As far as I can tell we have already achieved the scalability goals of that proposal in a much simple and more efficient way (by supporting Bloom filtering of the chain).

It's probably a good idea to just refund the pledges.

Unfortunately, I have some other very important, selfish priorities.  I absolutely would love to work on this, but I don't see where I'd get the time in the next 6 months.  On the other hand, if the blockchain could survive until then, I wouldn't mind working this into my priorities in about 6 months.

There have been lots of discussion with the devs, though the most interesting ones I've had were on IRC.  The biggest concern was expressed by gmaxwell, which was that he doesn't see it being acceptable to further expand the computational requirements of miners, despite the benefits that are offered by this idea.  It risks creating further centralization, when miners with less-powerful hardware are pushed out.  That doesn't mean it couldn't exist in a side-chain, it just means that he doesn't think it could ever be accepted into the core protocol -- which I think would be a desirable goal for this in the long term.

On the other hand, actually getting this working in a side-chain, and exploring the dynamics of this solution (and the associated benefits), may start to change peoples' minds.  If it turns out to work as expected, and 80%+ miners are supporting it anyway, then there may be a push for it to be adopted in the next hard-fork because of the benefits to the network.  Personally, I'm of the opinion, that if it doesn't change the amount of work/resources required of miners by more than an order of magnitude, then it should be absolutely be done.    This isn't just an "upgrade", it changes the nature of the network in dramatically positive ways.  The trade-off between usability and security is effectively eliminated for regular users.  Any device could boot up with a clean slate and get everything it needs to operate fully and securely, with a couple MB of download.

Making this "service" part of the protocol, you are then giving miners a very good excuse to support this service that many miners will probably already be providing.  This would just be a way of making it secure. 

I'd like to know more about this and SatoshiDice may be willing to fund all or a large part of it. I know Alan and have great respect for him.

How much is needed to make this happen? And, do any core developers dislike Alan's plan, and why? I realize this has probably all been discussed somewhere... links or excerpts are appreciated.

Alan if I forget to respond on this thread, please contact me on gmail.

I think it could be useful to consider a very different approach - if the "deliverable" can be broken up into smaller tasks (and I see no real reason why it cannot) then this could easily be handled using CIYAM Open's approach to Project Management - also currently any project started under CIYAM Open will be subject to *zero* fees for it's lifetime (this offer is limited but will be kept open for this particular project as I think it is something I would be happy to support).

Also understand that all projects run under CIYAM Open are financially controlled by their Project Manager (not by CIYAM itself - so the BTC is never even handled by anyone other than the Project Manager).

We are also working on being able to provide Paypal payments and are assessing Ripple as another payment option for contributors.

Just to be clear my definition of "bitcoin developer" includes people who make widely used Bitcoin clients, like Armory.

Well, I just stumbled on this thread for the first time.  I guess I need to browse the project development forum more often...

I started writing a response here, but realized it's something I had been meaning to express in the more-general thread here.

In summary, I like where justus is going.  Fund the developer to do the work, don't pay for a completed product.  "Completion" is too fuzzy and controversial.  Build and leverage trust, and give developers some leeway to make decision on their own without worrying about their financial security being at risk.

I have a theory that the bounty will be more effective if we pledge income instead of a completion bonus. We should try to get enough donations to match a reasonable salary. I'll start:

I will pay USD500 per month (in bitcoins) for six months to a bitcoin developer willing to work full time on implementing this proposal.

So you're saying (with regards to the highlighted point) that we wouldn't need to maintain an alternate block chain, but only need miners to include the Merkle root in the coinbase of mined blocks?

You mean if he pays out, right?

He's already missed Monday deadline by 1-2 days.
He is not communicating at all.

Regardless of the final outcome, I'm glad I didn't invest in him.

If I were to bet (and I won't be making that bet, just speculating), I would be that he's skipped town.

Can we add the bounty wallet to the OP?

Yes thats what I meant 

I hope you mean to this project, otherwise this means you have my password to blockchain.info

https://bitcointalksearch.org/topic/m.1022888  will be donating some each week from this project.

I have now "rescued" all funds from the Booster.io (read my previous message), and will manage the bounty myself.

My signature is a pitch for http://btctox.org/ - a calculator/currency converter between Bitcoin and any major currency (even those not supported by exchanges).