Oh, cool!  Ya, it looks like there are some strong parallels.

I being so vocal in my opposition to using small transactions on the Bitcoin network proper as a messaging system, I envisioned voting being implemented by signing messages with the private key.

I also have struggled mightily with ways of avoiding needing to trust the operator(s) of the secure systems which hold funds, or basically any entity which has the theoretical capability of absconding with a lot of funds from a lot of projects at one time.  A significant bond and a time-lock system which allows control of only one storage system at a time with a delay between them is one possibility.  So, say I owned the escrow company and set up a secure platform for each of a bunch of projects.  An external auditor/escrow person could perhaps control my ability to access each vault system (though said person could never access the vaults themselves or at least not with a lot of cooperation with others.)

Seems like "The biggest no-brainer in the history of mankind" (to quote a radio ad playing in my area) to ship in the order in which funds were deposited once to call for funds went out.

Now, it is true that I happened to be on-line and was, I believe, the second to put my money where my mouth was.  Ironic because I don't even expect to mine with the thing and have no pressing need for it.  In fact, I don't know if ~arklan has sold my device to someone else or not based on my earlier protestations.  I also don't really care to bother him with with information here since I currently feel happy enough to find out by checking my physical mailbox.

The question we are currently struggling with is (imo) related to the makeup of 'peers' in the system.  Quantitatively and qualitatively.

Your attempts to map this issue to broad political philosophies feels strained to me.  If anything, it is mainly a 'tragedy of the commons' type situation which is a concept laying in a somewhat orthogonal plane.

That said, my current preference is to provoke significant fees and see how things play out in the 'capitalist' mode.  This because I strongly favor and continue to see it possible that Bitcoin falls into a 'reserve' roll and leaves the heavy lifting of supporting a fair fraction of the world's exchange economy to a expanding set of dispensible solutions.


I think it is pretty fair to characterize this as a self evident and provable reality.  I'll take a second look if/when block chain pruning occurs.

Thanks for the comic relief afforded by your sarcasm.

Actually, I imagine that the core dev members, or at least certain of them, see the same value in SD that I do.  Namely, as a load generation tool capable of facilitating edge case analysis earlier than otherwise likely.

SD was almost single handedly responsible for helping discover the BerkeleyDB mis-configuration long before it otherwise may have been...and by an operator who was willing to work pro-actively to resolve the situation at expense to himself.

SD will also be responsible for understanding the impact of transaction fees on the economy and thus allow a better decisions to be made about how a design might best leverage that resource.

I have no info specifically, but I would suggest that generally speaking things which make a solution available to anyone with the capabilities which don't exceed your own, but come close to it would be considered less of a bug and more of a feature.  ...and Google has capabilities matched by very few.  I suspect that such entities could also derive business intelligence information from network analysis which would allow them to subsidize the operational aspects of operating the solution.  Much as they do with e-mail.  Such an intelligence value-add would be denied completely to lesser players.

I've worked with systems that generate data with no thought put toward clean-up.  By their nature, they never reach a state of equilibrium and become increasingly challenging to deal with.  Often they eventually lock up or collapse absent an overhaul.

Whether real or imagined, I was impressed by what seemed to be a concept of pruning the block chain which could potentially address some of the problem of bloat (though I always suspected that a determined attacker could subvert this more easily than something like the double-spending protection.)

Also, I thought I picked up on a concept of relay fees which would potentially keep verifying relay nodes (e.g., bitcoind/qt) in the game.  I went back a year ago or so and am pretty sure I found it again.  But it's buried and seems rarely discussed.  It could be argued that 'that is only for mining pool operators' I suppose.  And would anticipate mining pool operators making that argument.

I have heard pleas from dev to 'run a full node' (which, in my mind, conflict with the lack of focus on efforts to lighten the burden of doing so.*)  I had a chance to chat with Garzik briefly at the conference to obtain more information on this.  It might be noted that if one does not also hear a corresponding plea to 'punch a hole in your firewall', it was neglected for lack of time to explain.  Perhaps unfortunately, my bitcoind build seems to work fine without being accessible.


