Bitcoin Forum
December 04, 2016, 06:28:49 PM *
News: To be able to use the next phase of the beta forum software, please ensure that your email address is correct/functional.
 
   Home   Help Search Donate Login Register  
Pages: [1] 2 »  All
  Print  
Author Topic: Proposal : standard transactions for security/backup/escrow  (Read 4957 times)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 23, 2011, 09:17:36 PM
 #1

Sunday at the bitcoin conference I led a little brainstorming session on extending the set of 'standard' transaction types, and I've been picking people's brains via email and IRC chat (and pull request comments) to work through the details.

My motivation for wanting to do this NOW is because it will allow features like:

+ Multi-device confirmation of spends, so if your computer is infected by a trojan it cannot spend all of your coins.

+ Master-key emergency backup, so if you lose your wallet (and all of its backups) you can get the master key from your safe deposit box and recover all of your coins

It will also enable third-party escrow and some other nifty features that aren't as important to me.  The first step in doing all of these things is to work out the lowest-level transaction format and to allow those transactions to be relayed and included in blocks.  That is ALL I am proposing right now (actually implementing something like multi-device spend confirmation will require a little protocol for the devices to communicate, a new kind of bitcoin address that people will send into, etc etc etc).

Working out a common way of doing (for example) 1-of-2-keys-required transactions will make it much easier for sites like blockexplorer to display them intelligently, and will generally make life happier for anybody writing tools that look at the blockchain.

I'd rather not have this turn into a "lets get rid of the IsStandard() check" or "lets re-enable a bunch of currently disabled opcodes", so if you want to talk about that start a new thread.

Current draft proposal is here:
  https://gist.github.com/39158239e36f6af69d6f

How often do you get the chance to work on a potentially world-changing project?
1480876129
Hero Member
*
Offline Offline

Posts: 1480876129

View Profile Personal Message (Offline)

Ignore
1480876129
Reply with quote  #2

1480876129
Report to moderator
1480876129
Hero Member
*
Offline Offline

Posts: 1480876129

View Profile Personal Message (Offline)

Ignore
1480876129
Reply with quote  #2

1480876129
Report to moderator
1480876129
Hero Member
*
Offline Offline

Posts: 1480876129

View Profile Personal Message (Offline)

Ignore
1480876129
Reply with quote  #2

1480876129
Report to moderator
Advertised sites are not endorsed by the Bitcoin Forum. They may be unsafe, untrustworthy, or illegal in your jurisdiction. Advertise here.
1480876129
Hero Member
*
Offline Offline

Posts: 1480876129

View Profile Personal Message (Offline)

Ignore
1480876129
Reply with quote  #2

1480876129
Report to moderator
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 23, 2011, 10:42:08 PM
 #2

Excuse me for mangling the quote system somewhat...
(a AND b) OR C
--------------
This is a useful form for secure, backed-up wallets.
(a) would be private keys kept on a possibly insecure device. (b) would be
an account key kept at some type of 'wallet protection service'. And (c)
would be an emergency key kept completely offline, which could be used in
case the (a) or (b) keys are lost.
Code:
ScriptSig: siga pubkeya sigb pubkeyb 0
  OR
ScriptSig: sigc pubkeyc 1

ScriptPubKey:
  IF
   DUP HASH160 {hashc} EQUALVERIFY CHECKSIG
  ELSE
   DUP HASH160 {hashb} EQUALVERIFY CHECKSIGVERIFY
   DUP HASH160 {hasha} EQUALVERIFY CHECKSIG
  ENDIF
The unfortunate thing about this construction is that the emergency key c, kept offline and hopefully never used is likely to be constant over a very long period of time. This results in a dramatic loss of transaction anonymity.

It would be nice to have a ScriptPubKey for c from which it is computationally infeasible to determine whether another similar transaction has the same key c.

Perhaps the funder knows the public key for c, encrypts a random nonce with the key and stores it in the ScriptPubKey with an OP_DROP. The rest of the ScriptPubKey for c requires that the redeemer provide a signature and public key for the concatenation of the random nonce and the redeeming transaction. Could something like this be implemented in the scripting language?

ByteCoin
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
August 23, 2011, 11:50:24 PM
 #3

I don't see why it's necessary to support addresses for backup and secure-device transactions. Bitcoin can remember the public keys before they are exported to the backup or device.

With an additional device:
Code:
2 KeyA KeyB 2 OP_CHECKMULTISIG
KeyA is a local key known by Bitcoin. KeyB is probably remembered from previous use; if not, it can be transferred in a QR code without much trouble (~90 base64 characters is fine).

