Erik Aronesty [ARCHIVE] on Nostr: 📅 Original date posted:2016-08-04 📝 Original ...
📅 Original date posted:2016-08-04
📝 Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/dffea869/attachment.html>;
📝 Original message: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 at 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 at 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 at 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 at lists.linuxfoundation.org
>>> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>>>
>>
>
> _______________________________________________
> bitcoin-dev mailing list
> bitcoin-dev at lists.linuxfoundation.org
> https://lists.linuxfoundation.org/mailman/listinfo/bitcoin-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/dffea869/attachment.html>;