When there are new posts in a watched/subscribed thread, if all of the new posts are from users that are on your ignore list, that topic should not show up on the list as having been updated.

Does anyone have useful contact info for campbx?  I've tried explaining this to their helpdesk live chat several times now, but they think the problem is on my end.

Campbx uses kayako for helpdesk service.  If you click their helpdesk link, you'll eventually come to https://support.campbx.com/Tickets/Submit.  Problem is that the page has a kayako.com cert, not a campbx.com cert, which causes a SSL error in sane browsers.  Simple enough to bypass this one, just go to https://campbx.kayako.com/.

Also, the kayako helpdesk software forges emails claiming to be from support.1@campbx.com, but they actually come from a kayako.net server.  Problem there is that campbx.com has published SPF records that do not allow mail from the kayako IPs.  If you have a sane mail system, meaning one that understands and follows SPF records, it will end the session with a permanent (5xx) error as soon as it figures out that it is talking to a peer that is explicitly denied by the published policy.

Sorta like the DNSBL systems for ignoring email spam.

Simple text box in your profile where you can list user names, and then when the ignore function is working, it operates on the union of your ignore list and the ignore lists of the people you've listed.

A more advanced version of this feature could add named ignore lists.  I could then organize my lists into categories, and people could select only the ones they want.  For example, rather than ignore everyone that I've ignored, someone could use kjj.scammer to ignore only people on my scammer sublist.

Can we get a change to the error and double post pages?  I'd really like a textarea with the contents of my POST.

The typical error scenario is this:

I write up a bunch of stuff, click "Post", get an error page.  Reload, get same error page.

Click back, what I wrote is gone.  Click forward, document expired, reload, confirm that I want to redo the POST.  Ahh, but the security token from my post is now stale, and the board helpfully tells me that I'm double posting.

You already submitted this post! You might have accidently double clicked, or tried to refresh.

This page really need a textarea with the contents of $_POST['message'] in it because I'm getting tired of having to retype my posts.

I think that the quest for the perfect mixer has greatly hindered the deployment of imperfect mixers.

What we need is a simple system.  A very simple server that can operate over many protocols (HTTP, telnet, IRC bot, etc.), including tor versions.  A very simple set of scripts that run on the client that interact with it.

When the client connects to the server, the server advertises what sizes it is willing to mix and how many participants it wants.

If the client meets those needs, it sends an address that it wants included in the next batch.

It then checks back from time to time, and when the server has enough participants, it sends back a transaction that pays to the list of participating addresses.

The client sees the address it wants in the output and signs it with SIGHASH_ALL + SIGHASH_ANYONECANPAY and sends it to the server.

When the server gets all of them back, it assembles them into a full transaction and broadcasts.

Lots of things can go wrong.  None of these nodes provides any security because the node can de-anonymize the transaction by providing all of the other inputs and outputs involved.  Batches can fail because any participant fails to sign.  People can attack the system by intentionally signing up and then failing to pay.

But imagine a network with hundreds or thousands of these nodes running.  Literally anyone can set up a node.  Imagine clients constantly churning coins through them.  Each cycle adds between zero and full anonymity, so many cycles should, on average, work pretty well.  People could even build chains through the system, using the output from one cycle to feed the next.

[create their own decentralized exchange]

In light of the BTCT news, jgarzik reposted his idea for a decentralized exchange.

How about this:  make it possible for users to create their own decentralized exchange.

• Register a bitcoin address for each shareholder, if not already.  This enables the ability to authenticate cryptographically signed digital messages.  See this stackexchange answer for a guide.  Most bitcoin clients support signing messages.  Registering a GPG key for each shareholder is an alternative, though that requires additional software beyond a bitcoin client.
• Publicly declare a bitcoin address and GPG key for official ASICMINER messages.
• Publicly declare an email address for emailing ASICMINER robot
• At the end of every day, ASICMINER robot produces a message listing all shareholders, by key and share count.  Attach bitcoin and GPG digital signatures.
• To trade ASICMINER shares, the seller sends a digitally-signed message "transfer N shares to bitcoin address FOO" to the ASICMINER robot.

That is all that is needed on the ASICMINER side:  maintain a shareholder registry.  changes to the shareholder registry may be both pseudonymous and secure.

