Pages:
Author

Topic: Let There Be Dark! Bitcoin Dark Wallet - page 7. (Read 50217 times)

newbie
Activity: 8
Merit: 0
November 22, 2013, 01:55:10 PM
You got my $
full member
Activity: 153
Merit: 100
member
Activity: 88
Merit: 10
November 22, 2013, 10:20:32 AM
I will donate for this project.
legendary
Activity: 1232
Merit: 1076
November 22, 2013, 07:45:21 AM
hey, that email is just a bunch of whining. I reimplemented Bitcoin because all the internal parts are highly connected. Your validation code is linked to blockchain, network and script subsystems. It was a purely technical decision. In the beginning (early 2011) I started by refactoring the Satoshi codebase (made Python bindings and improvements in a custom fork) but the entire thing is total crap and tightly coupled. I decided if Bitcoin is the future then we need a solid foundation to build upon. Rewriting Bitcoin from scratch by comparison is not a big deal in the long perspective.

his complaint is invalid. satoshi is not a god. we write code, improve the software and move forwards. Bitcoin is not some mythical codebase.

The blockchain is bigger since it is optimised for servers. I'm thinking primarily about scalability then performance. bootstrap.dat is supported thanks to Robert Williamson. I'm working on supporting luke-jr's eloipool but a lot of the mining stuff is new to me and I'm preoccupied with dark wallet this month.
legendary
Activity: 1008
Merit: 1001
Let the chips fall where they may.
November 17, 2013, 10:41:24 AM
Dark Wallet was mentioned in a "leaked" e-mail correspondence:
Quote from: John Dillon
Posted to the foundation forum,
https://bitcoinfoundation.org/forum/index.php?/topic/483-bitcoin-dark-wallet/page__st__20#entry5410
 
Dunno if you have a membership or not.
 
 
Quote from: Saivann Carignan

Patrick Murck said it in simple terms: The use of Bitcoin will (and is) regulated, not the Bitcoin protocol itself..

He's right, but the way he's right is not at all the way you probably think he's right: Bitcoin mining can and almost certainly will be regulated, and by regulating mining you regulate all use of the Bitcoin protocol.
 
The first problem is ASICs, specifically the huge gulf in performance per unit cost between commodity hardware, or even hardware possible to create on a small scale with FPGAs, and ASICs. The nature of IC manufacturing is such that a very small number of companies, about two to three, can afford the immense capital costs required to operate top-of-the-line chip fabrication facilities. Put another way, the entire world's economy is unable to support a diverse IC manufacturing industry at the current level of technological sophistication.
 
Control those chip fabs and you control mining. It would be extremely easy for the US government to tell Intel and TSMC that from now on any wafers they process capable of doing Bitcoin mining must include additional circuits that let the US government control how, and by whom, they are used. This is a problem in general with computing, but controlling the manufacture of a special-purpose ASIC is far easier and simpler, both technologically and politically, than controlling the availability of general purpose computing hardware. Fortunately it is possible to create proof-of-work algorithms where custom ASICs have less of an advantage over general purpose hardware, but Bitcoin itself isn't going to change the algorithm.
 
The second problem is bandwidth: the Bitcoin protocol has atrocious scalability in that to mine blocks you must keep up with the bandwidth used by all transactions. The current 1MB blocksize is small enough to make this not a major problem yet, but if you increase that (with a hardfork!) at some point you will have increased it to the level where you can no longer mine anonymously and then regulating miners directly becomes possible. Unfortunately while technological improvements have made non-anonymous bandwidth more plentiful, for anonymous bandwidth - or even just censorship resistant bandwidth - the options are much more limited. Jurisdiction hopping is an option, but even for the likes of The Pirate Bay it's proved to be a huge pain in the ass, and they only had the relatively small media industry as their enemy rather than the much larger banking industry. (and government in general) It does appear that you could make a crypto-currency with better core scalability - as opposed to the well understood and already-used ways to fairly securely transfer funds off-chain - but no-one's quite yet figured out yet how to upgrade Bitcoin itself with those improvements.
 
