-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
> Why is the minimum storage quota of 550 MiB necessary for pruning
> nodes if the block data is not served to other nodes ? Could the
> client just do transaction verification and transaction relaying
> and only keep the block(s) being verified on
>> Block data that is stored can be used by other software, or potentially be
>> served to other nodes. The latter is not implemented at the moment - it
>> would require a change to the P2P protocol, thus right now pruning nodes
>> don't serve block data at all.
Why is the minimum storage quota
On Monday, January 25, 2016 04:05:59 PM Wladimir J. van der Laan wrote:
> I don't have time to work on the release notes right now, but if someone
> else wants to contribute that'd be awesome.
I cooked my first pull request to resolve this:
https://github.com/bitcoin/bitcoin/pull/7416
Thanks for
> > In the release notes for 0.12, it says that we have moved from
> > using OpenSSL to libsecp256k1 for signature validation. So what
> > else is it being used for that we need to keep it as a dependency?
>
> Openssl was dropped from the consensus layer (ECC) in 0.12, though, it
> still used
>
> So I'm interested whether this limitation has been lifted, and the whole
> feature is considered as finished.
Yes, it's exactly that limitation that has been lifted!
> If yes, I would highly recommend advertising it in the new release notes - as
> said, the disk space reduction is a big
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512
Binaries for bitcoin Core version 0.12.0rc2 are available from:
https://bitcoin.org/bin/bitcoin-core-0.12.0/test/
Source code can be found on github under the signed tag
https://github.com/bitcoin/bitcoin/tree/v0.12.0rc2
This is a
This is a bad idea. OP_RETURN attachments are tolerated (not encouraged!) for
the sake of the network, since the spam cannot be outright stopped. If it
could be outright stopped, it would not be reasonable to allow OP_RETURN. When
it comes to the payment protocol, however, changing the current
Hi all,
I'm submitting a new BIP draft for consideration and discussion. I've put a
pull request up on Github that implements this BIP (with discussion from
the Core team):
https://github.com/bitcoin/bitcoin/pull/7376
My original discussion of this issue:
On Tuesday, January 26, 2016 2:54:16 AM Toby Padilla wrote:
> Luke - As stated in the Github thread, I totally understand where you're
> coming from but the fact is people *will* encode data on the blockchain
> using worse methods. For all of the reasons that OP_RETURN was a good idea
> in the
It looks like my draft hasn't been approved by the mailing list so if
anyone would like to read it it's also on Gist:
https://gist.github.com/toby/9e71811d387923a71a53
Luke - As stated in the Github thread, I totally understand where you're
coming from but the fact is people *will* encode data
On Tuesday, January 26, 2016 3:01:13 AM Toby Padilla wrote:
> > As I explained, none of those reasons apply to PaymentRequests.
>
> As they exist today PaymentRequests allow for essentially the same types of
> transactions as non-PaymentRequest based transactions with the limitation
> that
On Tuesday, January 26, 2016 3:17:12 AM Toby Padilla wrote:
> I don't think every application of OP_RETURN could be classified as "spam".
Perhaps not, but in this context I cannot think of any non-spam use cases.
Use cases should come before changes to support them.
> I also don't think burning
12 matches
Mail list logo