Then anyone may build an exchange that trades shares.  Anyone may trade ASICMINER shares at any time, using this method.

Re-posting via quote, given today's BTCT  business.

Having a publicly auditable share registry is important.

This strikes me as being yet another example of a ledgerbook system.  You don't own anything, you just have your name in a book somewhere.  MPEX operates the same way.  They provide signed receipts, but ultimately, MPEX is just a ledger book.  A more robust ledger book than GLBSE, BTCT, etc, but still...

Jeff's idea amounts to moving the ledger book from the brokerage/exchange to the asset issuer.  Since the asset issuer already has the ability to default entirely, it would appear that letting them hold the registry of share owners too is a good idea.  Certainly, we've removed one potential point of catastrophic failure from the system.

What powers does as asset issuer hold in the ledger book system?  Should they hold those powers?  Can we do better?

I believe that we can.  Thanks to bitcoin, we know how to build globally distributed peer to peer networks that allow direct transactions between parties.  Thanks to namecoin, we know how to use such a system for arbitrary assets, and we know how to utilize the hashing power of the bitcoin network to provide extra security.

I'm thinking of an altchain for recording securities (stocks and bonds).  For now, I'm thinking it should be called securitycoin, or S-coin, or STC.

Say we add a payload field to the TxOut structure.  (It'll likely be a blob of DER)

If you want to create a new stock, you encode a bunch of information (the name of the issue, the number of shares, some other stuff and a hash of the prospectus) and call it the issue.  Then you hash the issue along with a secret and call that a registration.  Then you create a payload including the registration and burn a few S-coins in fees to embed it in the chain.  Then, when you feel it is deep enough, you redeem the transaction with the registration to create a new transaction with the issue as a payload (also the secret, to prove that it was you.  This is anti-front running stuff).

Now you can redeem the issue with a send to a bunch of brokers.  The brokers can redeem those as usual, and send the shares to clients.  Clients can redeem their transactions and send them to other people, if they so desire.  *

Once the issue is done, every share has a provable owner, and the owner owns the shares, not the issuer, not the broker, and not some exchange.  Even better, if we use regular bitcoin addresses on this network, the issuer can query the chain and get a list of addresses and holdings to send dividends to (on the bitcoin chain).

The system could even handle splits, merges and votes.  The only trick there is to encode the payload in a way that the network can validate the payload cheaply.  For example, in addition to enforcing coin_out < coin_in, it also needs to verify that shares_out = shares_in (paying network fees with shares seems silly, but replace the = with < and it can happen).

Since this system isn't for buying packs of gum at the store, we could slow the network down, maybe to 1 block per hour, to keep the size small.  And we could keep the value of the coins high-ish, giving an incentive for people to merge-mine it, by charging high fees for things like registrations, issues and vote requests, and small fees (or none) for sends and votes.

* I don't think it is possible to take the brokers out of the system.  I don't see any obvious way to make a pair of transactions on different chains that redeem each other.  If there is such a thing, you and your broker could create such a contract and make the trade atomic.  Until then, one of you needs to trust the other.  Then again, if we are using the same keys in both places, maybe multi-sig can do it, don't know.  At worst, it is no worse than any other bitcoin/world interaction, and you still get the benefits of recording stock ownership in the chain.

Neat idea.

One general comment RE: "we could keep the value of of the coins high-ish" :

I think NameCoin should not have combined the "it is a currency" function with "it is a name-tracking system" function.

And I think S-Coin should avoid that mistake. If I want to buy a stock, I don't want to have to FIRST buy some wacky currency just so I can buy the stock, I want to use bitcoins (or dollars, currency you use should be irrelevant).

Piggy-backing on the bitcoin blockchain to get a canonical, time-ordered list of trades makes sense, but doing that doesn't require full merge-mining.

Legally, it scares the pants off me, and isn't a project that I'd touch with a ten-foot pole. They sent Martha-frickin-Stewart to jail for violating securities laws!

In my opinion, if this catches on, the importance of this chain would rival or exceed the importance of the main chain.  How strong would namecoin be if they didn't have exchange value?  A quick look at the relative difficulty shows that even when mining is totally free (merged), 60% of the world doesn't bother doing it.  Namecoin doesn't have enough value to get most people even to that minimal bar.  Namecoin is LOL-cheap because registering names and changing metadata doesn't cost much.  Which is fine for namecoin, because namecoin is mostly about asserting priority.

And you wouldn't need to buy S-coins if you want to buy a stock, just if you want to issue a  new stock.  Presumably, if you are doing an IPO, you can afford to buy some coins in the stock chain to enable you to do so.  When sending a stock from one random guy to another, there isn't a reason why fees would be necessary, and having coins certainly wouldn't be needed to receive them

It is more than just a global list of trades, it is distributed ownership and control too.  It is your stocks protected by your secret keys.  I suppose we could embed the payload as a fake signature in a 1-of-2 P2SH transaction, but then the network isn't validating the payload.  It really seems to require a new chain.

Good call on the Martha Stewart thing, but she didn't go to jail for violating securities laws, she went to jail for lying to the feds (about something that would have been totally legal even if she had done it).  And I'm not sure that the things going through this chain wouldn't actually qualify as securities under existing law, even if we call them that.

And you wouldn't need to buy S-coins if you want to buy a stock, just if you want to issue a  new stock.

The purpose of a currency is to have value because it is scarce.

If you make "issuing stock" tied to currency, then you're saying "issuing stock" aught to be a (somewhat) rare, (somewhat) costly event.

Why?

That, in my opinion, is the same mistake NameCoin made.  Why should claiming a new domain name be rare or costly?  If you want your system to be a success, then it seems to me you want issuing stock to be easy and as close to free as possible.

I can't really disagree with any of what you are saying.  There is no reason to treat this like a currency, no reason for it to have value, no reason why operations should cost anything.

Except that namecoin has 40% of the security of bitcoin, when it should be closer to 90% or more because it is so easy to do.  If S-coin has even less cash value, or none at all, why bother with running the node?

It seems to me that having to buy coins to do stuff is the only way to make it so that people can sell coins, which is the only way to make it so that people will mine coins.  I will ponder on it some more, but it seems to me that artificial scarcity is the only way to make the system work.

We had a brief discussion on IRC about this today.  Some parties felt that since the system cannot prevent an asset issuer from defaulting entirely, the whole thing was pointless.

I disagree.  Because shares trade peer to peer in this system, the issuer cannot be sure who is holding shares, making selective default (paying some holders, but not others) far less attractive.  The issuer also cannot block transfers in this system, which keeps shares more fungible.  The issuer could also be prevented from diluting shares by issuing more, or could be constrained to only dilute in response to a vote verified by the entire network.

So, my question to you, the bitcoin community...  Is this an idea worth development?  Are there other ways to do this that may be better?

I see a lot of 2011 and 2012 threads getting new posts, usually by relatively new users making lots of short (one or two line) posts.

Giving a permanent -10 penalty to activity rating would make this activity useless for people hoping to boost their activity for PM or trust purposes, but not be overly punitive for people that really think that an old thread deserves a new read.

Also, I mentioned it in a different thread, but figure it is worth repeating here.  Ignores earned should deduct from activity, either actual activity or effective activity used for spamming.

[not]

Now that Avalon batch #2 (and #2.5) has "finished shipping" according to the newsletter, I feel that the time has come to really push on my missing orders.  I know that some batch #1 people are still missing units, and you guys have my sympathy.  You guys missed out on a fortune.  I merely missed out on cost recovery.

I placed two orders on February 3rd (batch #2), and paid through walletbit.  One was as a guest, and the other was using funds sent to my walletbit account.

Walletbit confirmed both orders (batch #16633 and #16813).  Walletbit support confirmed my contact (shipping) information.

I can confirm that those TXIDs, your name and email address match. This means everything has processed correctly and Avalon has received the correct information for your order. I have just sent confirmation emails for the newest transaction on each purchase. Please register with Avalon support for further instructions on your order. They are integrating purchases from their old shopping cart into their new one. When this happens, confirmation emails will be automatically sent from their new shopping cart as well.

If anyone is curious, the transactions are here:
https://blockchain.info/tx/099f523d5e9b21fca9d9f71b4f261a82ac0a56e3672d80680038071cfdf689cc
https://blockchain.info/address/1MMdh3JTRTDX3MvvYTaEmAnejjmtdEAqxc

The second one is an address instead of a transaction because I had to send multiple payments.  Walletbit considers the final payment to be the TXID.

My orders do not appear in the Avalon store.

I have two tickets open with Avalon.  Ticket # 806 from May 13th, and ticket # 1136 from June 22nd.  Both tickets mention that there are two orders, and each contains the transaction ID of one order.  Neither ticket has been updated.

I sent one PM on these forums, and BitSyncom has been online since then.  I have called the phone number listed at the bottom of the June 12th newsletter email several times, with no answer.

I have waited patiently while they were shipping, hopeful that I would hear something.

I've argued several times that incompetence and negligence don't constitute a scam, so I can't go to the scam thread to ask that the account get marked.
I could give them a negative trust rating (-4, counting the value), but no one will ever see it unless Theymos adds me to the DefaultTrust list (unlikely).
I could start posting this story in every thread about Avalon.  I've posted it in a few, when it seemed on topic, and in a few topics specifically about missing orders.  But I don't want to be a nuisance to everyone.  Hell, I don't even want to be a nuisance to BitSyncom, I just want this fixed.

What options do I really have now?

Note that I'm looking for options short of invoking the legal system.  I'd never collect a civil judgment, and all a criminal complaint (grand theft) would do is ban Yifu from attending conferences in the US.

I want an entropykey.  Their website only accepts google wallet, which I refuse to use.

So, I'm looking for someone trustworthy to buy me one (or maybe a 10 pack), to be shipped to a US address, in exchange for BTC.  Any takers?

Right now, there are at least 6 threads in tech support about blockchain.info, and that is just based on the titles.

Maybe we could spin off some of the more popular clients/services into sub-boards.  I read the tech support board mostly to answer questions about the satoshi client or technical questions about the network/protocol itself, and having to wade through all of the other stuff sorta puts me off doing it.  I might be the only one, but I'm probably not.

[This may be unsafe. Be careful.]

This may be unsafe.  Be careful.

Signature verification in ECDSA has an interesting quirk.  When you are validating a message, you end up with the public key of the private key that must have created the signature.  For safety reasons, the bitcoin client requires that you provide an address to the verification function, which then finds the public key from the message and the signature, and then returns true or false depending on whether or not that public key hashes to the address provided.

Because signatures include a random component, an attacker can easily keep trying until they find a valid signature for an address that "looks like" the real address.  For a human typing on the command line, this means that it is very unsafe to take just the message and signature and return the key.  If you do this, sooner or later, you will be fooled and you will think that a signature was valid when it really wasn't.

However, think about this other usage...  You have a website, and you don't want to make people register for it.  You just ask them for a bitcoin address that they will sign their messages with.  You stash that in your database, and then whenever commands come in, you take the command and the signature, and find the address that signed the message, then look that address up in your user database.  If you find a match, you know that the command came from a real user, and you know which user.  Obviously, this system won't be fooled by a second address that merely looks similar.

What would this look like?

Code:

kjj@inana:~$ bitcoind verifymessage "1EB28gbcAXsedys1UYTS8gcAJTiN8MHUSh" "Gy8cnYtUohz3wiUZFg4zqbWGulKWSMU0ady3Cbpvo6qZPFgtX5EJ8aNvnE/Sus51nMadDVbTDqDAmR/2prZGJko=" "bitcoin:15kfzDMX2Gr7hXrwRQQGkxrd5eBveKH777?amount=1&message=donation"
false

kjj@inana:~$ bitcoind verifymessage "19mP9FKrXqL46Si58pHdhGKow88SUPy1V8 ""Gy8cnYtUohz3wiUZFg4zqbWGulKWSMU0ady3Cbpvo6qZPFgtX5EJ8aNvnE/Sus51nMadDVbTDqDAmR/2prZGJko=" "bitcoin:15kfzDMX2Gr7hXrwRQQGkxrd5eBveKH777?amount=1&message=donation"
true

kjj@inana:~$ bitcoind verifymessage "?" "Gy8cnYtUohz3wiUZFg4zqbWGulKWSMU0ady3Cbpvo6qZPFgtX5EJ8aNvnE/Sus51nMadDVbTDqDAmR/2prZGJko=" "bitcoin:15kfzDMX2Gr7hXrwRQQGkxrd5eBveKH777?amount=1&message=donation"
19mP9FKrXqL46Si58pHdhGKow88SUPy1V8

In the third usage, verifymessage takes a literal question mark character where the address should be and returns the address corresponding to the message and signature.  This example was taken from https://ecdsa.org/bitcoin_URIs.html, just the first google result I came across with a valid message and address in it.  The first command is with a bogus key that I made up, and the second is with the correct key.  Together they show the safe (normal) behavior of the client, which is to require a proper address for verification, and return simply true or false if that key matches or not.

This functionality was left out intentionally to avoid users doing unsafe things.  I agree that this can be dangerous, but I don't think that it necessarily has to be.  So I'm just going to drop this here and let it sink quietly into the depths of Google's memory.  If anyone thinks that this would be useful for them, they can contact me for a patch.

Oh, and if you can follow EC math this can be done fairly easily outside of bitcoind too, and several devs have expressed the opinion that it should remain outside of bitcoin.  Someone was nice enough to show me code for it in Javascript, but I'm not sure if that person wants it distributed or not, so I'll let them pop in to provide the link if they want to.

How hard would it be to add a field to the account settings where we could put regex that would block only the signatures that match?

I finally got sick of the paid advertising in signature space and checked the box to nuke them all.  But a lot of the sigs were good, so I feel like I'm missing out by having to kill them all.

In IRC, we were talking about new index formats for the block chain.  Since most of the things we want to index by are random, this gets hairy.

I'm thinking of a tree of lists structure.  It should have pretty good performance even in the worst case, and be pretty safe under IO failures.

In practice, this is a collection of 4k chunks.  Each chunk starts with a header of some sort, probably very basic.  At a minimum, each chunk needs to indicate what type of chunk it is, and a chunk ID will make it very easy to keep a journal (see below).  4k was chosen because it is the native block size of modern hard drives.  It is also the native page size for virtual memory in lots of CPUs.  Memory mapped file IO should be FAST, not counting syncs.

The first chunk will be a tree chunk.  After the header, it has 64 pointers, each one 32 bits long.  These pointers are to chunk numbers inside the index file.  The first pointer is for the leftmost branch of a binary tree, corresponding to 000000, the second is 000001, the third is 000010, etc.  Lookups are very fast, simply isolate the 6 bits that are important, multiply by 4 and add the header size.  This could also be a different chunk type, a "root chunk" with extra metadata, but would mostly act like a tree chunk.

If a pointer is to another tree chunk (identified by the header) that subtree covers the next 6 bits, etc, etc.  In the block chain example, this means that there will be 5 mostly empty tree chunks, and the tree will be somewhat unbalanced.  The waste shouldn't be too bad, and a special case could skip through them.  If using this system for keys (or really anything but block header hashes) it will be more balanced.

If the pointer is to a list chunk, that chunk has a list of not more than 62 or 63 pointers (it depends on the size of the header) into the full block structure, each pointer is 64 bits long, just a byte offset.  Lists aren't necessarily sorted, but by the time you get there, it is just a matter of a few dozen comparisons.

Any time an insert would cause a list chunk to hit a high water mark, it triggers a reorg.  64 new list chunks and a new tree chunk are written and items from the old list chunk are distributed among the new lists.  Once those are done and synced, the parent tree chunk would be overwritten with a pointer to the new tree chunk.  Then the old chunk is marked available.  Since chunks are all the same size, the structure won't fragment.  Worst case is a crash just before updating the old chunk, which would leave 65 orphans.  Garbage collection should be trivial though, and the free chunk list easy to maintain.

For extra safety, writes could be done with a journal chunk or two, for example, reserve chunk #2 as the permanent journal, and any time you need to write, write there first, and then write the real chunk.  For performance, you'd probably want dozens or hundreds of journal chunks.  If they have IDs, any time you open the file, you can just replay anything you find there.  Zero the whole journal when you are done with it so that future writes can just start at the beginning of the journal and go in (write) order.

This system could be extended with a recent index buffer in addition to the main index.  This would be a third chunk type, but basically just a list chunk.  The difference would be a pointer back to the previous buffer chunk.  The buffer would be checked first, and the size of the buffer could be dynamic.  If your node mostly looks up recent blocks, most lookups will be buffer hits, so keep more buffer chunks.  If you get mostly buffer misses, you are wasting your time checking it, so keep fewer buffer chunks.

When the system is IO bound, the buffer could even have other uses.  For example, when used for the blockchain, during initial downloads, the buffer chain could be allowed to grow to unusual size, and kept mostly in memory, with completed chunks written only when full.  In a crash, only the most recent few dozen indexes would be lost.  When the node was caught up, it could then replay the buffers starting from the oldest chunk, and only freeing them after their contents were fully committed to the main structure.  This might cause a hole in the structure, but only once, and defragmentation would be easy.

[bitcoind getinfo]

Ever since I upgraded to 0.6.2, all of my CPUs have been pinned at 100% usage.  Anyone else having similar problems?

Here is a 11 year old Athlon XP 1800+ running 0.6.0:

root@inana:~# ps waxuf | grep bitcoin
bitcoind 27316  0.5 20.5 200604 102428 ?       SLsl 05:16   0:35 /usr/local/bin/bitcoind -conf=/etc/bitcoin/bitcoin.conf -pid=/etc/bitcoin/pid -daemon -datadir=/etc/bitcoin/ -noirc

And a modern Celeron G440 running 0.6.2:

root@linuxcoin:/opt/logs# ps waxuf | grep bitcoind
root     27863  0.0  0.0   7740   836 pts/6    S+   11:59   0:00                          \_ grep bitcoind
root      3566 60.0  1.3 222240 106664 ?       SLsl 01:44 369:33 /usr/bin/bitcoind -conf=/etc/bitcoin.conf -pid=/var/run/bitcoind.pid -daemon -datadir=/opt/bitram/
root      3567  0.0  0.0   3924   324 ?        Ss   01:44   0:00 startpar -f -- bitcoind

Before the upgrade, the Celerons were quite snappy and responsive.  Now, it can take several minutes (really!) to run a simple bitcoind getinfo.  And it isn't an I/O problem, the Celerons are totally diskless, running entirely out of RAM, like they have been for the last few months.

So, what is the best way to turn a WIF privkey into a public key / address?

Should I convert the WIF to DER or PEM and let openssl make the public key?  Or does anyone have some code that can do it directly?

My target is PHP on Linux, or shell, but I can probably use (or translate) from perl or python.

[CHAIN SELECTION BY NODES IS DETERMINISTIC AND MUST ALWAYS BE TO AVOID FATAL FORKS.]

I would like this thread to discuss only this one proposal for hindering empty block mining.  We already have two threads full of speculation about who is mining the empty blocks, and brainstorming other ideas for stopping them.  I'd prefer that this not become a third.

The idea has floated several times to reject blocks that don't contain at least some portion of the transactions that you node is aware of.  Might be time to reconsider it

Of course, it wouldn't be anything as simple as "reject empty blocks" or "reject blocks with less than X transactions".  Those won't work.

It will need to be more like "I see 100 pending transactions that are valid and should be included in the next block.  This block I just got from the network contains less than 25% of them, so I will reject it."  There will probably need to be a threshold too, like "I only see 10 pending transactions, and that isn't enough to enforce a minimum number on this incoming block, so I will accept it, even though it has none".

As a first guess, I would say that a threshold of 10 or 20 and a fraction of 1/4 to 1/2 would work well. 

Method b) Nodes invidually determine which nodes are invalid (seems to be the method advocated by kjj )

The problem is that at any moment in time your node my not see every transaction.  This is important:  CHAIN SELECTION BY NODES IS DETERMINISTIC AND MUST ALWAYS BE TO AVOID FATAL FORKS.  Now matter how a node is made aware of a block, how delayed, or what other data it has at the time it currently always picks the same chain.  This keeps the entire network operating on the same chain and avoids fatal forks (forks which can't be re-organized by simply allowing dominant chain to grow longer). 

If nodes determine which block is valid based on information it has (which may be incomplete) then it is possible (actually very probable given enough time) that some nodes will consider block X valid and some consider block X invalid.  Deterministic chain selection is now fatally broken.  Once a node considers a block invalid it won't change its mind and thus any blocks built on it also become valid.  The two fragments keep diverging.  Forks will build upon forks upon forks until the network a fragmented mess of sub networks each with a different view of the current coin balances.  An attacker could exploit this fact by broadcasting transactions (not in the block it just mined) selectively right before broadcasting the block to ensure some nodes will consider a block valid and some not.  Even without malicious intent the network would destroy itself if chain selection isn't deterministic.

It is a non-issue.  Over time transaction fees will make up a larger and larger share of the revenue a miner needs to stay profitable.

You've added a number of assumptions.  The biggest one is that you assume that block rejection is permanent.

Taking out just that one added assumption, and the system works again.  If my node has block X, and another block comes in (call it Y) that has the hash of block X-1 in it, that new block is rejected.  Unless when block Y+1 comes in and has the hash of block Y in it instead of X.  When that happens, block X is tossed out, and block Y gets unrejected.

In this case, if block Y+1 meets the acceptance criteria, block Y becomes valid, even though I didn't like it when I first saw it.  However, if block Y+1 is also an antisocial block, they both remain on the lonely pile until a good miner builds on top of it, or until the X chain grows longer than the Y chain, making the issue moot.

There may be holes in my idea, but I don't believe that this is one.

16 or 20 years from now, when the subsidy has dropped and hopefully the fees have increased, this may be a non-issue.  But today, it is a real issue.  We are paying full price for these blocks, but only getting part of the value.

For the record, I have no problem with botnets contributing to bitcoin, as far as bitcoin is concerned (i.e. ignoring the moral issues of theft of service or whatever you want to call it), as long as they are contributing to the security of both past and present transactions.

Seems like a bad idea. There's going to be a lot of wasted work if half the miners are working on a different block. You will effectively halve the total network hashrate and make it that much easier to 51% the network. Plus if X+1 and Y+1 are found around the same time, it gets worse. This also makes it easier for some to try to double spend their coins.

Probably best to keep things as they are and things will sort themselves out as designed.

We get network splits all the time.  And good miners would have an incentive to build off of the blocks other good miners, so the forks would rarely be anything near 50/50.

And most importantly, this gives the antisocial miners powerful incentives to become good miners, without waiting for however many years it takes for fees and subsidies to do that automatically.

Let me be very clear.  I propose that:
1. nodes temporarily reject blocks that they can identify as antisocial.  Nodes already temporarily reject blocks, but for different reasons.
2. nodes have a method whereby a block that was temporarily rejected can become accepted.  Again, nodes already do this.

Further, I assert that:
1. these will not lead to permanent or even long-lived chain forks, for exactly the same reason that the ordinary chain forks that we get about once a week are not permanent, and can't become permanent.
2. any method used to game the system to create blocks that include only dummy transactions created by the attacker to circumvent rejection will necessarily require more effort than simply doing the right thing (including ordinary transactions), giving the current antisocial miner(s) a strong incentive to become a positive part of the network.

The two main objections to my proposal are:

1.  It would cause forks, which would be bad.  I think that I've addressed this sufficiently.  It will indeed cause local forks, but those forks will not be global, and will not persist any more than the forks we already have.

2.  Miners would lose quite a bit of autonomy over which transactions they include.  Sadly, this is true, and is actually the entire point of the proposal.  But, the community at large is paying for the work done.  I think that we have the right to set standards for the quality of work which we will accept.

My proposal also has some less obvious advantages.

1.  It requires no new protocol and no new centralized authority.  Each node can make the decision to defer an incoming block based on the data it has locally.

2.  Each node would be able to set their own policy.  The network would reflect something like an average of the policies of all miners.

[Current]

I started with linuxcoin and my headless mining scripts, and I've added p2pool and some new tricks.  I'm calling it p2pcoin for lack of a better name.

* Network provisioning - checks DNS for a URL to fetch the config file - many config options can be specified in the file or fetched from URLs
* BFGminer pool list is localhost, then up to 10 PEER[0-9]= lines, then BACKUP_POOL=, then TEMP_POOL=
* uses "-S all" in bfgminer to find PGA/ASIC devices and "-S opencl:auto" to find Radeons
* full bitcoind node
* full namecoind node
* full p2pool node
* can use rsync to fetch both block chains
* can use persistence, but works much better using RAM drives (needs ~24 GB of RAM or flash or both if you want to run bitcoind/p2pool)
* works great from PXE
* works as a dumb miner if it can't run bitcoind

It still has a bunch of ugly hacks and quirks, but works quite well.  It attempts to handle local errors the best it can, and has a heartbeat function to report stats every minute.  I use the heartbeat stats to monitor each box and trigger a network power strip to reboot boxes that are seriously stuck.

Note:  The high share speed of p2pool might wear out your flash drive.  If this bothers you, don't use persistence, or just boot from CD or PXE.

Usage example (my mining farm):
I have one box with 32 GB RAM, and several boxes with much less.  All use PXE to boot, none have persistent storage.  All boxes fire up bfgminer as soon as they are booted.  The big box uses rsync to fetch a copy of the block chain from a server on my network, then reindexes it and eventually p2pool starts.  The smaller boxes detect that they are unable to run bitcoind, and just run as dumb miners.  While the p2pool box is starting up, all bfgminer instances (including on the p2pool box) fail down their list to an external pool.  Once p2pool is ready, they all switch back to the local pool.


Current - Version 0.7.0: p2pcoin-0.7.0.iso.torrent - 2013-12-18 - Updated bitcoind to 0.8.6, updated bfgminer to 3.8.1, updated p2pool to 13.4. 


Version 0.0: p2pcoin-0.0.iso.torrent - 2012-02-26 - initial early testing release
Version 0.1: p2pcoin-0.1.iso.torrent - 2012-02-28 - p2pool updated to 0.9.1 - still early testing
Version 0.2: p2pcoin-0.2.iso.torrent - 2012-03-09 - p2pool updated to 0.9.2, bitcoind updated to 0.6.0rc2 - fixed logrotate problem
Version 0.3: p2pcoin-0.3.iso.torrent - 2012-03-30 - p2pool updated to 0.10.3, bitcoind updated to 0.6.0final
Version 0.3.1: p2pcoin-0.3.1.iso.torrent - 2012-04-23 - fixed CD boot problem
Version 0.4: p2pcoin-0.4.iso.torrent - 2012-05-03 - updated p2pool to 0.11.1
Version 0.4.1: p2pcoin-0.4.1.iso.torrent - 2012-05-23 - changed RAMdisk settings, upgraded to p2pool 0.11.2
Version 0.6: p2pcoin-0.6.0.iso.torrent - 2013-01-26 - Tons of changes.  Now using BFGminer
Current - Version 0.6.4: p2pcoin-0.6.4.iso.torrent - 2013-07-07 - Updated bitcoind to 0.8.3, updated bfgminer to 3.1.1, updated p2pool to 13.0. 

I just did a trivial patch to my local 0.6.0rc1 code to add -addtag to the configuration options.  It adds arbitrary text to the COINBASE_FLAGS, exactly like -bip16 does, except provided in the config file or on the command line.

It appears to work.  My getmemorypool is showing 062f503253482f055b4b4a4a5d , exactly like it should.  I guess we'll know for sure in a month or two, or however long it takes my rigs to find a block.

So, I was wondering if there was a reason it isn't in the main tree.  Was it just that no one thought of it, or do we not want to make it easy for people to scribble up the chain?

There is brute-force tool that targets bitcoin RPC active in the wild.  See this thread.

Can we get an optional low volume log file to be used to report things like failed RPC requests?  Ideally the format should be simple and contain the IP address, so that it can be parsed by fail2ban or other tools.  I think that these failures are already logged, but I don't think that I'd want to point fail2ban at the firehose that is debug.log.

Having RPC throttling built in would probably be safer for most people, but adding a second log file seems easier.

http://forum.bitcoin.org/index.php?topic=5506.0

Two of the first three threads in this board are about gaining pool redundancy by dubious means.  For the love of all that is holy, use the flexible mining proxy instead.  It does that, and a whole lot more.