(*) not completely true.  The LevelDB and Bloom filter work helped immensely, although I sense that it was driven in part by a pressing need to simply keep the system operational and thus alive for long enough to get some more centralization in place.  And this without even barely touching the supposedly absurdly low 1MB block size limit and being less than 5 years into what is supposed to be a durable financial solution which people can rely on with significant funds.

It would be foolish not to assume that all website activity is not logged on any web site visited whether it is the case or not.

And if there is one silver lining to the absolutely appalling level of theft and loss which permeates the Bitcoin ecosystem it is that it provides a very robust level of plausible deniability should anyone come looking for a person's BTC

Essentially that, yes.  I'm bummed out that it takes so much overhead already that users (including my friends) are discouraged from running a full node.  In other words, are no longer reasonably capable of being 'peers' the the supposedly 'peer2peer' solution.  That lie is finally starting to be deprecated it seems...years after I suggested that it might be intellectually honest to start doing so...  Anyway, the issue will only get worse when they need to process data for everyone who wants to use Bitcoin as a reliable messaging and storage solution.

It does seem that there is a significant overlap in the groups of people who bitch most loudly about the fees/block size are they who are all ga-ga about colored-ish utilization.

Thx for the info.  Looks like by simplistic linear extrapolation one would be lucky to get 5 MH/s out of an available cyclone or spartan-6 powered by a USB.  In the ball-park of CPU mining (though much more efficient at least.)  ...For sha256...

This kind of order of magnitude estimation is all I really need at this point.

Another potentially interesting device would be one powered by PoE.  It might be convenient in some applications.

If I have to sit through one more presentation which starts out with a history lesson about 'first, humans used barter, then blah, blah, blah' I swear I'm going to puke.  I walked out of at least one presentation at the start for this reason.

About the only thing which is more annoying is when a person asking a question takes 5 minutes of everyone else's time to describe how much they want to suck the presenter's dick or whatever.  Sometimes they don't even get to the question at all.


Of course.  Everyone likes a free lunch and sees a way to get rich by sponging off the work of others.


I missed Boussac's presentations being more interested in the tech end of things, but got a chance to catch up with him in person.  Paymium either bought or was given coins that I entrusted with ~jav, then either lost or stole them.  This gave me a good reason to wish to meet him.  Pleasant conversation in spite of the misfortune though.


I didn't meet up with him this time, but I've met him in the past.  I'm still waiting for an answer to my question about what he would do if the government 'just said no' to Bitcoin.  No danger of figuring that out at something like the conference though so I was not to surprised.


Didn't get a chance to say 'Hi' to Erik either, and kind of wanted to since we worked on a minor project in the distant past.  As for being 'thoughtful', if he had done anything more than regurgitate Austrian school hokum and bunkum I'd be shocked.  Again, I found more interesting things to see so I missed his stuff.

---

My favorite presentation was Eli Ben-Sasson's thing.  I can see a large number of places where the work could be applicable to distributed-crypto-currency-like systems and tangential tasks.  I'll be looking forward with great interests to developments in his team's work.

