Search content
Sort by

Showing 20 of 25 results by MrFlibble
Post
Topic
Board Bitcoin Discussion
Re: Please Don't Shovel Unrelated Crap Into Bitcoin!
by
MrFlibble
on 08/12/2010, 17:21:39 UTC
I think it would be prudent to do as much as possible to prevent integrating other systems into bitcoin.

Yes. Merely not implementing feature requests in the core is a good start; although new tools to do the same in better ways (pooled mining springs to mind) should be allowed to prove their worth.

I would like to hear more about removing the scripting.

Quote
If you want to do some freaky shit, just start another blockchain.

Nooo!  We want all the miners on our one chain, to maximise our security.

I think we can have our cake and eat it.
Post
Topic
Board Bitcoin Discussion
Re: Please Don't Shovel Unrelated Crap Into Bitcoin!
by
MrFlibble
on 08/12/2010, 03:55:57 UTC
I think Bitcoin can do this already, with [...] no scripting and minimal data in the blockchain.

Erm, quick tech-check: the "message" one can add to a transaction, is that stored in the scripting area?

If it is, and you need to get rid of it, maybe there's a way to use the bitcoin addresses as a nonce to secure the external service?  Publishing sign( nonce concat hash( latest_database ) ) should be almost as good...  it's might be easier to pin the external service in time by silencing the publication of the signature?
Post
Topic
Board Bitcoin Discussion
Re: Please Don't Shovel Unrelated Crap Into Bitcoin!
by
MrFlibble
on 08/12/2010, 03:46:45 UTC
(I voted no.)

Let's cut this down to the core of what is wanted here:  [...] some sort of distributed public database with some kind of cryptographic controls to both timestamp, certify that the information has not been tampered or modifed unless through proscribed rules and protocol, and that effort to store the data be associated with Bitcoins so far as charging for either access to that database or more importantly to put information into that database.

That is my understanding.  I think Bitcoin can do this already, with no bloat in code or protocol, no scripting and minimal data in the blockchain.  I wrote about it over on https://www.bitcoin.org/smf/index.php?topic=1938.msg26342#msg26342 but maybe not very clearly (please ask if interested).

Bitcoin provides timestamping.  If you make a transaction which includes (e.g.) a sha-256 of some data then it becomes part of the timestamped chain.

Other systems must maintain their own sets of data (monotonic chain or otherwise) with their own P2P system and rely on Bitcoin only to timestamp it, and prove a simultaneous spend of >= 0 BTC.  The reason to use Bitcoin this way is to avoid fragmenting the proof-of-work effort, which benefits only the cheaters.


Quote
The perception and growing consensus is that the only way to accomplish this task is to shove it all into transaction blocks.  If you can find another solution to this problem, I'm totally open to a solution.  The best alternative is a separate block chain and hence independent currency which as creighto and others have suggested is not likely to succeed.

My suggestion would put a small amount of data into a small transaction.  The txns to do this will include fees to get into the chain regularly and promptly - maybe the transaction consists only of fee?  Heavily used systems might want a timestamp every 10 min, so that makes one txn per external service per Bitcoin block.  Aggregating these into one txn per block looks like a service the market might provide.

This is not taking charity from the original Bitcoin, but buying a service from the miners.  The only extra requirement is 32 bytes of message on the transaction; I think this is necessary for purchasing from an online retailer anyway.
Post
Topic
Board Bitcoin Discussion
Re: bitcoin://
by
MrFlibble
on 08/12/2010, 02:51:24 UTC
You guys are over my head...  but rather than the Bitcoin program needing to be running 24/7.....

If you're including me there, sorry.  I can try another explanation or answer some questions?  (But my IRL-lag may be high.)

I don't think bitcoind needs to be running.  The mimetype has an app to handle it, call it bitcoin_pay_gui (or plain bitcoin with some option flags).  When this starts it needs to check for a running bitcoin(d) and talk to it, else start one or do the operation itself.

