|
Nice one. As for nonstandard txs - you know that Eligius pool processes those, right?
And there's also a pull request from Gavin to bitcoin core that will make most scripts standard - including the ones you need.
|
|
|
|
Can't help you, but this is quite cool  Good luck! |
|
|
|
[re:ethereum] Hm. Adopting script changes is _trivial_— in fact we've done it before. Playing a bit of devil's advocate here... but Ethereum is turing-complete, and that would be hard to implement in Bitcoin. Right? |
|
|
|
I think Ethereum is quite close to that feat, although they still haven't launched. There are also projects, like ours - Orisi.org - which can potentially bring so-called sidechains to fruition. Sidechain is an alt-coin that's pegged 1 to 1 to Bitcoin. So you have a different architecture, perhaps even not based on Blockchain, but you're using Bitcoins as a currency on that alternative architecture. So technically, any feature that any other alt-coin has, can be replicated directly within Bitcoin ecosystem. If not through a direct implementation, then through the usage of sidechains. You might also want to check out http://gavintech.blogspot.com/2014/06/bit-thereum.html for more details. |
|
|
|
I wonder if some sort of side chain mechanism could do this, or maybe a new coin could handle this. Just yesterday we released a proof of concept smart contract for handling timelock functionality: https://github.com/orisi/wiki/wiki/Performing-a-Timelock-transactionThe idea is, that there are N oracles (three right now, up to 15 in the future), handled by independent and trustworthy individuals. You create an M of N multisig address, requiring at least 50% of oracles to sign the transaction, and then broadcast the request for signing to them. As of now, the system runs on just three nodes that were set up by ourselves, but if anyone wants to join in, let me know. timelocked in a transaction might also be a way of passing on an inheritence to your children It would be quite easy to do a similar contract within Orisi. The timelock part is ready, but what you could also add is a "timelock extension" mechanism - if a signed message gets posted to oracles before timelock expires, the timelock gets extended by the next X amount of time. That way, as long as you post a message, the money will be locked on an account. You could also prepeare a special message kind for withdrawing the money to a different account. Here's a whitepaper about our system: https://github.com/orisi/wiki/wiki/Orisi-White-Paper |
|
|
|
The amount of information in each sentence I wrote is a lot too high ftfy. Good to see that you know what your problem is. Once you're a well respected member of the community, you could probably get away with writing unclearly. But until that time comes - nobody will care. Just explaining why nobody bothered to read you and reply to you. You wasted your time writing all this. |
|
|
|
|
Regarding the compressed keys that should make the transaction standard. Did you test that, Edmund? We're compressing the keys, but tx is still too big to be accepted by anything besides Eligius.
|
|
|
|
|
It's not a matter of currency, it's a matter of exchanges. You can create an exchange that processes bitcoin for Gold.
|
|
|
|
That's not how you do them. You combine the hash with private key of the party so you can redeem with "(Alice-priv + data-hashing-to-yes-hash) OR (Bob-priv + data-hashing-to-no-hash)". That assumes that you know is in advance either the receiver's key, or receiver's address. There are contracts that say: "The first person to perform X will receive bitcoins protected by oracles". |
|
|
|
Hashes should be shorter, and avoid using up sigops. Yeah, on the other hand, the problem with hashes is that they are "all or nothing", and they don't really allow for locking in the output address. The no output address lock is problematic, because there's of an obvious attack vector. I lock in my funds on an address protected by a hash. Once I want to redeem them, I publish a transaction, and a potential attacker can grab my transaction, replace the address with his, and try to race me to miners. The issue can be solved, and such an attack is hard to pull off, but still - a threat. But the bigger issue is that "all or nothing". We have contracts in the pipeline that will withdraw only a part of money from a multisig. For example, in case when you want to use oracles to handle a trusted wallet system (where oracles allow you to withdraw only a part of money per given day), or for term contracts, where the receiver gets from 0 to X bitcoins depending on details of the condition (e.g. he's to receive an equivalent of USD$1000, and the rest should go to the sender). Or a scenario where oracles are used to build a distributed mixer - everyone puts in money into a multisig address, and at a later date withdraws that money. (btw. if there's anyone willing to do a mixer, or a trusted wallet, or term contracts, contact me at kolinko@gmail.com, we'll help you do that using Orisi).There are ways to mitigate "all or nothing", but not in all scenarios (not in the mixer scenario), and in other scenarios it's quite problematic (you'd have to create multiple multisig addresses holding various denominations). |
|
|
|
|
> My wife disallows me to write freeware.
> PM me for more details if you want.
And how well is it going so far?
There are various benefits to doing small open source tools. You gain publicity, you can meet other interesting programmers, get involved in cool projects, etc. Saying "I don't share my code for free" is a bit like saying "I don't share my thoughts for free".
I'd argue that you stand to gain far more by sharing small scripts like this, than you could by charging money. You'll be earning thousands of dollars on your scripts, and losing tens of thousands on opportunities you'd get otherwise.
|
|
|
|
|
Care to share the tool?
By the way, why the interest in more than 2 of 3?
|
|
|
|
Ah, we were going through exactly the same problem with our distributed oracles implementation. Ultimately we pushed 8 of 15 through Eligius pool two weeks ago. Still haven't implemented the compressed keys, which should bring the transaction size down - just like Edmund said. You might want to check our github repo: http://github.com/orisi/orisi to see how it's all being implemented. (and http://orisi.org for details about the project) |
|
|
|
|
Yeah, didn't read that either. Wall of text, and hard to read. Take a writing class, or read a book on writing well, if you want to be heard.
And I'm interested in anything M of N.
|
|
|
|
This is something that we'll be needing soon. Thanks  |
|
|
|
Gavin has written a pull request that will make the transactions that allow you to do the key-issuing model cleanly standard.
Wow, this is great news for smart contracts altogether. Do you know when it will get pulled, and what's the e.t.a. on this reaching the stable bitcoind release? Even with this update though, there's a problem with transaction size, right? IIRC we had problems submitting anything above 3 of 3 sig to pools other than Eligius due to the transaction size exceeding 500 bytes. |
|
|
|
|
Just a thought, as a boyfriend of a girl who runs an organisation of women in IT...
By saying "women are better at X", you're enforcing stereotypes about women. If you say that "By the paradigm of biology women are more complicated, sophisticated and finesse.", you invite questions like: "then what women are worse at, by the paradigm of biology?". You're inviting all the misogynists to say: "yeah, and also, by the paradigm of biology they are worse at programming, overcomplicate things and are generally less intelligent and can't handle science that well." This is *not* the way to go.
Also, even if most women are sophisticated, it doesn't mean that this is due to the biology and not upbringing. Do you have any research to confirm that?
Finally, if you're coming to a forum full of males with a product that says on the front page that most of us are simple brutes incapable of understanding shades of grey between two extremes, don't be surprised if you won't be greeted warmly.
To remain positive though... I think it would be a good idea if you decided what is your target audience really. Is it "sophisticated, finesse" people, or is it women? Because "sophisticated and finesse" is a term that encompasses a plenty of people. You could write about the recent paintings' auction that took place in Poland, or about exclusive products that can be bought using bitcoin, or about beautiful and elegant pieces of technology.
On the other hand, if you really want to target woman, I think it might be a good idea to not exclude women who are more of a geeky type. There are women who are tomboys, geeks, or have aspergers ( as @tjohej mentioned). There are women who are rough, who love tech, fast cars and great pieces of engineering. There are women who don't consider themselves tiny delicate flowers, but who have to deal with everyone treating them like one.
If your site really wants to be for women, you could use it to empower them. Tell them that it's fine if they want to dig deeper into this tech. Show them role models that already do so. Reprint the tech articles written by women. If you really want to bring gender parity to tech, show people that it's okay to be a woman and be interested in tech.
|
|
|
|
|
Show Posts
