That text is far from complete. Help improving it would be most welcome.

Any implementation needs to specifically test for uniformity with the network: Bitcoin is a distributed consensus algorithm and differences in what nodes accept or reject in the blockchain— things which would be minor harmless behavioral differences in most software—  can often result in fatal security flaws where an attacker can move the nodes in question onto a separate fork and double-spend their funds away or partition the network. This requires a unusual level of care and system level tests.

Many of the most interesting cases are the great many things which must be rejected as no amount of exposure to the live network will trigger those cases (until an attacker exploits them to partition the network).

PM me their account names and I'll gladly do so.

Yes, and the explicit and stated purpose was to build an ecurrency based on cryptographic proof which does not require is all the trust that conventional currencies require.

Add more swap, run bitcoind from git.

A semi-ontopic aside:   If you were thinking about getting a rpi to run bitcoin you will be infinitely happier with a odroid u2: http://www.hardkernel.com/renewal_2011/products/prdt_info.php?g_code=G135341370451  it's much faster than an rpi, _far_ more than just the clockspeed and core count implies.  Failing that, a beaglebone: http://beagleboard.org/Products/BeagleBone%20Black is still close in price and should be more than twice the speed of an rpi while drawing a lot less power.  The rpi is a really handicapped arm, and Bitcoind/bitcoin-qt is designed to be a _full_ participant in the bitcoin network, it's not really meant for small systems. You don't really want to skimp on the cpu power if you don't have to.

There is not yet a way to limit it inside bitcoind/bitcoin-qt itself, though it's something that will be done in the future.

Virtually all the bulk users is new users sucking down the chain from you— there has been a _ton_ of new nodes added lately, so it's more obvious than ever. You can prevent this by setting listen=0 in bitcoin.cof or -listen=0 on the commandline.  This will prevent inbound connections, and since only nodes which have most of the chain will listen for outbounds this will mostly opt you out of feeding new clients.

Simplistic network rate limiters don't do anything to tell your peers they should pull from someone else instead, and the Bitcoin software itself isn't yet smart enough to figure it out... so even if (or especially if) you have a network rate limiter, it's probably best to set listen=0 so your ratelimited transmission doesn't cause a slow sync for someone else.

Cheers.

Thats not really what they're for— though that have the effect too. Most of their usefulness is that they prevent a dos attacker from filling up bitcoin node's disk space with long runs of low difficulty blocks forked off low in the chain.

e.g. you start off with difficulty 1 blocks at block 0, now mine-able by the millions by a single asic— _MAYBE_ a chain that starts off that way could eventually turn out to be the longest so absent the checkpoints a node would happily follow an endlessly long chain of them.

They also make is so that an attacker who has complete control of your network (and thus can prevent you from hearing the longest chain from the honest bitcoin network) from putting you on a fake (low difficulty) isolated chain unless they can also trick you into running replaced software. With the checkpoints such an attacker hast to have a ton of mining power in order to continue the chain.

Greetings,  sounds interesting.

What strategy are you using to make sure that you're implementing the distributed algorithm consistently with the reference software?

Okay, enough sticky.

The first instance of satoshipoker.org in my logs is your spamming the URL on IRC on April 24th apparently prior to the creation of this thread on Bitcointalk.

You also use the same IP...

You've got yourself a deal!   The base fee that this is set based on is configurable in bitcoin.conf, just as you were demanding.  The option won't be promoted at least initially because its relatively important that the network have roughly consistent settings (or transactions will get stuck when they get poor propagation due to being right on the boundary) and changing it on your own system won't change miners or your peers, but it's absolutely settable in order to avoid forcing everyone to update (or recompile) should people start selling cars for 1 BTC.

Your ignorance is showing. Will you be apologetic when you realize that you look foolish here? Sadly, I expect not.

I suggest you look at Kano's post history wrt avalon before batch #1 shipped. It may aid your reasoning on this matter.

