-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
The notification transactions are a pain point when it comes to
privacy, and yet they must exist in order to to ensure that nobody can
lose their money as long as they back up their wallet seed.
They could be treated as a backup, however, that
On Tue, Apr 28, 2015 at 04:01:00AM -0700, Pieter Wuille wrote:
As softforks almost certainly require backports to older releases and other
software anyway, I don't think they should necessarily be bound to Bitcoin
Core major releases. If they don't require large code changes, we can
easily do
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
I'll point out that at this rate the soonest we'll see CHECKLOCKTIMEVERIFY
implemented on Bitcoin will be something like summer 2016, a year and a half
after it got adopted on Viacoin. (and a few other alts whose names I forget)
Right now the
Hi Jorge,
I don't think I understand the question. Proof of Payment is used to prove
that you have the credentials needed for a certain transaction. It does not
care where in the blockchain the transaction is. Or if it's in the
blockchain at all.
/Kalle
So at the low level, how does a proof of
Forget it, sorry, I misunderstood the proposal entirely, re-reading
with more care...
On Tue, Apr 28, 2015 at 2:41 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote:
Hi Jorge,
I don't think I understand the question. Proof of Payment is used to prove
that you have the credentials needed for a
So at the low level, how does a proof of payment differ from just proving
that a given transaction is in a given block (what SPV nodes take as proof
of payment today)?
On Apr 27, 2015 2:42 PM, Kalle Rosenbaum ka...@rosenbaum.se wrote:
Or a really high lock_time, but it would not make it invalid,
Even if it's new and has not received any feedback, I think my solution to
op_maturity is quite clean.
But anyway, yes, the non-relative cltv is much simpler in design and
doesn't have to wait for the other. On the other hand, I would upgrade it
to absolute cltv like you suggested and take the
Hello all,
The release window for 0.11 is nearing, I'd propose the following schedule:
2015-05-01 Soft translation string freeze
Open Transifex translations for 0.11
Finalize and close translation for 0.9
2015-05-15 Feature freeze, string freeze
2015-06-01 Split off
On 27 Apr 2015, at 21:21, Peter Todd p...@petertodd.org wrote:
Even right now there are edge cases without
good solutions, like how in a multisig environment any of the key
holders can mutate transactions.
Can't we add requirement for RFC6979 signatures to mitigate this? Of course,
9 matches
Mail list logo
