Topic: Hiding your bitcoin behind a timelock AND "m of n keys" at the same time? - page 2. (Read 6800 times)

Of course not, it's like the private key to public adress, so the coins are gone.
If you fail to write down/print the third key, it's your own fault. Just like failing to write down the private key when you make a paper wallet.

So you kinda want the miners to store user data like those fail safe adresses, don't you?
Because you cannot setup constraints client-sided, they are useless.

So let's assume that I malware got my wallet and has my private key.  I've used the private key to freeze my coins so they are stuck in a pending state.  Let's ignore for a moment how the network and other nodes (not just my wallet) will know the coins are in a pending state.  We've set it up so that a 3rd key can unlock the frozen coins and send them out to a fail-safe address.  This key would have to be mathematically associated with my address so that it provides an ECDSA signature when used.  But unfortunately let's assume that I forgot to literally write down the key on paper.  Are my coins gone forever?  Is there anything that will be able to show me what that 3rd key is supposed to be?

I guess the point I'm trying to make is that it might be possible to pre-specify an exact failsafe address without the need for an extra key at all, such that the private key can still send to it instantly. This means the thief can only see their transaction frozen, or sent back to you.

The danger is only at the time you are creating the new adress, not when you use it to spend coins.
At the moment you also have this danger when using an adress to spend coins, because you have to use the private key to do this.
Obviously the third key should only be on a piece of paper or offline hardware.

You don't have to use the third key unless malware got your wallet, except for the waiting time there wouldn't be other drawbacks.

As I read this its interesting, but let me see if I understand you correctly.
- You want to allow your wallet to create an address which by nature can send coins but only after a delay following the withdrawal request.
-Creating the address allows two keys to be created, one which can freeze the coins during the delay period and one which can release the bitcoins back to a new address (presumably one you also control)
- If a thief has access to just your private key, they can only spend your coins (with a delay) or freeze them.  They need both your private and this release key to truly liberate the coins to an address of their choosing.

Yet how do you propose reliably generating these 2 keys so that they are not viewable on the same system?  I could be misunderstanding you, I'm just interested in how you see it working.  Usually if a thief has gained access to your private key, he has access to everything else.  

I've tried to solve that problem by making knowledge of the private key independent of the ability to spend coins.  Perhaps a transaction could be created with output scripts that would require both a delay OR a transfer back to a failsafe address you control (no extra key required)  

Making it so that the miners recognize a transaction is pending is another topic entirely, which may or may not necessitate the need for vanity addresses.

I had a similar idea, so I will post it in this thread.
Maybe this approach would solve some of the problems:

Create a second type of adress that acts like a normal adress, but with those exceptions:
- When you create the adress, you get a third safety key.
- The safe adress starts with e.g. 7 to distinguish it from normal adresses.
- The safe adress will transfer the money like a normal adress, but after a certain delay (2 days?1 week?), if you have private key to this adress you can freeze the adress and stop the transaction whenever you want. Miners can see that the transaction is from an adress with a starting 7, so it should be possible to implement.
- If an adress is frozen, you are able to release all Bitcoins from the safe adress with the third safety key to a new adress.


It may be some extra work, but it would add a new layer of safety for those who want it.
So if your PC is compromised later in the process your coins wouldn't be gone in an instant anymore.
It would be easy to set up an app that would alarm you in case the money is spent from your safe adress.

To Danny Hamilton: Your patience is commendable.  I hope you realize how dead-set I am on understanding this.  Indeed my suggestions might sound a little ludicrous at this point, but hopefully I can get to where I able to describe them in terms that are understandable.  Also, if you want to post an address I'll tip you for your time.

What you've explained so far is interesting.  


I understand that Bitcoin uses an interpreted scripting system to determine whether an output's criteria have been satisfied.

AND

Scripting provides the flexibility to change the parameters of what's needed to spend transferred Bitcoins.  

AND usually,

