Interesting ideas s, thx for sharing! A few comments below:


If I understand you correctly, you propose that in this system a coin would be represented by a rare mathematical artifact. This is an interesting idea, but - and you might be aware of that - it's not how Bitcoin works. The Bitcoins themselves are just numbers associated with a Bitcoin address. Only the blocks, that secure the block chain, have the rare mathematical property. This distinction is important, because it means that coins can easily be divided into smaller units. If a rare mathematical artifact itself would represent the coin, then you would most likely not be able to divide it and thus would need much more of them. Maybe not an insurmountable problem, but I think it makes the whole problem of the rate of money supply a little trickier.

Speaking of the rate of money supply, I'm not sure how you would keep that under control in your proposed system. You say the difficulty of the process doesn't need to be static, but how is a change in difficulty decided and how can you reliably know what the current accepted difficulty is?


I don't find this whole "spitting things into the public domain" quite that trivial. Let's say you build a p2p-broadcast kind of system that Bitcoin has. An attacker could bring up lots and lots of nodes (IP addresses aren't hard to come by) and you might end up connecting only to nodes controlled by the attacker. The attacker is then controlling your perception of the "public domain" and can - for example - filter out those incidents where he already spent a coin that he is planning on double-spending at your store. Or do you think more of a centralized system to be this "public domain"? That would simplify it, but I would also consider a centralized solution as a disadvantage.

Very entertaining thread indeed. :-) I love how the first 20 pages are basically 5 guys repeatedly saying: "What the hell? This can't be true!"

So many brilliant quotes to be found:



But, miners brace yourselfs, you also see a couple of posts like this:


A lot of people seemed very concerned about what it is computing and whether it's cracking passwords or whatnot. This seems like a frequent worry that people have. Do we have a good FAQ entry about that?

I don't know if the museum visitors would understand it, but I think a good exhibition piece for Bitcoin would simply be a nice printout of a private key holding a freshly awarded 50 BTC block. I guess one of the "earlier" blocks would be nice, but hey, this is all still pioneering days, so no need to be so picky. The museum would just need to make sure that you can't see all of the private key, otherwise a smart visitor will steal the money from them. =)

I would think it would make a nice exhibition piece for a cryptocurrency. After all, that's what they are all about: numbers! :-)

Interesting project! Can you elaborate on the JSON-RPC interface you provide? This runs on a single Bitcoin wallet but isolates different Bitcoin Pouch accounts from each other? How exactly do you achieve that?

Well, let's say I run a miner that accepts transactions below 0.01 BTC for a 10% fee. So someone out there sends a transaction of 0.005 BTC with a fee of 0.0005 BTC. Problem: I'm never going to see that transaction, because all the nodes in between won't relay it, because they require a 0.01 BTC fee on everything below 0.01 BTC (the new "dust rule").

Or are you saying I need to be in direct (network) contact to everyone who potentially wants to take advantage of my fee structure? is this the expectation?

But from whose pocket did those $2 in interest come from? If everyone of us wants to be Steve, someone has to lose out, right?

So what's the standard economist answer to that? Increase money supply and grow economy, I guess. But isn't it time we think about a system that doesn't require an endlessly growing economy?


Can you elaborate on this? What's the method of redistribution for dollars?

Reading the current Bitcoin source on github, I can identify theses rules for getting a transaction relayed by a node:

- if a transaction is fairly large, 0.01 BTC per kb is required
- if I want to send less than 0.01 BTC, a fee of 0.01 BTC is required
- if I want to avoid the rate-limiter, a fee of 0.01 BTC is required
- something about raising fees when a block is almost full (not sure I understand that completely)

Any other rules I have forgotten?

To be honest, I don't really like where this is going. Especially this arbitrary value of 0.01 BTC, which is hardcoded in the source. Sure, it can be changed at some point, but it just doesn't seem very flexible.