Okay, a little confusion on my part then. Whats happening in couple weeks isn't the starting countdown for a hardfork, it's the required end date. So I thought you were proposing this be pulled into that. I think the sighash with input value seems pretty inelegant. Instead I'd just assume it would be a field external to the script for each input.

You're going to have to work awful hard to convince me that hashing data on the fly as it comes in and storing a single integer out of the middle is so insanely burdensome that it's worth the considerable risk of an incompatible change to the bitcoin protocol, requiring upgrading hundreds of thousands of machines.. etc.

It's certainly not happening in two weeks.

Another piece of fun advice:  Laptop thefts happen with some regularity at tech conferences ... at a Bitcoin conference if the thieves don't STEAL ALL THE LAPTOPS, they're sleeping on the job.

Prepare for theft by having a good backup and either not leaving coins on your laptop or at least using full disk encryption and wallet encryption. Be prepared to keep your laptop with you at all times. Consider bringing a lock for it.

So, how do you prevent that from basically being the same as "everyone flip a coin?", I'm not sure what kind of guidance you could usefully give there.

I might, with enough effort and thinking into how you do something useful with the instructions there be convinced that there could be something useful along those lines— or at least, no more harmful than any other rearrangement of the titanic's deckchairs— but then there is the issue of if someone has enough computing power to create a 10k reorg, the could constantly reorg 9999 blocks over and and over again.  "This isn't any better".

If it really is only a matter of picking which color tie the corpse of Bitcoin will wear— well the software to implement anything like that itself has a cost (size, review bandwidth, vulnerability surface)— and I can't get too excited about something costly that doesn't make a real improvement. And I also think thats a general issue for these sorts of last-resort thing: if they're only attractive in a already doomed outcome its hard to justify their cost.

Really?


I mean— nothing wrong with being radical, I've certainly taken some rather radical positions too.  But I think that if you don't see Matonis' views as radical you've been desensitized by this forum, to the greater world that stuff is pretty darn radical, and moreover it puts us on in us a opposed-to-state position which will potentially get us crushed like bugs, as well as scaring away a good chunk of our untapped market potential.  As far as I can tell Maronis' radical positions are a big part of his value add.

Hopefully it wasn't overstated there, that why I only commented on it when someone demanded quotes— I don't think he's a bad guy or anything.

For some strange reason a lot of people assume that Bitcoin is _already_ illegal in the US, or at least that it soon will be. Arguments like the above do not help improve things there.

I never commented on Mr. Ver before— but the concern there wasn't that he's too radical (he's generally seemed pretty even keeled in public from what I've seen), it was just the general concern about the felony conviction,  as Luke put it: "you can see how the media would be able to easily spin your past as "Roger Ver, spokespreson for Bitcoin, holds a conviction for selling explosives to terrorists" or something along those lines?"   I think it's quite unfortunately, but especially since Roger's involved in a pretty acrimonious lawsuit with some other members of the community it seems unlikely to me that he can appear in the press without someone blasting the press with "you know that dudes a fellon, right?"  

 Names? perhaps not— you certainly weren't being especially civil to people who didn't agree with you. I assume that your unwillingness to correct you numbers means they were intentional?

In the interest of being a tough guy like you, here is the rest of our PM discussion which you must have missed in your posting:


to which you replied:



I honestly believed that if it were actually a vote the position I was recommending would have eventually won out, the vote-stacking you were conducting only goes so far— as I said in the discussion, the only criteria I've seen I've seen suggested that would have kept Bruce Wagner, Nefario, or even Pirate40 off is the one of not including people where there was genuine concern— all hard large basis of public support. That this has been an enormous time and emotion suck, and it had reached the point where aantonop was name calling people who didn't agree with him, along with threats and other embarrassing responses... it probably was best to kill it mercifully.

Stickying per request, I don't see any harm in giving this a day or two of sticky.  If anyone has a reason not to, please feel free to PM me.

Link to your stats?