With a backup:
Code:
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG
KeyBackup is static, remembered by Bitcoin. KeyNormal is a local key.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 24, 2011, 12:08:39 AM
 #4

I don't see why it's necessary to support addresses for backup and secure-device transactions. Bitcoin can remember the public keys before they are exported to the backup or device.

With an additional device:
Code:
2 KeyA KeyB 2 OP_CHECKMULTISIG
KeyA is a local key known by Bitcoin. KeyB is probably remembered from previous use; if not, it can be transferred in a QR code without much trouble (~90 base64 characters is fine).

The multi-device use-case I'm imagining:

I sign up with Acme Bitcoin Security Solutions, Inc.  They give me a WalletProtection public key (or bitcoin address, doesn't matter) and a unique-for-me URL.  I put the address/pubkey into my bitcoin client as "Second factor off-device Send Authentication." Or something.
(ABBS also sends me the private key in the mail and tells me to keep it safe in case they go out of business)

Now I want all coins sent to me to require signatures from keys in my wallet AND the ABBS key to spend.

What bitcoin address do I give to people so that all coins going into my wallet have that property?

If it is raw CHECKMULTISIG, then I need to give out addresses containing 2 full public keys.  Which would be 186 characters in base58 and look something like this:
LeFKX5Uhue9B4bVNqFouRdH9xyJ4uVksV16Gc3v5Kov6SEtyUmKmF3j582VHcmhKGEfBXvrft6SHAq4 SQPw5kbGryZj4aGqZKGFSPsotRJvrmQXCT8qZ2LZd3KyxFLDt1rsBx2uisukHPvBnyCpbyVdgNhyQYn z3Cf4oakK9Rm6oxFHwjHxHnnbdW3

Using 20-byte hashes and the more complicated 2-of-2 transaction i'm proposing, the address is a more reasonable 61 chars:
2SEe6qhJ11baZfpk9qXt3gfz3qAgFj4BMc2FXh9ojoBoLU4GAhft1hJAb5TAK


How often do you get the chance to work on a potentially world-changing project?
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 24, 2011, 12:15:34 AM
 #5

The unfortunate thing about this construction is that the emergency key c, kept offline and hopefully never used is likely to be constant over a very long period of time. This results in a dramatic loss of transaction anonymity.

Clients could make c the base for a deterministic key; derive a series of keys from c, and use them in subsequent transactions.  (given full public key for c, you can derive a series of public keys without having the private key)

Same could be done for the 'wallet protection service' key b -- every time you use b, contact the protection service and ask for a b' derived deterministically from b.  Then b'', b''', etc...

How often do you get the chance to work on a potentially world-changing project?
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
August 24, 2011, 12:29:03 AM
 #6

I don't think it's reasonable to put the burden on the sender (in the general case, at least). The large addresses will be annoying to work with, and fees will be higher due to larger data sizes. There may even be programs made to transform "expensive" addresses into "cheap" addresses by changing the version and removing all but one address.

The recipient should receive on a normal address and then resend to himself with the odd transactions. Then the recipient pays the extra fees, and no one will have to deal with huge addresses. There will be a short period of time when the funds are unprotected, but I don't think this will usually be a problem, and it's worth the benefits.

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
August 24, 2011, 02:42:24 AM
 #7

Gavin,

My suggestion to modify OP_CHECKSIG was moved to https://bitcointalk.org/index.php?topic=38954.msg476689#msg476689 and is incorporated herein by reference, along with your reply suggesting the idea is incompatible with the desired release schedule and that the expectation of a blockchain fork (presumably by the proportion of solo miners who simply won't ever upgrade) is an unacceptable consequence.  I feel this reply is more relevant, however, to the ongoing discussion.  But feel free to move this reply as well if you feel it's misplaced.

If the idea (or any similar idea with similar consequences) has merit and solves the problem, why not just put it in now, but just not provide any UI for anybody to use it for six months?  Right now, security is the achilles heel of Bitcoin - the user expectation that the client evolve to incorporate useful practical security is vastly greater than the expectation that one should be able to solo mine with a client 4 versions ago.

Creating a new address format - especially a longer one - is going to add to the mental workload of every future user of Bitcoin, and is going to force everyone to upgrade all the same anyway.  Every joe blow user will now have to ask why every other user is giving out two bitcoin addresses, one to stay compatible and one to stay safe.  It will also break the withdrawal routine of every website that dispenses Bitcoins (or again force people to maintain two flavors of addresses).  At some point, a client replacement is going to be inevitably necessary even without changes, because the amount of time it takes to initially populate and validate the blockchain is already growing exponentially, well past inconvenient, and on to the point of becoming monumental and infeasible sort of like CPU mining.

Changing OP_CHECKSIG may not be the particular answer to the problem, but I'd like to submit to you that while this software is labeled as being in beta, the possibility that everyone might have to upgrade their client shouldn't be a dealbreaker, and pales in terms of "social cost" when compared to introducing a new address format. My understanding is the current client allows you to trigger a message informing users an upgrade is needed?  There will never be a better time and we're begging to upgrade.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
August 24, 2011, 04:11:01 AM
 #8

Quote
I don't think it's reasonable to put the burden on the sender (in the general case, at least). The large addresses will be annoying to work with, and fees will be higher due to larger data sizes. There may even be programs made to transform "expensive" addresses into "cheap" addresses by changing the version and removing all but one address.

The recipient should receive on a normal address and then resend to himself with the odd transactions. Then the recipient pays the extra fees, and no one will have to deal with huge addresses. There will be a short period of time when the funds are unprotected, but I don't think this will usually be a problem, and it's worth the benefits.

I think this is an arbitrary distinction.  Users themselves will need to communicate with their own clients to execute 1-of-2, 2-of-2, etc, transactions.  Providing a standard "code" for these will allow the users to know what they're doing.  If I'm telling my wife to put money in our 1-of-2 or 2-of-2 account, I give her the long code.  If I'm selling stuff on the internet, I use your suggestion (give buyer reg address, move it myself).  The key is to create the language.  People will use it as they feel is appropriate.

For these more complicated transactions, we'll need to come up with terminology and methodology for executing them.  We not only need to create the transactions, but also make an intuitive interface for spending them.   I suggest we make a "proposal" msg that users can import and choose to sign.  Each person can sign and pass the result to the next party.  Once the last party signs it, the client will tell them "This is a valid proposal!"  and be presented with a button for "Broadcast now!" or something like that


Click here for the full-sized image:  http://dl.dropbox.com/u/1139081/BitcoinImg/AdvTxDialogs.png

I left off the "save to file" button so it can be attached to emails instead of inline.  Of course, the Base58 there would be the exact serialization of the proposed Tx, with the single input and the proposed outputs.  Don't pry too deep into the details of the attached images:  they're just notional.  

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
August 24, 2011, 04:35:32 AM
 #9

Just for comparison's sake, here is what the user experience would be if the modified OP_CHECKSIG proposal were accepted.

Jimbob, who is just an average guy using a wallet protection service, would give out a normal-looking well-formed Bitcoin address to Sally and would receive payments just like normal.

Jimbob is using a version of the Bitcoin client that knows that his funds are encumbered by keypairs A, B (never mind C for now), and that it only possesses the private key for A.  It knows that private key B is managed by a 3rd party through a web service.

When he goes to spend his funds, his client signs the transaction with key A, and ships the incomplete transaction off to the web service for verification.  The web service does its due diligence, example, this particular service sends an SMS to JimBob's cell phone, "You are sending 57.00 BTC to 1xyzabcdABCD123... Reply 1 if OK".

JimBob replies 1, and the webservice signs with B and forwards his transaction on to the network.

Safe for JimBob?  You bet.

Easy for JimBob to understand?  You bet.

Will it pass the media scrutiny and calm them down about how bitcoin is rife with hacking and fraud?  You bet!

Now, key C is what Jimbob printed and stuck in his safe when his wallet was generated.  It is his failsafe against his computer crashing or the webservice going out of business.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 24, 2011, 12:17:35 PM
 #10

Just for comparison's sake, here is what the user experience would be if the modified OP_CHECKSIG proposal were accepted.
With reference to Gavin's first post on this thread
I'd rather not have this turn into a  "lets re-enable a bunch of currently disabled opcodes", so if you want to talk about that start a new thread.
I think that casascius' recent post is offtopic for this thread and should be moved to casascius' "Modify OP_CHECKSIG" thread

I will delete this message after the move.

ByteCoin
ByteCoin
Sr. Member
****
expert
Offline Offline

Activity: 416


View Profile
August 24, 2011, 04:38:54 PM
 #11

In the interests of my being critical in an unbiased fashion, I must mention that I think etotheipi and theymos' most recent posts on this thread are also offtopic.

It sounds to me like Gavin had two proposals from his original and second posts: one about widening the parameters of what IsStandard() will accept, and the second about constructing a new form of Bitcoin address.

To quote Gavin again
... to work out the lowest-level transaction format and to allow those transactions to be relayed and included in blocks.  That is ALL I am proposing right now
He specifically mentions that the implementation may require a new address format which is outside the scope of this discussion.

To me, this thread is about the second proposal, because the first one is a slam-dunk uncontroversial proposal that has no negative consequences

In that case, you have nothing, apart from your approval to contribute to this thread.
The thread is about what you term "the first proposal", as what you term "the second proposal" was never proposed.

If you look at the comments on the document Gavin linked to, you can see that there was plenty to talk about and correct regarding his proposal which you deem uncontroversial.

This thread is intended to attract more critical attention to the proposal so that any problems are corrected.

Your suggestions with regards to an a new address format would be welcome but probably more appropriate on another thread.

ByteCoin
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
August 24, 2011, 05:23:34 PM
 #12

I think it does help, in general, to consider how users could/would use these transactions, and then the message formats can be designed to accommodate.  But, upon rereading the original thread, I see that I slightly mis-understood the original intent of Gavin's proposal.  He's looking more for how these transactions will be encoded in the blockchain, not how people will use them.  So yes, my post was a little off-topic.   Feel free to ignore it then.  I'll recycle those mock-ups for a more-appropriate thread.

I see Casascius' point about changes to the OP_CHECKSIG improving the original request, but I don't think it precludes us from needing to have to come up with standard formats that don't use casascius' improvement.  Casascius' suggestion simplifies a lot of things, but does require all parties to be manually notified that they are part of a given transaction.  This may not always be preferable, and I think we have to accommodate more-explicit transaction types that are already possible, anyway (and to be used sooner than we can implement Casascius' suggestion).

