To quote a certain alt-coin designer, "tough titties".

I think you slightly misunderstand me here. I definitely can see multisigns being fairly user-transparent and friendly.

256+ "exotic" transaction types ? not so much. But I guess it is best to start discussing the issue when a lot of "exotic" stuff starts popping up.

As long as exotica goes to a separate addresstype and Auntie can keep sending coins the old way, oblivious to the "pro stuff", I am okay.

Well, Gavin explained in #bitcoin-dev that the plan is actually to have two addresstypes, one for "vanilla" old-timer transactions, and another as catch-all for "advanced" OP_EVAL stuff, which is something I am quite fine with.

Now, the transaction type pluralism is mildly disturbing. People manage to terribly screw up (and whine) with just one transaction type exposed to them and supported on all client soft, I can only imagine the magnitude of chaos when there is a whole load of divergent transaction types with affinity to a particular type of wallet software.

Good thing BTC is not a corporation. We'd have to hire entire India and most of Ukraine for tech support

Pardon if I am being slow, but does OP_EVAL allow for crafting new and wonderful transaction type through RPC ?

I thought that every new exotic transaction implemented by this way will still require one to implement it in the code and compile...


Quite frankly, the implications of having more than 10 (let alone more than 256) distinct transaction types, each with unique "quirks" in operation, are disturbing.

The GUI will end up being like a fighter jet cockpit, for one.

I'd still like to have at least two distinct address forms, one for "simpleton" transactions (like what we have now), another for everything else, just to make demarcation between "basic" functionality and "advanced user features" more explicit. Because you know, people have trouble grokking Paypal interface (and bitcoin GUI), and having them away from getting involved with complicated 5-party signing schemes until they really know what they are doing would be wise.
 

With all due respect, you overestimate the average user.

Well, as long as it essentially ends up being dependent on something deterministic - like "output"'s size, it should be fine.

I'd still prefer "new and brave" transactions to use a different address format though.

Ah, now IC the rational core of the concern, no need to bother theymos

However... How does the receiver get to know what his fees will be like ?

Let's say I want you to send me an escrow-OP_EVAL transaction. I want you to send, like... oh, 5 BTC.

It would be very unkosher if there would be no way for me to know in advance what fee to expect "on my end" after the escrow authority signs stuff (oh noes, it ated 3 BTC out of 5!  )

Actually, I am quite disturbed with implications of shifting the burden of fees to the receiver (as transaction fees are at least partially dependent on conditions that only the sender is exposed to, such as for instance whether the sender's balance is made up of a bajillion of tiny 0.5 BTC inputs)

I'll PM theymos so that he can convince me without turning this topic into a rehash of something he might have already discussed and explained in detail


In my very humble opinion, giving "new and exciting" types of BTC transactions a different address type (either as "catch-all" for all innovative transactions or have a separate address type for each "officially supported" new transaction type,) to avoid confusion and help people grok new and fairly complicated functionality more easily.

Methinks that different addresses for exotic transactions will actually increase usability, especially for "the kind of person" who only lives in GUI and won't touch the  user manual unless ABSOLUTELY necessary

First and foremost, I'd like to say that I like multisign on general principle and invite people to try out various ways of doing it on GG (it allows nonstandard by default).

However, I doubt that multisign in its most classical "(n+1) escrow" scenario is just as useful as it is usually portrayed to be, and I am convinced that lack of it is not a massive barrier to adoption.

As for op-eval specifically, I am quite worried about moving the fee burden to the receiving end of the transaction, as it seems to me that it would make the "unpredictable transaction fee" blight worse, but I think I'd best discuss this with Theymos - he's quite a smart guy, so it is possible that he is right, shifting fees to receiver is awesome, and he will convince me to that effect.


It seems to me that since any reasonable company with more than one man involved and a wallet teeming with hundreds of thousands of bitcoinses would have the machine the wallet resides on pretty buttoned up and gapped, so the rules regarding necessity for multiparty approval of transactions can be enforced on the level of "walletbox" authentication (with possible reasonabl-ish requirement of at least one decision maker to be physically present at the walletbox office if the sum is really huge)

So lack of multisign is hardly an adoption boundary (besides, AFAIK, painpal, libreserve, pecunix et al don't explicitly allow multiparty confirmation as well, and that does not seem to hamper their adoption all that much).

If anything, finding a way to split private keys in a manner that several different devices would have to cooperate to create a "normal" BTC transaction would be closer to what a corporate "multiparty validation" entails.

Lower trust escrow and "wallet lockdown" services are kind of neat, but not "we need it NOW or else" kind of neat.

P.S.:
It would be also neat to have a separate address format (different addressversions or perhaps even a new-ish address format specially for "exotic" stuff).

It would be also neat to have frugal (as in, puts only a little bit of info into the blockchain) transaction earmarking as well as intra-network messaging (incidentally, those are two things I hope to eventually implement in Tenebrix since they are needed for a website-less laundryStrong Transaction Decorrelator system)

P.P.S.: Personally, I love Gavin's Hidden Send, but sadly this type of custom transaction has turned out to be DOA. I would really love to see it (or a functional equivalent) to "come back", maybe with some nifty improvements (a man can dream right? ) but that would likely require a large (and dangerous) scripting language overhaul...

I am quite alive and messing around with things (some TBX related, some plain IRL related).

Perhaps evil, evil BTCEx could hack the workstation with the magical miner code ?

Currently, there are a few things that need to be implemented first, specifically coin burning and sidechannel comms (which, hilariously enough, will be useful for things other than laundry, especially as long as long as coin is cheap)

Next Big Hobby:
Cryptothingie necromancy

Moving site to new host, please stand by

I am Satoshi and this is my favorite thread on bitcointalk forum

With all due respect, planning thirty years ahead is problematic to the point of intractability.

Planning for hundreds of years ahead borders on  delusional - consider the world of 1911, and you will realize that our not so ancient past is more alien to us that most "alien civilizations" contrived by science-fiction authors (even good authors), and this process is accelerating.

It is not unlikely that our grandchildren will be almost incapable of relating to us and our concerns due to changes in lifestyle and psychology (the inverse will also be true)

Replied in the relevant thread, but one question though - do solidcoin (and hypothetical bot-buddeh) estimations account for behaviors associated with pig blocks trusted nodes ?

Anyway, methinks it would be best to wait and see, just gotta not to forget to check SC2 hashrate if / when next DDoS spree happens...

That would require working on custom miner code (or some very contrived workaround), which in case of SC2 would mean either reverse engineering or convincing CH to provide source.

Errrr... are you having a stroke ? Please seek medical attention

Or maybe it just changed its embarrassing miner id ...

More like coinspiracy