> Why not just provide hardware to support the blockchain as a part of the deal? Eliminates the problem and the ~$100 to purchase the hardware should be little compared to expected revenue, etc.

Well, would you install a Twitter, or GIMP on your laptop, if it required you to provide your postal address, pay $100, wait a week for delivery, and then carry that hardware with you everywhere you go?

Not to mention, that it's impossible to run such a service in the cloud, and it increases a cost of trying out the service from one download & 15 minutes of fooling around, to a payment, waiting and technical hassle.

For that, you'd need nLockTime, as others said

The problems start when you want to create a customer-facing application, and you have to explain to him, that this tiny payment tool will require a 30GB download to start.

Or - in our case - when you want people to set up virtual machines monitoring one or two addresses each - because of the size of the blockchain, it's hard for people to quickly set up such machines and see if the solution fits them or not.

Bitcoin has a nLockTime mechanism within the protocol, but there are various issues with it: http://bitcoin.stackexchange.com/questions/5783/transactions-with-a-wait-time-using-nlocktime

You can achieve a similar feat using M of N oracles:
https://github.com/orisi/orisi
https://www.youtube.com/watch?v=boPW1FwNu4c

So... is this implemented yet?


Nice... although I'd prefer to use bitcoind if that's possible...

Speaking of a lite node / SPV... How is that working out right now? I have a hard time finding good docs for it.

In our system, we want oracles to watch a specific multisig address for incoming transactions. Do we really need to store a whole blockchain for that (and not a - say - tree of unspent outputs that we ourselves extracted from blockchain and therefore trust it?)

Speaking of smart contracts - you might want to read a bit about oracles as well - https://github.com/orisi/wiki/wiki/Orisi-White-Paper . Right now our oracles don't use OP_RETURN, but they will..

There's also:
https://bitcoin.stackexchange.com/questions/tagged/contracts
https://en.bitcoin.it/wiki/Contracts

Not about OP_RETURN per se, but closely related to it

Thanks for the explaination... I already asked in another thread, but I'll ask here as well.. That 520 bytes limit also makes txs above 3 of 4 nonstandard right?

For example this one:
0100000001422991e418b7b92c3127c22dd5bfac0743d56ab216aeb1573bba9a1025747d6400000 000fd200100483045022100d5bc891c4305e67096cee29dceef455830decda9eb9e89b41a9a5fe3 dbe75c6202207964ea2f464f525748a39fcfeaf405f45312c4ba542879fb7beeaaf20a442835014 830450221008022e32bf35c05f44cef659653724dc1ddb164035d8056ccb60e9db8f3eadb0b0220 6da064420a221958a2e65add7e0bb51739423dbfdba733d5eaf3dbe6d7b7cdf6014c8b522102e8e 22190b0adfefd0962c6332e74ab68831d56d0bfc2b01b32beccd56e3ef6f02103903ea684377ca5 1d84fbdf1566db58499d80240725ab78e2917c3c285ace4eab2103a9bd3bfbd9f9b1719d3ecad86 58796dc5e778177d77145b5c37247eb306086182103f6c9fbe11ac0345676d0eb02f212a83bd0c9 1b3e9c3adfbf6c0a8d0b51b9235c54aeffffffff05b80b0000000000001976a91425de2fdaa7954 bb4e6a53f5228847afc09bee0cd88acb80b0000000000001976a91480e4032cf40387a2714d7511 05ec93a709d17f2688ac70170000000000001976a914f38ba5d948bf2016db759124bf0440e4bfa d8e4388ac080c0100000000001976a914f32e72b477081756559b5569a66647a5bf01051488acb8 0b0000000000001976a91476a4dc3e419783ec85503f12b591069c9b47639b88ac00000000

For example, this tx, which redeems "2 of 4":

0100000001422991e418b7b92c3127c22dd5bfac0743d56ab216aeb1573bba9a1025747d6400000 000fd200100483045022100d5bc891c4305e67096cee29dceef455830decda9eb9e89b41a9a5fe3 dbe75c6202207964ea2f464f525748a39fcfeaf405f45312c4ba542879fb7beeaaf20a442835014 830450221008022e32bf35c05f44cef659653724dc1ddb164035d8056ccb60e9db8f3eadb0b0220 6da064420a221958a2e65add7e0bb51739423dbfdba733d5eaf3dbe6d7b7cdf6014c8b522102e8e 22190b0adfefd0962c6332e74ab68831d56d0bfc2b01b32beccd56e3ef6f02103903ea684377ca5 1d84fbdf1566db58499d80240725ab78e2917c3c285ace4eab2103a9bd3bfbd9f9b1719d3ecad86 58796dc5e778177d77145b5c37247eb306086182103f6c9fbe11ac0345676d0eb02f212a83bd0c9 1b3e9c3adfbf6c0a8d0b51b9235c54aeffffffff05b80b0000000000001976a91425de2fdaa7954 bb4e6a53f5228847afc09bee0cd88acb80b0000000000001976a91480e4032cf40387a2714d7511 05ec93a709d17f2688ac70170000000000001976a914f38ba5d948bf2016db759124bf0440e4bfa d8e4388ac080c0100000000001976a914f32e72b477081756559b5569a66647a5bf01051488acb8 0b0000000000001976a91476a4dc3e419783ec85503f12b591069c9b47639b88ac00000000

