Bitcoin Forum
February 23, 2019, 02:09:36 PM *
News: Latest Bitcoin Core release: 0.17.1 [Torrent]
 
   Home   Help Search Login Register More  
Pages: [1]
  Print  
Author Topic: Making Hot Wallets Impossible to Steal - Now with 5 BTC bounty.  (Read 3243 times)
coastermonger
Sr. Member
****
Offline Offline

Activity: 367
Merit: 250

Find me at Bitrated


View Profile
October 07, 2013, 01:07:55 PM
Last edit: October 07, 2013, 05:16:43 PM by coastermonger
 #1

Cold storage and hardware wallets are fine, I am not here to knock them. I am looking to improve hot wallet security.

It occurred to me the other day that if I had some way of enforcing a "spend delay" on my bitcoins, they could never be stolen from my hot wallet during that delay.
I would need the ability to store bitcoins with the following rules:

  • Specify a delay time: X
  • If the last spend attempt is greater than X time ago, send the transaction.
  • If not, or if no previous attempt, create a new spend attempt.

These simple but powerful rules (if enforced) would mean I could spend my coins as I please anytime, simply suffering a small delay before they actually start getting sent out. If a thief accessed my private key and tried to spend my BTC they too would suffer the same delay. Yet, as long as I was watching (or had some program to watch for me) I'd be able to redirect the transaction back to a destination of my choice!  In order to avoid a game of endlessly redirecting transactions between myself and a thief, the wallet could also include instructions for a fail-safe address.  

But how on earth could these rules be enforced to the most absolute degree possible? It's not good enough to simply design a wallet with these constraints, because a thief could design another wallet to simply bypass these rules.  How could I make sure that everyone absolutely had to follow them?

Imagine a special wallet program that contributes to and communicates with another kind of blockchain. It does not replace the bitcoin blockchain, but it moves in parallel to it.  It would be a peer to peer decentralized network that stores transaction attempts, private keys, and the specific delays made by their owners. It could ultimately forward to the bitcoin network to create transactions, but only after the specified waiting conditions are satisfied.

Creating an address in a Vault Wallet creates a 2-of-2 multisignature address that requires both private keys to spend. Within minutes it is confirmed and your rules are eternally bound to this address.  
You hold one private key in your wallet, encrypted by a password (similar to the bitcoin-qt).  The other private key is held by the vault chain itself, encrypted until its conditions are satisfied. These are the rules you created at the beginning, and once logged in the vault chain they are buried by consensus blocks and forever granted primacy so no one can supersede or overwrite your instructions.  

When you go to spend your coins, your private key is only the first half of the spend equation. The coins go into limbo in the vault chain as a spend attempt is registered. They must wait there until your X delay is over.  If the destination of the coins changes with another spend attempt then the waiting time reset and overwrite the first attempt.  Once the timer is up and enough confirmation blocks have been created, the Vault chain decrypts the other necessary private key and immediately creates a transaction to spend in the bitcoin blockchain.  A receiving address would see zero activity until this process is completed, so this is not a way to chargeback or revoke payment, only delay the spending of the coins on your end for security purposes.  Once actually sent in the bitcoin blockchain, the transaction is irreversible.  

Since the keys are split up and one of them isn't even on my computer, there is no point in trying to hack my password.
Since the vault-chain is trust-less and decentralized and requires consensus in order to spend the transaction, there is no point in trying to run a rogue client with its own rules that attempts to ignore the delays.  

Try to spend my coins and I'd know about it right away, and I can stop you. I'd fail-safe them right into a paper wallet. Think about that for a second. Imagine being alerted that your coins are being stolen before they're gone for good, and imagine being able to do something about it!

And how is it all supported? With tiny extra transaction fees for those that want the security. There are blocks to be found, transaction attempts to be logged, bitcoins to be earned, and miners to be paid. ASIC miners can contribute to both chains simultaneously, and their power would continue to find blocks in each chain and secure both of these networks.

What I'm imagining requires quite a bit of creative thinking to implement properly, but it results in rules that are very hard to circumvent and a hot wallet with very hard to steal bitcoins. I want to give people the power to put a delayed-fuse on their coins. All of these changes would be user-initiated, optional, and would require zero changes to the bitcoin protocol itself.  A Vault wallet is simply software, no extra hardware or paper required. Please poke holes in this idea, I'd love to heard your feedback.  (I am also aware of Oracles, but they are not quite trust-less enough in my opinion)

