Length is fine, I just had some confusion about what *exactly* was considered Standard by the reference client. I searched for a while to find any topics discussing the exact bytes in the scriptPubKey and couldn't find anything. So hopefully this helps anyone going through the same process.

99% of the time, OP_RETURN scriptPubKey will be (in hex):

  6a

If you need 76 - 78 bytes of data... add an OP_PUSHDATA1 (0x4c)

  6a 4c

While implementing the sample code for reusable addresses, I had to implement this line:

    stealthTx.Vout.Add(TxOut.OpReturn(P));

Generally the OP_RETURN support is talked about as "OP_RETURN " but sometimes it's also described as OP_RETURN followed by anything.

So my question was whether or not you have to pack the data inside an OP_PUSHDATA, e.g.

    public static TxOut OpReturn(byte[] data)
    {
        byte[] scriptRaw = new byte[data.Length + 1];
        scriptRaw[0] = (byte)Script.OpCode.OP_RETURN;
        scriptRaw[1] = (byte)Script.OpCode.OP_PUSHDATA1;
        scriptRaw[2] = (byte)data.Length;
        Array.Copy(data, 0, scriptRaw, 3, data.Length);

        return new TxOut()
        {
            Value = 0L,
            ScriptPubKey = Script.Parse(scriptRaw)
        };
    }

Note, I could save a byte there if data was between 1 and 75 bytes... and the function as written assumes data is less than 255 bytes, but I'm trying to keep the example simple.

In practice, if I did *not* pack the data, then I get something like this from 'decoderawtransaction':

{
   "value" : 0.00000000,
   "n" : 1,
   "scriptPubKey" : {
   "asm" : "OP_RETURN -30205 OP_UNKNOWN OP_UNKNOWN OP_NOP6 OP_UNKNOWN [error]",
   "hex" : "6a02fdf5c5e6b5d3419e42cc0e12a53b3bd42795a2bdd937739e5eb6eca5cf542206",
   "type" : "nonstandard"
}

And so in the test transactions I sent, I did pack the data inside OP_PUSHDATA1.

I did find an Issue #3313 - 'OP_RETURN is now standard':

  https://github.com/bitcoin/bitcoin/issues/3313

Reading the discussion it still wasn't really clear to me, no one really seems to come out and say that actually the code as-is does NOT allow ....

Looking at the actual Solver() code...

   mTemplates.insert(make_pair(TX_NULL_DATA, CScript() << OP_RETURN << OP_SMALLDATA));

It eventually becomes clear that OP_SMALLDATA (not really an OP) will allow a single block of data appropriately wrapped in a PUSHDATA (not necessarily PUSHDATA1, I don't think we force 'most efficient' encoding yet).

And so the following code in Solver()...

  else if (opcode2 == OP_SMALLDATA)
  {
    // small pushdata, <= 80 bytes
    if (vch1.size() > 80)
       break;
    }
  }

I think that allows up to 78 bytes of actual data payload in an OP_RETURN output.

Since you can PUSH up to 75 bytes with a single OP code, and pushing 76-78 bytes requires OP_PUSHDATA1 . Making the cutoff 80 bytes seems like a funny number, I would have gone with a cutoff at 77 -- which would discourage OP_PUSHDATA1/2/4.

Or to be even more explicit... require OP_RETURN (0x6a) followed by either nothing, or followed by a single byte 1 - 75 (0x01 - 0x4b) indicating length and the specified amount of data.

I suppose the proof of work could take the previous block hash along with some nonce and then iterate on the data in a 'memory-hard' fashion to add latency. Each nonce+result would be redeemable for a single payment coupon within some fixed time period, e.g. when the next block is found.

I think a good solution to this problem is useful in all sorts of interesting ways... for example, when the blockchain itself is the target data, and the storage payments are transaction fees.

Is there some mechanism for preventing a single node storing a single copy of the data, and then spoofing multiple identities and claiming payment as-if the data were stored across multiple nodes?

The obvious solutions are proof-of-work or proof-of-stake, but I can't see how proof-of-work alone would suffice.

If the expected cost of performing the proof-of-work is greater than the reward for storing the block, then no one stores it. Otherwise, what's to stop an attacker from generating multiple possession-txs in order to claim all the available payments for a given storereq-tx?

Proof-of-stake would at least provide some capital reserve to allocate to each identity, then you could add a field for minimum proof-of-stake amount into the storereq-tx, and/or you could use it as an ordering criteria instead of the Kademlia distance.

The cost of breaking the password is based on the strength of the password AND the strength of the KDF. If the password is 'password', nothing will save you. If your password is random 14 character case-sensitive alphanumeric (80 bit), your KDF can even be a single round of SHA512, and it would take the entire BTC network 63 years at the current hashrate (300,000GH/s) to break it.

If the password is 9 random lowercase alphanumeric, that's 46-bits of entropy, or about 50 trillion guesses to decrypt. If you were using scrypt/10-1-1 (LTC) and you had the whole LTC mining network (24GH/s) at your disposal, you could bust through that in 30 minutes. scrypt/18-16-16 however would reduce 24GH/s *well below* 24MH/s for the same network, meaning now the entire network would take 30,000 minutes (20 days) to decrypt the file, which is plenty of time to move funds after your house is broken into and your encrypted paper wallet is stolen.  (Yes, that assumes you know your house was broken in the first place.)  A single iteration of scrypt/18-16-16 takes less than a second on my i7, it's quite manageable.

Now if Satoshi put 1,000,000 BTC into an password-based encrypted wallet and published it on the internet, and promised not to move the funds for exactly 5 years, with a random 12 character case-sensitive alphanumeric (71 bits of entropy) and scrypt/18-16-16 KDF, actually, I think those bitcoin would be pretty damn safe. The cost to decrypt is reasonably in-line with the value of the coins themselves.

TL;DR the point is to increase the cost to steal the funds. The tradeoff is increased risk of losing funds through forgetting the password.  There's no free lunch, but some people will chose to encrypt their paper wallets, and in that case, it would be nice if there was a standard agreed-upon way to do it.

Interesting idea, but I'm not sure why KDF strength should be linked to seed length?

A 128-bit seed is suitable given the overall BIP32 design; you can make it bigger but it doesn't really buy you anything. If 128-bits isn't enough, much bigger things are probably broken.

A stronger KDF, on the other hand, is all about deterring brute-force attacks.  It might be perfectly reasonable for it to take 60 seconds or longer to run the KDF when I'm restoring my HD wallet from cold storage.

Ultimately the difficulty factor for the KDF will have to change over time to respond to advances in hardware and software, so it's definitely "planned obsolescence" to pick a fixed difficulty. In other words, the entire proposal becomes less and less secure over time (easier to brute-force) if users or implementers can't scale up the difficulty.

It's less clear how well 'scrypt' itself will scale over time, but at least it "should" be able to scale up, barring any fundamental weakness being discovered in its design. So exposing some degree of control of the scrypt parameters should mean the proposal can still protect against brute-force attacks as well 5 years from now as it does today.

For what it's worth, I read that LTC uses scrypt with 10-1-1 and right now the network is doing 24GH/s.

My last thought is KDF speed also varies with the use case. If I'm encrypting/decrypting the seed every time I unlock my smartphone and open up my wallet app, obviously that's going to need to run a lot faster than if I'm backing up my "life savings cold wallet" from a desktop app which I only plan to make deposits to over the next 10 years. So different apps could expose radically different timings to the end user (I'm not saying the end-user would/should know enough to pick the timings themselves).

Does anyone know how fast 14-8-8 even runs on an older Android or a Raspberry Pi? For all I know, even though I'd like something slower than 14-8-8 on my desktop, the same could be totally unusable for mobile.

I think a standard format for encrypted backup of the key material (not the hierarchy) is useful.

The heart of any password-based encryption is the KDF -- in this case you've chosen scrypt with n=2^14, r = 8, p = 8.  Just a quick benchmark on my desktop shows this runs at about 25 iters / sec, using about 12MB of RAM per thread, which may be "slow enough", but hard to say definitively. By comparison n=16, r = 16, p = 16 which runs at about 2 iter / sec, using 100MB of RAM for per  thread...  or even n = 18, r = 16, p = 16 which runs at 0.5 / sec, using 500MB of RAM per thread.

Since we're talking about backing up 128 bits, I think it's reasonable to assume the end-user could either just memorize a 128-bit mnemonic (e.g. BIP39), and then they don't need a password (or a backup) at all, or alternatively they would use a password with most likely, significantly less than 128-bits of entropy.

The trade-off of using stricter 'scrypt' parameters is some devices may not be suitable for running even a single iteration. The problem is, if you target your settings to make these devices usable, you're throwing away a lot of the benefit of 'scrypt' -- to make brute-force attacks expensive across a wide range of devices, including GPU and ASIC.

A couple possible options:

  1) Do nothing -- Keep 14/8/8 as the standard hard-coded settings for the KDF as it's "slow enough"
  2) Increase difficulty -- Then we need to decide what the "right" settings are, including what the maximum RAM requirement should be
  3) Provide some means of using different difficulties since there's no one-size-fits-all

Ultimately #3 would come down to somehow encoding the KDF/difficulty -- there are a few ways to do it...

  3a) Add a one or two byte KDF enum -- 00 could mean "scrypt/14-8-8".  01 = "scrypt/16-16-16", 02 = "scrypt/18-16-16", etc.  This has the advantage of allowing us to keep the format and use KDFs other than scrypt if desired. Possibly include a default of "scrypt/14-8-8" if these bytes were not present.

  3b) Hard code assumption that the KDF is scrypt, and give a 2 or 3 byte encoding of the scrypt parameters that were used.  Possibly include a default of 14-8-8 if these bytes were not present.

Let's take the great state of California, for example...

"Persons or companies performing escrow services over the Internet in California, or performing escrow services over the Internet for consumers in California, are subject to the licensing requirements of the Escrow Law"