It barely fits the 512 bytes limit, right? Are we doing something wrong?

From our experience more than 3 of 4 causes redeemScript to exceed 520 bytes size. Do you have an example transaction that redeems anything higher than X of 6, and will still be considered standard?

But that's a requirement for validity, right? Because the new rules say that for tx to be standard it should have no more than 15 signature checking operations:

https://gist.github.com/gavinandresen/88be40c141bc67acb247

There are a few replies to this question on Bitcoin Stackexchange:

https://bitcoin.stackexchange.com/questions/23893/what-are-the-limits-of-m-and-n-in-m-of-n-multisig-addresses/28104#28104

(linking to my reply, but other ones are also interesting)

+1 - custom script, the only problem is that it has to go through Eligius and you'll have to wait 1-10 hours for the block to be mined.

7 of 9 that TimS suggested would also be considered nonstandard due to tx size.

What happens if some clients have a trust-list different than some other clients? There will be two separate and incompatible blockchains then, right?

E.g. some nodes/clients include a pool A, but not B. Some nodes/clients include B, but not A. But everyone includes C, and nobody includes D.

After a short while there's a situation like this:

ABCD (so, first block mined by A, second by B, third by C..)

Then "A" mines a block. Part of the network accepts it, part of the network doesn't trust A, and rejects it, because it was right after D which is also untrusted. So now we have:

ABCDA - some clients consider this the longest block
ABCD - some clients consider this the longest block

But then "B" delivers a new block to "ABCD" (because "B" doesn't trust "A" either, so it doesn't consider "ABCDA" the longest blockchain), so it's now:

ABCDA - some clients believe this is the only valid blockchain
ABCDB - some clients believe this is the only valid blockchain

aaaand we have a hard fork. Some clients use one blockchain, some clients use another blockchain.

In other words still - clients having different trust lists would lead to a hard fork of blockchain.

Wow, interesting

A loose thought - what if such a system were a "sidechain" to Bitcoin?

Let's say that we run N of M oracles that hold keys to a multisig address. And oracles are running an alternate transaction system (modelled on SWIFT or Ripple, or whatever). That system would be using bitcoin as a currency (so bitcoin would still be basis for the value), but would not be blockchain based.

So now - people would trust in Bitcoin because blockchain guarantees impartiality, and security, but would use that other system for performing most transactions.

Kinda like Coinbase really, but hosted on distributed oracles You could imagine a day when there are a couple such competing transaction systems, and bitcoin is sent between them only when really necessary. Just like with dollar, and many banking systems holding it.

The question would be - if such a situation were to occur, and block reward was close to zero, how would the network survive? In other words - what if a majority of transactions in future happen outside of blockchain?

Another question - if by chance, one of such transaction systems, had a majority of volume, wouldn't bitcoin become a sidechain to that system really? (e.g. 99% merchants use x-bitcoin for transactions, and most people keep their bitcoin within x-coin. What happens if x-bitcoin decides to mint new bitcoins?)

(To elaborate on why gmaxwell is right)
Your solution requires "pool trust lists", or "pool ids". If I want to become a new independent miner, or a new pool, I need to get on that list. Obviously, those lists need to be exactly the same for all the bitcoin users - if a bitcoin node has a different list, then it will be running a hard fork of bitcoin, because anything after a first block mined by a pool that the node trusts, and the other nodes don't, will be a different blockchain.

Ergo, your solution requires that there be a single list of trusted pools, and that list is what people define as "Bitcoin". And if you have a closed list of pools, you can as well retire the whole proof of work, and just say that everyone on the list gets one vote on accepting/rejecting the next block.

It's not a stupid solution really - aside from SWIFT, also Ripple uses it if I'm not mistaken.

Actually, he's correct. It's you who should reread what you wrote. Seriously.

He did just that So - once this gets through, any script with less than 15 sigops will be considered standard

By the way, I'm sorry if I missed it, but what other algorithm do you plan to use that would fit the standard tx criteria as we understand them now?

Finally, a small pointer regarding your indiegogo campaign. I'll probably send some cash your way closer to the end, but so far what turned me off were the rewards and overall vision presented there. You mention debit cards, then there is BlockSpace, and your video talks also about supporting USD, and real products. While I love the idea you presented in this thread, your IndieGogo suggests that you want to add a ton of other features // create a feature bloat.

Debit cards are a startup on it's own, BlockSpace also, and USD/real currencies are a huge challenge. If you're telling me that you plan to do all those things, I'm less inclined to believe that you can deliver if you just focused on the p2p exchange (and did it well).

You can do it through distributed oracles:

https://github.com/orisi/wiki/wiki/Performing-a-Timelock-transaction
and
https://github.com/orisi/wiki/wiki/Orisi-White-Paper

The idea is that you have a set of 5 to 15 trusted arbiters who keep keys, and will unlock money only when over 50% of them decide the time has passed. Orisi is an example implementation - still in alpha, but you can pm me or the project (support@oracles.li), if you're interested.