What's interesting is with good cryptography we've figured out ways to at least detect if miners are violating every other aspect of the Bitcoin protocol: some relatively small and backwards compatible changes to the protocol allow auditing everything miners do with peicewise audits done on low-bandwidth connections. If your wallet randomly audits 0.1% of every block, and there are a few thousand like you, the chance of fraud not being detected quickly approaches zero.
 
But auditing can only detect if miners fail to follow the rules of the Bitcoin protocol; it can't force miners to decide to include your blacklisted transactions in a block. If a majority of hashing power is under government control, there's no way we can prevent them from blacklisting whatever they want. Secondly, if the government does decide to change the rules of the Bitcoin protocol by fiat, then what? Suppose the Federal Reserve or equivalent decides that the deflation of Bitcoin is bad for the economy, and the coin distribution schedule needs to be changed. Or perhaps the courts decide that some stolen Bitcoins, that were subsequently lost, are to be returned to their former owners in an invalid transaction. They can order the majority of hashing power to follow new rules, and while you're wallet software may detect that fraud and shutdown, what alternative do you have but to "upgrade" it to accept the new rules? If you're transactions aren't protected by the majority of hashing power, you're transaction aren't secure.
 
Where Dark Wallet goes wrong
 
This is what bothers me about their efforts: I see no reason to think they understand any of the above. They're approach of making a ground-up re-implementation of Bitcoin is fundementally flawed, both from an engineering point of view, as well as a political point of view. What they should be doing is latching on to the notion that the core Bitcoin protocol is a fixed suicide pact that must only be changed with the true consent of all users. As step #1 they should have taken the Satoshi source code, stripped out everything that isn't directly related to that core consensus protocol, and turned it into an easy to use library. Only then should they have built a wallet/node implementation around that core, unchanging, protocol.
 
Where Amir Taaki and the rest of the Dark Wallet team go so very wrong is they don't understand that the Bitcoin specification is the consensus-critical part of the Satoshi source code. Instead they are pursuing a ground-up re-implementation, and like it or not, they're just not smart enough to get all the details right - nobody is. Because they haven't gotten the details right, no significant amount of hashing power is going to ever use their node implementation to mine with - what pool wants to lose thousands of dollars of profit just because yet another libbitcoin consensus bug was found? Of course, with no-one using their code to mine, they have no political power - Gavin and the Bitcoin Foundation's ability to control the core Bitcoin protocol is entirely based on the fact that almost all the hashing power uses the source code at https://github.com/bitcoin/bitcoin
 
On the other hand, if even just a quarter of the hashing power used the Dark Wallet node implementation, and could trust it because the !@#$ thing actually implemented the Satoshi protocol properly by using that protocol's source code, changing that protocol in fundemental ways would be far harder - Dark Wallet would have a lot more genuine political weight. With hashing power using that implementation, they would be able to implement their own rules for relaying transactions. For instance while much of the community complained violently about the 0.8.2 dust rule, which made it far harder to get "dust" outputs mined, if the Dark Wallet team decided they didn't like that rule and had hashing power that trusted their node implementation, they could make the rule irrelevant. They could even come up with a anything-goes mechanism with no rules at all governing what transactions got relayed, and let individual miners make those decisions.
 
