You can much more easily publish data via the blockchain w/o OP_RETURN, and furthermore, you can easily put that data in to the UTXO set which all nodes *must* have if they are to maintain consensus.

Mike Hearn suggested we adopt blacklists to solve this problem back when someone put the child porn sections of the hidden wiki into the UTXO set; no-one's come up with a better solution since. You can make publishing that data more expensive by a small linear factor - about 10x to 100x - but that's the best you can do.

The best solution to this problem is legal and political: the idea that you have to prevent every last trace of "illegal data" from getting into a public ledger is absurd.

OP_RETURN, seriously.

re: pay-to-contract, note how using it creates very significant and dangerous backup risks. Every pay-to-contract transaction creates a scriptPubKey that isn't derivable from the HD wallet seed, which means you need to immediately create a backup of your wallet metadata least you risk losing user funds. I strongly recommend not implementing it for this reason, without carefully considering this risk. Storing metadata in OP_RETURN outputs - as is done in stealth addresses - is an excellent way of avoiding this risk.

It's been known for awhile now that if a miner wishes to find more blocks than their competition - equally get more fees - they have no incentive to broadcast their blocks to more than ~30% of the hashing power. Re-deriving that number from first principles is a nice exercise in applying some basic highschool math to miner incentives. The well-known selfish mining is another example of this principle, albeit in a more advanced - active - context.

This about this a little harder: you can replace the <pubkey> CHECKSIG pattern in BIP19 with OP_DUP OP_HASH160 <address2> OP_EQUALVERIFY OP_CHECKSIG.

The point of using BIP19 is it's more flexible; edmund's construction doesn't do n-of-m easily.

FWIW I'd recommend reposting this to the bitcoin-development mailing list - it'll get more review there. (I personally would prefer to reply there myself)

edmundedgar is on the right track, but an even better way to do it is to adapt Luke-Jr's BIP19:

{pubkey} OP_CHECKSIG OP_SWAP {pubkey} OP_CHECKSIG OP_ADD OP_SWAP {pubkey} OP_CHECKSIG OP_ADD {n} OP_EQUAL

Replace {pubkey} OP_CHECKSIG as appropriate; you can even mix-n-match multiple forms.

https://github.com/bitcoin/bips/blob/master/bip-0019.mediawiki

Like stealth, I don't have the background to really understand the ring-signatures ShadowCash uses; I was contacted by ShadowCash to do an audit and deferred it to a cryptographer I know. They said the math looked to be a clone of Monero, done on top of Bitcoin. They were however potentially interested in doing an audit of the ring signatures idea to get a better idea of what kind of privacy it really gives people in practice - we'll see if they have the time to work on that further in the near future.

Best not to say more publicly than that given I just haven't done the research to really know. 

I wouldn't say I "invented" stealth addresses; I'd say I designed stealth addresses. The part that you could call an "invention" was created by ByteCoin (the bitcointalk user) years ago - what I did was take that math and figured out a good way to use it given real world constraints. (some of them 100% political!)

To be perfectly honest, I don't really understand the math behind ECC signatures, and hence stealth addresses. My original stealth addresses writeup actually got some of the details there wrong, basically because I was copying-and-pasting from the BIP32 writeup. But IMO that's actually a nice example of how you can treat the math as a "black-box" with known properties and do your innovation elsewhere - no different than how most of you probably don't know much about how compilers work under the hood, yet successfully use them every day to make software.

Huh? I quite clearly give Bitcoin Core as an example of C++ done right, precisely because it uses a safe subset of the language that is a higher-level language via the abstractions used. You brought up C, which just isn't a safe language to write code in.

I read Mike's post as pointing out that knowing how to use C++ correctly - what subset to use - is something that does take skill. It's notable that we've changed a few things in Bitcoin Core to, for instance, use pointers where we didn't before, gradually decreasing the safety of the system by using parts of the language beyond that safe subset.

+1

Each project you get yourself involved with is a significant mental overhead, especially when what the codebase is doing is similar, but not 100% identical, to other codebases you work on. Even on Bitcoin itself I specialize on one specific aspect of it, the consensus critical code, and within that, the scripting system.

You might be interested to find out that Python is actually moving towards static types; the language recently added support for specifying function argument types in the syntax. How the types are actually checked is undefined in the language itself - you can use third-party modules to impose your desired rules. IIRC next major version, 3.6 (?) will be including a module with one approach to actually enforcing those argument types as a part of the standard library. Similarly class attributes have syntax support for specifying types, and again you can already use third-party modules to enforce those rules.

