They got disabled quite early and enabling them one by one is a soft-fork in many cases. Also to trade one needs a order book - are you really suggesting that the whole order book for several decentralized exchanges should be stored in the memorypool of Bitcoin clients?

I am aware that Bitcoin CAN work with scripts (and in some cases it might make sense to represent IOUs with Bitcoins). The trading + order books of the represented IOUs however should likely happen outside, either with blinded tokens on dedicated servers like OpenTransactions suggests, on a completely new alt-chain (several ideas flying around, never heard about actual implementations - maybe Namecoin could be viewed as one), on Ripple or a fork of it or on a centralized exchange (GLBSE, btct, bitfunder... you see how they end up!).

If you use BTC to issue IOUs (no matter if Mastercoin or colored coins), you anyways have the "trust issue" that a lot of people around here don't seem to like about Ripple. The only thing that's left aside from requiring trust (which any of these solutions will need) is that it is not sure if Ripple consensus really is as safe as advertised. Contrast that with the known problems/limitations of MasterCoin and colored coins and you might get why I suggested it in the first place.

Also it works _right now_ with a working open source client and server, order books, trades etc. as opposed to a lot of other technologies presented here which are in the best case just starting up with some funding and in the worst case some forum ramblings of people who think "a p2p exchange would be a nice idea, someone just has to do it!" (Edit: like the OP who re-invented colored coins).

Service Discussion: Discussing about existing Services (e.g. MtGox etc.)
Project Development: "I have an idea, how do I implement feature X/is it feasible?"

Your post falls into category 2 imho.

Well, then there's still the issue with altcoins being (far) less secure than Bitcoin:

Alice reveals X, Bob 51% attacks Altcoin to undo/prevent Alice's transaction for the remaining n hours, Bob redeems Bitcoin. Are Altcoins just viewed as "secure" in this scenario and is this a reasonable assumption in reality? This again might be seen as not relevant, as not the protocol but the chain is attacked.

Still it would be nice to allow Alice to trade with anyone, not just a certain Bob.

As far as I understand, Alice cannot put out a general offer though, she can only trade with Bob and vice versa. This might be a potential drawback. On the other hand this is about atomic transfers, not cross chain trade offers...

What if Alice (because she likes to do arbitrage and is speculating on shifting values) reveals her x very late (after 23:59h and 59 seconds)? This would lead to the case that she doesn't get her altcoin but bob can still claim the Bitcoin, right? Also might it be the case that this leads to some issues in the altcoin network, if half of the nodes see her revealing X thus granting her the altcoin and the other half believe that the time is over and the altcoin should return to Bob?

The "competition" offers 1 BTC for ~13k XRP at the moment (https://ripplecharts.com/market/BTC:Bitstamp/XRP)

Do you intend to beat these rates actually or do you just want to compete with the other people on this forum and their huge markups by offering slighly lower 2-digit markups?

Then you'd end up with potentially presenting the same address to several users, as there will always be some lag time between presenting the user an address and the user sending something there.

The only thing to prevent this is to create some accounts on your service (which is something I want to avoid) or doing ugly things such as using IP addresses to distinguish between current users...

It might be possible to re-use addresses (if you re-implement the blockchain API, one could save all addresses that were not used for 1 week and then use these again) to migitate this somehow, still wallet bloat is an issue, as long as keys are 100% independent of each other and not BIP31. Even if Bitcoind (finally!) implements BIP31 deterministic keys, there is still the issue with Altcoins that are poorly maintained and that would take even longer to pull the necessary code.

Maybe creating a relatively large pool of addresses (e.g. 100k or so) that are rotated would work too, but that's actually backend stuff. Still, the "generating new address" part is what worries me most, the rest could be also simply polled with getreceivedbyaddress as already said.

You could simply use Ripple for this... Bitcoin is not really made to act as a marketplace from within, so you need an external network for trades anyways.

One of the problems is the generation of new addresses that can lead to very large wallet files over time. With blockchain.info you offload this stuff to them, if you do it yourself, you might want to look into rate limiting or something like that to avoid someone spamming your server with 1 million requests that would fill your wallet files and also maybe even DoS you with key generation.

"Gateway" only means that you are offering to issue and redeem tokens ("IOUs") on Ripple - this can be done manually or automated/scripted.

Ripple transactions can be blinded, just like Bitcoins too, so they could be kinda taken offline and redeemed later. It is much easier and more convenient to leave them inside Ripple.

/fixed ...

Naja, eventuell reicht's auch, die eletronische Rechnung auszudrucken, 2 Mal zu falten und einzuscannen - ich habe da eher selten eine elektronische Rechnung bekommen, die komplett anders war als einfach das, was man sonst ausgedruckt zugeschickt bekommt.

Maybe you didn't get my question:
How is it possible that binary options are "made in some unclear way"? Either they are valid and thus VERY clear or he tried to backdate them somehow and failed (then it might be DoS, though 8 bets in one minute are not THAT much...) or succeeded (then you are incompetent).

You are taking deposited funds away and not redeeming them. Even if you don't hold onto them, but instead move them to another (not involved) third party this is still stealing in my book ("I didn't take the money from that person for myself, I wanted to donate it to Wikipedia!" won't help you in court either).

Also I don't get your statement "It's not a bet amount - it's a bet character." - what does this sentence mean and how does it relate to you being able to have "unclear" binary options?!

Nachdem ich gerade mal wieder das B-A Wiki durchstöbert habe und hier im Forum noch keine Ankündigung war:

http://bitcoin-austria.at/wiki/Treffen/Graz/4


Vielleicht interessiert's ja den/die eine(n) oder andere(n).

http://bitcoin-austria.at/wiki/Hauptseite

Treffen gibt's in Wien anscheinend am Monatsanfang jeweils im metalab.

Falsch.

Man könnte zwar auswählen, wenn 2 Transaktionen bestehen, welche jetzt diejenige ist, die bestätigt wird - man kann aber nie beide in die Blockchain bringen, da damit der Block ungültig wäre, egal wieviele % der Rechenleistung man hat.

Gar nicht annehmen wäre allerdings möglich, das stimmt.

Ideally I'd like a piece of code that just interfaces with bitcoind's RPC interface and generates the callbacks on its own, if necessary even just by simply polling every 2 seconds or so.

Has anyone written something like this already? It doesn't seem too difficult to do on my own, but it would be nice if it already exists.
I do explicitly not want to extend bitcoinj or Electrum etc., as I would like to use this approach on altcoin clients too, which are (too) often based on bitcoind and expose the same or a very similar RPC interface, so I'd love to keep it generic.

This seems like autorenew is being activated by autolend and also takes precedence over it. I also noticed it, though it doesn't bother me that much. Still it would be nice, if autolend would NEVER activate autorenew at all.

There are suddenly a LOT of accounts that were created prior to 2012 who just have 2 posts... one of them in this very thread.

Use hash to calculate private key, send coin to corresponding address, send coin back... Done.

To give proof: reveal hash, calculate private key again and present the transaction that already took place.

You pay miners twice for the transactions and you are not worse off concerning pruning than before, potentially better if you combine inputs for the first transaction.

Das ist eher ca. 2140, nicht 2030. Dieses Missverständnis kommt daher, weil der Graph auf der Wikipediaseite nur bis 2030 gezeichnet ist. Er geht aber recht eindeutig NICHT bis 21 Millionen im Jahr 2030...