On Wed, Sep 5, 2018 at 1:49 PM Erik Aronesty via bitcoin-dev
wrote:
> Detailed explanation with code snippets:
>
> https://medium.com/@simulx/an-m-of-n-bitcoin-multisig-scheme-[snip]
This appears to be a repost of the broken scheme you posted about on
Bitcointalk, but then failed to respond to th
Humour me please,
Where you say "create transactions which are only valid if they are mined on
top of a specific block." - in practice, does that usually means at any height
above a specific block?
From: bitcoin-dev-boun...@lists.linuxfoundation.org
on behalf
Functionality such as this does not currently exist not because no one
thought of it before, but because it has been proposed many times
before and determined to be harmful. The existing design of CLTV/CSV
were carefully constructed to make it impossible for a transaction to
go from valid to inval
I think a simple approach to what you want to accomplish is to simply have a
multisig option with a locktime pre-signed transaction which is broadcastable
at the 24h mark and has different spendability. This avoids introducing
reorg-induced invalidity.
On September 6, 2018 9:19:24 AM UTC, Aleja
I feel it is breaking a principle that if a transaction is valid it remains
valid. There might be dangerous repercussions to breaking that rule. For
instance chain of transaction become invalid which might lead to losses.
On Thu 6 Sep, 2018, 6:37 PM Alejandro Ranchal Pedrosa via bitcoin-dev, <
bit
Hi Damian,
>Where you say "create transactions which are only valid if they are mined on
>top of a specific block." - in practice, does that usually means at any height
>above a specific block?
Those details aren't important for the point I was trying to make.
BIP115 allows the transaction to b
I think you misunderstood my proposal. What you'd do is the transaction
is spendable by either Bob OR (Bob AND Alice) and before
broadcast/during construction/whatever sign a new transaction that
spends it and is only spendable by Alice, but is timelocked for 24
hours. At the 24h mark, Alice broadc
Hi Jonas,
Great to see progress in this area. I have quite a few comments.
Post-quantum key exchange
=
I think that's overkill. Bitcoin has huge problems in the presence of a quantum
computer, and the
confidentiality of the P2P messages is the most minor one. If there is
I made a similar proposal about 7 months ago, and documented some of the
discussion points here:
https://github.com/reardencode/bips/blob/reverselocktime/bip-0zzz.mediawiki
On 2018-09-06 (Thu) at 15:16:34 +, Gregory Maxwell via bitcoin-dev wrote:
> Functionality such as this does not currentl
