 Show Posts
|
|
Pages: [1] 2 3 »
|
|
change can be sent using stealth too, there is no limitation about number of OP_RETURN, each one is working on the output next to it.
|
|
|
|
|
ok, several things:
first, the fact is the current mechanism's goal is that we don't need to do any communication between sender and receiver since otherwise we might as well communicate a new address.
so, having to scan all tx and having no way to pre-filter makes it unfeasible from the (light) client side, I have to scan all incoming tx and will have to calculate on all of them to make sure there is no stealth. with the other method, we just need to scan all tx but calculate just on OP_RETURN against the next output. also a matrix op_return, address can be generated to avoid needing to download that much data to scan.
so, having a stealth matrix in the server is a not requisite with the current darkwallet method (just helps for light clients), if you're willing to scan all tx then no need for server table, it just makes it more convenient. and also, even if you need to scan all tx you can still discard most as not having stealth, if they do we still dont need to calculate all in*out to make sure.
also little bug (i think), the mechanism how you avoid address reuse:
vout_priv = sha256((scan_pubkey + prev_hash + vout + index).decode('hex'))
maybe you want scan_privkey instead of pubkey there otherwise the secret is public...
|
|
|
|
...is not it a web implementation ?
Yes but at the moment it's focused on working as a browser extension. |
|
|
|
Is there any online implementation of DarkWallet, e.g. MyWallet of BlockChain.info ?
Not yet. We're aiming supporting more environments once the core implementation is more finished. |
|
|
|
I'd like to see a functioning prototype.
Then you definitely want to check out openbazaar because that's exactly what it is  Not sure about the current state, but it's been a functioning prototype since day one (I know because I am one of the original authors)... maybe you mean a "production grade software" that will take more time but it can't be that far. |
|
|
|
One of the DarkWallet developers, sem, has made the following module implementing bitid for mediawiki so it can be used as a login option: https://github.com/sembrestels/mediawiki-bitidSem has made a great plugin that allows linking different keys to a user account, and also revoking them, as well as login or create user from bitid in a way that is almost transparent for the user. You can see some screenshots of how the login looks: https://wiki.unsystem.net/en/index.php/DarkWallet/Alpha5#Annex_1._BitId_WorkflowWe have enabled it in our unsystem wiki (check the top right for the login option): https://wiki.unsystem.netAnd also is supported by the latest DarkWallet release (alpha 5) so the wallet will perform the necessary steps just a one click decission, and will manage the keys for logging into websites. Enjoy! |
|
|
|
Today we released DarkWallet Alpha 5 version. * Release notes: https://wiki.unsystem.net/index.php/DarkWallet/Alpha5 (A lot of details here) * Download: https://github.com/darkwallet/darkwallet/releases/tag/0.5.0The main features are bitid implementation and watch only pockets. Bitid allows to login into a website by signing a nonce offered by the website and posting it to the website. This links the website user to a public key controlled by the user, in this case a bitcoin key where they key is held by the dark wallet. At the moment we sign doing a hardened derivation over the host name so we get a deterministic key for the user, different for every site. We have made a module for mediawiki implementing bitid so it can be used against the darkwallet: https://github.com/sembrestels/mediawiki-bitidWatch only pockets allows configuring custom pockets by linking a contact and adding different addresses to that contact. Many more details in the detail notes above. Enjoy! |
|
|
|
Today we released DarkWallet Alpha 4 version. Release notes: https://wiki.unsystem.net/index.php/DarkWallet/Alpha4 (Important) Download: https://github.com/darkwallet/darkwallet/releases/tag/0.4.0Reddit thread: http://www.reddit.com/r/Bitcoin/comments/282mmn/darkwallet_alpha_4/This release brings automatization of multisig actions (see release notes) on top of our lobby/messaging system, as well as other small fixes, polishing etc. This release marks the end of implementing "big features" and will now focus on hardening, polishing, rearchitecting, documenting etc to bring the software to production quality. Beta starting to be in sight but not yet there. Thanks to all who donate, pull request, make issues, document, translate, test, etc, this wouldn't be possible without the community. Cheers! |
|
|
|
is there a doc of the actual protocol?
There are several layers involved (and also there are two ways to connect... websocket or zmq to the p2p cloud over python). The protocol is not fully defined, some things are documented in the links i gave you (the more specific can be the Trollnet and DarkWallet/Identity docs), others in the code... Right now, if you go the websocket way, then you use the chan_post and chan_subscribe ws commands as in https://github.com/darkwallet/gateway/blob/master/client/gateway.js. How the name and encryption, peering etc is done is now coded under https://github.com/darkwallet/darkwallet/tree/develop/js/backend/channels (we dont use btcchan.js at the moment which is a version using bitcoin encryption...). I will be reviewing the documentation soon so you (and us!) understand better everything. We now are more or less done with implementing functionality and will be refactoring, cleaning up and getting this into the beta stage. Also we can review and consider options about crypto primitives that we are using. |
|
|
|
Do you design it with a DoS prevention in mind?
That's definitely a must have, for a system like this - there will be a big money trying to break it.
Recently I was reading a bit about how darkcoin solved DoS problem for coin joining; they do it by taking a collateral from the coinjoin parties, so if any of them would back off he gets to pay for it. That's a smart DoS prevention idea, though I'm guessing people also came out with other solutions.
But going back to secured chats - they also need some DoS prevention, especially if the client code is in javascript.
We do think about dos protection and other attacks. For now we are doing a reference implementation that will be hardened for production, so we are trying to have something simple where parts can be replaced, for example the channel system could be replaced by something like bitmessage, irc or in some cases the bitcoin network itself (systems offering more guarantees). We will rather adopt systems with full teams dedicated to those problems than reinvent the wheel. On the same line coinjoin protocols can become more ellaborate and offer greater protection, anyways we will try to keep the modularity and flexibility. For now we rather have things running and people using it than waiting for the perfect system in face of threats that may not materiallize or people can avert in other ways (now people can switch channels for example). |
|
|
|
This is pretty much what we have in DarkWallet (about the op comment and also specifics described by piotr_n). http://coinjoint.info/dark-wallet-lobby-enables-secure-group-chat/https://wiki.unsystem.net/en/index.php/DarkWallet/Alpha3#New_lobby_featureshttps://wiki.unsystem.net/en/index.php/DarkWallet/Alpha2#P2P_gateway_channelshttps://wiki.unsystem.net/en/index.php/TrollNethttps://wiki.unsystem.net/en/index.php/DarkWallet/IdentityAlso openbazaar/darkmarket and our gateway's p2p network communication is building on similar concepts ( Trollnet document has more details). For now we have implemented this using a different elliptic curve system (25519) than bitcoin, but everything can be done with bitcoin addresses in the same way, we just preferred the system to be considered without the implications of actually using a bitcoin address as your identity, anyways there are ways to link the different systems using signatures so web of trust, registrations or public key queries can work on different systems simultaneusly (this is what we aim, to tie our communication anon oriented wot, the btc and gpg ones too). We have implemented some mechanics so peers can stablish links with each other in a similar way to what piotr proposes, calling them beacons and pairings (we also try to ensure identities never leak to untrusted parties). ( The Alpha3#New_lobby_features document describes the beacons and pair in more detail as well as private messaging, while the Identity document has more implementation details) The transport we assume is like an irc, although we don't need usernames since we don't ourselves identify users... that's all done client side. We also don't use irc atm since we needed to connect over websocket and irc is not specially suited for that, plus we had some operational/strategic benefits atm from using code openbazaar uses too and see where they go, and having the lobby together with other proxy services in our gateway (which is like kind of a bouncer too). Our main goal at the moment is using the lobby/chat for coinjoin and multisig interactions, but also allows for irc-like conversations and private messaging. |
|
|
|
Darkwallet does indeed implement coinjoin, albeit using a centralized matchmaking service to setup the mixes.
Just to clarify, we (darkwallet) don't exactly use a centralized matchmaking service, nor did we do at any point (as I would define it anyways). We did use a centralized matchmaking server in our first proof of concept on this thread. The current scheme works on top of any chat service, where we initially integrated a simple chat in our lobby and now it's the same lobby but the channels exist in a p2p network of all gateways so clients can connect to any gateway or gateways seed from any other gateway. You are right otherwise we don't yet use ring or blind signatures at the moment, so restricted to 2 party coinjoins, but the general design is done so we can (more or less) easily implement more complex coinjoin protocols. cheers! |
|
|
|
Ok we have fixed the issue in darkwallet git. The fix also is using a different api than proposed that also makes sure the point is encoded as 32 bytes, not totally sure it's required but probably is what we want, will double check that soon with genjix. https://github.com/darkwallet/darkwallet/commit/da6a084c3102bbaf50aabd1ba524f5365f27d7edWe also added some backwards compatibility code so funds in bad addresses won't be just stuck. Tried to make it in the most simple way and so the workaround can easily be removed later. Thx again for finding the issue and providing a fix. |
|
|
|
|
I manage the js implementation and genjix the sx one.
|
|
|
|
|
hey,
We agree the dw implementation is at fault, I'm going to apply the fix and think about some way so we can redeem old dw stealth funds too so I can take a bit to apply the pull request but will do it asap.
cheers and congrats on finding out the error!.
|
|
|
|
Anonymous bitcoin wallets are 99.99% scams the only for sure safe wallet is blockchain.
You do well to be careful but DarkWallet's model is more secure than blockchain.info (nothing bad to say about them). 1. DarkWallet is a browser plugin that updates respecting whatever policy you want on your comp, blockchain.info is a webpage that serves you scripts 2. With darkwallet you hold the keys in a way that you can use the wallet in offline mode, or not hold keys using multisig or in the future readonly. Again, don't want to compare with blockchain.info, they do a great service and we're still alpha, but please open your mind and read the docs we paste there is a lot of information: https://wiki.unsystem.net/index.php/DarkWallet/Alphahttps://wiki.unsystem.net/index.php/DarkWallet/Alpha2https://wiki.unsystem.net/index.php/DarkWallet/Alpha3The first one is a general detailed description of initial alpha status, the other 2 documents provide very rich details about what we have been working on for the last 2 weeks. So, our model is, it's not like we won't run with your coins, it's like we can't run with your coins since we don't hold *any* user data, keys or nothing at all. Also we can't just make a phantom update like say other webwallets could do and then deny it, all our changes are very publicly documented in git ( https://github.com/darkwallet/darkwallet) and our release procedure is strict where we sign our code releases (I do myself). cheers! |
|
|
|
|