To make the payment, ideally you have the latest block so you know your balance (yes?) but in cavalier mode you could issue the transaction on old money without checking you still own it.

Then the app should probably hang around to see some confirmation, or failures, and notify the user.  After this it can quit if nobody needs it.


Quote
What if the link opened the web-based MyBitcoin.com... inserting all the proper fields into a Send Money page....

Hmm, if the browser says it Accepts:application/bitcoin-payment-request then mybitcoin.com is irrelevant, but if it doesn't (very likely) then it's certainly worth putting a suitable link in the "page you get before it just gives you a file you can't yet deal with".  I'm not sure this is what Accepts: was intended for...

Presumably mybitcoin.com could usefully fetch & process this mimetype?  This seems less useful than a multi-format spec of standard keys & values to send when requesting payment from someone..?
Post
Topic
Board Marketplace
Re: Margin Trading
by
MrFlibble
on 07/12/2010, 00:41:11 UTC
The bid will be put automagically by Mt. Gox whenever someone do this kid of trading.  The price isn't going to fall below that bid until everything has been bought at that price by someone.
That's not foolproof. If there is a big bubble and it bursts, [...]

If the market is volatile, third parties may spread their BTC purchase offers thinly down to quite low prices...  making it more likely there is insufficient depth to cover the trader's loss?

At this point we are beyond my economicsfu, but...  if the broker holds some of the trader's USD, is he not better covered for drop in the BTC price?  Compared to holding some BTC and trying to sell them in time to avoid loss?

Could someone post a worked example perhaps?  Including profit, loss and disastrous loss modes?
Post
Topic
Board Bitcoin Discussion
Re: bitcoin://
by
MrFlibble
on 06/12/2010, 23:01:58 UTC
I've been lobbying for the mimetype solution.

+1  (populism != sanity)

The bitcoin: URL scheme makes sense by analogy to mailto: but


Quote

Cool!

I have cooked up an email version,
  • One encrypted email from Bob to Alice requesting payment and attaching your file.
  • Another mail containing a copy of Alice's GPG keys so you can read the first mail.
  • Currently for the benefit of those happy to download and open an mbox file.
  • I suggest moving your ~/.gnupg/ out of the way while trying it, to avoid accumulating the cruft key.


