public inbox for bitcoindev@googlegroups.com
 help / color / mirror / Atom feed
From: Erik Aronesty <erik@q32.com>
To: Matthew Roberts <matthew@roberts.pm>,
	 Bitcoin Protocol Discussion
	<bitcoin-dev@lists.linuxfoundation.org>
Subject: Re: [bitcoin-dev] BIP clearing house addresses
Date: Thu, 4 Aug 2016 08:43:34 -0400	[thread overview]
Message-ID: <CAJowKgJXAJSJc=AiBSYWFBTRYk539hpQt-Q=xetCv3YhdhvQ1Q@mail.gmail.com> (raw)
In-Reply-To: <CAAEDBiGYz+q=1iTEQjQu2ewDw7QRS+EZQOrq6v4y6Z9RT+e-aQ@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 4587 bytes --]

https://www.reddit.com/r/Bitcoin/comments/4w016b/use_of_payment_channels_to_mitigate_exchange_risk/

On Thu, Aug 4, 2016 at 12:53 AM, Matthew Roberts via bitcoin-dev <
bitcoin-dev@lists.linuxfoundation.org> wrote:

> >This is already possible. Just nLockTime your withdrawls for some future
> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
> beyond the present tip.
>
> The problem with nLockTimed transactions is a centralized exchange isn't
> going to know ahead of time where those locked transactions need to go or
> the amount that needs to be signed so you will end up having to keep the
> private key around. If there was a way to create these transactions offline
> with special SIG_HASH flags (and I don't think there is) there's nothing
> about nLockTime that forces that the transactions be broadcast straight
> away and plus: since the TXs aren't confirmed until the lock-time expires
> they can be overwritten anyway.
>
> I think given the requirements that a centralized exchange has:
> TierNolan's idea is the best so far. Essentially, you have a new type of
> output script that forces the redeemer to use a designated output script
> template in the redeeming transaction, meaning that you can actually force
> people to send coins into another transaction with "relative lock-timed"
> outputs. The new transaction can then only be redeemed at the destination
> after the relative lock-time expires OR it can be moved before-hand to a
> designated off-line recovery address. This is much better than creating a
> new transaction system, IMO.
>
> >And the refund TXN would need to be able to go to a new address entirely.
>
> Agreed.
>
> On Thu, Aug 4, 2016 at 1:49 PM, Andrew Johnson <andrew.johnson83@gmail.com
> > wrote:
>
>> "This is already possible. Just nLockTime your withdrawls for some future
>> block. Don't sign any transaction that isn't nLockTime'd at least N blocks
>> beyond the present tip."
>>
>> This would have prevented the Bitfinex hack if BitGo did this, but it
>> wouldn't have helped if the Bitfinex offline key had been compromised
>> instead of BitGo doing the 2nd sig.  In the BFX hack the TXNs were signed
>> by Bitfinex's hot key and BitGo's key, they required 2 of 2.
>>
>> If I'm understanding correctly, what Matthew is proposing is a new type
>> of UTXO that is only valid to be spent as an nLockTime transaction and can
>> be reversed by some sort of RBF-type transaction within that time period, I
>> believe.
>>
>> But I don't think this will work. What do you do if the keys are
>> compromised?  What's to stop the attacker from locking the coins up
>> indefinitely by repeatedly broadcasting a refund transaction each time you
>> try to spend to an uncompromised address?
>>
>> You'd need a third distinct key required for the refund TXN that's
>> separate from the keys used to sign the initial nLockTime TXN.  And the
>> refund TXN would need to be able to go to a new address entirely.
>>
>> On Aug 3, 2016 11:28 PM, "Luke Dashjr via bitcoin-dev" <
>> bitcoin-dev@lists.linuxfoundation.org> wrote:
>>
>>> On Wednesday, August 03, 2016 6:16:20 PM Matthew Roberts via bitcoin-dev
>>> wrote:
>>> > In light of the recent hack: what does everyone think of the idea of
>>> > creating a new address type that has a reversal key and settlement
>>> layer
>>> > that can be used to revoke transactions?
>>>
>>> This isn't something that makes sense at the address, since it
>>> represents the
>>> recipient and not the sender. Transactions are not sent from addresses
>>> ever.
>>>
>>> > You could specify so that transactions "sent" from these addresses must
>>> > receive N confirmations before they can't be revoked, after which the
>>> > transaction is "settled" and the coins become redeemable from their
>>> > destination output. A settlement phase would also mean that a
>>> transaction's
>>> > progress was publicly visible so transparent fraud prevention and
>>> auditing
>>> > would become possible by anyone.
>>>
>>> This is already possible. Just nLockTime your withdrawls for some future
>>> block. Don't sign any transaction that isn't nLockTime'd at least N
>>> blocks
>>> beyond the present tip.
>>>
>>> Luke
>>> _______________________________________________
>>> bitcoin-dev mailing list
>>> bitcoin-dev@lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev@lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>

[-- Attachment #2: Type: text/html, Size: 6388 bytes --]

  reply	other threads:[~2016-08-04 12:43 UTC|newest]

Thread overview: 16+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-08-03 18:16 [bitcoin-dev] BIP clearing house addresses Matthew Roberts
2016-08-03 21:13 ` Troy Benjegerdes
2016-08-03 23:55 ` Tier Nolan
2016-08-04  2:07   ` Matthew Roberts
2016-08-04  3:27 ` Luke Dashjr
2016-08-04  3:49   ` Andrew Johnson
2016-08-04  4:53     ` Matthew Roberts
2016-08-04 12:43       ` Erik Aronesty [this message]
2016-08-06 10:39 ` s7r
2016-08-06 11:13   ` Tier Nolan
2016-08-07  5:35     ` Matthew Roberts
2016-08-07 22:59       ` Erik Aronesty
2016-08-08  0:48         ` Matthew Roberts
2016-08-08  9:56           ` Tier Nolan
2016-08-08 10:09           ` Erik Aronesty
2016-08-08 11:01             ` Tier Nolan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAJowKgJXAJSJc=AiBSYWFBTRYk539hpQt-Q=xetCv3YhdhvQ1Q@mail.gmail.com' \
    --to=erik@q32.com \
    --cc=bitcoin-dev@lists.linuxfoundation.org \
    --cc=matthew@roberts.pm \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox