Matthew Roberts [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2015-06-13 to 2016-12-23
💬 Posted a total of 11 messages
📚 Participated in the following categories: Bitcoin-development, bitcoin-dev
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 17:55:02

- reply

📅 Original date posted:2016-12-23
📝 Original message:The following won't be directly applicable to your question without some
kind of tremendous hacking on your part: but in cryptography there is
actually a way to sign a message using only hash functions.
If you're interested look up the definition for "Lamport Signatures." It's
an algorithm for masking the bits of a message by exchanging a table of
hashes prior to signing and then revealing the "secrets" behind said hashes
in such a way that you can selectively mask the bits of the message hash
that you're wishing to sign.
It's actually a really cool algorithm and probably the most elegant thing
I've ever seen in the way of digital signatures - and besides just being
something that's really cool: Lamport Signatures have the advantage of
being quantum safe too (if you care about that kind of thing.)
To actually answer your question indirectly: you would use a consensus
system that understands Lamport signature operations in the "scriptPubKey"
(Ethereum could probably do this now.) And note that as Nick ODell has
already said: using the hashes alone in this scheme won't work since the
moment you publish the transactions with said hash secrets anyone is then
free to pluck out those values and double spend the original transaction to
a new destination (and this is actually the reason why Peter Todd's
proof-of-hash collision scheme in Bitcoin is insecure but still allows us
to incentivize whether or not there may be a flaw with the recent SHA
algorithms.)
Regarding hash protected M of N multi-sig: there is already a similar smart
contract algorithm called "atomic cross-chain contracts" that relies on
hash values to be released as part of the protocol to swap coins across
blockchains but said algorithm also uses ECDSA public keys to prevent the
transactions from being double-spent. So in Bitcoin Multi-sig using hash
values will work - though you still need to include an ECDSA pub key to
protect them from attackers on the network.
(I hope this helps. You didn't say much about the intended use-case for
this.)
On Fri, Dec 23, 2016 at 4:29 AM, Andrew via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Hi
>
> Is there a worked out scriptPubKey for doing multisig with just hashes
> of the participants? I think it is doable and it is more secure to a
> compromised ECDSA. I'm thinking something like this for the
> scriptPubKey:
> 2 OP_SWAP OP_SWAP OP_SWAP OP_DUP OP_HASH160 <pubKeyHash1>
> OP_EQUALVERIFY OP_DUP OP_HASH160 <pubKeyHash2> OP_EQUALVERIFY OP_DUP
> OP_HASH160 <pubKeyHash3> OP_EQUALVERIFY 3 OP_CHECKMULTISIG
>
> and <sigs><pubkeys> for the scriptSig
>
> Can anyone confirm or send me a link to the worked out script?
>
> Thanks
>
> --
> PGP: B6AC 822C 451D 6304 6A28 49E9 7DB7 011C D53B 5647
> _______________________________________________
> 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/20161224/1926b5e7/attachment.html>

2023-06-07 17:53:06

- reply

📅 Original date posted:2016-08-24
📝 Original message:Really nice idea. So its like a smart contract that incentivizes
publication that a server has been hacked? I also really like how the
funding has been handled -- with all the coins stored in the same address
and then each server associated with a unique signature. That way, you
don't have to split up all the coins among every server and reduce the
incentive for an attacker yet you can still identify which server was
hacked.
It would be nice if after the attacker broke into the server that they were
also incentivized to act on the information as soon as possible (revealing
early on when the server was compromised.) I suppose you could split up the
coins into different outputs that could optimally be redeemed by the owner
at different points in the future -- so they're incentivzed to act lest
their reward decays even more (this is of course, assuming that the
monetary reward for this is greater than any possible legal consequences
for the attacker -- it might not be. Thinking about this some more: it
would also be somewhat hard to deny that this -wasn't- a honeypot with such
a complex and unique scheme required for transactions, and I for one
wouldn't like to reveal that I'd hacked a server if I knew it was all a
calculated ploy. Don't honeypots rely on subtly?)
What about also proving to an attacker that by breaking into a server they
would be guaranteed a reward? I know that the use-case for this is proof of
compromise so incentivizing a security audit would kind of fall more into
an active invitation to audit but couldn't you also make a cryptocurrency
that allowed coins to be moved based on a service banner existing at a
given IP address? Attackers could then break into the server, setup a
service that broadcasts their public key hash, and then spend coins locked
at this special contract address to that pub key hash which miners would
check on redemption (putting aside malicious use-cases for now.)
On Wed, Aug 24, 2016 at 11:46 AM, Peter Todd via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> Bitcoin-based honeypots incentivise intruders into revealing the fact they
> have
> broken into a server by allowing them to claim a reward based on secret
> information obtained during the intrusion. Spending a bitcoin can only be
> done
> by publishing data to a public place - the Bitcoin blockchain - allowing
> detection of the intrusion.
>
> The simplest way to achieve this is with one private key per server, with
> each
> server associated with one transaction output spendable by that key.
> However
> this isn't capital efficient if you have multiple servers to protect: if we
> have N servers and P bitcoins that we can afford to lose in the
> compromise, one
> key per server gives the intruder only N/P incentive.
>
> Previously Piete Wuille proposed(1) tree signatures for honeypots, with a
> single txout protected by a 1-N tree of keys, with each server assigned a
> specific key. Unfortunately though, tree signatures aren't yet implemented
> in
> the Bitcoin protocol.
>
> However with a 2-of-2 multisig and the SIGHASH_SINGLE feature we can
> implement
> this functionality with the existing Bitcoin protocol using the following
> script:
>
> 2 <honeypot-pubkey> <distriminator-pubkey> 2 CHECKMULTISIG
>
> The honeypot secret key is shared among all N servers, and left on them.
> The
> distriminator secret key meanwhile is kept secret, however for each server
> a
> unique signature is created with SIGHASH_SINGLE, paying a token amount to a
> notification address. For each individual server a pre-signed signature
> created
> with the distriminator secret key is then left on the associated server
> along
> with the honeypot secret key.
>
> Recall the SIGHASH_SINGLE flag means that the signature only signs a single
> transaction input and transaction output; the transaction is allowed to
> have
> additional inputs and outputs added. This allows the thief to use the
> honeypot
> key to construct a claim transaction with an additional output added that
> pays
> an address that they own with the rest of the funds.
>
> Equally, we could also use SIGHASH_NONE, with the per-server discriminator
> being the K value used in the pre-signed transaction.
>
> Note that Jeff Coleman deserves credit as co-inventor of all the above.
>
>
> Censorship Resistance
> =====================
>
> A potential disadvantage of using non-standard SIGHASH flags is that the
> transactions involved are somewhat unusual, and may be flagged by
> risk analysis at exchanges and the like, a threat to the fungibility of the
> reward.
>
> We can improve on the above concept from Todd/Coleman by using a pre-signed
> standard transaction instead. The pre-signed transaction spends the
> honeypot
> txout to two addresses, a per-server canary address, and a change address.
> The
> private key associated with the change addres is also left on the server,
> and
> the intruder can then spend that change output to finally collect their
> reward.
>
> To any external observer the result looks like two normal transactions
> created
> in the process of someone with a standard wallet sending a small amount of
> funds to an address, followed by sending a larger amount.
>
>
> Doublespending
> ==============
>
> A subtlety in the the two transactions concept is that the intruder doesn't
> have the necessary private keys to modify the first transaction, which
> means
> that the honeypot owner can respond to the compromise by doublespending
> that
> transaction, potentially recovering the honeypot while still learning
> about the
> compromise. While this is possible with all honeypots, if the first
> transaction
> is signed with the opt-in RBF flags, and CPFP-aware transaction
> replacement is
> not implemented by miners, the mechanics are particularly disadvantageous
> to
> the intruder, as the honeypot owner only needs to increase the first
> transaction's fee slightly to have a high chance of recovering their funds.
> With CPFP-aware transaction replacement the intruder could in-turn respond
> with
> a high-fee CPFP second transaction, but currently no such implementation is
> known.
>
>
> Scorched Earth
> ==============
>
> We can use the "scorched earth" concept to improve the credibility of the
> honeypot reward by making it costly for the honeypot owner to doublespend.
> Here
> a second version of the honeypot pre-signed transaction would also be
> provided
> which sepnds the entirety of the honeypot output to fees, and additionally
> spends a second output to fees. An economically rational intruder will
> publish
> the first version, which maximizes the funds they get out of the honeypot.
> If
> the owner tries to dishonestly doublespend, they can respond by publishing
> the
> "scorched earth" transaction, encouraging the honeypot owner's honesty and
> making CPFP-aware transaction replacement irrelevant.
>
> Of course, miner centralization adds complexity to the above: in many
> instances
> honeypot owners and/or intruders will be able to recover funds from
> altruistic
> miners. Equally, the additional complexity may discourage intruders from
> making
> use of the honeypot entirely.
>
> Note that as an implementation consideration CHECKSEQUENCEVERIFY can be
> used to
> ensure the honeypot output can only be spent with transaction replacement
> enabled, as CSV requires nSequence to be set in specific ways in any
> transation
> spending the output.
>
>
> References
> ==========
>
> 1) https://blockstream.com/2015/08/24/treesignatures/
>
> --
> https://petertodd.org 'peter'[:-1]@petertodd.org
>
> _______________________________________________
> 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/20160825/9d41f9d8/attachment.html>

2023-06-07 17:52:16

- reply

📅 Original date posted:2016-08-04
📝 Original message:>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
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/9a441ba6/attachment-0001.html>

2023-06-07 17:52:15

- reply

📅 Original date posted:2016-08-07
📝 Original message:Not everyone who uses centralized exchanges are there to obtain the
currency though. A large portion are speculators who need to be able to
enter and exit complex positions in milliseconds and don't care about
decentralization, security, and often even the asset that they're buying.
Try telling everyone who currently uses Btc-e to go do their margin trading
over lightning channels, for example. They're not going to want to do that
because these exchanges are already meeting their needs perfectly well, and
like I argued before -- it would be very hard to do that as efficiently
with any other design (there are major drawbacks for traders with a
decentralized exchange.)
Like it or not, these exchanges play an integral role in the current
Bitcoin eco-system since they allow us to most efficiently discover price
and help improve liquidity. A decentralized exchange isn't going to stop
any more centralized exchanges from being hacked even if they are more
secure simply because traders don't want to use them.
(Sorry for the duplicate message Erik, I haven't used many mailing lists
before. I think I have the hang of it now though :) )
On Mon, Aug 8, 2016 at 8:59 AM, Erik Aronesty <erik at q32.com> wrote:
> I still feel like you're better off getting rid of "hot wallets" and use
> lightning-esqe networks to route orders. I don't think either speed or
> flexibility is an issue there.
>
> IMO, the point of Bitcoin is to avoid the centralization that seems to be
> happening on the network now. By making "hot wallets" more "secure", we
> encourage things to keep heading downhill with massive centralized
> crappy-security exchanges.
>
> Because, ultimately, there's no security that will prevent an inside
> job. And all of these thefts have, in my opinion, been at least partly
> inside jobs.
>
> And centralization is the actually demon that needs slaying here.
>
> A client-side library with P2P order routing, tether.to + bitcoin ....
> and you've got a decentralized exchange... with orders matched to users
> directly, and channel-trades executed instantly. And "market makers"
> running nodes to facilitate routing, etc.
>
> No center... nothing to shut down or sue... and no one holds your funds.
> That's a real Bitcoin exchange.
>
>
>
> On Sun, Aug 7, 2016 at 1:35 AM, Matthew Roberts via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> I'm wondering if we're fully on the same page here. What I was thinking
>> was that this protection mechanism would be applied to the coins in the hot
>> wallet (I wasn't talking about moving coins from the cold wallet to the hot
>> wallet -- though such a mechanism is also needed.)
>>
>> With the hot wallet you would have an output script that only allowed
>> coins to be sent to a new transaction whose output script was then only
>> redeemable after N confirmations (the output is relative time-locked) but
>> which can also be recovered to a fixed fail-safe address before the
>> time-lock is reached (exactly like TierNolan already listed only the
>> time-locked destination shouldn't be completely fixed.) So the private key
>> for this hot wallet can still sign valid transactions to withdraw coins to
>> any known destination and these transactions still reach the blockchain.
>>
>> The key difference from a regular transaction is that the destination
>> only has access to the coins -after- the relative time-lock is reached (N
>> blocks after first confirm) so everyone knows where withdrawals are suppose
>> to be going and how many coins are being withdrawn at any given time.
>> Deposits to the hot wallet would therefore need to be encumbered by the
>> same protection so that from then on this time-lock to redeem coins can be
>> applied to every new transaction trying to move coins (withdrawn by a user
>> of the exchange or sent to the cold wallet.)
>>
>> Notice we don't care about the destination in the TX script for the hot
>> wallet because to process user's withdrawals we can't know ahead of time
>> where they need to be sent (so it isn't possible to use a fixed address
>> here – though you might want to remove the clearing phase and set a fixed
>> address for coins sent from the hot wallet to the cold wallet.) The benefit
>> here comes from being able to see what withdrawals are being cleared,
>> matching those up to our expectations, and being able to "cancel"
>> withdrawals if they look suspicious, and you get the benefits for transfers
>> made from the hot wallet to the cold wallet and visa-versa.
>>
>>
>> This approach is good for a number of crucial services:
>>
>> 1. Wallets could be built that grouped coins into different "accounts"
>> with different time-frames required for clearing / unlocking coins. Your
>> savings or investment account would say -- take up to a week to clear --
>> whereas your everyday account used for smaller purchases (with less money)
>> would only take a few hours. This could all be linked up to services that
>> notified you of your money being moved + made any phone calls needed to
>> verify any larger transfers.
>>
>> The service could also be entrusted with the “cancellation” key which can
>> only be used to move money to your offline fail-safe address. This would be
>> quite an interesting way to mitigate fraud without the user having to be
>> trusted to do anything (except I suppose – not storing their recovery keys
>> online … but this could be partially solved with BIP 32-style “master”
>> public keys + hardware wallets + multi-sig, N factor auth, etc ...)
>>
>> 2. Gambling websites that process a lot of Bitcoins also have a hot
>> wallet which could be better protected by this.
>>
>> 3. Various other e-commerce websites also accept Bitcoins directly. (Deep
>> web markets come to mind -- hey, people breaking the law need good security
>> too.)
>>
>> 4. Provable dead man's switches on the protocol level is another idea --
>> no need to keep special time-locked transactions around and rely on them to
>> be broadcast = more reliable escrow services.
>>
>> 5. And obviously exchange hot (and cold) wallets - enemy number 1.
>>
>> I hope that makes sense. I think I initially managed to confuse a lot of
>> people by talking about revoking transactions / “settlement layers”, etc.
>> But IMO: all of this needs to take place on the blockchain with a new set
>> of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
>> the general idea would still work.
>>
>>
>> tl; dr, A pseudo-reversal mechanism for transactions would mean that
>> stolen private keys were no longer such an issue. This is desperately
>> needed for exchanges, wallets, and other services that are forced to manage
>> private keys, and whose users (I argue) already expect for this to be
>> possible (or at least will when they're hacked.)
>>
>>
>>
>>
>> On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>
>>> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <
>>> bitcoin-dev at lists.linuxfoundation.org> wrote:
>>>
>>>> * reversal of transactions is impossible
>>>>
>>>
>>> I think it would be more accurate to say that the requirement is that
>>> reversal doesn't happen unexpectedly.
>>>
>>> If it is clear in the script that reversal is possible, then obviously
>>> the recipient can take that into consideration.
>>>
>>>
>>>> * keep private keys private and safe. Lose them, it's like losing cash,
>>>> you can just forget about it.
>>>>
>>>
>>> Key management is a thing. Managing risk by keeping some keys offline
>>> is an important part of that.
>>>
>>>
>>>> * while we try hard to make 0-conf as safe as possible (if there's no
>>>> RBF flag on the transaction), we make it almost impossible or very very
>>>> expensive to reverse a confirmed transaction.
>>>>
>>>
>>> BitGo has an "instant" system where they promise to only sign one
>>> transaction for a given output. If you trust BitGo, then this is safe from
>>> double spending, since a double spender can't sign two transactions.
>>>
>>> If BitGo had actually implemented a daily withdrawal limit, then their
>>> system ends up similar to cold storage. Only 10% of the funds at Bitfinex
>>> could have been withdrawn before manual intervention was required (with
>>> offline keys).
>>>
>>> Who will accept
>>>> such an input and treat it as a payment if it can be reversed during the
>>>> settlement layer?
>>>
>>>
>>> Obviously, if a payment is reversible, then you treat it as a reversible
>>> payment. The protection here relates to moving coins from the equivalent
>>> of cold storage to hot storage.
>>>
>>> It is OK if it takes longer, since security is more important than
>>> convenience for coins in cold storage.
>>>
>>>
>>>> The linked page describes that merchants will never accept payments from
>>>> 'vaults', and it will take 24 hours for coins to be irreversible moved
>>>> outside the 'vault'.
>>>
>>>
>>> This relates to the reserves held by the exchange. A portion of the
>>> funds are in hot storage with live keys. These funds can be stolen by
>>> anyone who gets access to the servers. The remaining funds are held in
>>> cold storage and they cannot be accessed unless you have the offline keys.
>>> These funds are supposed to be hard to reach and require manual
>>> intervention.
>>>
>>> I think this is a wrong approach. hacks and big losses are sad, but all
>>>> the time users / exchanges are to blame for wrong implementations or
>>>> terrible security practices.
>>>>
>>>
>>> Setting up offline keys to act as firebreaks is part of good security
>>> practices.
>>>
>>> _______________________________________________
>>> 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/20160808/39344b7f/attachment.html>

2023-06-07 17:52:13

- reply

📅 Original date posted:2016-08-07
📝 Original message:I'm wondering if we're fully on the same page here. What I was thinking was
that this protection mechanism would be applied to the coins in the hot
wallet (I wasn't talking about moving coins from the cold wallet to the hot
wallet -- though such a mechanism is also needed.)
With the hot wallet you would have an output script that only allowed coins
to be sent to a new transaction whose output script was then only
redeemable after N confirmations (the output is relative time-locked) but
which can also be recovered to a fixed fail-safe address before the
time-lock is reached (exactly like TierNolan already listed only the
time-locked destination shouldn't be completely fixed.) So the private key
for this hot wallet can still sign valid transactions to withdraw coins to
any known destination and these transactions still reach the blockchain.
The key difference from a regular transaction is that the destination only
has access to the coins -after- the relative time-lock is reached (N blocks
after first confirm) so everyone knows where withdrawals are suppose to be
going and how many coins are being withdrawn at any given time. Deposits to
the hot wallet would therefore need to be encumbered by the same protection
so that from then on this time-lock to redeem coins can be applied to every
new transaction trying to move coins (withdrawn by a user of the exchange
or sent to the cold wallet.)
Notice we don't care about the destination in the TX script for the hot
wallet because to process user's withdrawals we can't know ahead of time
where they need to be sent (so it isn't possible to use a fixed address
here – though you might want to remove the clearing phase and set a fixed
address for coins sent from the hot wallet to the cold wallet.) The benefit
here comes from being able to see what withdrawals are being cleared,
matching those up to our expectations, and being able to "cancel"
withdrawals if they look suspicious, and you get the benefits for transfers
made from the hot wallet to the cold wallet and visa-versa.
This approach is good for a number of crucial services:
1. Wallets could be built that grouped coins into different "accounts" with
different time-frames required for clearing / unlocking coins. Your savings
or investment account would say -- take up to a week to clear -- whereas
your everyday account used for smaller purchases (with less money) would
only take a few hours. This could all be linked up to services that
notified you of your money being moved + made any phone calls needed to
verify any larger transfers.
The service could also be entrusted with the “cancellation” key which can
only be used to move money to your offline fail-safe address. This would be
quite an interesting way to mitigate fraud without the user having to be
trusted to do anything (except I suppose – not storing their recovery keys
online … but this could be partially solved with BIP 32-style “master”
public keys + hardware wallets + multi-sig, N factor auth, etc ...)
2. Gambling websites that process a lot of Bitcoins also have a hot wallet
which could be better protected by this.
3. Various other e-commerce websites also accept Bitcoins directly. (Deep
web markets come to mind -- hey, people breaking the law need good security
too.)
4. Provable dead man's switches on the protocol level is another idea -- no
need to keep special time-locked transactions around and rely on them to be
broadcast = more reliable escrow services.
5. And obviously exchange hot (and cold) wallets - enemy number 1.
I hope that makes sense. I think I initially managed to confuse a lot of
people by talking about revoking transactions / “settlement layers”, etc.
But IMO: all of this needs to take place on the blockchain with a new set
of OP_CODES and other than the fixed address issue with OP_SPENDTO, I think
the general idea would still work.
tl; dr, A pseudo-reversal mechanism for transactions would mean that stolen
private keys were no longer such an issue. This is desperately needed for
exchanges, wallets, and other services that are forced to manage private
keys, and whose users (I argue) already expect for this to be possible (or
at least will when they're hacked.)
On Sat, Aug 6, 2016 at 9:13 PM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Sat, Aug 6, 2016 at 11:39 AM, s7r via bitcoin-dev <bitcoin-dev at lists.
> linuxfoundation.org> wrote:
>
>> * reversal of transactions is impossible
>>
>
> I think it would be more accurate to say that the requirement is that
> reversal doesn't happen unexpectedly.
>
> If it is clear in the script that reversal is possible, then obviously the
> recipient can take that into consideration.
>
>
>> * keep private keys private and safe. Lose them, it's like losing cash,
>> you can just forget about it.
>>
>
> Key management is a thing. Managing risk by keeping some keys offline is
> an important part of that.
>
>
>> * while we try hard to make 0-conf as safe as possible (if there's no
>> RBF flag on the transaction), we make it almost impossible or very very
>> expensive to reverse a confirmed transaction.
>>
>
> BitGo has an "instant" system where they promise to only sign one
> transaction for a given output. If you trust BitGo, then this is safe from
> double spending, since a double spender can't sign two transactions.
>
> If BitGo had actually implemented a daily withdrawal limit, then their
> system ends up similar to cold storage. Only 10% of the funds at Bitfinex
> could have been withdrawn before manual intervention was required (with
> offline keys).
>
> Who will accept
>> such an input and treat it as a payment if it can be reversed during the
>> settlement layer?
>
>
> Obviously, if a payment is reversible, then you treat it as a reversible
> payment. The protection here relates to moving coins from the equivalent
> of cold storage to hot storage.
>
> It is OK if it takes longer, since security is more important than
> convenience for coins in cold storage.
>
>
>> The linked page describes that merchants will never accept payments from
>> 'vaults', and it will take 24 hours for coins to be irreversible moved
>> outside the 'vault'.
>
>
> This relates to the reserves held by the exchange. A portion of the funds
> are in hot storage with live keys. These funds can be stolen by anyone who
> gets access to the servers. The remaining funds are held in cold storage
> and they cannot be accessed unless you have the offline keys. These funds
> are supposed to be hard to reach and require manual intervention.
>
> I think this is a wrong approach. hacks and big losses are sad, but all
>> the time users / exchanges are to blame for wrong implementations or
>> terrible security practices.
>>
>
> Setting up offline keys to act as firebreaks is part of good security
> practices.
>
> _______________________________________________
> 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/20160807/c4d377f1/attachment-0001.html>

2023-06-07 17:52:12

- reply

📅 Original date posted:2016-08-03
📝 Original message:This would honestly work. It forces the attacker to go through with the
clearing phase which simultaneously makes it possible to "cancel" the TX
through another logic branch before the timeout occurs. I'd say that would
meet the needs of a clearing mechanism / fraud prevention system for an
exchange perfectly while requiring minimal changes to the software.
Very, very smart idea. A++, would read again.
On Thu, Aug 4, 2016 at 9:55 AM, Tier Nolan via bitcoin-dev <
bitcoin-dev at lists.linuxfoundation.org> wrote:
> On Wed, Aug 3, 2016 at 7:16 PM, Matthew Roberts via bitcoin-dev <
> bitcoin-dev at lists.linuxfoundation.org> wrote:
>
>> The reason why I bring this up is existing OP codes and TX types don't
>> seem suitable for a secure clearing mechanism;
>>
>
> I think reversing transactions is not likely to be acceptable. You could
> add an opcode that requires that an output be set to something.
>
> [target script] SPENDTO
>
> This would require that [target script] is the script for the
> corresponding output. This is a purely local check.
>
> For example, if SPENDTO executes as part of the script for input 3, then
> it checks that output 3 uses the given script as its scriptPubKey. The
> value of input 3 and output 3 would have to be the same too.
>
> This allows check sequence verify to be used to lock the spending script
> for a while. This doesn't allow reversal, but would give a 24 hour window
> where the spenders can reverse the transaction.
>
> [IF <1 day> CSV DROP <live public key> CHECKSIG ELSE <offline protected
> key> CHECKSIG] SPENDTO <live public key2> CHECKSIG
>
> Someone with the live public key can create a transaction that spends the
> funds to the script in the square brackets.
>
> Once that transaction hits the blockchain, then someone with the <offline
> protected key> has 24 hours to spend the output before the person with the
> live keys can send the funds onward.
>
> _______________________________________________
> 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/4eda2f65/attachment.html>

2023-06-07 17:52:11

- reply

📅 Original date posted:2016-08-03
📝 Original message: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?
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.
The reason why I bring this up is existing OP codes and TX types don't seem
suitable for a secure clearing mechanism; Nlocktimed TXs won't work for
this since you can't know ahead of time when and where a withdrawal needs
to be made, plus there's still the potential for key mismanagement; Similar
problems with OP_CHECKLOCKTIMEVERIFY apply too – unless you keep a private
key around on the server which would defeat the purpose. The main use case
here, would be specifically to improve centralized exchange security by
making it impossible for a hot wallet to be raided all at once.
Thoughts?
Some existing background:
http://hackingdistributed.com/2016/08/03/how-bitfinex-heist-could-have-been-avoided/
-- Proposed the basic idea for a time-based clearing house but using
blockchains directly, this is a much better idea than my own.
roberts.pm/timechain -- My original paper written in 2015 which proposed a
similar idea for secure wallet design but implemented using time-locked
ECDSA keys. Obviously a blockchain would work better for this.
Other -- if the idea has already been brought up by other people, I
apologize.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160804/fe4335fb/attachment.html>

2023-06-07 17:50:55

- reply

📅 Original date posted:2016-05-20
📝 Original message:Good point, to be honest. Maybe there's a better way to combine the block
hashes like taking the first N bits from each block hash to produce a
single number but the direction that this is going in doesn't seem ideal.
I just asked a friend about this problem and he mentioned using the hash of
the proof of work hash as part of the number so you have to throw away a
valid POW if it doesn't give you the hash you want. I suppose its possible
to make it infinitely expensive to manipulate the number but I can't think
of anything better than that for now.
I need to sleep on this for now but let me know if anyone has any better
ideas.
On Fri, May 20, 2016 at 6:34 AM, Johnson Lau <jl2012 at xbt.hk> wrote:
> Using the hash of multiple blocks does not make it any safer. The miner of
> the last block always determines the results, by knowing the hashes of all
> previous blocks.
>
>
> == Security
>
> Pay-to-script-hash can be used to protect the details of contracts that
> use OP_PRANDOM from the prying eyes of miners. However, since there is also
> a non-zero risk that a participant in a contract may attempt to bribe a
> miner the inclusion of multiple block hashes as a source of randomness is a
> must. Every miner would effectively need to be bribed to ensure control
> over the results of the random numbers, which is already very unlikely. The
> risk approaches zero as N goes up.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160520/6d2ee1d5/attachment.html>

2023-06-07 17:50:55

- reply

2023-06-07 17:50:54

- reply

📅 Original date posted:2016-05-20
📝 Original message:== Background
OP_PRANDOM is a new op code for Bitcoin that pushes a pseudo-random number
to the top of the stack based on the next N block hashes. The source of the
pseudo-random number is defined as the XOR of the next N block hashes after
confirmation of a transaction containing the OP_PRANDOM encumbered output.
When a transaction containing the op code is redeemed, the transaction
receives a pseudo-random number based on the next N block hashes after
confirmation of the redeeming input. This means that transactions are also
effectively locked until at least N new blocks have been found.
== Rational
Making deterministic, verifiable, and trustless pseudo-random numbers
available for use in the Script language makes it possible to support a
number of new smart contracts. OP_PRANDOM would allow for the simplistic
creation of purely decentralized lotteries without the need for complicated
multi-party computation protocols. Gambling is also another possibility as
contracts can be written based on hashed commitments, with the winner
chosen if a given commitment is closest to the pseudo-random number.
OP_PRANDOM could also be used for cryptographically secure virtual asset
management such as rewards in video games and in other applications.
== Security
Pay-to-script-hash can be used to protect the details of contracts that use
OP_PRANDOM from the prying eyes of miners. However, since there is also a
non-zero risk that a participant in a contract may attempt to bribe a miner
the inclusion of multiple block hashes as a source of randomness is a must.
Every miner would effectively need to be bribed to ensure control over the
results of the random numbers, which is already very unlikely. The risk
approaches zero as N goes up.
There is however another issue: since the random numbers are based on a
changing blockchain, its problematic to use the next immediate block hashes
before the state is “final.” A safe default for accepting the blockchain
state as final would need to be agreed upon beforehand, otherwise you could
have multiple random outputs becoming valid simultaneously on different
forks.
A simple solution is not to reveal any commitments before the chain height
surpasses a certain point but this might not be an issue since only one
version will eventually make it into the final chain anyway -- though it is
something to think about.
== Outro
I'm not sure how secure this is or whether its a good idea so posting it
here for feedback
Thoughts?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20160520/951fcc41/attachment.html>

2023-06-07 17:50:54

- reply

2023-06-07 15:37:43

- reply

📅 Original date posted:2015-06-13
📝 Original message:I've been tossing around an idea in my head that involves time-locked
encryption [0] and I wondered what the devs here think about it. In a
nutshell: the timechain is a serial chain of time-lock encrypted GPG keys
at N minute intervals (meaning that it requires N minutes to decrypt a
single link / key in the chain and each link must be fully decrypted before
decryption can start on the next link.) For those not aware of how
time-lock encryption works it goes something like this:
1. Choose some random, unique text - this is the initialisation vector or
IV.
2. Hash that text -> output.
3. Hash the output -> output.
4. Hash the output -> output.
5. ...
6. Process is repeated for N minutes.
7. Result is then used to generate encryption keys and the public key can
be used to time-lock encrypt an arbitrary number of plaintexts.
8. All intermediary results are discarded -- only the pub key is kept and
giving out the IV forces an individual to have to repeat the same amount of
work used to generate the encryption key.
What's interesting about this is that the keys can be generated in parallel
and then "stitched" together to form a single serial chain of keys. So
potentially, if a person had access to a GPU cluster then they could
generate a years worth of work in only 5 minutes. Now imagine if one were
to stitch these keys together into a chain of keys at five minute intervals
(a structure I refer to as the "timechain"): you could use this structure
to encrypt ECDSA keys which could then be used in multi-signature contract
schemes as a 100% decentralized, trustless way to execute refunds in
contract protocols.
Unexpected benefit: time-lock encryption can be used to build unbreakable
DACs.
Peter Todd has already done work on using Bitcoin to incentivize the
decryption process of time-lock encryption [1] but what he may not be aware
of is how important this process is for the construction of DACs.
Imagine a true peer-to-peer cryptocurrency exchange [2] that time-lock
encrypts a chain of ECDSA keys using the timechain and then sets up
contracts to pay a small portion of their fees "into" the ECDSA keys.
Essentially the exchange has created a DAC that pays its participants to
decrypt itself. This is the incentive for the decryption. The reason for
the incentive is that another chain of keys can be generate at 5 minute
intervals which can be used in contract protocols in place of nTimeLocked
refund transactions (which are vulnerable to transaction malleability.)
Sample contract using the timechain:
3 of 4 multi-sig: Owner, Owner, Recipient, Timelock
Pay N coins to recipient sequentially (micropayment channel) before [time /
date], otherwise fall back on timelock decrypted refund key to give full
leverage back to owner. This is how smart contracts would work using the
timechain for refunds (instead of nTimeLock TXs.)
Using the DAC, it might also be possible to force participants to reveal
their solutions to the decryption of the timechain (otherwise the first
person who starts on the chain would receive all the fees which isn't very
fair.) One way to do this would be to use the public key for the fee ECDSA
key as the IV used to generate the next key on the chain. To spend the fees
would therefore require revealing the public key if the fees were paid to a
pay-to-pub-key-hash transaction.
A further precaution would be to generate the pay to fee transaction in
such a way that the amount needs to be redeemed otherwise another
transaction would burn the coins. (I haven't worked out the full details
for this but similar schemes have been used successfully, for example in
BitHalo [3]. The Lightning Network [4] offers another potential solution.)
Perhaps a custom blockchain or sidechain could also be used to award coins
for successful (and timely solutions) but this is a subject for future work.
In conclusion: I have described a simple way to solve the TX malleability
problem in smart contract protocols without requiring a fork or relying on
a third-party escrow scheme to manage coins. My solution doesn't require
any trust beyond the initial need for the timechain to be generated in a
secure cluster and the solution remains secure so long as participants
stick to using future keys in the chain regardless of how far along
decryption is.
What do you think of the idea so far?
Obviously the biggest flaw here is that the integrity of a timechain can't
be known before-hand but if a timechain were to be generated securely by a
reputable party, the biggest benefit of using it is that it basically runs
itself: it does not require any third-party to manage its functionality and
the entity which originally generated it can completely disappear without
interrupting service. This could, for instance - allow companies to create
entirely secure and reliable systems that couldn't be hacked as the
behaviour of a timechain is deterministic. I think this is a huge
improvement over existing systems which require third-parties to be
perpetually trusted with managing key-pairs on their web servers.
Anyway, that's the basic idea. Let me know what you think.
Sources:
[0] http://www.gwern.net/Self-decrypting%20files
[1]
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05547.html
[2] http://www.uptrenda.com/uptrenda.pdf
[3] https://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosided.pdf
[4] https://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/6fbc7681/attachment.html>

2023-06-07 15:37:43

- reply

📅 Original date posted:2015-06-13
📝 Original message:I've been tossing around an idea in my head that involves time-locked
encryption [0] and I wondered what the devs here think about it. In a
nutshell: the timechain is a serial chain of time-lock encrypted GPG keys
at N minute intervals (meaning that it requires N minutes to decrypt a
single link / key in the chain and each link must be fully decrypted before
decryption can start on the next link.) For those not aware of how
time-lock encryption works it goes something like this:
1. Choose some random, unique text - this is the initialisation vector or
IV.
2. Hash that text -> output.
3. Hash the output -> output.
4. Hash the output -> output.
5. ...
6. Process is repeated for N minutes.
7. Result is then used to generate encryption keys and the public key can
be used to time-lock encrypt an arbitrary number of plaintexts.
8. All intermediary results are discarded -- only the pub key is kept and
giving out the IV forces an individual to have to repeat the same amount of
work used to generate the encryption key.
What's interesting about this is that the keys can be generated in parallel
and then "stitched" together to form a single serial chain of keys. So
potentially, if a person had access to a GPU cluster then they could
generate a years worth of keys in only 5 minutes. Now imagine if one were
to stitch these keys together into a chain of keys at five minute intervals
(a structure I refer to as the "timechain"): you could use this structure
to encrypt ECDSA keys which could then be used in multi-signature contract
schemes as a 100% decentralized, trustless way to execute refunds in
contract protocols.
Unexpected benefit: time-lock encryption can be used to build unbreakable
DACs.
Peter Todd has already done work on using Bitcoin to incentivize the
decryption process of time-lock encryption [1] but what he may not be aware
of is how important this process is for the construction of DACs.
Imagine a true peer-to-peer cryptocurrency exchange [2] that time-lock
encrypts a chain of ECDSA keys using the timechain and then sets up
contracts to pay a small portion of their fees "into" the ECDSA keys.
Essentially the exchange has created a DAC that pays its participants to
decrypt itself. This is the incentive for the decryption. The reason for
the incentive is that another chain of keys can be generate at 5 minute
intervals which can be used in contract protocols in place of nTimeLocked
refund transactions (which are vulnerable to transaction malleability.)
Sample contract using the timechain:
3 of 4 multi-sig: Owner, Owner, Recipient, Timelock
Pay N coins to recipient sequentially (micropayment channel) before [time /
date], otherwise fall back on timelock decrypted refund key to give full
leverage back to owner. This is how smart contracts would work using the
timechain for refunds (instead of nTimeLock TXs.)
Using the DAC, it might also be possible to force participants to reveal
their solutions to the decryption of the timechain (otherwise the first
person who starts on the chain would receive all the fees which isn't very
fair.) One way to do this would be to use the public key for the fee ECDSA
key as the IV used to generate the next key on the chain. To spend the fees
would therefore require revealing the public key if the fees were paid to a
pay-to-pub-key-hash transaction.
A further precaution would be to generate the pay to fee transaction in
such a way that the amount needed to be redeemed before a certain
time-frame otherwise another transaction would burn the coins. (I haven't
worked out the full details for this yet but similar schemes have been used
successfully, for example in BitHalo [3] and the Lightning Network [4]
offers another potential solution.) Perhaps a custom blockchain or
sidechain could be used to award coins for successful (and timely
solutions) but this is a subject for future work.
In conclusion: I have described a simple way to solve the TX malleability
problem in smart contract protocols without requiring a fork or relying on
a third-party escrow services to hold keys. My solution doesn't require any
trust beyond the initial need for the timechain to be generated in a secure
environment and the solution remains secure so long as participants stick
to using future keys in the chain regardless of how far along the
decryption is.
Critique / flaws
Obviously the biggest flaw here is that the integrity of a timechain can't
be known before-hand but if a timechain were to be generated securely by a
reputable party, the biggest benefit of using it is that it basically runs
itself: it does not require any third-party to manage its functionality and
the entity which originally generated it can completely disappear without
interrupting service. This could, for instance - allow companies to create
entirely secure and reliable systems that couldn't be hacked as the
behaviour of a timechain is deterministic. I think this is a huge
improvement over existing systems which require third-parties to be
perpetually trusted with managing key-pairs on their web servers.
You could even use collateral as a way to incentivize the reliable
construction of the timechain by collecting collateral into a multi-sig
controlled by a number of neutral parties and only releasing the coins back
to the entity if the chain behaves as expected. I imagine some kind of
signed copy of a GPU cluster bill + proof of code executed would be
additional proof.
Anyway, that's the basic idea. Let me know what you think.
Sources:
[0] http://www.gwern.net/Self-decrypting%20files
[1]
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg05547.html
[2] http://www.uptrenda.com/uptrenda.pdf
[3] https://bithalo.org/wp-content/uploads/2014/06/whitepaper_twosided.pdf
[4] https://lightning.network/lightning-network-paper-DRAFT-0.5.pdf
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150613/ddc1964c/attachment.html>