With regard to Internet escrow companies, “escrow” also includes any transaction in which one person, for the purpose of effecting the sale or transfer of personal property or services to another person, delivers money, or its Internet-authorized equivalent, to a third person to be held by that third person until the happening of a specified event or the performance of a prescribed condition, when it is then to be delivered by that third person to a grantee, grantor, promisee, promisor, obligee, obligor, bailee, bailor, or any agent or employee of any of the latter.

I guess the question is, if you are a 3rd party in a multi-signature transaction, has the money been "delivered" and is it being "held" by the third person? Technically no, but probably the state would not agree.

Why do you say there is such a long time gap?  Obviously it might be a while before it gets in a block, but you'll see the pending unconfirmed transaction very quickly.

If you don't think seeing the pending transaction is reliable, you could have a button where the user could click 'payment sent' which would mark the cart as 'payment pending' anyway, to prevent double-pays.  Obviously you would still wait for confirmations before sending the goods.

The way this "should" work in the future is that when the user goes to check out a cart, they get a payment protocol message with the payment details, which their wallet will hold for them until they decide to pay it.  That cart is immediately marked as 'payment pending' and you wouldn't accept further payments for those items.

Still looking for volunteers -- 0.25BTC for 15 - 30 minutes talking about what you love and Bitcoin, and what you wish it did better. Newbies and experts welcome.

I'm looking for Bitcoin users (with varying levels of experience) to participate in some user/market research.

I'd like to learn more about what drew you to Bitcoin, what you're looking for in a wallet, features which are most important to you, what's most frustrating about current products, etc. Responses will be kept private and confidential. We'll be using your feedback to refine the design and prioritize features of a new Bitcoin wallet which is currently under development.

I'm very interested to hear your story, and the best way to do that is if we can speak real-time via Skype, Google Talk (or similar) service.

If you are interested in participating, please PM me with the following background information, and I will be in touch in the next week:

1) Do you have a bitcoin wallet? What type of wallet? (desktop/full node, spv, hybrid/web, or web)
2) Have you ever purchased products online using bitcoins?
3) Have you ever used bitcoins in a 'real life' (physical store, or in-person trade)?
4) On a scale of 1 - 5, where 1 is novice and 5 is expert, how would you rank your knowledge of bitcoin?
5) In five words or less, "Why bitcoin?"
6) What time zone do you live in?
7) Contact Info
Email:
Skype or Google Talk:

I am offering a 0.25BTC donation for doing an interview, which should run less than 30 minutes. I'm looking for about 10 participants to start.

Thanks very much!

In comparison to the 25BTC coinbase, all transactions are essentially 'free' - so saying it comes down to orphan risk; it's more complicated than that.

If it came down to minimizing orphan risk due to propagation delay, all miners would mine empty blocks. While we do still see that occasionally, miners also realize that for bitcoin to grow and prosper, and for their horde to increase in value, they need to do a good job actually including the majority of pending transactions in their blocks.

So I think it's more a result of miners "doing what they think they are expected to do" - and also to some extent miners running the software they are given to run. The result is that 0 fee transactions get delayed, because miners believe they're fulfilling their end of the bargain. There's a lot of game theory that keeps the system running as smoothly as it does.

The core team has done a lot of research into block size and propagation delay, and if I understand it correctly, the problem with larger blocks is it will ultimately lead to centralization as mining pools end up co-location and anyone outside the data center gets put at a disadvantage.

Your signature hash (7a05...) is correct.

This verifies for me:

Hash: 7A05C6145F10101E9D6325494245ADF1297D80F8F38D4D576D57CDBA220BCB19
Sig: 304402204E45E16932B8AF514961A1D3A1A25FDF3F4F7732E9D624C6C61548AB5FB8CD410220181 522EC8ECA07DE4860A4ACDD12909D831CC56CBBAC4622082221A8768D1D09
PubKey: 0411DB93E1DCDB8A016B49840F8C53BC1EB68A382E97B1482ECAD7B148A6909A5CB2E0EADDFB84C CF9744464F82E160BFA9B8B64F9D4C03F999B8643F656B412A3

Yes, that's right.

You can also do a 2 of 3 multi-sig and let the 3rd signer be the trustee of the estate.  If gramps kicks the bucket, the estate signs to release the funds early.

The answer is clear: too long.

If you wanted to prevent the grandfather from spending the coins before the 18th birthday, you would use multisig.

Grandfather would pay into a multisig with his pubKey and his grandson's pubKey.  Then grandfather could make the same locked spend from the multisig, which would become valid when the grandson was 18.  The grandson would also sign with his key and broadcast when he's 18.

Encrypt your wallet BEFORE you backup.  An un-encrypted backup is your coins asking for someone to take them.

You need to make a new backup regularly with the bitcoind client because new addresses are created as you use it, and it only pre-fills so many before it has to create new ones.  If your backup is missing addresses that your wallet sent coins to, then you won't be able to spend those coins.

I didn't even see the error the first time and didn't understand your question.  The error at the bottom is "Denied for your account. Contact support."

Seems pretty bad that they haven't gotten back to you, and are holding your coins.  I understand if your account has been flagged due to a hacking attempt, better they hold it than let it go to the wrong person, but they should be responding to emails from the same address where the account was created.