In other words, I am siding with both, here:  I'd like to see casascius' change vetted and implemented if it seems secure (although nested scripts might open some very creative security problems, I don't know for sure).  But I think the original proposal Gavin presented still needs to be addressed.  In that regard, I'm not concerned about long strings.  Unless someone has a specific, common use-case that I'm not familiar with, addresses are almost always communicated via copy-and-paste into email/IM, or through QR code scans.  In this case, I don't see how it's really relevant how long it is, probably as long as it doesn't exceed half the length a QR code can handle (which is about 3 KB).

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 24, 2011, 05:34:49 PM
 #13

Phew.  Ok, I feel better; consensus seems to be that enabling some or all of the proposed 'new standard' transactions is a good idea.

All the rest (new address format?  send to old addresses and immediately resend?  etc etc etc) can be argued to death later.

How often do you get the chance to work on a potentially world-changing project?
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
August 24, 2011, 06:04:37 PM
 #14

Phew.  Ok, I feel better; consensus seems to be that enabling some or all of the proposed 'new standard' transactions is a good idea.

Yep, it's a great idea.

I could see a case for limiting it to very specific syntaxes - such as (A AND B) OR C plus a few others with specific identified uses - so that the flowchart for deciding "is this payment mine" doesn't become infinitely complex.  For example, the client who receives this transaction and only has key A needs some way to clearly display to the user these funds are "yours" but are encumbered.

In addition to (A AND B) OR C (wallet protection scenario), I could also see (A AND B) OR (C AND D) being useful.


Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
theymos
Administrator
Legendary
*
expert
Offline Offline

Activity: 2492


View Profile
August 24, 2011, 06:06:40 PM
 #15

Phew.  Ok, I feel better; consensus seems to be that enabling some or all of the proposed 'new standard' transactions is a good idea.

All the rest (new address format?  send to old addresses and immediately resend?  etc etc etc) can be argued to death later.


Please also enable the non-address versions. Like:
2 KeyA KeyB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG
2 KeyA KeyB 2 OP_CHECKMULTISIG OP_DUP OP_NOTIF KeyBackup OP_CHECKSIG OP_ENDIF

1NXYoJ5xU91Jp83XfVMHwwTUyZFK64BoAD
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
August 24, 2011, 11:44:41 PM
 #16

So part of the discussion is about the length of acceptable keys, which would help drive the format for these multi-sig addresses.     Casascius... you mentioned in another thread that you actually type some addresses in by hand.  What is the reason for this?  So far, I have never needed to do it myself, and was wondering if you have special requirements, or if we anticipate a common scenario that people would be copying by hand (i.e. typing).  If so, then perhaps it's not ideal to push the multisig approach with long addresses.  It's okay if it's done occasionally, but if there's a common scenario that most users would run into semi-frequently, we probably should focus on keeping them short.

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
casascius
Mike Caldwell
VIP
Legendary
*
Offline Offline

Activity: 1344


The Casascius 1oz 10BTC Silver Round (w/ Gold B)


View Profile WWW
August 25, 2011, 12:53:52 AM
 #17

So part of the discussion is about the length of acceptable keys, which would help drive the format for these multi-sig addresses.     Casascius... you mentioned in another thread that you actually type some addresses in by hand.  What is the reason for this?  So far, I have never needed to do it myself, and was wondering if you have special requirements, or if we anticipate a common scenario that people would be copying by hand (i.e. typing).  If so, then perhaps it's not ideal to push the multisig approach with long addresses.  It's okay if it's done occasionally, but if there's a common scenario that most users would run into semi-frequently, we probably should focus on keeping them short.

I use paper bitcoin wallets and multiple computers, including one dedicated to transacting in BTC, and a different one for interacting with financial websites (including bitcoin exchanges) which browses no other websites, so I minimize the risk of having my bitcoins lost or stolen and my accounts compromised.  Although that seems somewhat heretical, the more people have their bitcoins stolen without seeing it coming, the more it makes sense.

I have a serious amount invested in bitcoins, am aware that skilled adversaries are after them, and don't want to risk it.  All my bitcoins are offline pretty much all the time.

When I take bitcoins offline, I break them into denominations so if I just need to buy something small, I can import a "twenty" or whatever, and leave the remainder of my stash safe.

Companies claiming they got hacked and lost your coins sounds like fraud so perfect it could be called fashionable.  I never believe them.  If I ever experience the misfortune of a real intrusion, I declare I have been honest about the way I have managed the keys in Casascius Coins.  I maintain no ability to recover or reproduce the keys, not even under limitless duress or total intrusion.  Remember that trusting strangers with your coins without any recourse is, as a matter of principle, not a best practice.  Don't keep coins online. Use paper wallets instead.
Gavin Andresen
Legendary
*
qt
Offline Offline

Activity: 1652


Chief Scientist


View Profile WWW
August 25, 2011, 02:06:01 AM
 #18

Please also enable the non-address versions. Like:
2 KeyA KeyB 2 OP_CHECKMULTISIG
1 KeyNormal KeyBackup 2 OP_CHECKMULTISIG

Those are "Proposal 1" -- enabling all the 'plain-old' OP_CHECKMULTISIG transactions.

groffer reports finding a bug in CHECKMULTISIG (pops too many items off the stack), which makes me wonder if it would be better to avoid it. For small n, using CHECKSIG multiple times is straightforward and doesn't make the transactions much larger.

The (a and b) OR c transaction with public keys instead of addresses isn't in the proposal, but for consistency's sake I agree it should be.

How often do you get the chance to work on a potentially world-changing project?
hashcoin
Full Member
***
Offline Offline

Activity: 122


View Profile
August 25, 2011, 04:28:06 AM
 #19

Note that many of the escrow use cases also need nLockTime to be useful (NOT replaceable TX/sequence numbers, just a TX that won't even be accepted into a memory pool until a given time/block).  I would strongly urge you to enable nLockTime.  Here are two use cases:

http://bitcointalk.org/index.php?topic=25786.0
http://bitcointalk.org/index.php?topic=22581.0

In one of them I mentioned using replaceable TX, not sure why, but they aren't needed.

Multi-signed TX and locktime is all that is needed for instant secure offline transactions with future-settled payment.

The "untrusted exchange" use case just needs one more thing: multiple uses of OP_HASHEQUALVERIFY.  I know you said not to beg for arbitrary additions in this thread, but I figure it's worth a shot since OP_HASHEQUALVERIFY is already used/allowed, but just once in accordance with IsStandard.  Untrusted exchange can be done if you allow 2 more HASHEQUALVERIFY in a TX... I hope you'll agree allowing a script to couple more HASHEQUALVERIFYs is not dangerous.
etotheipi
Legendary
*
expert
Offline Offline

Activity: 1428


Core Armory Developer


View Profile WWW
September 18, 2011, 07:02:26 PM
 #20

Gavin, what is the status of the new standard transactions?  Did anyone actually authoritatvely decide on how the new transactions will look in the blockchain (specifically, the OP_CODE structure of the transactions)?  Any decision on the how they will be serialized (for the purpose of handing out addresses)? 

I recognize that you are probably working on the updated client, but I wanted to know if you reached any conclusions, since this thread seems to have been left dangling a month ago...

Founder and CEO of Armory Technologies, Inc.
Armory Bitcoin Wallet: Bringing cold storage to the average user!
Only use Armory software signed by the Armory Offline Signing Key (0x98832223)

Please donate to the Armory project by clicking here!    (or donate directly via 1QBDLYTDFHHZAABYSKGKPWKLSXZWCCJQBX -- yes, it's a real address!)
Pages: [1] 2 »  All
  Print  
 
Jump to:  

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!