Most Bitcoin outputs encumber the newly transferred coins with a single ECDSA private key

I know that multi-sig transactions  encumber the output with additional constraints (like m of n private keys needed to spend)

I think it's significant that users as well as thieves are forced to use these same constraints. In effect it means a user might encumber his own coins in a way that is to his advantage.

So before we think about designing constraints, What basic properties are we focused on here?
1.) The coins can be spent, but the pending transaction is broadcast and a specified amount of time (or confirmations) must pass before the coins actually leave your wallet.
2.) Sending the transaction again overrides the first, and again renews the pending withdrawal time.
3.) A failsafe address is added that allows the coins to immediately be spent to it.  (very important)

I would find such constraints useful for several reasons:
Transaction mistakes happen all the time by human-error.  This allows users a window of time to change something before it becomes irreversible if they messed up a detail (like the amount, miner fee, or destination)
If a thief obtains the private key to an address and attempts to import/spend the coins, they too are subject to the same constraints that make withdrawals pending for the amount of time the owner originally specified.  Any attempt to spend the coins will notify the owner, and by scripting design he can send to a failsafe address (which should be set up to have a private key stored elsewhere).  A whole chain of such addresses set up so that the job of hacking 1 wallet becomes the job of hacking many.  
Unlike multi-sig, which just makes hacking many private keys necessary, "pending withdrawals + failsafe" allows the owner to be notified that his private key has been obtained if the thief ever attempts to spend his coins.  The coins are still his, and he can act accordingly.

It's literally like saying to a thief: "You can steal the key to my vault, but if you try to spend the money there I will know about it and can cancel it.  Also, I can immediately send all the money to another vault I control that you don't have the key to"  

Some similar (but not identical) functionalities already exist in the protocol like time locking contracts.  The difference is that time locking just specifies a time until the coins become spendable in advance.  Whereas we want to specify a time that the coins must wait to become spendable the moment that they are spent, in advance.