If I were the US Government and had co-opted the "core" Bitcoin dev team, you know what I'd do? I'd encourage ground-up alternate implementations knowing damn well that the kind of people dumb enough to work on them expecting to create a viable competitor anytime soon aren't going to succeed. Every time anyone tried mining with one, I'd use my knowledge of all the ways they are incompatible to fork them, making it clear they can't be trusted for mining. Then I'd go a step further and "for the good of Bitcoin" create a process by which regular soft-forks and hard-forks happened so that Bitcoin can be "improved" in various ways, maybe every six months. Of course, I'd involve those alternate implementations in some IETF-like standards process for show, but all I would have to do to keep them marginalized and the majority of hashing power using the approved official implementation is slip the odd consensus bug into their code; remember how it was recently leaked that the NSA spends $250 million a year on efforts to insert flaws into encryption standards and commercial products. With changes every six months the alts will never keep up. Having accomplished political control, the next step is pushing the development of the Bitcoin core protocol in ways that further my goals, such as scalability solutions that at best allow for auditing, rather waiting until protocols are developed, tested, and accepted by the community that support fully decentralized mining.
 
Dark Wallet has the opportunity to make the very idea of the "core" Bitcoin dev team irrelevant. But sadly Amir's lot seem to understand the art of PR a lot better than the political science of decentralized consensus systems.

The take-away is that to have real political power, libbitcoin (and btcd) must be in use by a large portion of the hash-power. In order for this to happen, at least one implementation using libbitcoin must be bug-for-bug compatible with the standard bitcoind. At the very least, it should pass the same regression tests.

Before running this as a miner I would like to know:
  • How much extra space (if any) is needed to store the block-chain in this implementation
  • Is bootstrap.dat supported?
  • Extra CPU time for block verification may increase the orphan rate: the multi-threaded design may mitigate that on systems with many CPUs.
  • I plan on mining namecoin and using P2Pool. It would be nice if those (and other alt-coins) were ported to libbitcoin as well.

Edit: for the ASIC thing, there is always 110nm chips Tongue (not sure how small the independent fabs can go)
hero member
Activity: 644
Merit: 500
P2P The Planet!
November 17, 2013, 09:02:31 AM
So this is how it will work.

Blockchain.info for person to person and online transactions
DarkWallet for silkroad
Coldstorage for saving and very big transactions


I'm hoping however zerocoin will be eventually implemented into bitcoin.
full member
Activity: 182
Merit: 100
November 15, 2013, 02:10:45 PM
If anyone wants to come participate in development, you're more than welcome.

https://wiki.unsystem.net/index.php/DarkWallet/Meeting_Nov2013

This is the event for starting everything. We have more public talks in the first week of December, and spaces if people need a place to sleep (although it will be quite busy). If you have a proposal for a talk or need a bed then send me a PM. Feel free to visit if you're around.

Our mailing list:

https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem

I'm not a real developer, but would it be ok if I checked it out?
sr. member
Activity: 337
Merit: 250
November 15, 2013, 12:30:19 PM
#99
I'm not donating even a satoshi until I see some work.
legendary
Activity: 1722
Merit: 1217
November 15, 2013, 12:28:02 PM
#98
can someone explain to me what would be the purpose of incorporating tor? what benefits would that offer that wouldn't already be achieved by coinjoin?
legendary
Activity: 1232
Merit: 1076
November 15, 2013, 12:23:00 PM
#97
If anyone wants to come participate in development, you're more than welcome.

https://wiki.unsystem.net/index.php/DarkWallet/Meeting_Nov2013

This is the event for starting everything. We have more public talks in the first week of December, and spaces if people need a place to sleep (although it will be quite busy). If you have a proposal for a talk or need a bed then send me a PM. Feel free to visit if you're around.

Our mailing list:

https://mailinglists.dyne.org/cgi-bin/mailman/listinfo/unsystem
sr. member
Activity: 378
Merit: 325
hivewallet.com
November 14, 2013, 10:00:15 PM
#96
Dark Wallet Certification proposal:

Ref: Let There Be Dark!

Greetings from Bitcoin Singapore!

Hive will be attending unSYSTEM's DarkWallet meeting in Milan on the week of the 24th. We propose that the outcome of this meeting be, at minimum, the establishment of a v1 "Dark Wallet Certification", a set of best-practice guidelines for wallets focused on decentralization and anonymity.

