Pledging coins for ultimate blockchain compression

[Pieter Wuille]

Know what you're pledging for. The basis of etotheipi's proposal is not pruning itself, as that was already described by Satoshi in his paper.

It is about the ability to have a pruned node serve light clients with the same security guarantee as an SPV client (like BitcoinJ; trust the longest chain).

Implementing this consists several parts, and some of them are useful by themselves:

• Having fully validating nodes that explicitly maintain a pruned txout set
• ... and also keeps that set indexed per-address
• ... and maintain a merkle tree for that (or other authenticated data structure)
• ... and commit the merkle root of that in the coinbase (miners putting it there, other nodes verifying it)
• Having light nodes designed to use that information

(Alan, if you're reading this, please correct me if i'm wrong or missing something)

I'm currently myself working on the first step in the reference client. It will speed up block validation, and allow (optional) pruning of old blocks.

[1715024830]

1715024830

[1715024830]

1715024830

[1715024830]

1715024830

[ripper234]

Do you really want an organization that is supposed to be safeguarding your bounty loaning out the coins for interest? What if a deal they make goes bad?

Anyway, I have no problem with you managing it, ripper234, if you can get my 2.5BTC back. I'd do it myself, but I have a horse in this match

Great news!

1. Your donation was rescued from Booster.io, and now sits safely at this new bounty wallet I created: https://blockchain.info/address/16ofWVGwqDVjwhV95fDUrkyqT4Bcy1Nc6G
2. Booster.io will reduce their fee structure:

- Bounties under $10 are free
- First 100 bounties that collect more than $10 are free (incentive for new bounties)
- Subsequent bounties that collect more than $10, are at 1% capped at $100.

In Jan 1, 2013 I may change these numbers for new bounties.

I will consider them for future bounties I start. I will manage this one myself, as agreed - please add this to the OP.

3. I match your 2.5 BTC.

[ripper234]

Ripper, you own the bounty right? Is it still open?

Also, what's with your signature "How much is 134 BTC in yen?"

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

[Bitcoin Oz]

https://bitcointalk.org/index.php?topic=92684.msg1022888#msg1022888  will be donating some each week from this project.

[ripper234]

https://bitcointalk.org/index.php?topic=92684.msg1022888#msg1022888  will be donating some each week from this project.

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

[Bitcoin Oz]

https://bitcointalk.org/index.php?topic=92684.msg1022888#msg1022888  will be donating some each week from this project.

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

Yes thats what I meant 

[ripper234]

Can we add the bounty wallet to the OP?

[ripper234]

Can we add the bounty wallet to the OP?

Done

btw, I'll send my 10 over after pirate pays out

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.

[unclescrooge]

Can we add the bounty wallet to the OP?

Done

btw, I'll send my 10 over after pirate pays out

[runeks]

Know what you're pledging for. The basis of etotheipi's proposal is not pruning itself, as that was already described by Satoshi in his paper.

It is about the ability to have a pruned node serve light clients with the same security guarantee as an SPV client (like BitcoinJ; trust the longest chain).

Implementing this consists several parts, and some of them are useful by themselves:

• Having fully validating nodes that explicitly maintain a pruned txout set
• ... and also keeps that set indexed per-address
• ... and maintain a merkle tree for that (or other authenticated data structure)
• ... and commit the merkle root of that in the coinbase (miners putting it there, other nodes verifying it)
• Having light nodes designed to use that information

(Alan, if you're reading this, please correct me if i'm wrong or missing something)

I'm currently myself working on the first step in the reference client. It will speed up block validation, and allow (optional) pruning of old blocks.

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?

[justusranvier]

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.

[etotheipi]

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.

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.

[justusranvier]

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

[CIYAM]

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.

[evoorhees]

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.

[etotheipi]

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.

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. 

[Mike Hearn]

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.

[Sukrim]

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.

[d'aniel]

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.

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.

[justusranvier]

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