Bitcoin Forum

I really like the concept of ultimate blockchain compression (https://bitcointalk.org/index.php?topic=88208.0).

I don't have the time nor the expertise to contribute code to implement etotheipi's idea, but I do have the coin. I hereby pledge 10 BTC to the person or persons that implement ultimate blockchain compression. With such a scheme in place, I would feel much more secure about Bitcoin's future.

If you feel the same way, then lets make this a pledge thread.

Addendum 8/21/2012: Ripper has been entrusted to manage a bounty wallet, so send coins here:

I feel the same way too. So I pledge 10 btc also. Pruning blockchain is, i feel, essential.

Do we set up an btc address or something? How do we organize?

I don't think we need to organize. It's probably best that each person do the donation themselves directly to those that implement the necessary compression features. Otherwise there could be disagreement on how to distribute the pledges, for many reasons...

This thread is just to give incentive to solve the blockchain bloat problem. It's up to each individual to follow through on their personal pledges.

I have been thinking about an idea that is similar to this.

The concept is to have a max chain size that grows according to Moores Law, so that over time the max chain size gets larger.

When a chain reaches the max chain size a chain split occurs, the user is prompted if they wish to maintain both chains or just one of the the sub chains.

The chains exist at the leafs of the tree much in the same way as the proposal you mention.

Transactions occur in two steps, the output phase of the transaction and the input phase. This will facilitate inter-chain transaction.

Each client only receives input out output transaction for the chains they are maintaining.

Mining occurs at the the node junctions and all hashes must be mined to the root node to become a valid part of the tree.

Yes, I agree.

Come on people, your bitcoins are worth nothing if we can't prune the blockchain!

I'll pledge some coins.  Not sure how much.

Open a bounty on Booster.io (https://booster.io/)

I wonder if we could have a "superblock" every so often that is simply a hash of all the previous blocks. In essence you start out with a new genesis block and chain each time but old coins are still valid because they are in this "superblock".

I dont know if that makes sense...

As a developer seriously considering implementing this, I would prefer someone unbiased (so not me, obviously) organize a blockchain.info donation wallet, or maybe booster.io (first I heard of it). That way I'd only have to collect from one person, and that person risks the ire of everyone who donated if he runs off with the money.

I haven't yet thought about what the tipping point will be, but if the total gets high enough I will do this.

You can't simply hash all the blocks and forget about everything else because you need the unspend transactions. If you hash all the blocks you will get something like this:
aab4bab5af2a3deb2706954cffc89ad5cbed6dcc328d9e9daef3483cadbfa053
a simple plain hash. Now how do you know if Bob has bitcoins? And how do you know how much bitcoins Bob has? That's impossible to know if you only have that hash.

Pruning works more like that:
Let's say we have 3 people A, B and C

A sends 1 BTC to B and B sends that bitcoin to C. That means we have 2 transactions. But we can forget about the first one if we are pretty sure that there wont be a chain reorg because your client doesn't have to know if A sent 1BTC to B it only needs to know that C has 1BTC.

                                                           BTC ONE BTC

I opened a booster.io bounty jar (https://booster.io/tipjar/0cataqj). Please add a link to the OP.

For the uber lazy, this is the condition to claim:

Thanks, but if we go this route, who owns the bounty and who decides if the feature is implemented to each of our likings?

Aso, looks like they take a 5% cut of the bounty.

WTF???

This caught me completely by surprise.
Here is the complaint I just submitted (https://bitcointalk.org/index.php?topic=15689.msg1063124#msg1063124) on the Propster.me thread.

Except the 5% fee, I think the terms are rather clear - I submitted exact conditions for the bounty.
You may argue that some of the figures there are a arbitrary (15% merge mined). If anyone suggests better numbers perhaps we can revise. However, besides this point, I don't think there is an ambiguity in the bounty.

Still, due to the 5% fee, the above point is irrelevant. I won't be using Booster.io as long as this fee remains.

The fee is not a huge issue--they do provide a service that costs money to maintain. Although 5% is a little excessive.

Still, a blockchain.info wallet managed by someone with good reputation accomplishes the same feat with similar risk.

If they become hugely successful, they will make a decent live just from the interest alone.
(Booster.io and its twin site Propster.io).

5% is huge. Who do we nominate as the keeper of the bounty?

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

It's not a question of wanting it or not ... I think that most businesses that hold lots of BTC today are doing it, whether they're telling their customers or not.

If you want, I can manage the fund (assuming I manage to get the 2.5 BTC back).
These conditions apply:

1. I will open a new blockchain.info account dedicated to this purpose.
2. I will use a fresh strong password that will be kept in my usual keepass keyfile and nowhere else (backed-up to dropbox).
3. I will not invest the funds in any interest-bearing vehicles, but simply store the keys to the blockchain.info wallet.
4. I will not be liable in any way if the wallet are hacked. A non-trivial amount of my own funds are sitting on blockchain.info, so I will lose a lot if my keepass file is hacked as well.
5. I might transfer the stewardship of the funds to another trusted forum member, given sufficient consensus is formed.
6. Refunds to incoming donations will only be made within 48 hours of depositing, and with hard proof of ownership of funds.
7. These are the conditions required to unlock the funds:


These conditions might be slightly refined in the future, if ample consensus exists (my discretion). The spirit of these conditions will not be changed - the bounty will only be given to someone who makes a solid proof of concept, and get significant miner support.

8. Project abandonment - if sufficient time has passed (> 1 year), and I deem the project is abandoned by its originators and there is no interest to develop it in the community, then funds will be donated to a Bitcoin related organization (e.g. developers of Bitcoin-qt, managers of bitcointalk.org, etc...). I will choose the organization/s, and will consult on this thread before doing so (but the final call will be mine).

Fair enough. I hope it won't take 1 year to do this ;)

The blockchain data is public, however, so if they touched the donations we'd notice. But we both digress...

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

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

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.

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:


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.

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

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  :D

Can we add the bounty wallet to the OP?

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.

:D

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?

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 (https://bitcointalk.org/index.php?topic=141786.msg1549715#msg1549715).

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.

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

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.

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. 

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.

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

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

Does gmaxwell still think this?  I've noticed lately he seems keen on the idea:
https://bitcointalk.org/index.php?topic=88208.msg1599126#msg1599126 (https://bitcointalk.org/index.php?topic=88208.msg1599126#msg1599126)
https://bitcointalk.org/index.php?topic=137933.msg1599093#msg1599093 (https://bitcointalk.org/index.php?topic=137933.msg1599093#msg1599093)

It's also in his alt-coin wishlist: https://en.bitcoin.it/wiki/User:Gmaxwell/alt_ideas (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://bitcointalk.org/index.php?topic=137933.msg1596626#msg1596626 (https://bitcointalk.org/index.php?topic=137933.msg1596626#msg1596626)

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

The SPV clients would be auditing commitments to the UTXO set as well, of course.

Edit: One way I can see to do this is for each block, full nodes keep handy all the branches of the UTXO tree that get updated in the next block.  If they're pruning, then they only have to keep this data a reasonable ways back in the chain.  To audit commitments to the UTXO set in a given block, an SPV node would download transaction merkle branches in this block and the relevant branches in the UTXO tree from the previous block, then check that the commits were done properly, i.e. produce the correct root to the current UTXO tree.

Mike,

I can't tell if you misunderstood/didn't-read the UBC thread, or if you have understood it, picked it apart, and 12 steps ahead of me in considering the dynamics of it (and decided you don't like it).  I'll assume the former...

No one has to use it.  I don't think "integrate with lightweight clients" is a goal for the developer here, other than integrating it somewhere to demonstrate its benefits.  With the addition of subtree-sums in the data structure, it appears to solve even more problems than I originally posted.

I continue to be hounded by Armory users complaining of how long it takes to rescan the blockchain when they restore their wallet, or import a key.  I could ask another node for that information ... but there's no guarantee they tell me the truth, or that they even have the information.  So, I am at a trade-off between downloading some non-negligible part of the blockchain myself, just to make sure I know how to spend my coins, or accept the risk of other nodes playing game with me just so I can make a "simple" client.  And the users are making the same decision when deciding which client to use. 

But with this, there is no trade-off.  The simple client only needs the headers, and then about 2 kB/address to get a fully verifiable, spendable balance directly linked to the chain with the most work.  If the program saves the headers, it could save nothing else between loads, and redownload its own balance information every time for less than 1MB and without sacrificing security.  It would frequently be much less data than downloading hundreds of blocks since my device was last running, and more secure than trusting that nodes are filtering properly for me.  There is no more "rescanning" the blockchain.  No "searching" for your UTXOs.  You just get them, and it's easy for any to prove inclusion or exclusion of existing or non-existent UTXOs at any block.

In essence, forcing full nodes to maintain this "service" isn't just an upgrade, it changes the network in a positive way.  It means SPV doesn't even really exist anymore, you just have miners and you have secure-non-full-nodes that can run on just about any device.

Well, you're right, I haven't understood your proposal. And I still don't :(

Firstly I'm not sure I understand the rationale. Restoring a wallet or importing keys should be a very rare event. I'd hope that people don't need to restore from backup all that often, so optimizing for it is a bit puzzling. Perhaps they are doing this to satisfy some other use case that can be tackled in a better way.

But regardless, I don't see how implementing this proposal changes anything. With current SPV code the bottleneck in re-scanning the chain is how fast the blocks can be loaded off disk and scanned on the remote node side. The client itself only receives headers, merkle branches and the transactions it needs (along with a few false positives if it wants them). To make it faster still you don't need to put any new data into blocks, you can have additional indexes be created by nodes that want to offer that service so they can avoid loading/scanning blocks that don't contain any matching transactions. It's a protocol transparent upgrade, beyond maybe an addr service flag.

But I'm not sure that's really so important right now. BitcoinJ + an unloaded Bitcoin 0.8 node can scan through the latest parts of the chain at many hundreds of blocks per second. Even if your client was offline for a month it can catch up in less than 10 seconds, and that's with a completely unoptimized filtering implementation on the server (it's not doing bulk reads or multi-threaded filtering). It could go much faster still with smarter code on the C++ side. Bloom filtering really changes the game for thin client performance in a fundamental way, with only a simple protocol upgrade and without the maintenance of any additional indexes or data structures by peers.

Anyway, security. SPV nodes cannot have games played on them except in two ways: by a 51%+ miner who is forging a false chain, or (with bloom filtering) mounting a complicated DoS attack. You can solve the latter by just querying a bunch of different nodes and the former is inherent in any system in which you don't fully verify all transactions. Now as far as I can tell, what you're saying is that with extra data in the blocks you can have equivalent security to a full node, but without actually verifying all transactions. I don't see how that's possible. And yes I read your proposal so I guess I still don't understand it. If you're trusting some data you found in a coinbase input, then if I have majority hash power I can make a new best chain that contains whatever UTXO commitments I want, and you would accept it as valid. How is that not SPV-equivalent security?

Upon rereading this, a better response would have been to say that this new trust model is "trust what you haven't seen a valid fraud proof disputing".  So if no false updates in the authenticated UTXO set have been proved to you, you assume it to be valid.

It's okay to base a fraud proof on the assumption of validity of the authenticated UTXO set because one could simply construct a proof that it was invalidly updated in order to prove any fraud that followed from this assumption being false.  This is the same as for the other fraud proofs, which all rely on the assumption that previous blocks upon which it was built have been valid.

The partial verification stuff I mentioned in the first response is just icing on the cake that helps ensure that fraud proofs are very likely to be found, even in the event that few full nodes are looking for them.

But that's not the rationale that was being given before. I'm not sure why it even helps. You can prove double spending or fake spending of inputs just by providing the transactions and their merkle branches, it's not very intensive. To prove a coinbase is of the wrong size requires more, but how does putting a utxo commitment in every block help with that? You still need to download the entire block to check it's not valid.

That's true, it's not the rationale that was given before.  So if this is to be the current one (to be clear, it's just been my rationale), then it does bring the legitimacy of the pledges into question.  And you're right that it's not needed to prove any of these cases of fraud.

Excuse me while I think out loud for a minute...  On the one hand, having a trustworthy up-to-date commitment of the authenticated UTXO set - trustworthy because you haven't received any fraud proofs for it, and you assume you have at least one honest peer - would let you know for sure that a UTXO that you've received in a transaction hasn't been spent yet.  But on the other hand, it technically only requires one honest peer in the current arrangement to send you proof that such such a UTXO has been spent more recently than you've been led to believe.  So this proposed benefit seems kind of dubious...

The partial verification stuff is becoming less clear the more I think about it too...  But that's a far-in-a-hypothetical-future optimization anyway, to be made only if the number of full nodes becomes too low for comfort.  More important things to be funding currently IMHO.

I guess I'll have to eat my hat on this ;)

Would it be feasible and useful to turn blocks and transactions themselves into Merkle trees too?
That way the index could reference smaller parts of the main block chain.
Does this make any sense? Why not?
I'm talking about miners signing a tree of transactions that are trees of entries (inputs and outputs) instead of the block as a list of transactions, so this would be a hard-fork.

Another question, does the proposed index use content addressable storage (http://en.wikipedia.org/wiki/Content-addressable_storage) ?

Jtimon, that is what they do currently. The list entries are used as the leaves of a binary tree. hashMerkleRoot in the block header is the root hash of this tree.

Various real-life events have conspired to find me in-between jobs right now. More than anything I would rather work on bitcoin full-time, and so I am taking a cue from @etotheipi and offering my services to the community to implement this proposal. Since this is a separate proposal from the OP's bounty, I have created a new thread:

https://bitcointalk.org/index.php?topic=204283.msg2135237#msg2135237 (https://bitcointalk.org/index.php?topic=204283.msg2135237#msg2135237)

Thank you for the clarification. I was whining about something not being done which was actually done.

This offer is now closed because I'm giving it to makku:

https://bitcointalk.org/index.php?topic=204283.0 (https://bitcointalk.org/index.php?topic=204283.0)

So, I'm doing a cleanup of old wallets ... and this one seems to have 5.725 BTC & BCH, currently worth a total of $48,977.83.

I think the "Blockchain pruning" project counts as abandoned by now:

> 8. Project abandonment - if sufficient time has passed (> 1 year), and I deem the project is abandoned by its originators and there is no interest to develop it in the community, then funds will be donated to a Bitcoin-related organization (e.g. developers of Bitcoin-qt, managers of bitcointalk.org, etc...). I will choose the organization/s, and will consult on this thread before doing so (but the final call will be mine).

I plan to take a couple of weeks to find a proper home for this money.
As it's been years since the bounty was started, I don't want to take any action to swiftly - I will give people a chance to voice in any issues they have.
Barring any concrete issues, the money will be donated to a relevant project within a couple of weeks.

Update: I think BCH should go to a relevant BCH project, and not to Bitcoin/BTC.

Also, I'm in contact with Anton from Scaling Bitcoin conference (upcoming in Tel Aviv on September), sponsoring that might be a good usage of the funds.

Posted on /r/bitcoin (https://www.reddit.com/r/Bitcoin/comments/bzx0oi/which_bitcoin_scalability_project_deserves_575/) + another thread (https://www.reddit.com/r/btc/comments/bzx7gq/which_project_to_scale_bitcoin_cash_deserves_a/) on /r/btc for donating the BCH.

Eltoo and lightning seem to be properly funded and with a ton of help already, Ruben needs some help.

Best to hire a developer or offer rewards for different milestones to test and work on statechains -

https://medium.com/@RubenSomsen/statechains-non-custodial-off-chain-bitcoin-transfer-1ae4845a4a39

https://tokyo2018.scalingbitcoin.org/files/Day2/statechains.pdf

https://www.youtube.com/watch?v=eG8th2x8XHY

I am sure several developers can multisig this in a responsible manner for payouts.

My favorite way to proceed is to give the funds to the Scaling Bitcoin committee, and they can decide how to distribute the funds to the various projects.

Sounds good, these reddit threads were a bit depressing when looking at the quality of answers...

Following discussions over the past few weeks within the Bitcoin community in Israel and members of the Scaling Bitcoin Planning Committee, it has been decided that funds held by Ron Gross will be contributed to the Scaling Bitcoin event.

The established requirement is that roughly ~50% of these funds will be used for R&D stimulus, while the remaining ~50% will be contributed to the event budget. Since a large portion of Scaling sponsorships is used to provide for academic and developer subsidies, received funds allocated toward the budget will be prioritized to cover our subsidy and diversity efforts.

For the R&D stimulus, we will allocate 3.0 BTC for grants and form a grant committee that will award these funds to presenters at Scaling. The grant committee will establish the required criterion for the award recipients. Participants in the grant committee will be published at a later date on the Scaling Bitcoin website.

The only requirement we would like to set forth is that only the work that directly relates to and impacts the Bitcoin protocol or Bitcoin development qualifies as a recipient of these awards. This was the initial purpose of the donations collected, so this remains the priority.

Funds will be transferred in the coming days to 1V5Sbs6TghoaEJzoWkmsSGefNaAbhVdwY following which, 3 BTC will be parked at 3A8oxUi1XFoX9umM1VDD9ChPywMgG2kz22 pending the conference.  The conference will take place on 11th and 12th of September 2019 at the Tel Aviv University and funds will be awarded on the 12th of September at the end of the conference.  The award ceremony is scheduled to take place at approximately 17:55 IDT (UTC+3) but the conference schedule frequently drifts.  For a more detailed schedule and related information please visit https://telaviv2019.scalingbitcoin.org#schedule

On behalf of the Bitcoin development community, we would like to thank Ron Gross for such generous contribution and in the coming weeks, we will be making sure these funds are used to produce the maximum impact on the Bitcoin community.

Best,

Anton Yemelyanov
On behalf of the Scaling Bitcoin Planning Committee

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Receiving Address: 1V5Sbs6TghoaEJzoWkmsSGefNaAbhVdwY

===
Upon receipt, 3 BTC allocated toward R&D grants will be parked at 3A8oxUi1XFoX9umM1VDD9ChPywMgG2kz22
This message is signed with the address that will receive funds on behalf of the Scaling Bitcoin 2019 Planning Committee
Anton Yemelyanov / Chairman of the Scaling Bitcoin Planning Committee
https://keybase.io/aspectron PGP 20B0 E184 0CA0 E895
===
HxycmRJcgc/w9CYCfzP5/AxTINFSKLsMNl2ayRKBbi57Izg9u83C1alPf1Rh6p89YRHgQiUVGE9NLFA3YKvLZgs=

-----BEGIN PGP SIGNATURE-----
wsFcBAEBCAAGBQJdURWoAAoJECCw4YQMoOiV9GYQAJrHP0hsODHfc4IHpmnG
daivbsdqhwPuWrh6i9o4Sa64MZ+cptsy7vepkJZqhAS0qK/QCOZOh7UYId4l
PqAknIBNvroL+U/B/9htt/BSTaxKOAccOfS/SJ+Mx4FfrTmMVAz/7OgZx9hM
vRkxk59bHdyb4RZkiwDhpeH3ercuoKGpItVF56skJq/ttDg3OUEZx+YcQ4qP
ABv6upU3jeC9+EvKSIrAW6cDCzNDH3VvgU5LJ3QQdr3HUfrPDTSVUFIBhEmG
57kKrA8pUWZl/PpoctRsbvzEzGtMJOGH34bRqQFuvvIi5T3KdFSAz+NKcF8A
rKBX3Sw4U3luqBfdKF8kU7/NhQbc6UyXwKRvz4aa8n7HzO8SGYItP3jeEapV
dfgKV0poDW/O/slazgicRC2JPJfvDPfBhyhbyeTTvelfDKPmwcWSfjSyLwyi
TuyjUhphUB/Dow1VnCGU54chUNcGkn3h+mYnb2FBf0KfcL38YKJl4WiIsmhW
T+0kNnnz79cLznQV9/l+7U6viJsBjrdGDEwjekDKrjC7LSBlD00qdvL/sFIZ
nCOBJur+dpRXKOcb222Dp6Q571oU3RND5jevqLdEkKednyxgtKP69+DeRp1g
c5SJup5224BFNXJ46cqrz4FBUUsEKE2qfU+isW4nwBVfOK06yor4Lzs1kJwS
1gaM
=4ndb
-----END PGP SIGNATURE-----

Confirmed. I will give a few days for additional feedback, and then transfer the funds.

Transaction sent!

https://www.blockchain.com/btc/tx/06388e75b2f82c4e068c667150c98b0327555803c1488e544f39072922378ef2

This concludes the BTC side of this bounty.

And BCH sent to Bitcoin Cash development fund at https://www.bitcoincash.org/ (bitcoincash:qq29gww57twmvq07las39p3m65x8nw2ngvvuq6adpn).

https://www.blockchain.com/bch/tx/924f62e7bdb554fffe5d9d78871eadd9f50834c9f325a7cae3995a8de2fd805a

This concludes this thread for the time being.