I am willing to add a 5BTC bounty to this idea if it can be successfully implemented and a Core-Dev confirms it performs as described.  

Bitrated user: Rees.
Your Bitcoin transactions
The Ultimate Bitcoin mixer
made truly anonymous.
with an advanced technology.
Mix coins
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1550930976
Hero Member
*
Offline Offline

Posts: 1550930976

View Profile Personal Message (Offline)

Ignore
1550930976
Reply with quote  #2

1550930976
Report to moderator
1550930976
Hero Member
*
Offline Offline

Posts: 1550930976

View Profile Personal Message (Offline)

Ignore
1550930976
Reply with quote  #2

1550930976
Report to moderator
jl2012
Legendary
*
Offline Offline

Activity: 1792
Merit: 1010


View Profile
October 07, 2013, 02:57:39 PM
 #2

5 BTC is just a joke. You won't get such thing implemented in bitcoin even with 50,000 BTC bounty.

And there are free solutions to theft: cold storage.

Donation address: 374iXxS4BuqFHsEwwxUuH3nvJ69Y7Hqur3 (Bitcoin ONLY)
LRDGENPLYrcTRssGoZrsCT1hngaH3BVkM4 (LTC)
PGP: D3CC 1772 8600 5BB8 FF67 3294 C524 2A1A B393 6517
cbhelp
Newbie
*
Offline Offline

Activity: 56
Merit: 0


View Profile
October 07, 2013, 03:07:29 PM
 #3

What about if i client is created that allows a user to only send bitcoins to one address, ever.  Then, you send the the second address to where it needs to go.  This way, an attacker would need access to both private keys, to steal the funds, since they wouldnt be able to take the funds from wallet A, even if accessed.
coastermonger
Sr. Member
****
Offline Offline

Activity: 367
Merit: 250

Find me at Bitrated


View Profile
October 07, 2013, 03:51:49 PM
 #4

5 BTC is just a joke. You won't get such thing implemented in bitcoin even with 50,000 BTC bounty.

And there are free solutions to theft: cold storage.


This kind of criticism is narrow minded.  Cold storage is fine but don't assume it's applicable or preferable to every situation. 

Properly implemented, this would require exactly zero changes to the bitcoin protocol.  It would be a 3rd party network than anyone could run and mine from. 
It would inform users when their systems are compromised and give them a chance to counter an attack, no paper or extra hardware required. 

Bitrated user: Rees.
coastermonger
Sr. Member
****
Offline Offline

Activity: 367
Merit: 250

Find me at Bitrated


View Profile
October 07, 2013, 03:54:57 PM
 #5

What about if i client is created that allows a user to only send bitcoins to one address, ever.  Then, you send the the second address to where it needs to go.  This way, an attacker would need access to both private keys, to steal the funds, since they wouldn't be able to take the funds from wallet A, even if accessed.

This is essential the function of an address that requires multiple private keys to spend.  A Vault Chain would attempt to do exactly this, but instead of just keeping the other key(s) on a computer, it would entrusting the other private key to a distributed network.  This network would enforce conditions that you applied when making that address. (agreed upon by consensus and buried with each successive block), they must be followed and cannot be bypassed by any practical means.  Thus, your "spend delay" or "forwarding" rules that you specify in the beginning would become concrete and unchangeable, even by someone who attempted to run a rogue program that told the network to act differently.  

Bitrated user: Rees.
Dabs
Staff
Legendary
*
Offline Offline

Activity: 2254
Merit: 1118



View Profile
October 08, 2013, 08:41:38 AM
 #6

I don't see how this would work, as it seems similar to your earlier proposal. But good luck anyway.

Escrow Service (Services) - GPG ID: 32AD7565, OTC ID: Dabs
All messages concerning escrow or with bitcoin addresses are GPG signed. Please verify.
CompTIA A+, Microsoft Certified Professional, MCSA: Windows 10; Windows Server 2012, MCSE: Cloud Platform and Infrastructure; Productivity; Messaging
goatpig
Legendary
*
Offline Offline

Activity: 2128
Merit: 1111

Armory Developer


View Profile
October 11, 2013, 12:19:01 PM
 #7

Some sort of transaction script could get it to work I guess:

To clear coins on current address one needs to
1) either wait x blocks to send to any address
2) or send them instantly to a predefined "safe" address under your control