Well I admit that's where it gets murky to me.  The problem is that we have to convince other nodes to reject a transaction that prematurely tries to send the full amount. That's what a thief with a modified wallet would try to do.  But the thief can't change the output scripts because they're already set up.  So we need script that's very smartly designed to begin with, we could try to design it so that it can't prematurely send the full amount, it needs to wait in a wallet first.  The scripting should be flexible so that a variety of time frames can be inputted during creation.  (I'm using 144 as an arbitrary number).

Perhaps the coins with these scripts would broadcast a kind of "intention to send" or "transaction start" in blockchain record.  The intention then sticks with each successive block as pending until the requirements are met and it can finally be confirmed as sent.  This kind of transaction first has to plant its foot somewhere, because the script requires:

• if the "intention to send" is > 144 blocks prior in the blockchain.  Send = true  and the coins will relay a transaction
• If it can't find its "intention to send" (never existed), or if it is < 144 blocks prior (still pending) then send = false and it creates a new point to start over again.

Because nodes have an awareness of which block they are currently viewing, it should surely be possible to create a script which is able to find a previous starting point in the blockchain and compare it to the number of blocks that have passed since, either sending or pending the transaction based on the result.  (For these purposes, I mean to say pending = the coins stay in the wallet, waiting to be sent)

Ideally if we set it up correctly, attempting to spend the transaction again to a different address or different amount would broadcast another intention, overriding the first.  


We shouldn't have to re-write the blockchain.  Starting a delayed wtihdrawal transaction keeps the coins in your wallet, but it absolutely has to broadcast a kind of transaction.  Some solutions are more elegant than others.  

• Maybe it sends a tiny amount first, (I don't think this is feasible)
• maybe the output scripts specify that it first must send the coins to another kind of intermediary address that you also control, and then it will either spend the coins to the ultimate destination or return them to an address you control based on which script has been satisfied.
• maybe the blocks are changed to be capable of storing these kinds of "intention to send" reference points that must exist before coins can ultimately be spent based on the requirements of these output scripts.
• maybe the transaction has outputs that specify that it simply must confirm much more slowly, able to become purposefully double-spent in the meantime (I also do not like this idea)
  
• or maybe its a case where all miners/clients/wallets update after a hard fork to be capable of recognizing/relaying/accepting these kinds of transactions which broadcast an intention first and a confirmation later.

Dabs
brings up the point of what happens when both a user and hacker control coins and can cancel each others transactions


That's what the failsafe address is for.  We need a script that will say [require all these delays OR allow them to be sent to X address immediately and make sure the owner can provide the ECDSA with the private key] The failsafe address is another that is under the control of the owner and should be elsewhere so that the thief has to hack THAT failsafe address as well to get at the coins.  A whole chain of such addresses could be set up.  The thief would have to hack or know the private key for not just for "m of n," but for each and every one in reverse order so that they can attempt to irreversibly spend the coins without notifying you.  That's the apparent magnitude of this idea.  As of now when your bitcoins are stolen, the first time you learn about it is when it's too late.  This changes it so that you're notified if your coins are stolen and you have the opportunity to act.


Absolutely not. Indeed it sounds like a terrible idea, I don't think transactions should be reversible.  I'm trying to create a situation where everyone's node basically understands that my transaction can't be sent until a specified amount of time has passed since its origin.  Properly implemented, these scripts would not allow double spending because each new request replaces the last.  It would not allow chargebacks because once the pending transaction is finalized it cannot be re-spent or refunded.  The blockchain would record the coins as having a new owner.

There is another matter to address, in that no one should be able to send Bitcoins with these kind of constraints to an unwitting victim.  Transactions that attempt to create coins with these encumbrances should be rejected by default for most every user.  They should only be accepted willingly, most likely under a circumstance when a person is turning their own coins into "delayed withdrawal coins" for themselves.

So just a quick recap: I'm imagining a scenario where sometimes we can send coins which require extra output scripts to satisfy.  These kinds of encumbrances are similar to but different than existing ones used in contracts.  Why would they be useful?  Because in the case that your private key is compromised, what would normally become a catastrophic loss becomes a case where the thief cannot spend your coins without notifying you, the coins take time to leave your wallet, and you (and the thief) are able to immediately transfer the coins to another wallet under your control.  This may also be a voluntary encumbrance that users enact to protect themselves from sending a transaction with human errors like: the wrong amount, the wrong miner fee, the wrong destination.  

The irreversible nature of of bitcoin transactions is an absolutely huge advantage over other currencies, but we should also have the option to sometimes say "not just yet"

I was not defending the idea, just pointing out that the blockchain is not just data, it's data and a majority of clients who enforce a set of rules.

A rule to allow chargebacks for about 144 blocks is technically possible, I'm not saying it's a good idea or it can not be exploited by evil attackers, just that the bitcoin network has the capability to enforce those kind of rules if it must.

Your suggestions require total protocol change, not just bitcoin-qt. (if you think bitcoin-qt = bitcoin network, that's completely wrong), and that will provide only very limited improvement in security.

Without a protocol change, your grandma can still use bitcoin at a safety level comparable to cash and credit card. The solution is temper-proof hardware wallet. I think we will have one very soon.

So you are creating a situation where transactions are reversible for 144 blocks?  So I can pay you for merchandise, and almost a day later I can send those bitcoins back to myself even though I don't know your private key?  And this sounds like a good idea to you?

If someone wanted to create havoc in bitcoin, they could create software that would watch the blockchain for transactions from addresses that start with d144, and 20 blocks later they could just randomly reverse some of them?  They could essentially keep your bitcoins locked in your d144 address forever, because every time you try to spend them, they's just be reversed back?

And if the transaction has 2 inputs, and only one of the inputs is from the d144 address?  Then what happens to the bitcoins?

Let's pretend the bitcoin protocol gets modified the way OP wants it.

1. coastermonger has 100 BTC in his "slow" wallet.
2. hacker compromises computer/wallet and gets private key.
3. hacker sends 100 BTC to another wallet.
4. coins are in "waiting" period for 72 hours.
5. coastermonger is alerted, cancels the transaction.
6. hacker notices that the transaction has been cancelled.
7. hacker sends 100 BTC to another wallet again, with a different transaction.
8. coins are in "waiting" period for 72 hours.
9. coastermonger is alerted, cancels the transaction.
10. hacker notices that the transaction has been cancelled.
11. hacker sends 100 BTC to another wallet again, with a different transaction.
12. coins are in "waiting" period for 72 hours.
13. coastermonger is alerted, cancels the transaction.
14. hacker notices that the transaction has been cancelled.
15. hacker sends 100 BTC to another wallet again, with a different transaction.
16. coins are in "waiting" period for 72 hours.
17. coastermonger is on a vacation, 72 hours pass, all his coins are stolen.

Or

1. coastermonger is alerted, cancels the transaction.
2. coastermonger sends his 100 BTC to another wallet.
3. coins are in "waiting" period for 72 hours.
4. hacker is alerted, cancels the transaction.
5. hacker sends 100 BTC to another wallet.

Wow, nobody's mentioned this yet? https://en.bitcoin.it/wiki/Contracts

I think it solves the problem that OP wants to solve, but is much better designed and solves a lot of other problems too.

If the majority of the clients knew and enforced this rule a block which included a transaction to spend those coins before 144 confirmations would be considered an invalid block and would be rejected. Just like trying to spend coins without the correct private key or doing a double spend, it breaks a rule so it's an invalid mined block.

The only transaction allowed before those 144 confirmations would be a transaction where the amount where identical and the source and destination addresses where reversed (source -> destination and destination -> source). That would "unspend" the coins.

No.  They are not forced to send the coins "from your address".  The are forced to spend the unspent transaction outputs in the blockchain that have a script that requires an ECDSA signature from the private key that is mathematically associated with your address.

I think the problem you are running into here is you are trying to make random guesses at ways to change what bitcoin does without any understanding yet of what it is actually doing, why it is doing it, and what decades old problems it solves by doing it the way it does things.  It might help you come up with good ideas if you first take some time to learn about what is happening in the first place and why.


An address is just a short-hand for a script.  We humans use addresses as a way of communicating a concept that is represented in the blockchain by way of output scripts.  The output scripts determine what the requirements are for spending the output.  As such when we say "send the bitcoins to address 1MyBitcoinAddress", that is "human-speak" shorthand for a particular type of output script.  What you are actually saying is: "Create an output script that requires the future spender of the output to supply both a public key that hashes to address 1MyBitcoinAddress and an ECDSA signature proving that they have access to the private key associated with that public key".

If someone wanted to, they could instead "send bitcoins to" an output that requires that a user supply a string of characters that hashes to a particular value.  This output wouldn't have an "address" at all.  The only person who could spend the output would be the person who knew what string would hash to the value indicated.


The blockchain is just data.  If doesn't recognize anything, it doesn't know anything. It isn't a program.  It is just a list of transactions.  I assume that you mean that you'll convince every user to run this new special wallet/client protocol so that they will refuse to recognize the new output as spendable until it has 144 confirmations if one or more of the inputs to the transaction were previously outputs sent to an address that started with d144?  They would all refuse to relay transactions that attempt to spend the new output at the new address much like they refuse to relay transactions that spend "coinbase" outputs until they are sufficiently aged.  That doesn't seem like it would work, by the time it has just a few confirmations, it is already embedded in the blockchain.  Since blocks committed to the blockchain can't be modified, how would you "unspend" the transaction?  It seems like you'd be increasing the size of the UTXO list (since you'd need to know not only the unspent transaction outputs, but also all the outputs used as inputs to any transaction that currently has a UTXO)?


How is your wallet going to rewrite the blockchain without re-mining all the blocks since the transaction got its first confirmation?


No.  As already stated, the "blockchain" isn't programmed at all.  It is just data, a list of transactions and attributes and requirements.  It doesn't "recognize" or "do" anything.  So I'm sticking with the assumption that you are saying that all the wallets/clients/miners should update their software to refuse to recognize such transactions as re-spendable until they have 144 confirmations.  I still can't figure out how such a concept would help, but for the sake of discussion I'll go along with such a concept temporarily.


And at the moment, not only hasn't this idea been proven, but it doesn't even seem to consider any of what bitcoins does, nor the issues it solves.


Spouting random ideas with no understanding of the technology behind bitcoin is far more likely to result in a knowledgeable person spending a lot of time trying to help you understand why the idea doesn't make sense than to result in anything anyone can build off of.  The only good thing that is likely to come of it is that you at least might gain a better understanding of bitcoins inner workings.  However, there are much more productive and easier ways of accomplishing that goal than by asking others to chase down ideas that pop into your head.


No need to change the protocol.  These output scrips can already be used to change the spending behavior of the coins.  This is why things such as multi-sig work/exist.


Yes.  This is the design of bitcoin.  You ask someone to provide you with a way to have exclusive control over some value that they currently have exclusive control over.  They create an output script that you recognize as providing you exclusive control over that value.  Once you confirm that their output script gives you exclusive control, you consider the transaction complete.  If the transaction does not give you exclusive control over the value, you tell the sender that you haven't received it.  The current output script that we humans call a "bitcoin address" is simply a script that we all agree provides exclusive control over the value.  You feel comfortable telling someone to "send to an address" because you trust that that phrase means the exact same type of script to everyone, and everyone recognizes such a script as providing exclusive control over the coins by nature of the way ECDSA signatures work.

If you want to create a new type of output script, you'll want to be very certain that:

• Everybody (or everybody's wallet/client) knows exactly how such a script should be created
• Such a script reliably gives the "receiver" control to "spend" the value
• Such a script reliably prevents anybody else from having control to "spend" the value

Then you convince everyone to upgrade their wallet/client/miners to new software that can recognize this new output script, and that can validate it well enough to be certain that the sender can't create an altered script that defrauds the receiver.

To DannyHamilton: Okay, so private keys must remain as they are since they are only dealt with by wallets.  But here's an idea: aren't attackers also forced to send the coins from our address?  Can the blockchain protocol be changed so that it will recognize some addresses as special case?  If so then any kind of feature imaginable could be put into the protocol to deal with certain coins a certain way.

Here's what it might look like:

• I instruct my wallet to make a "vanity" address for me that will start with the prefix "1d144"
• This is not difficult, there are a plethora of such addresses and it may take a few seconds to minutes to generate it depending on processor power. So I receive some coins at that address.
• When the coins go to be spent, the blockchain has been changed to recognize that the d144 prefix means to delay the sending of those coins for 144 confirmations.  I could be importing a private key or initiating a send transaction with a wallet.  Doesn't matter, the blockchain still knows that the coins are coming from a "d144" address.
• Meanwhile later a thief obtains my private key by some means.  He goes to import the private key (and my coins) to his wallet.  
  
• Yet the blockchain can still recognize that they are coming from this delayed address that I set up.  This address can be imbued with all kinds of properties that are to my advantage and not the thief's.  Say the thief does indeed initiate a withdraw transaction, it will still not actually send the coins out of my wallet until 144 blocks later.  Say we added a failsafe that in the meantime can immediately return the bitcoins to another address I control.  It makes the job of hacking one wallet the job of hacking multiples.
• So even if my private key is stolen and a thief is attempting to spend my coins I am able to cancel this unauthorized transaction through my wallet and since the coins are still mine.  Depending on the rules I set up with this address, other options may be available to me.
  

I want to make sure the underlying part is clear first: the blockchain should be able to be programmed to recognize certain addresses as different, and then be able to apply special rules to those addresses no?  


To John Smith: I appreciate the insight, but unfortunately I have very little experience with programming.  My only hope is to try to stir up ideas and hopefully someone with much more skill than me will be able to build off of them.

 

So just out of curiosity, could these output scripts themselves be made to change the spending behavior of the coins if the bitcoin protocol was changed?  My only concern is that this is a power given to the sender, not the receiver.  Meaning someone could send bitcoin but try to defraud the person receiving it.  Perhaps allowing modified addresses is more useful because the rules attached to it only concern the owner of that address.

confirmed for 10 second attention span



Also, you have no idea what ad hominem means. All you're doing is randomly spewing out buzzwords. Let's recall:
I raised questions about each one of your suggestions. Instead of providing clear implementation details, you called me out for attacking you.

You're the one proposing a change/feature. Therefore, you should be able to provide implementation details to overcome the problems that others raise. I'll reiterate again: half-baked ideas are worthless.

Well with account ledger we can define different account types. It's possible to define account with two keys. One master key which can set account limits/unlimited spending and other with spending limit attached (eg. max 1 BTC per day). You use second key for day to day transactions and if attacker gets it he can only spend max 1 BTC per day and you have time to react.

This is a futile effort.  You can't force the attacker to use the wallet you want him to use.  He'll just create his own wallet software that ignores the restrictions you are trying to put on the private key.  Since no other wallets/clients can see the private key, they won't know about the restriction, they'll have to assume that the wallet that sent the transaction followed the proper rules enforcing the "private key restrictions".  If you want the network to enforce something, then you have to use criteria that the entire network can see.  The only thing that the entire network can see that the attacker doesn't have control over are the output scripts that were placed on the transaction outputs when the transation sending the bitcoins to the receiver was added to the blockchain.

Not a programmer, nor a security specialist but isn't it possible to build in the client something that allows you to besides encrypting the wallet with a password you can also encrypt it with something like a yubikey, so that you actually need something physical to decrypt it? So if a computer is infected they still can't send any coins because you also need the usb device.

OP has a point, I have the knowledge to keep my coins secure. But no way my mother could do this, sticking something like a usb key in the computer is even for her a nobrainer.

The way to do it would be to first experiment with it on an alt chain. Once it turns out to be workable, and the alleged advantages really hold up, it could be implemented in Bitcoin. In principle it's possible to change a lot of the internal workings using a hardfork (see also https://en.bitcoin.it/wiki/Hardfork_Wishlist) but it has to be proven first.

To DannyHamilton: I appreciate your insight and for bringing up the topic of output scripts.  You seem like a really knowledgeable guy.  I am sorry that my terminology might not be up to par.  So the blockchain itself does not see or store private keys, got it.  But the wallet does correct?  What I am trying to do is introduce the idea that sometimes the private keys themselves could be generated to have some specific function like an output script.  It would have to be a universal quality that any wallet would recognize.  What would technically need to happen to make this change?  Be as grandiose as you like, it's just brainstorming.

To aaaxn: I'm curious about your idea of replacing input/output script with account ledger.  One of the main problems I'm trying to solve is that sharing a private key always allows instantaneous theft/transfer of a coins.  I want to give users the options to sometimes not make this the case, to be able to store their coins in addresses that have private keys which modify the behavior of how their coins can be spent.    (the protocol itself would have to be modified to accomodate this behavior) Under your example, could I still immediately steal all of your coins if I discovered the private key of your address?  Why or why not?  I'll also make sure to check out the other idea thread.

And to John Smith: I realize that this might be more the domain of alt coins if the changes to bitcoin are too complicated or too far gone to implement.  I just kind of hate the idea of introducing another alt coin.  I'm ultimately curious if these are changes that can be introduced because they would keep the current functionality of the bitcoin protocol intact, but also change it for those who want the option to.