Can't we come up with something that auto-adjusts in some way? For example: A node could commit to a certain maximum number of transactions relayed per minute. If it sees that the rate is exceeded, it gradually increases the fee it requires, until the rate is within limits again. If someone starts penny-flooding again, you only have to pay a little more than the attacker, instead of having to jump to the arbitrary value of 0.01 BTC right away. (Just to clarify: I know that the node isn't getting any fees for relaying transactions. When I say it "requires a fee", I mean it in the sense that it wants to see that fee on the transaction to consider it for relaying.).

Also: In the discussion about fees, you often hear: "the miners will sort it out". I think it's important to be clear that there are two different issues:
1) What transactions to include in a block. If this gets crowded, miners can figure out whatever fee structure they think will work best. This is very flexible and nice
2) What transactions to relay. Because bandwidth is a limited resource as well. And that's not flexible at all right now, with an increasing number of fixed rules in the source code. This is where I would like to see some auto-adjusting mechanism.

Hey! Great to see you are working on a "Bitcoin address discovery system". That would definitely be cool to have!

I was thinking about that myself and am still unsure, if I would not prefer this to be its on daemon. So let's say you would connect to the domain in question on some well-known port (say 8334) and be connected to a simple daemon which you can then query for those things. Somehow that seems like a good thing to do to me, considering "separation of concerns" and all that.

I guess you went with this route in order to make it much simpler to deploy? That's definitely a big advantage, I agree. So maybe that's the pragmatic thing to do to actually see some adoption of it and some point. If we marry it to the webserver, I would prefer these changes though:

1. Use .json instead of .txt as the file ending
2. Move all the user lookups (user@example.org) to a folder, as to not "clutter up" the root folder too much

So that would mean:

/bitcoin-address.json (instead of /bitcoin-address.txt)
/bitcoin-address/user.json (instead of /bitcoin-address-user.txt)

That's correct. Well, the total reflects the sum of all "outs" and then the outs are listed separately in brackets. Eventually I plan to list the sum of the "ins" as well, which also makes it possible to calculate the fee (total in - total out = fee). But just from looking at a single transaction you don't actually know the sum of the "ins". You have to look up the in-transactions in the block chain / database. I haven't implemented that yet and it will probably require a little bit of reorganizing of my codebase.

In any case, this is probably still not the faucet, because it's just 0.01 BTC and the faucet still gives out 0.05 BTC as far as I know.

I agree with you, but it's probably not technically feasible. You also have to take variance into account. Even if you would lower the average block creation rate to something crazy like every 10 seconds, you would still need to wait 30 seconds to have a 95% chance of seeing the next block (because 10 seconds is just the average wait time). And even then, 5% of your costumers in line would need to wait even longer than 30 seconds. Not really competitive with a VISA payment that goes through after a few seconds.

What you might be able to do is to build some heuristics that try to figure out whether an unconfirmed transaction will eventually confirm. If you are well-connected to the Bitcoin network that might be feasible with an acceptable risk. For more discussion on the whole "fast transaction acceptance" thing, see also this thread: http://bitcointalk.org/index.php?topic=3441.0

Once Bitcoin trickles into more Linux distributions, I think one great advantage will be the fact, that a payment system is just one "apt-get install" away. Just install some software packages and you are ready to receive and send Bitcoins. Think LAMPB: Linux, Apache, MySql, PHP and Bitcoin. :-)

I'm wondering what a good standard setup for this would be. Linux distributions could integrate the necessary daemon scripts to run bitcoind as a system service to which you then connect using the JSON-RPC interface. But maybe bitcoind should support some kind of user schema for that? In the same way that you only run one instance of mysqld, but can have different user accounts using databases that are isolated from each other. There would be only one bitcoind running and only one copy of the block chain be managed, but several different wallets that can be accessed by supplying different user credentials using the JSON-RPC interface.

Do you feel that this is something that should be added to bitcoind at some point? or would you prefer this to be an external component that provides the user management on top of a single wallet?