Since you have to clear the script requirements of an output to redeem its balance, you can thus enforce transaction emitters to add this "spend in X blocks" rule. Other txns would be turned down by the network, unless they point directly to the safe address listed in the output's script.

Once the new txn is hashed into a block, the signed coins will be available until hashed block number +X is achieved, which gives you time to emit a direct txn to the safe address if needs be. Kind of a delayed double spend I guess. Should be implementable in the main chain at limited cost, just a matter of activating some script opcodes I think.

Sukrim
Legendary
*
Offline Offline

Activity: 2436
Merit: 1002


View Profile
October 11, 2013, 12:28:35 PM
 #8

Might work with the "oracle" style transactions, but then you (or your customers) trust the oracle again...

An oracle that just broadcasts the current UNIX timestamp should be fairly easy to deploy and validate I guess.

https://www.coinlend.org <-- automated lending at various exchanges. No fees(!).
Mail me at Bitmessage: BM-BbiHiVv5qh858ULsyRDtpRrG9WjXN3xf
sdp
Sr. Member
****
Offline Offline

Activity: 433
Merit: 251



View Profile WWW
October 14, 2013, 12:28:28 PM
 #9

I can think of two ideas for this.  One is you need to start an ALT coin.   The other is a trusted party with a multi-sig address to ensure your Bitcoin address follows the rules you have laid down.

The ALT coins are experiments for features of crypto-currencies.  I have read up on the bitcoin protocol and there is no way to load the time into it.  The scripting language has no way of querying the time on the server.  Hypothetically, if you could query the time on a server you could make an address that requires it to be some timestamp in the future and have a program run on a server or two to generate new such addresses each time the timestamp constant would push the time into the future.  Being an alt coin this could be made a lot easier maybe associating a 'speed' with the 'coins' that the owner can set.

The other is with multisig addresses.  Being 'unstandard', it wont be relayed by the network according to the Wiki article. (https://en.bitcoin.it/wiki/Script).

sdp

██████████████████████████████████████████████
██████████████████████████████████████████████
█████                                    █████
█████                                    █████
█████                                    █████
█████           ▄█▄        ▄█▄           █████
█████          ████████████████          █████
█████           ▀████████████▀           █████
█████           ████▀    ▀████           █████
█████           ████▄    ▄████           █████
█████           ▄████████████▄           █████
█████          ████████████████          █████
█████           ▀█▀        ▀█▀           █████
█████                                    █████
█████                                    █████
█████                                    █████
██████████████████████████████████████████████
██████████████████████████████████████████████
▄██████████████████████████▄
██                        ██
██                        ██
██                        ██
██             ▄█▀███████████
██              ▀▀▀▀▀▀▀▀▀▀██▀
██                        ██
██                        ██
██▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄██
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

▄██████████████████████████▄
██                        ██
██                        ██
██                        ██
██                        ██
████████████████████████████
██                        ██
██                        ██
██▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄██
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
▄██████████████████████████▄
██                 ▄███▀  ██
██             ▄▄██▀▀  ▄█ ██
██     ▄    ▄███▀▀  ▄███  ██
██    ██▄▄██▀▀   ▄█████   ██
██   ████▀▀  ▄▄██▀▀ ▀█    ██
██  █▀▀   ▄▄██▀           ██
██    ▄▄███▀              ██
██▄▄▄████▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄██
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

▄██████████████████████████▄
██                        ██
██  ████▄  ▄▄▄▄▄▄▄▄▄▄▄▄   ██
██     ▀█▄ ▀▀▀▀▀▀▀▀▀██    ██
██      ██         ██     ██
██       ███████████      ██
██        ▄▄     ▄▄       ██
██       ▀██▀   ▀██▀      ██
██▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄██
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀
▄██████████████████████████▄
██                       ▄██
██                     █████
██         ▄         ███▀ ██
██       ▄███     ▄███▀   ██
██   ▄▄███▀▀███▄████▀     ██
██▄▄███▀     ▀███▀        ██
████▀                     ██
██▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄▄██
 ▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀▀

▄███████████▄  ██████████████
█           █  █            █
█           █  █            █
█           █  █            █
█           █  █            █
█           █  █            █
█           █  █            █
█           █  █            █
██████▀██████  ██████▀███████
 ▀▀▀▀▀▀▀▀▀▀▀   ▀▀▀▀▀▀▀▀▀▀▀▀▀▀
Pages: [1]
  Print  
 
Jump to:  

Bitcointalk.org is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!