This topic is has been opened in order to get the community thinking about what exactly a "Dark Wallet" should be: We assume the use of Tor, CoinJoin, CoinSwap and other such developments. We assume the lack of centralized services wherever possible. We presume that we can evolve ideas about authentication (see the work of John Light, Joe Casico etc)... Still, our ignorance is vast and we would like to come armed at this meeting, with your feedback.

What ideas or thoughts do you all have?

https://bitcointalksearch.org/topic/dark-wallet-certification-334241
legendary
Activity: 1204
Merit: 1001
RUM AND CARROTS: A PIRATE LIFE FOR ME
November 14, 2013, 08:18:40 PM
#95
did I hear on lets talk bitcoin that there is going to be some launching event in Milan for Dark Wallet?



Planning event.

Milan, italy?
sr. member
Activity: 378
Merit: 325
hivewallet.com
November 14, 2013, 06:41:51 PM
#94
did I hear on lets talk bitcoin that there is going to be some launching event in Milan for Dark Wallet?

Planning event.
full member
Activity: 182
Merit: 100
November 14, 2013, 05:44:51 PM
#93
did I hear on lets talk bitcoin that there is going to be some launching event in Milan for Dark Wallet?
member
Activity: 84
Merit: 10
November 14, 2013, 03:39:40 PM
#92
- You tolerate a dangerous, rather-much-extremely-more-extremely-more-mentally-ill-than-Amir-or-me beast like luke-jr

I'm curious, what's wrong with luke-jr?
legendary
Activity: 1708
Merit: 1019
November 13, 2013, 01:56:40 PM
#91

Vote for Dark Wallet as your favorite Bitcoin Project of Autumn 2013

Only KNCMiner has more votes as of now.
legendary
Activity: 1526
Merit: 1129
November 07, 2013, 09:20:31 AM
#90
OK, good to hear that.
newbie
Activity: 44
Merit: 0
November 06, 2013, 01:32:26 PM
#89
Regarding bloom filtering you say:


So they take a giant dump on Bloom filtering - which I proposed and partly designed to solve this very problem - then it turns out that their "Obelisk server" doesn't have any alternative solution. It has a cool name but no solutions to difficult privacy problems. So in fact your privacy is much better protected by using the regular P2P protocol, talking to the regular P2P network and uploading a noisy Bloom filter (or sharded set of noisy filters). Too bad Amir regards that scheme as impure, rushed and a "debasement", otherwise he could just use it in Dark Wallet.


We don't discard bloom filtering altogether.

We have discussed about it, but are unsure about using it and would like to investigate other solutions. The zmq encryption is only so good to protect communications with the servers or other clients, but I'm not sure we can use bloom filters in all situations, also I'm not sure they really provide so much privacy unless used with other deniability or  practices to make sure information is not leaked because of for example how you use the program or other patterns that could be traced to de-bloom your transactions.

Anyways that kind of privacy is very important for us, and will make a client taking these things into account. We're making a client (and architecture) that will *care* about your privacy, but want to have some leads open for exploration, like darknet or onion routing... we're making a client here so can think a bit out of the box.

We're making a wallet that knows big brother is out there looking for you, we won't be so dummy as to think the only enemy is the user or the server, you know what happens when you don't make those assumptions.

Also mind that this is not just Amir working here, we have a lot more minds that thanks to this crowdfunding will be focusing on those problems.
full member
Activity: 153
Merit: 100
November 05, 2013, 12:22:39 PM
#88
NSoogleA

That aggregation didn't really work.
Lol I know, but could not find something else!

But the idea behind and the question is real good...

America is out of controle!

For what it's worth: https://plus.google.com/+MikeHearn/posts/LW1DXJ2BK8k
legendary
Activity: 1204
Merit: 1002
Gresham's Lawyer
November 04, 2013, 06:01:55 PM
#87
Interested but not investing... yet.
I wish you every success.
Pages:
Jump to: