We've already got good reason to expand the context to be at least the CTxOut's of previous transactions, and expanding it still further to include things like block hashes is a common request. If more such things were added I'd be inclined to formalize this notion of "Context" in the EvalScript() and so-on routines. Easy to see why you might not want to have to do that of course.
Including things which are not a function of the transaction changes the model pretty substantially though. There isn't too much that comes to mind as "would also break" but it seems like the sort of thing that may have subtle implications. The effect on compact proofs of misbehavior immediately comes to mind if done badly. Well as we discussed before on -wizards, locktime usage with a timelock rather than a block height lock may create bad incentives for miners to skew timestamps anyway; might be a good idea to disable it entirely. Also, it's not the 2038 problem, it's later: nLockTime is unsigned. Perhaps, but there really isn't a reason that the network couldn't soft fork in more strict time checking such that similar shenanigans would only really work if a supermajority of hashpower was in on it. An argument against it is that people will use centeralized sources of time if you ask them for second level precision, but thats not fundamental. Well, my thinking re: Viacoin is it wouldn't be a crazy idea to use the young age of the coin to hard-fork in less strict time checking, say a 4 hour window to be sure that daylight savings changes don't cause problems. Not a big deal, but it sends the right message. I do somewhat wish the nlocktime time check were on the median of 11, which would make the funny business much less attractive— actually that could be a soft-forking change, since the median is strictly less than the block time. Basically in that case lying about your time wouldn't help you specifically mine a transaction.
Right, I'll look into that. Anyway, for OP_CHECKLOCKTIMEVERIFY specifically seems that the following form would make sense:
<test_nLockTime> OP_0 OP_CHECKLOCKTIMEVERIFY
If in the future it's decided that you really need different behavior - say for testing time and block nLockTimes in the same transaction - the OP_0 can be changed to something else to soft-fork in new behavior with the same opcode. Otherwise anything but OP_0 behaves as a NOP. Basically just a specific instance of the "OP_EXTENSION" pattern to enable as many new opcodes as you could ever want that I mentioned before on the mailing list. |
|
|
|
Perhaps its angels dancing on the heads of pins— but you can never check the validity of a signature without the scriptPubKeys, you can— however— check if the nlocktime is valid, e.g. and defer the more expensive operation of worrying about the signatures for transactions which have met their locktime requirements.
It also means that no transaction scheduling logic— e.g. code that decides if a transaction is locked yet needs to deal with scripts, and it means that the invariant that if a signature is invalid for a transaction is is always invalid, remains preserved (e.g. script remains a pure function with no non-deterministic inputs). E.g. you could still cache the entirety of script evaluation.
The downside with the criteria sniffing is that it's possible to have inputs with a mutually exclusive locktime type— e.g. two txins which can never be spent in the same transaction. This seemed inelegant to me, especially in contrast to the elegance of the rest of the approach. I still think it's better— just wish I had a way to avoid the risk of mutual exclusion. Obviously a receiver can just demand to use one type or the other.
Well one way to think about all this is that a script is valid in a given context. Currently that context is simply the transaction itself and the scriptPubKeys of previous transactions; my patch would expand that context to include the transaction and the current block height/time. Your version of the patch cleverly avoids having to expand the context. We've already got good reason to expand the context to be at least the CTxOut's of previous transactions, and expanding it still further to include things like block hashes is a common request. If more such things were added I'd be inclined to formalize this notion of "Context" in the EvalScript() and so-on routines. Easy to see why you might not want to have to do that of course. Pity Satoshi just didn't make transactions have a nLockHeight and nLockTime separately.  Another odd concern with locktime in general is that it's incompatible with the natural solution to the y2038 problem (which isn't a real problem for the rest of the system since you can just unwrap header timestamps into 64 bit values).
Well as we discussed before on -wizards, locktime usage with a timelock rather than a block height lock may create bad incentives for miners to skew timestamps anyway; might be a good idea to disable it entirely. Also, it's not the 2038 problem, it's later: nLockTime is unsigned. Thanks very much for making the patch source available!
I try to get my head around about your conversation with Peter regarding to the implementation details, but I am not sure what is the better implementation Peter's or yours?
Well, they're both ideas at this point, not fully fledged "implementations" per-se. I'm sure quite sure what's the better approach; need to think through it all some more. |
|
|
|
Are you a programmer now? Did you see the code?
Better let the experts (like Todd or Anonymint) have an opinion on this..
No need to take my word for it! These two fragments of code do similar things: void tree_hash(const char (*hashes)[HASH_SIZE], size_t count, char *root_hash) {
assert(count > 0);
if (count == 1) {
memcpy(root_hash, hashes, HASH_SIZE);
} else if (count == 2) {
cn_fast_hash(hashes, 2 * HASH_SIZE, root_hash);
} else {
size_t i, j;
size_t cnt = count - 1;
char (*ints)[HASH_SIZE];
for (i = 1; i < sizeof(size_t); i <<= 1) {
cnt |= cnt >> i;
}
cnt &= ~(cnt >> 1);
ints = alloca(cnt * HASH_SIZE);
memcpy(ints, hashes, (2 * cnt - count) * HASH_SIZE);
for (i = 2 * cnt - count, j = 2 * cnt - count; j < cnt; i += 2, ++j) {
cn_fast_hash(hashes[i], 64, ints[j]);
}
assert(i == count);
while (cnt > 2) {
cnt >>= 1;
for (i = 0, j = 0; j < cnt; i += 2, ++j) {
cn_fast_hash(ints[i], 64, ints[j]);
}
}
cn_fast_hash(ints[0], 64, root_hash);
}
}
uint256 CBlock::BuildMerkleTree() const
{
vMerkleTree.clear();
BOOST_FOREACH(const CTransaction& tx, vtx)
vMerkleTree.push_back(tx.GetHash());
int j = 0;
for (int nSize = vtx.size(); nSize > 1; nSize = (nSize + 1) / 2)
{
for (int i = 0; i < nSize; i += 2)
{
int i2 = std::min(i+1, nSize-1);
vMerkleTree.push_back(Hash(BEGIN(vMerkleTree[j+i]), END(vMerkleTree[j+i]),
BEGIN(vMerkleTree[j+i2]), END(vMerkleTree[j+i2])));
}
j += nSize;
}
return (vMerkleTree.empty() ? 0 : vMerkleTree.back());
}
The latter is a lot easier to read, and because it's C++ with boost there's no error-prone manual memory management. |
|
|
|
I just checked, and there is one "goto err" used in EC_KEY_regenerate_key() in the current codebase. But regardless, the Cryptonote codebase is far worse. For one thing, writing it in C with pointer arithmetic is just nuts.
Can you check BBR too? I know your time is super precious but... BBR is Cryptonote, which uses gotos for error handling in a bunch of places. Pretty standard technique on C. Dangerous of course, but using C is dangerous in a whole lot of ways. (in most cases) |
|
|
|
Ah thanks for the correction, I remember this coming up in a "bitcoin code is bad" discussion last year or something and thought the goto was in the code.
Thanks Peter.
I just checked, and there is one "goto err" used in EC_KEY_regenerate_key() in the current codebase. But regardless, the Cryptonote codebase is far worse. For one thing, writing it in C with pointer arithmetic is just nuts. |
|
|
|
That's a proposed pull-req - it was never merged into the Bitcoin Core codebase. (in part because of the goto) |
|
|
|
All new systems have bugs; based on the code I've looked at I fully expect we'll find an order of magnitude or three more serious bugs in the Cryptonote codebase than we found in the Bitcoin codebase.
Besides, by re-using the Bitcoin codebase you get the benefit of all the bugs that have been fixed over the past few years.
Are you offering help Not quite - I've been hired as an advisor. There are other things besides ring signatures that are good and I have no idea how compatible they are. As always, tradeoffs.
I can't think of anything in Monero that would be fundementally incompatible with the Bitcoin codebase, although you'd certainly need to write some code. One good thing is that there's been a lot of recent work on the Bitcoin codebase to make it significantly more modular, to that reusing it for altcoins is easier than it used to be. |
|
|
|
Lets keep the record straight: Bitcoin v1.0 had significantly better code quality than Cryptonote does from what I've seen; I just checked and there weren't any goto statements in the codebase. Cleaning up this mess isn't going to be easy, although it certainly is doable.
I'd strongly suggest taking the good part of Cryptonote - the ring signatures - and porting them over to the Satoshi codebase. Monero could be re-released based on that much better codebase and the UTXO set ported over at the same time so all coin owners on the old system were coin owners on the new system.
what about the bug that created billions of BTC? All new systems have bugs; based on the code I've looked at I fully expect we'll find an order of magnitude or three more serious bugs in the Cryptonote codebase than we found in the Bitcoin codebase. Besides, by re-using the Bitcoin codebase you get the benefit of all the bugs that have been fixed over the past few years. |
|
|
|
So what? The code base is brand new and needs work. Every Monero investor should know this. Bitcoin was crap as a stack of cards at one point, it even had freaking goto loops in the code. Lets keep the record straight: Bitcoin v1.0 had significantly better code quality than Cryptonote does from what I've seen; I just checked and there weren't any goto statements in the codebase. Cleaning up this mess isn't going to be easy, although it certainly is doable. I'd strongly suggest taking the good part of Cryptonote - the ring signatures - and porting them over to the Satoshi codebase. Monero could be re-released based on that much better codebase and the UTXO set ported over at the same time so all coin owners on the old system were coin owners on the new system. |
|
|
|
I circulated a patch for a different approach for Bitcoin a long time ago: https://people.xiph.org/~greg/OP_CHECKLOCKTIMEVERIFY.patch (It's not complete and doesn't include the transition rules or cover some states, OTOH it simplifies code by not having to check the scripts (which may not even be inside the transaction itself) to know if the transaction is lock-time-good or not). Huh? You do have to check the scripts - the scripts are a new way for the transaction locktime to be bad. The advantage of your approach is that you don't need to add block height and current time inputs to EvalScript(), the source of quite a few lines of code changed in my patch. Basically it makes CHECKLOCKTIMEVERIFY similar to CHECKSIG in terms of the data needed to evaluate the opcode. In any case, my plan right now is to use your approach, with the additional rule I suggested on IRC to check that tx.nLockTime < LOCKTIME_THRESHOLD if test_nLockTime < LOCKTIME_THRESHOLD to handle the two different ways of interpreting nLockTime. (block height and block time) |
|
|
|
As a software developer new to the bitcoin source I am really grateful for the work you have done in contributing to BTC and thanks for the reply.
Do you refer to the consensus as an organisation level obstacle or it is a technology term related to the blockchain ... sorry for the silly question :-) and I just want to make sure I understood you correctly.
Organizational/political level, although that's sort of driven by technological constraints. Basically adding stuff to Bitcoin is risky - a mistake that takes the Bitcoin network down costs tens of thousands of dollars an hour - so naturally people are fairly conservative and getting everyone to adopt your proposed change is tough. Adding it to Viacoin OTOH isn't a big deal, because if you screw up you haven't done that much damage, so getting consensus to adopt the change shouldn't be too hard. |
|
|
|
|
My proof-of-concept patch was written for Bitcoin about a year ago; absolutely it could be integrated into Bitcoin Core. The only obstacle specific to Bitcoin is getting consensus.
|
|
|
|
Great! Is the increase in ScriptSig length to account for greater M and N values of M-of-N multisig transactions?
Correct:
commit 84fe0ffd685627689bbbcd14cf419938f2a100b2
Author: Peter Todd <pete@petertodd.org>
Date: Mon Mar 10 16:38:44 2014 -0400
Increase IsStandard() scriptSig length
Removes the limits on number of pubkeys for P2SH CHECKMULTISIG outputs.
Previously with the 500 byte scriptSig limit there were odd restrictions
where even a 1-of-12 P2SH could be spent in a standard transaction(1),
yet multisig scriptPubKey's requiring more signatures quickly ran out of
scriptSig space.
From a "stuff-data-in-the-blockchain" point of view not much has changed
as with the prior commit now only allowing the dummy value to be null
the newly allowed scriptSig space can only be used for signatures. In
any case, just using more outputs is trivial and doesn't cost much.
1) See 779b519480d8c5346de6e635119c7ee772e97ec872240c45e558f582a37b4b73
Mined by BTC Guild.
|
|
|
|
This thread is kinda depressing; this sillyness should have been fixed a year ago. FWIW greenaddress.it was talking about implementing fee bumping to me; tell Lawrence you want to see it. I've also suggested it to the rest of the DarkWallet team, again, telling them you want to see this too helps. Also, everyone who runs my replace-by-fee patch helps out the network. Even if you aren't a miner, nodes that run it help get replacements to miners who will accept them for whatever reason. |
|
|
|
|
Have you found a qualified ASIC expert with low-level hardware experience to evaluate it yet?
I have zero reason to think you have the right background based on what you have previously said on this topic.
|
|
|
|
It should take 525 bytes, so you could only store 19 pubkeys
Doh! Looks like I had a stray pubkeys[1:] in my Python script and miscounted. It could be simplified if it requires M-of-M signatures:
Good idea! |
|
|
|
That's not to say doing a 20-of-20 P2SH is impossible though - you can put 20-byte hashes in the limited size redeemScript and provide the pubkeys in the scriptSig: (OP_DUP OP_HASH160 8e4358ca4d6c9cd53a8e01e75bf0d25475c352e7 OP_EQUALVERIFY OP_TOALTSTACK) * 20
20
(OP_FROMALTSTACK) * 20
20 OP_CHECKMULTISIG
Total size: 500 bytes. That's close enough to 520 bytes that I'm sure you could squeeze in one more pubkeyhash with some micro-optimizations, but I'm procrastinating right now so I'll let someone else do it. |
|
|
|
1) If there is an avenue for zerocash developers to work more closely with bitcoin, what does that look like? Does it mean that @imichaelmiers & @matthewdgreen (on github) could be invited to work directly on the bitcoin protocol, and have the ability to make commits along with yourself, Gavin, and others?
I've been hired as an advisor to the Zerocash team, and likely will be doing development work as well. There's not very much need for Zerocash developers to be working closely with Bitcoin at this stage, although in the future that may change. As for "ability to make commits" - there is no need to try to "grant" that ability, and in any case, those with commit access the https://github.com/bitcoin/bitcoin repository have no special powers in practice. If anything I personally would consider that access an annoying burden, not a useful thing to have. |
|
|
|
|
Even anonymity as strong as Zerocash is not incompatible with strong public auditing of Bitcoin holdings; if anything it improves the auditing situation by making it easy to selectively choose who can audit your activities. I might be perfectly happy with my chosen accounting firm to see all my books in a provable way, maybe even my local government, while still wanting to ensure that criminals and competitors do not see my activities. With a bit of cleverness you can even make these audit proofs non-transferable - that is Alice could provide solid proof to Bob that she has the funds she claims too and her accounting books are correct, yet Bob would not be able to provide that proof to Mallory as either Alice or Bob could have produced it.
And yes, I agree 100% with gmaxwell's comments on the need for privacy. Bitcoin without privacy is simply a non-starter. In many jurisdictions failing to provide that basic level of privacy is even illegal in the context of many financial products, which will prove to be a serious barrier to Bitcoin adoption.
|
|
|
|
This is amazing. Peter Todd has some intense software security knowledge. And "much of his research covers Proof of Publication and Embedded Consensus systems, both highly relevant to Counterparty technology." ( https://www.counterparty.co/team/) Thanks, although I wouldn't call my knowledge "intense" myself. Rather I'd describe it as very different from what other auditors normally look at. Having Sergio do an audit as well was a smart choice - he thinks very differently than I do and finds issues that I miss all the time, and vice versa! |
|
|
|
|
Show Posts
