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 t
> I don't see any benefit to
changing that. It is better that coins are burned.
I think this is our fundamental disagreement. People will burn coins to
encode data, why allow this when there's a better alternative?
> You *always* need a key, to redeem inputs... regardless of values.
Correct, but
> 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 OP_RETURN values must be greater. In that sense they're basically a
pre-OP_RE
On Tuesday, January 26, 2016 3:07:40 AM Toby Padilla wrote:
> > I don't see any benefit to changing that. It is better that coins are
> > burned.
>
> I think this is our fundamental disagreement. People will burn coins to
> encode data, why allow this when there's a better alternative?
My point i
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 OP_RETU
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 firs
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
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:
https://lists.linuxfoundation.org/piper
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 b
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
-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
All of this is already implemented in the bitcoind and bitcoin gui.
The theoretic minimum for the prune target would be 0 (just the header
of the current best block) as Bitcoin Core already stores the
chainstate (about 2 GiB) regardless of what you set for -prune=.
In practice, the minimum is 510
> > To enable block pruning set prune= on the command line or in
> > bitcoin.conf, where N is the number of MiB to allot for raw block & undo
> > data.
>
> From having read the Bitcoin whitepaper quite a few months ago ago, I have
> the
> very very basic understanding that pruning is meant to:
On Monday, January 25, 2016 01:03:17 PM Wladimir J. van der Laan wrote:
> > If yes, I would highly recommend advertising it in the new release notes -
> > as said, the disk space reduction is a big deal.
>
> Good idea, has been added by Marco Falke in commit fa31133,
Thanks. The RC2 changelog now
-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 release
>
> 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 de
> > 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 for.
18 matches
Mail list logo
