Michael Gronager [ARCHIVE] on Nostr: š Original date posted:2013-07-17 š Original message:Hi Wendell, What Peter ...
š
Original date posted:2013-07-17
š Original message:Hi Wendell,
What Peter describes (a hash of the current set of UTXOs as part of the coinbase) is already implemented in libcoin, on which you can easily build both a bitcoind and any client. Libcoin is a library originally based on the satoshi client, and as such it is compatible/replacable with "master".
Have a look at github.com/libcoin/libcoin and look in the BlockChain.h/cpp and the MerkleTrie classes then you can see how it works.
What is missing from libcoin is a scheme to bootstrap the hash of UTXOs, there is some stub code for a p2pool like mining scheme ensuring several UTXO hashes every 10 minutes, but I will not have time to finalize it the first few months - anyone are of course welcome to help out ;)
Michael
On 17/07/2013, at 09:37, Wendell <w at grabhive.com> wrote:
> Peter,
>
> This sounds like a _very_ good idea for a desktop client, and probably acceptable to users so long as we take available disk space into consideration, and only ever use a fraction of it.
>
> Will you implement this?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive
>
> On Jul 17, 2013, at 12:58 PM, Peter Todd wrote:
>
>> So what's useful about that? Basically it means your node starts with
>> the same security level, and usefulness to the network, as a SPV node.
>> But over time you keep downloading blocks as they are created, and with
>> whatever bandwidth you have left (out of some user-configurable
>> allocation) you download additional blocks going further and further
>> back in time. Gradually your UTXO set becomes more complete, and over
>> time you can verify a higher and higher % of all valid transactions.
>> Eventually your node becomes a full node, but in the meantime it was
>> still useful for the user, and still contributed to the network by
>> relaying blocks and an increasingly large subset of all transactions.
>> (optionally you can store a subset of the chain history too for other
>> nodes to bootstrap from) You've also got better security because you
>> *are* validating blocks, starting off incompletely, and increasingly
>> completely until your finally validating fully. Privacy is improved, for
>> both you and others, by mixing your transactions with others and adding
>> to the overall anonymity set.
>>
>> In the future we'll have miners commit a hash of the UTXO set, and that
>> gives us even more options to, for instance, have relayed transactions
>> include proof that their inputs were valid, allowing all nodes to relay
>> them safely.
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/d6c0fe64/attachment.sig>;
š Original message:Hi Wendell,
What Peter describes (a hash of the current set of UTXOs as part of the coinbase) is already implemented in libcoin, on which you can easily build both a bitcoind and any client. Libcoin is a library originally based on the satoshi client, and as such it is compatible/replacable with "master".
Have a look at github.com/libcoin/libcoin and look in the BlockChain.h/cpp and the MerkleTrie classes then you can see how it works.
What is missing from libcoin is a scheme to bootstrap the hash of UTXOs, there is some stub code for a p2pool like mining scheme ensuring several UTXO hashes every 10 minutes, but I will not have time to finalize it the first few months - anyone are of course welcome to help out ;)
Michael
On 17/07/2013, at 09:37, Wendell <w at grabhive.com> wrote:
> Peter,
>
> This sounds like a _very_ good idea for a desktop client, and probably acceptable to users so long as we take available disk space into consideration, and only ever use a fraction of it.
>
> Will you implement this?
>
> -wendell
>
> grabhive.com | twitter.com/grabhive
>
> On Jul 17, 2013, at 12:58 PM, Peter Todd wrote:
>
>> So what's useful about that? Basically it means your node starts with
>> the same security level, and usefulness to the network, as a SPV node.
>> But over time you keep downloading blocks as they are created, and with
>> whatever bandwidth you have left (out of some user-configurable
>> allocation) you download additional blocks going further and further
>> back in time. Gradually your UTXO set becomes more complete, and over
>> time you can verify a higher and higher % of all valid transactions.
>> Eventually your node becomes a full node, but in the meantime it was
>> still useful for the user, and still contributed to the network by
>> relaying blocks and an increasingly large subset of all transactions.
>> (optionally you can store a subset of the chain history too for other
>> nodes to bootstrap from) You've also got better security because you
>> *are* validating blocks, starting off incompletely, and increasingly
>> completely until your finally validating fully. Privacy is improved, for
>> both you and others, by mixing your transactions with others and adding
>> to the overall anonymity set.
>>
>> In the future we'll have miners commit a hash of the UTXO set, and that
>> gives us even more options to, for instance, have relayed transactions
>> include proof that their inputs were valid, allowing all nodes to relay
>> them safely.
>
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk_______________________________________________
> Bitcoin-development mailing list
> Bitcoin-development at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 495 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20130717/d6c0fe64/attachment.sig>;