Recently I was part of a group buy and was thinking of ways to automate things.  This led to the following rough outline:

 - an organization employing a number of escrow agents who's qualifications are advertised.

 - a 'job' would assign one of the escrow agents and he/she would work closely with the client (project owner) to obtain identity information and familiarity with the task.

 - project participants (who cough up funds) would fund individual green addresses which they retain access to.  They could withdraw their support at any time by withdrawing funds (making this an unusual escrow...'youscrow' and 'yescrow' and 'mescrow' domains were taken   Communications about participation and decisions would be understood by simply evaluating the funding level green addresses.

 - The project owner would propose a funding need by a vote and the results would be weighted in relation to how much funding each participant had.

 - Funding would be obtained from the participants account by a scripted operation.  The escrow agent would evaluate the votes and execute the script to transfer funds.

 - The escrow agent would probably have to obtain cooperation from another escrow agent at the 'office' in order to execute the script.  A reasonable number of escrow agents could execute scripts absent the primary agent (to avoid hit-by-a-bus accidents.)

 - The addresses would probably exist on a very secure system where only script execution was allowed (no logins, for instance.)

 - The entire escrow company would be backed by a bond which was sufficient to cover the costs of accidents to any one of the underway projects (loss of secure machine or some such.)

Such an elaborate setup would probably be overkill except for expensive and complex projects.  The project I had in mind was related to commissioning the development, production, and delivery of a new piece of hardware.  If anyone wants to steal the idea, or parts of it, please do.  I'm much more interested in using such a solution than in working on development of it.

I should probably have clarified that what interests me is the ability to hop between multiple hashing algorithms, including currently unknown or undeveloped ones.  Performance is nice of course, but a secondary goal.  Obviously ASIC is not suitable for such an effort though of course the would hammer the shit out of FPGA in an 'application specific' role.

As I understand things, there are a multitude of FPGA's of different capabilities.  Many devices have them, and I figure that most of them could be programmed for a lot of different duties.  Some hashing algorithms are designed to be inefficient on such devices of course.

---

I'll doubly-up this post and thank ~tabbek for the link to the 'mojo' board.  It's interesting and along the lines of what I was thinking.  I did not expect a spartan-6 to be applicable (powered by USB current at least.)  It does give some info on the type of support which a spartan-class chip might require.  A chart I found indicate to me that some spartan-3 might be in range from a power consumption perspective, but my knowledge of the stuff is only barely sufficient to make some rough guesses about this.

I'm inspired by the Bitfountain BE and Klondike drawings for USB thumb-drive form factor ASIC devices.  I'm wondering if there has been any discussion of the same thing for FPGA that anyone can point me to.

If not, I'm hopeful that those with like interests and more knowledge about it than I can theorize or point to information on suitable FPGA chips which meet the power requirements?

What kind of chipset support might be needed to make the thing brick-resistant (or hopefully brick-proof) or operate at all for that matter (aside from the obvious USB support)?

---

My interest along these lines is stirred in part by Kaminski's comments at the 2013 conference, but I could imagine applications for various other goals than mining Bitcoin.

Ripple had a seat on the 'alternate crypto-currency roundtable at the 2013 conference.  I didn't see anyone holding a gun to their heads.

No matter where it happens to be filed, I would not mind it it were open-sourced one of these days.  Relatedly, I wish to know the underlying architecture so I can make my own decisions about robustness, scaling, centralization, and that sort of thing.  A 'start with all and subtract' scheme was something which hit me some time ago as a means of mitigating against certain kinds of scaling issues.  I'm academically interested in knowing whether Ripple has the same basic goal with this design.

It's actually probably a bit dumb to say anything about one's BTC storage methods...and a bit rude to ask.

That said, I've spouted off about my techniques off and one.  Now I regret doing so to some extent.

Thanks for the pics!  Time for people to get busy with Facebook and Google's helpful and fun 'pin a name on this person' UI.  I can imagine it being very handy in rounding up the thought criminals who threaten our security and way of life at some point in the future, so please do your part!

Seriously, I was surprised at the dearth of anonymous masks at the event.  The only one's I saw were those dancers.  What a difference a little growth and the hopes of making some money brings!  I guess the more paranoid (or perhaps simply more careful) Bitcoiners stayed home.  For my part, I happened to be in the area to finally terminate my job and could not resist the temptation to attends.

The initial report seemed a non-issue to me personally, but it had the effect of reminding me to move some value out of Instawallet.  Due to BTC valuation rise, my 'spending money' value had gone from $100-ish range to multiple thousands and I had not gotten around to re-distributing it.

So, I can thank the original reporter for halving my losses (in the event that they turn out to be total losses come July or whatever.)

I do suspect that I was not alone in removing funds from Instawallet.org.  The attacker (be it an insider or external party) may well have been in possession of the database and the URL's for some time and was waiting for an opportune time to capitalize.  It would make sense for the attacker to sit on his hands while money was flowing in the inward direction.

It also would make sense to choose an attack time when the hot wallet(s) backing the solution were well funded.  If the operators got tired of transferring cold storage to hot wallets (which, one would hope, would be a tedious task) they make have picked a fairly high value in light of the outflows of which I was a part.

One way or another Paymium was in the best case negligent not only in operating a system which was exploitable (and I understand that very skilled attackers were probably working on it) but separately in that they put enough funds at risk to call into question their solvency.  The latter was a novice mistake in my opinion.

I had a pleasant chat with Boussac at the conference which I will outline later on a more appropriate thread when I feel like it.

All of the panelists were plenty bright enough to the various sides to the issue.

Taint/tarnish is a really compelling mechanism to address the theft issue.  I strongly feel that it is a siren's song though and was surprised at how strongly most of the panelists embraced the idea.

One of them mentioned the issue of centralization aspect of tarnishing authority (as a problem.)  With enough engineering and complexity, I suspect that that could be distributed, but that is only one small issue to me.

A bigger issue is determining what, exactly, constitutes a theft.  It's not so easy.  If I gave someone else coins and felt like being a dick, what's to stop me from claiming they were stolen?  Who's going to fund the investigative efforts to track down the legitimacy of the millions of 'thefts' both real and invented?

Secondly, many legitimate thefts go undetected for a fair period of time.  Are we really going to place the burden of constantly checking balances in order for thefts to be discovered within some window or whatever?

Then there is what I am sure will turn into a very real attack vector (state level) in using the taint system as a chock-point for other projects.  Does a coin become 'tainted' because a citizen of Iran person touched it?  I'll bet it will.

Very sticky issues, and I am pretty confident that this way lie dragons.  I'm sure it has been discussed ad-nausium, and the panelist's reaction to the question will spur another round.

(By way of being constructive, I'll pump my idea of Bitcoin migrating to a 'reserve' role where the holders are on balance well prepared to take care of their holdings and thus reduce theft to a tolerable level.)

I also.  It was a somewhat jaw-dropping statement and one of the most interesting things I saw at the conference.

I cannot imagine such a change of this magnitude in this timeframe on the basis of a theoretical weakness (i.e., non-exploited semi-monopolization of hashing hardware.)  I can think of a number of hypothesis, but won't outline them until I can find the most appropriate thread (stumbled here via a Google search.)

My best case scenario is that Kaminiski simply felt that nobody in core dev has put the appropriate effort into conceptualizing how such a shift might be engineered (were it necessary) and was hoping to light a fire under their asses.

I did, and I will tomorrow as well.

Like I've said before, a healthy and active solution of off-chain activity would provide the necessary user numbers to give the protection you (supposedly) seek.  Any regulatory attacks are going to be a broad enough brushes to impact all such economic activity.  You seemed to have no answer for that.

I also said back in 2011 that a viable way to attack Bitcoin might actually be to either leave it alone or foster it's growth and let it burn itself out (or mutate away it's peer2peer nature) due to uncontrolled growth.  The relative lack of molestation and surprisingly positive media attention that allowed/facilitated growth over the last few years makes me wonder if that was not a course of action chosen.  The likes of Chuck Schumer have been interestingly mum since their initial burst of verbal diarrhea.

Again, I see a light and highly distributed core value system with a myriad of off-chain solutions of different postures as being a pretty hard whack-a-mole problem to attack on a sustained basis.  Which is why it appeals to me.


I don't see it as crippling in the least.  Nor do I see a lack of room to grow at our current settings.  On the other hand, the fantasies of a one-world currency that are everything to everyone are almost certain to end in tears as I see it.