What is wrong with some people? Seriously... someone with the technical skills to automate this can't think of something more worthwhile to do than to steal pennies?

It's really unfortunate, because the Faucet is probably the most important promotional tool that Bitcoin has. So what's next? manual approval of every Faucet transaction? maybe a group of trusted forum members could do this, so that there is always someone online? would be pretty tedious though, I guess.

I have thought about setting up a service like that and am still toying with the idea. I would, however, like to know more about what happens in case of fraud and Zaypay doesn't say much about that on their website. I haven't mailed them yet. Looking at the numerous attempts of fraud that Coinpal has to deal with, I wouldn't want to be left sitting on phone bills that won't actually be paid.

I also looked at Zong (www.zong.com) which provides similar services and from what I remember reading on their website would guarantee a payment to you once it passed their fraud control. That would be a hassle free way of doing things and simply letting Zong worry about fraud attempts. Unfortunately they didn't want anything to do with Bitcoin. A salesperson at Zong told me that their carriers won't allow anything where you can "cash out" later. So selling virtual currencies is fine, but only if the only thing you can do with them is spend them on some stuff (like virtual game addons or whatever). If there is an option to change them back to "real" currencies, then that would be against their agreement with the carriers. Since then I haven't looked further into the whole "buy Bitcoins with your phone" idea.

Since Zong claimed, that it's the carriers who wouldn't allow this type of stuff on their network, other providers like Zaypay should theoretically have the same problem. But maybe they have different agreements or simply don't care as much.

An additional thought: I think it's fairly hard to judge for a sender how much fee is appropriated and needed for a timely procession. Maybe there should be a standard way for the _receiver_ to pay a transaction fee as well. So as a receiver I would monitor the network for transactions to one of my addresses and when I see such a transaction T, I send out a special "bounty transaction" that basically says: "if you include transaction T in your block, you can additionally collect my bounty".

This way senders could just send out transactions without a fee, and if they risk getting lost in a sea of free transactions, the receiver could "fish them out" for a small fee.

Indeed, problem solved, but usefulness of Bitcoin greatly diminished. I know that Bitcoin is ultimately not a micro-payment solution, but while it still is, it has great potential to catch market-share in that area. I would hope we are able to keep that up as long as possible.

A naive question: what problems does transaction spam cause? besides blocking other free transactions? Is there any other harm to the network that would be a big problem at the current time?

Because I don't consider it such a big problem. There was a lot of spamming going on a few weeks ago, which has seemed to calm down again. During that time you couldn't really send a free transaction, which was unfortunate, for sure. But if we now employ a complicated policy which basically boils down to not being able to send free transactions anymore, then we are kind of in the same situation, aren't we? Might as well keep it simple then and don't have such a policy.

I would rather be able to send out a free transaction and hope it gets through, then having to worry about some complicated fee-structure to figure out if that will get me banned or not. This is mostly speaking from the point of someone interested in running Bitcoin services.

Thx for the detailed explanation, that was very helpful!

I'm trying to get a better grip on the correct math to use on block distribution: If the average time between blocks is 10 minutes, does that mean that the average time - from a random point in time - until the next block is 5 minutes? Or is that reasoning flawed for this kind of distribution?

Also: Can you fill in the correct values for A and B in this statement: "The average waiting time until the next confirmation block is between A and B minutes in 95% of all cases". It would be nice if you could explain how you go about calculating that. :-)

I expect the exchange rate to drop significantly over the following weeks. It is just way too high. The system currently costs about $4500 a day just to keep running (number of Bitcoins mined per day at current exchange rate), without actually providing all that many things you can do with it. Besides admiring its beauty. And recent Slashdotting has shown: Not too many people care about that beauty too much, they maybe think it's a cute idea, but move on when there isn't anything to do with it that they can't do already.

But it's probably not too bad if the hype wears off a little and the project can catch some breath. The reality of software development is, that it takes a lot of time and can not really be scaled up that well. And I think that's the most crucial part that needs improving right now. Yes, I agree, we need more "goods and services", but I think the precursor to that is better software. It's just too much work to integrate Bitcoin right now. We need software libraries and webservices to make that much easier, we need better and easier to use client software and we need mobile clients. These will take time to develop and the hype economy will probably crash in the meantime.

As I have said elsewhere ( http://bitcointalk.org/index.php?topic=4793.msg70391#msg70391 ): Great work! :-) I just fear that it might not be able to inspire the kind of fascination that Bitcoin deserves. But that is hard to do, for sure, and I saw in this thread that it is meant to be more of a kickstarter and a more technical video might follow at some point. So that sounds good!

I have been kicking an idea around for a little while on how to explain the technical side of Bitcoin and just wanted to document it here in case someone finds some inspiration in it. I would approach it from the question "What would it take to build a decentralized payment system?" and from there explore the difficulties and Bitcoin's answers to it. I think this way there is a chance for a newcomer to quickly appreciated what all the alien concepts ("block chain") are needed for.

So here is a rough outline following 'Professor Bitcoin' in inventing a payment system:

-- Start of script --

Professor Bitcoin: "Let's invent a payment system today! Moving cash or wealth in general around is part of our everyday live and something we increasingly do online as well. Before we build our own system to do that, let's look at one of our competitors: Paypal. When using Paypal, you give them some of your money and the record it in their books [show some image of a big Paypal book in the center]. Moving your money to someone else who has Paypal is easy now. You can just change the owner in the big Paypal book [animation of a new transaction recorded in the big Paypal book]. So, what's wrong?"

"In a central solution everyone depends on the entity that manages the big transaction book. If they don't like you, they can just freeze your account [animation of entry in the big PayPal book being frozen]. Can we somehow get ride of the need for a big central book?"

"How about this: we just give a copy of the book to every single participant [show animation of the big Paypal book being copied and distributed to a number of participants and the big book itself vanishing] Nice, now everyone has a copy. But how do we make sure they all say the same thing? [let one of the smaller books show the transaction "Mallory to Alice" and another book "Mallory to Bob"]. We no longer have a central authority, so we need a system to keep these records in sync."

"How about some form of voting? Everybody votes on what is the correct version. The one with the most votes wins out, in the hope that honest people hold the most votes. How are votes granted though? It's the Internet, everybody is anonymous and we don't want to ask for IDs. Maybe one vote per IP address? easy to fake. Let's try this: The more CPU power you have, the more votes you get! Maybe not the fairest voting system, but at least everyone can stay anonymous and a supercomputer isn't found at every corner"

"How can we make sure that someone has the computing power they claim? Cryptography to the rescue! Fortunately there are some very hard mathematical problems with just take some time to find the solutions to, even with some of the fastest computers. To vote for a version of the transaction book, you need to spend the time solving these problems [show animation of one version of the transaction book being covered in more and more mathematical formulas until it forms a huge pile; show another version of the transaction book next to it covered in a smaller pile of mathematical formulas]."

"Very good! We have found a way for a number of decentralized and anonymous participants to reach consensus on what is recorded in the transaction book. One last problem remains: how to get money in and out of the system?"

"We can't just let everyone write something in the book - even with the voting in place, nobody could be sure the money is actually there. So we design it as a closed system instead: Those who invest CPU power to keep the voting going and keep everybody honest will occasionally be rewarded with some fresh 'Bitcoins' which they are allowed to record in the book of transactions. To use the Bitcoin system, you either have to invest a lot of CPU power yourself to get some Bitcoins or buy them from other people who are doing so. In effect you pay them for keeping the system going, which is only fair."

-- End of script --

This has some holes, especially the part of what it means to "write in the book" and how you can not just write anything (but only move your own coins around). I'm not sure there is a nice way of explaining that without having to go to deep into public/private key stuff. But still, maybe this approach to explaining it can turn out to be useful.