I wouldn't be surprised if the "sweet spot" for most tasks is a language much like Python with the ability to specify type information as well as the ability to easily enforce 100% usage of that technique in important code, while still giving programmers the option of writing quick-n-dirty untyped code where desired. And of course, with a bit of type information writing compilers that produce reasonably fast code becomes fairly easy - Cython does that already for Python without too much fuss.

I'm referring specifically to the demographics of people writing code for Bitcoin-related applications.


C with machine-verifiable proofs has nothing to do with the type of C programming I'm criticizing; neither does SystemC. Those types of environments are so far removed from the vanilla and unsafe C(++) programming that gets people into trouble that you might as well call them different languages in all but name.

I'm mainly concerned about whether or not using C(++) with manual memory management is acceptable practice. Screwing up manual memory management exposes you to the king of all implicit details: what garbage happens to be in memory at that very moment.

Given that we have at least C++ available which can insulate you from manual memory management(1), there's just no excuse to be writing code that way anymore by default. Equally writing C++ in a way that exposes you to that class of errors is generally unacceptable.

Bitcoin itself is a perfect example, where some simple "don't be an idiot" development practices have resulted in a whole class of errors having never been an issue for us, letting development focus on the remaining types of errors.

1) Where manual memory management == things that can cause memory corruption and invalid accesses. There are of course other meanings of the term that refer to practices where memory is still "managed" manually at some level, e.g. allocation, but corruption and invalid accesses are not possible.


And since when did I say anything about "magic bullets"? I'm talking about acceptable bare minimum practices. Over and over again we've seen that doing manual memory management requires Herculean efforts to get right, yet people do get far enough in C(++) to cause serious problems doing it.

It's no surprise that easier languages attract even less skilled programmers who make more mistakes, but it's foolish to think that giving skilled programmers a tool other than a footgun is going to result in more mistakes. I think the unfortunate thing - maybe the root cause of this problem in the industry - is you definitely do need to teach programmers C at some point in their education so they understand how computers actually work. For that matter we need to teach them assembler too. The problem is C is nice enough to actually use - even the nicest machine architectures aren't - and people trained that way tend to reach for that footgun over and over again in the rest of their careers when really the language should be put on a shelf and only brought out to solve highly specialized tasks - just like assembler.

Equally, how many computer science graduates finish their education with a good understanding of the fact that a programing language is fundamentally a user interface layer between them and machine code?

That's an incredibly bold statement given that there's almost no-one writing Bitcoin applications in C / C++ with the exception of Bitcoin Core itself. Equally the demographics of people writing the tiny amount of C / C++ code out there is very different than the demographics writing in more modern languages.

Fact is right now we just can't say anything about what approach is better based solely on where the most bugs have been found; we can say other industries have consistently been moving away from C and to a lesser extent C++ due to the difficulty of writing secure code in those languages.

You're also conflating two separate problems. It may turn out that writing consensus-critical code in other languages is harder, but that's a very different problem than writing secure code in the more general sense. Equally it may turn out that better approaches to writing consensus-critical code are more important than what language you choose to write it in. But right now we just don't know.

Don't have time to help out as much as I'd like, but go for it! With stealth we're still at the point where getting data on how various possible standards perform and what the tradeoffs are is very useful prior to developing the first "set-in-stone" standard; changing stuff now based on feedback will be much less work than doing so later.

Decentralised asset exchange needs it: https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg03892.html

Ha, epic-level trolling right there.

Yup, which is a pretty serious problem because you need to be able to audit that those libraries were actually copied over correctly, are up to date, and actually do what they claim to do; sounds like there's even real reasons to suspect that the codebase may even have backdoors and other flaws deliberately added by the original CN team, let alone more prosaic flaws. While Bitcoin's use of OpenSSL had it's own set of problems, it did ensure that the huge C codebase of OpenSSL was at least the same huge C codebase everyone else used, flaws and all.

But again to be clear, like I've said elsewhere, these are all fixable problems and the Monero team is working on fixing them.

I removed it because I meant to say "much of" - the Tweet as originally written gave the inaccurate impression that Cryptonote is written exclusively in C, which just isn't true. I removed it pretty quickly, within about an hour.

Anyway, code quality is a relative thing; consensus-critical code in cryptocoins needs to have very high standards to be safe and secure. In most cases something like this set of unittests for this code that I'm working on for another project would be considered pretty good, but in the context of consensus-critical I'd consider that code to be really rushed. It'll take a lot more documentation and testing before I'd be anywhere close to trusting it, as well as more thought towards how to make sure others can easily read the code. Even then I still have my doubts that the algorithm is worth the relatively high complexity and thus peer-review penalty compared to a more simple algorithm. (not to mention the language - Python - is kinda suspect due to typesafety issues) But I am on a deadline to get a prototype done, so it'll do for now.