|
Wouldn't be overly difficult to do. You're just storing an extra value with each send / receive, then developing the reporting tools for it.
Loads of developers around here that can quite easily do that. If you'd like a quote, feel free to PM me.
|
|
|
|
That isn't how multisig escrow arbitration works. The escrow does indeed sit locked in limbo on the blockchain until m of n keys unlock the funds. This isn't anything like traditional escrow where there is counter party risk involved with concern that the arbitrator can directly run off with your funds.
You never send funds to an arbitrator, they only get a partial key. You don't need the arbitrator to release the funds either, they only are introduced in the less than 1% cases if there is a dispute. Sorry, and you're completely right. I knew it was too late, and I was too tired to be posting. Long day.  |
|
|
|
|
It doesn't really work that great for escrow. You can't put a partially signed transaction on the blockchain, so escrow would have to work exact same as we do now with fiat. You send funds to an arbitrator, they hold the funds, then release them accordingly once the transaction is completed and/or dispute resolved.
There's no requirement for multisig there though. That 1 BTC must leave Alice's wallet, then a new transaction must be created by the arbitrator once the deal is complete. Multisig is meant more for security, not escrow.
|
|
|
|
I'm already used to BTC, so nah, switching over to mBTC would confuse me too much. |
|
|
|
|
I have to admit, it bugs me that so many involved in bitcoin are not completely honest with people. Saying things like, "the greatest advantage of the setup, is that your bitcoins are 100% safe" is a pretty bold claim, and you know full well it's false.
I guess it doesn't really matter, but nonetheless, still irks me somewhat.
|
|
|
|
How secure is this? Have you got any reviews about the service from anyone?
Hi Baitty, Thanks for the question. What I can say is, although the software isn't widespread yet, it has been used in a production environment on a decent number of bitcoin sites for over 18 months now. There have been absolutely no issues for 8+ months now with SQL injection, file injection, XSS attacks, and things of that nature. We did have some problems in the beginning, but they are now patched, and a thing of the past. We were also lucky enough to bring a couple of our attackers on as consultants, who did help pinpoint vulnerabilities within the software, and to secure it. I can confidently say the base security within the software itself is top notch. Then again, no funds, private keys, or wallet passwords are stored anywhere within the software. If someone manages to dump and decrypt the database, there is simply nothing to steal. Instead of being a bank that stores money in its vault, you're basically a money transfer agent that sends & receives messages across the network (blockchain), and takes a fee for doing so. If you'd like, please register for a demo test account to get an idea of what happens. Upon first logging in, you're asked to define a wallet password, and are then provided with two QR codes to download. The contents of the QR codes are heavily encrypted with AES256 bit, and neither, the QR codes or wallet passwords are stored anywhere within the software. You need to input both in order to conduct a send or access your funds in any way. To sum it up, I can safely say the software itself is very secure. Please note though, nothing compensates for a server setup that is properly configured and hardened. If an attacker manages to find an exploit in one of the services on the server, and gains root access to it, then any and all security built into the software is potentially out the window. However, this is something we can also help with. If you have any further questions, please feel free to ask, and I'll do my best to answer them. Thanks! |
|
|
|
|
Thanks for the private contacts everyone. If anyone has any questions, or anything of that nature, please feel free to ask and I'll be happy to answer the best I can.
|
|
|
|
|
Do you have the private keys (preferably in WIF format)? If so, it's easy. Just type:
bitcoind importprivkey WIF_KEY false
Except for the last private key you import. For that one, change "false" to "true".
|
|
|
|
Wrap an exception around your code doing the RPC call: try{
$client->listtransactions();
} catch (Exception $e) {
echo "Didn't work -- " . $e->getMessage();
}
|
|
|
|
That is a lot but with that number of connections it is possible. What version are you using?
Latest version. 0.9.2.1. Nevermind though, I actually read it wrong -- memory use it just over 1GB, so not too bad for 80 - 90 connections at any given time. Ohhh, I also have the -txindex option turned on, so that might be doing it as well. |
|
|
|
Envrin Web Wallet -- Start Your Own Professional, Secure Online Web Wallet / Exchange!After extensive development and testing, we're very proud to release the new Envrin Web Wallet, a high quality, professional, secure online software solution allowing you to professionally start your own web wallet / exchange. Comes fully featured with the latest in bitcoin technology, including BIP32 HD wallets, full multi-signature functionality, altcoin support, SMS authentication & notifications, multiple coin accounts, sub-accounts, friends list, delayed sends, buy / sell coins features, instant vs. manual site signing, complete tracking and auditing tools, and much more. You can rest assured knowing your operation is on the cutting edge of technology, and always will be as we're continuously working hard to provide you with the best, and most secure solutions possible. Security for us is paramount, which is why no funds, private keys, or wallet passwords are stored anywhere within the software, making it virtually impossible for attackers to steal any funds. With full multi-signature functionality, plus using SSSS and strong encryption via AES256, and other optional features such as a friends list, instant vs. manual site signing, and SMS authorization, you can rest assured that your user's funds are safe. Please check us out today, including a fully functioning online demo: We're also available for any custom development needs, and we can do virtually anything -- your imagination is the only limit. Please don't hesitate to contact us for a free consultation and quote, and we'll be happy to assist you in any way we can. You can contact me personally here via PM, via e-mail at support@envrin.com, or via Skype at envrin.group. Thank you, and we look forward to working with you both, now and into the future.
|
|
|
|
|
Hmmm.... I just looked, and why is my bitcoind taking 2.729 GB of memory? That's a little excessive, no? I have 87 connections, so maybe that's why.
|
|
|
|
|
I think your best bet is to make more money first, and get a dedicated server that you can run bitcoind on. Please note, a lot of VPS's out there will kick you off if you're running bitcoind, as it's pretty resource intensive, especially at the beginning while it's downloading the blockchain.
|
|
|
|
|
Looked through the changelogs and couldn't really see anything, except one mention that RPC calls would be separated from bitcoind sometime in the future. Anyway, has there been a chance recently (ie. v0.9.2+) in the startup process? Previously, I would just run "bitcoind -daemon", and all would hum along just fine.
Now though, that doesn't seem to work, because if I kill that SSH connection, things like "blocknotify" seem to stop working. I've resolved this with using "nohup bitcoind -daemon &", and that seems to keep it going just fine even after the SSH session. Just curious, has anything changed in that regards, and is there anything else I should be aware of?
Thanks!
|
|
|
|
Am I missing something?
Don't think so. Write some software, and run a watch-only wallet. After you generate some addresses, scan all transactions and blocks for outputs (deposits) coming into them. Then keep track of the outgoing spends, which will give you the new inputs to use (ie. change address). Use bloom filters if desired. |
|
|
|
|
You poo yourself? That's gross.
|
|
|
|
then I would have to use bitcoind to perfotm the sign and send the transaction using signrawtransaction and sendrawtransaction respectively. Is that correct?
You got 'er! You don't necessarily need to use bitcoind to sign & send the transactions, but all considering, probably easiest to do that. Just create the raw transaction by hand, which actually isn't very difficult once the get the hang of the format. From there, fire it off to the bitcoind RPC API to sign & send it. Actually, I'm not sure... will bitcoind sign OP_RETURN transactions? There's a chance it may throw an error saying the transaction is non-canonical. If that happens, you're stuck signing your own transactions. The StackExchange link above explains how, but it's a bit of a pain. Just Google around and there's lots of blogs & code examples out there in all languages showing how to do it. Creating transactions is easy, signing them is a bit of a pain though. If you read through the blogs from others who've already jumped the hurdle, when it comes to signing transactions, you don't hear any of them saying, "geez, that was easy". |
|
|
|
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?) You're looking for BIP037 (Bloom Filters). https://github.com/bitcoin/bips/blob/master/bip-0037.mediawiki |
|
|
|
No, you can't create OP_RETURN transactions with bitcoind. You'll need to create the raw transactions from scratch yourself. From your example above, here's a raw transaction in hex format: ---------------------------- 01000000010c432f4fb3e871a8bda638350b3d5c698cf431db8d6031b53e3fb5159e59d4a900000 0006b48304502201123d735229382f75496e84ae5831871796ef78726805adc2c6edd36d23e7210 022100faceab822a4943309c4b6b61240ae3a9e18ed90a75117c5dc4bfd8f7e17a21d301210367c e0a1c3b3e84cece6dad1a181d989d8e490b84f5431a1f778a88b284c935e6ffffffff0100f2052a 010000001976a9143744841e13b90b4aca16fe793a7f88da3a23cc7188ac00000000 ---------------------------- To use OP_RETURN, you need to recreate the above, but by hand without using bitcoind or anything. Here's a couple links to get you going: http://bitcoin.stackexchange.com/questions/3374/how-to-redeem-a-basic-txhttps://en.bitcoin.it/wiki/Protocol_specification#tx |
|
|
|
|
Show Posts