Also may I suggest from my armchair,
  • The message file looks quite minimal.  Can you put up a bells'n'whistles example with more fields, such as
    • Suggested txn fee.  If it took the form of a range it would allow newbie customers to exercise discretion with an "express payment .. cheapskate" slider bar...  but still be only a request or recommendation.
    • a nonce or id, to be recorded in the wallet.  This allows prompting "You paid this request on yyyy-mm-dd and it was confirmed an hour later.  Do you want to pay it again?"
    • a suggested txn message (how big are these? just an id?)
    • a symmetric key (reuse the nonce? take 20 bits as the nonce and bin the rest after a week?) to encrypt the txn message, because it is public
    • state how many confirmation blocks the merchant will wait for.
    • Some X-Foo: headers to show extensions.  X-Face: raises the issue of phishing...
    • dates...  bill issue (now) date, due date, request expiry date?  But I guess we don't want to re-invent the B2B monstrosity.
  • It might be good to include some characteristic magic string, so file(1) can guess the mimetype.  I don't know a good way to do this.
  • How would the merchant sign the payment request in a way that makes it clear what is being bought? Should the request contain mime attachments or be included in a multipart/mixed ?
  • How does the txn message make it irrevocably clear that the payment is in answer to this request?  Suppose it ends up in court after wrong goods are delivered - customer has the offer to treat in the form of (( self-contained inventory HTML+images of shopping cart contents; request for payment; merchant signature )) and there is a public payment in the blockchain with a message identifying that request.
  • Can the request delivery to existing browsers be improved with mime Accepts headers?  (I haven't dabbled with this aspect of the HTTP spec.)  Is it good for browsers to advertise acceptance of the payment-request type?

HTH,
Post
Topic
Board Development & Technical Discussion
Re: Bitcoins sub-nets
by
MrFlibble
on 03/12/2010, 03:50:43 UTC
[...] your clients would have an account on your server, and they could change their balance into bitcoin when it reaches a significtive amount, or on a daily basis.

It makes sense to use two systems, each to patch the shortcomings of the other.

Also if clients make a 1BTC deposit (escrowed, if there is no server?), they can go "in debt" in the microcurrency without being overall in debt.  This way you don't need CAPTCHAs or trust mechanisms to stop hit'n'run bad debts.


Another idea might be to make a mini-BTC-style currency.  AIUI, Bitcoin's neat feature is using the proof of work to enforce one linear timestamped history, and thereby prevent double-spending.  You could benefit by hanging your linear coin-spend history off this,
  • use "mini-blocks" in your world to log the transfers between IDs.  The full anonymous wallet private key thing is optional, but the owner must sign the transfer.  Presumably your world already has IDs?
  • choose a "mini-block" creation rate.  I think it can be less than 10min, as well as 1:1 or greater delay; but there will always be the Bitcoin multi-block confirmation time if you need to know for "certain" that history is locked down irrevocably.
  • publish the mini-blocks, and put the hash of the top of your chain into Bitcoin's chain..  by moving 0.01BTC.
  • you might be able to run on free transactions for this, but otherwise the N participants must spend 0.01BTC/N per mini-block history lockdown.  At 1BTC/$0.25 that looks like $1.30/year for N=100 people and 1:1 miniblock:bitcoin sync.

This way you're not sucking CPU out of the main Bitcoin network, just making a small contribution to its running for the small service you need (timestamping of hashes).
Post
Topic
Board Economics
Re: Should money have intrisic value ?
by
MrFlibble
on 03/12/2010, 03:28:06 UTC
I know that I'm being anal here, but money and currency are not the same thing.

Currency = small physical money tokens (coins & notes).
Money = more general concept of spendable stuff including currency and credit.
(My summary based on http://en.wikipedia.org/wiki/Currency and http://en.wikipedia.org/wiki/Money )

Then I'm really confused, because money requires an intrinsic value by definition.

I'm not sure about that.  Which definition?

I thought money's main necessary properties were
  • Mostly conserved.  Sure you might lose some if careless, but you can't duplicate it (double spend, shaving the edge off gold coins, counterfeits).
  • Like currency, needs to be transferred around in useful-size easy-to-validate denominations without too much inconvenience (= cost).
  • Scarce.  Hence, in part, the Hitchhiker's Guide joke about using leaves off trees as money?  I put it last, but I suspect it is of primary importance.

Various forms of money have problems,
  • Consider diamonds & rubies as currency.  Now they can be made (some would say counterfeited) industrially it is very difficult to justify or enforce a high price for the ones coming out of mines.
  • Consider the popular electronic fiat money forms - credit cards and paypal.  The inconvenience here seems to me to be running quite high (~5% per transfer).  How this compares with the old days of shipping gold coins on horseback, I don't know.
  • Gold is nicely scarce.  Fiat money less so?  Of course some people have not enough to live, but others make (!!) oodles of it.
Quote
However, it might be lost in translation because based on this thread, many don't understand the word "intrinsic".

Actually I'm skeptical about "intrinsic value" of any object, it seems to be an oxymoron; but grondilu tweaked the question.

Does money need to be useful for something else?  I suspect not, but back when money was just currency the options were more limited.

As kiba said, gold is good for decoration & its physical properties.  If it wasn't useful, we wouldn't work so hard to dig it out; but if it's not hard work to get some more, the "scarce" property is absent.
Post
Topic
Board Development & Technical Discussion
Re: RFC: ship block chain 1-74000 with release tarballs?
by
MrFlibble
on 03/12/2010, 02:09:04 UTC
I tested it on a slow 7 year old drive, where bandwidth and CPU were clearly not the bottleneck.  Initial download took 1 hour 20 minutes.

If it's taking a lot longer than that, certainly 24 hours, then it must be downloading from a very slow node, or your connection is much slower than around 15KB per sec (120kbps), or something else is wrong.  It would be nice to know what appears to be the bottleneck when that happens.

My ~24hr download was to (cheap) Compact Flash in a PATA adapter, with a ~4 Mbit/s ADSL line, port 8333 forwarding from the router, 700MHz Pentium3 and 256MiB RAM on Debian Lenny.  Download rate varied wildly.

I ran bonnie++ so we have some idea how this heap performs,
Code:
$ /usr/sbin/bonnie -d ~/bon/ -f -s 1500MiB -m clunker
[...noise...]
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
clunker       1500M            5396   6  5034   5           17658  11 601.4   5
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16 10494  60 +++++ +++   980   3  7919  45 +++++ +++  1106   4
clunker,1500M,,,5396,6,5034,5,,,17658,11,601.4,5,16,10494,60,+++++,+++,980,3,7919,45,+++++,+++,1106,4

$ /usr/sbin/bonnie -d ~/bon/ -f -s 1500MiB -m clunker -b
[...noise...]
Version 1.03d       ------Sequential Output------ --Sequential Input- --Random-
                    -Per Chr- --Block-- -Rewrite- -Per Chr- --Block-- --Seeks--
Machine        Size K/sec %CP K/sec %CP K/sec %CP K/sec %CP K/sec %CP  /sec %CP
clunker       1500M            4921   6  5382   6           19630  12  33.4   0
                    ------Sequential Create------ --------Random Create--------
                    -Create-- --Read--- -Delete-- -Create-- --Read--- -Delete--
              files  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP  /sec %CP
                 16    68   0 +++++ +++    16   0    68   0 +++++ +++    17   0
clunker,1500M,,,4921,6,5382,6,,,19630,12,33.4,0,16,68,0,+++++,+++,16,0,68,0,+++++,+++,17,0

The second run is with -b "no write buffering.  fsync() after every write.", it doesn't change block writes much (random seeks lose 18x?) but file creation and deletion are 60x - 150x slower.  %CP is CPU usage, +++ is "too fast to be meaningful".


I can compile & test new versions but my realtime-lag is quite high at the moment.
Is there ever anything in debug.log one might wish to redact / anonymise?
Post
Topic
Board Trading Discussion
Re: The Robotic Courier Network Thought Experiment
by
MrFlibble
on 03/12/2010, 00:21:19 UTC
[Those robots] would be the physical equivalent of open source software which also "belongs" to no one. 

Open source software does belong to someone.  Copyright law has teeth here, http://www.informit.com/articles/article.aspx?p=1390172&rll=1 and without that protection there would be no copyleft, http://en.wikipedia.org/wiki/Copyleft

(Sorry to rant but IMHO "freedom" requires knowledge of & respect for the relevant laws.  Embarrassed)

Quote
The more BTC stored inside the robot, the smaller the chance of vandalism.

ISTR studies support this.  Nice, shiny cars parked in rough areas are less likely to be vandalised; possibly because people appreciate the cars' beauty.  Sorry I forget the references here.

Quote
Destroying a "wealthy" robot for fun would be the equivalent of you  finding a safe on the street that you know has $100,000 inside it, and then dumping that safe in the ocean, just for fun.

If the safe is not beautiful, then "sour grapes" may take over.  Undecided
Post
Topic
Board Development & Technical Discussion
Re: Pooled mining for official bitcoin client?
by
MrFlibble
on 02/12/2010, 20:59:04 UTC
Who else think that the pooled mining must be embedded into the official bitcoin client (as option in GUI menu) to allow for any user could start again to generate 0.01 bitcoin per day?

I think* it's the Way Forward, but perhaps should mature before being shipped with the GUI.  Can you make this thread into a poll?  (e.g. Yes Now / Yes Later / No)


*  I could blow some money on GPUs, but I don't play *any* big 3D games so I can only justify that if I start writing my own OpenCL code, or purely to support bitcoin.  Undecided

I lack enough CPU (spare, on machines in my home DMZ) to expect to mint a block ever, unless difficulty flattens off soon.  I could buy some coins, but have no use for them yet...  I'm left with 0.05 from charity, so I am a (not disgruntled) outsider.

Quote
Bitcoins generator in fact is an excellent advertisement for bitcoin!

I didn't understand this bit, sorry.
Post
Topic
Board Bitcoin Discussion
Re: What will keep transaction fees up?
by
MrFlibble
on 26/11/2010, 00:45:00 UTC
The current [...] generators [...] only ignore a block if it is deemed illegal.

[In the next breed of generators] certain 'rules' will be voluntarily agreed upon, some will not accept blocks that have two many low fee transactions, and will wait for blocks that have only higher fee transactions.

The risk of a generator who accepts too many (new) low fee transactions is that the most of the network will ignore and orphan it's block.

This is an interesting, market based solution. Generators can stop competitors from undercutting them, by "voting" out blocks that don't adhere to their own customized rules. I'm not convinced that it is sustainable. It looks like a problem for game theory.

Yes!  This sounds cool.  When generators disagree there will be inefficiency, confusion and confirmation-delays.  It would be useful to mediate agreement among competitors.

Quote
If this sort of thing works, then miners should be doing it now! This will stop the spam problem: If miners start rejecting blocks that are too generous to spamers, we shouldn't need a block size limit. I suppose, though, that the block size limit IS an implementation of a voluntary rule. Though a rather primitive one, it's sufficient for now.

Perhaps miners will converge to using an optimal rule, similar to what I've described and I'm trying to preempt this development. This definitely looks like the problem of finding an "optimal strategy" in game theory.

Miners could do it now, but the software-capital cost and uncertainty look high enough to postpone it for a while.

Meanwhile, it should be possible to simulate the network.  No need to calculate hashes, just model a population of generators G[0 .. g] pulling hashrates HPS[0 .. g] and having their own rules & motivations, and some clients.

This needs three sets of parameters,
  • one to describe generators (effective costs for electricity, existing hardware & incremental hardware purchase) and allowing for resistive heating, gamers' hardware habit as well as hard-nosed corporations etc.
  • another to describe 'voluntary rules' used by generators for declaring a block of transactions valid.  We have ideas here, they just need a weighting parameter each s they can be combined.
  • finally (the hardest?) for a model which generates transactions among a population of merchants, speculators, hoarders, spammers etc..  Assuming they all know what the 'rules' are at any time, but can only influence them by generating, spending or getting patches accepted and installed.

Might make an interesting student project (one semester?).  I don't have time, sorry.

I suspect the generator rules can vary with time, but to fend off chaos they should be a deterministic function of the content of previous block(s) and not depend on the transaction pool.  I also suspect that if the customers & merchants do not hold a significant fraction of the Ghash/sec, the 'rules' will tend to make a generator cartel with high fees.
Post
Topic
Board Development & Technical Discussion
Re: RFC: ship block chain 1-74000 with release tarballs?
by
MrFlibble
on 25/11/2010, 23:19:55 UTC
My first reaction was "+1 for fast setup", but most of the 24hr delay I suffered was local disc.  Disabling fsync (?) on the database while in catch-up mode would help the most.

Huh, isn't P2P supposed to be faster because you can download from many users at once instead of one source?
(also the reason why some gaming companies use bittorrent to distribute updates)

Good point.  But since the sha-256 of the block is wired into the code, it is perfectly reasonable to ship the data too.  When the blockchain is over 500meg, I think transfer efficiency will become important.

We have options,

  • ship blockchain from SF until it's not politely within their AUP, then re-evaluate.  I couldn't find a file size limit, even for the project website service (only a quick surf of their docs).
  • ship 'small' binaries from SF, and 'large' releases with data via BitTorrent
  • ship 'small' release, including the .torrent for the blockchain and a fetcher script. This looks for one of three popular command line BitTorrent clients for the platform and uses that to fetch the chain, or whinge if it can't.

http://sourceforge.net/apps/trac/sourceforge/wiki/Developer%20web says
Quote
Note: All file releases should be a single file. Multiple files for the same release should be archived together (tar, deb, zip, etc.). We recommend using rsync for all uploads over 20 megabytes in size, as rsync allows for resuming canceled or interrupted transfers.

Hmm, shipping the blockchain for each binary arch would be perverse.


Then, who provides the tracker & seed for the data?  Someone with incentive or community spirit?  Well, this forum+wiki seem to live on http://www.slicehost.com/ => min $20/month.  It could probably share without hurting the website, and (I think) the seed could be severely throttled to make other BT seeds pull more weight.
Post
Topic
Board Development & Technical Discussion
wx + build
by
MrFlibble
on 24/11/2010, 23:51:11 UTC
(Sounds like wx was broken.  I haven't messed with it yet, sorry.  Does it have a helloworld you can build?)
Yes, I stated in my post that I could build and run the demos included with wx.

Sorry.  I didn't read your post carefully enough, just the compiler output.   Embarrassed
Post
Topic
Board Development & Technical Discussion
Re: Some testing that I did on the testnetwork, my findings.
by
MrFlibble
on 24/11/2010, 23:15:17 UTC
Gaming the system  by including 1000 or so recently turned over BTC to bump the priority as described in my post above still works of course!
Or managing how much priority you spend on a transaction.  The software would have to know your future plans to know whether to spend your priority now or save it for later.

Forgive me for suggesting complexity, but the "priority" of input coins could be tracked back more than one block to make some sliding average.  This reduces the effect of "temporarily devaluing" money by transferring it.

If you look back ten hops and found no "old" money, then there is frivolous jiggling going on.  It also creates a new type of complexity attack.   Sad
Post
Topic
Board Bitcoin Discussion
bitcoin faucet
by
MrFlibble
on 24/11/2010, 23:05:13 UTC
MrFlibble:  "Fair" is one set of coins (however many the Faucet is giving out at the time-- hopefully, bitcoins will continue to become more valuable, and I'll give out fewer over time...) per person.

I suspected this, but reading between the lines.  Some folks can't do that, or are blinded by the free money.

Where pseudonyms are cheaper than a "first one is free" offer such as yours, I think most enforcement solutions (passport id?!) would be unacceptable to most folk here.  (Hmm, is this a form of arbitrage?  I have been reading a lot recently.)

Quote
I like the postcard idea, although I'm not willing to type in bitcoin addresses written on postcards!

Grin

QR codes?  bit.ly URL?  Your website displays a "confirmation number" which must appear on the postcard?

But I believe you are trying to drink the ocean here.  I'm most interested in helping you prolong your patience with this kind but futile task.  Undecided
Post
Topic
Board Development & Technical Discussion
Re: Bitcoin harddisk attack
by
MrFlibble
on 24/11/2010, 01:22:16 UTC
Sounds like the problem I noticed, only with spinny disk instead of Compact Flash (cheapskate SSD drive).
https://www.bitcoin.org/smf/index.php?topic=274.msg23624#msg23624 (a sticky topic)
[...]
I suppose it depends on where you live, but in an area where power supply is stable, I think keeping everything in memory and writing it in one go would be best. [...]

Yes. I used /dev/shm and a symlink, until the blockchain download finished.

Quote
I still have the problem of building the application, which is also bad for adoption; many people don't like it when they are running black boxes. Can someone look here?  http://bitcointalk.org/index.php?topic=1898.0

(Sounds like wx was broken.  I haven't messed with it yet, sorry.  Does it have a helloworld you can build?)

I don't like running black boxes, but I don't have time now to read the source so I see little benefit in compiling.   (I have read "Reflections on trusting trust".)  I have a DMZ and that's good enough for now.

HTH,
Post
Topic
Board Development & Technical Discussion
Re: Amtel AT88SA102S
by
MrFlibble
on 24/11/2010, 01:15:00 UTC
[...] I can't find any performance numbers. I'm inclined to believe this is more of a 'secure box' than a performance contender.

You would be hard pressed to try and scale this to a point where it was interesting, imho.

I skimmed through the datasheet for the AT88SA102S ... when I was tired...

It does report tEXEC_MAC = 30ms (Delay to execute MAC command) in table 4-1.  I think this is the only SHA-256 operation where you get the output, the other is to generate some encryption key for burning in the secret.

It looks like the 512 bits it hashes are rather tightly constrained - you can include some message, but the rest is internal (secret, write-only) state.  But assume it will hash anything for you, on request.  Input is 36 bytes, output is 32 bytes; each(?) plus 3 bytes to form the IO Block.

Sending data down the serial interface (tBIT in table 3-1) takes >37us per bit.  Receiving data takes >41us (the chip's clock spec is looser than that of the host issuing commands).

Total time per hash (MAC command) looks like
   IO: (36 + 3) byte * (37 microsec / bit) + (32 + 3) byte * (41 microsec / bit) = 23ms
   + Compute: 30ms

Per chip looks just under 19 hashes/sec.  You need 150,000 of these to match a modern (3Mhash/sec) CPU.
Post
Topic
Board Bitcoin Discussion
https://freebitcoins.appspot.com/
by
MrFlibble
on 24/11/2010, 00:14:56 UTC
I've been thinking about implementing a two-tiered Faucet:  one that gives out a smaller number of coins and just requires you solve the CAPTCHA (and has all the current anti-cheating measures in place; [...]

And another that gives out a larger number of coins if you login with a valid Google account. [...]

Ack, please not Google!  They make the 'net too centralised already.

Quote
But if I did do that... I'd get accused of implementing the Faucet as a sneaky way of stealing Google account email addresses.

Piff. TANSTAAFL.

You could delay the gift for a while, to see who else shows up asking later in the day.  Then if it looks like someone cheated, you can cancel all their pending transactions.  This way, when they game your rules for spotting cheats they risk all their effort in (window of time), rather than the effort for one more drip.

Or you could require the recipient address on a postcard with a nice picture, if you don't mind publishing a snailmail address.

It might help if you made it clear what you regard as fair..?  I asked once & got 0.05 (thank you).
Not being sure that you are happy for me to ask again, I didn't.
Post
Topic
Board Bitcoin Discussion
Re: Please Read: A personal appeal from Wikipedia founder Jimmy Wales
by
MrFlibble
on 23/11/2010, 23:42:06 UTC
as far as getting donations to the wmf in bitcoins... i figure it doesn't hurt to ask... pointing fingers at EFF may be a helpful bit of persuasion...

Why ask when you can tell?  If "we" want to dictate terms for donations, we must ask first.  They already accept on their terms.

  • respectable person makes new bitcoin address and advertises it
  • donations roll in
  • wait until the amount looks "significant", at the prevailing BTC/$ rate (some rules announced up front? into the fountain if the idea dies with less than $10 ?)
  • (offer it to them in bitcoins first, if you like)
  • sell BTC for $ and post it through their (virtual) letterbox with a note explaining
  • publish here to maintain the warm fuzzies

It would be best to come from a united front on our side, but there's no way to enforce that.

Exactly how much effort WMF might be willing to put in & how often is likely to depend on demonstrating a cashflow.
(Unless it turns out they have an ideological objection.)