LOL.  The pot calling the other pot black.  Your tea leaves and sheep's entrails may be fancier than his, but don't pretend that there is some science going on here.

Actually, the Merkle root is the easiest part.  All you need to do is never accept transactions into your block candidate and your Merkle root will always be valid, at least as long as the claimed subsidy isn't greater than the network's approved subsidy.

You can't create a future block because of the four things I listed earlier.

To generate a future block, you need to pick a random prevHash value to include in the header, and then wait until a real block comes in with an actual hash value that matches the one you picked.  Right now, each block has roughly a 1 in 2^203 of matching your chosen prevHash value.  By itself, this is much harder than merely finding a hash of the current block, which is about a 1 in 2^53 chance, and you still have to do that too.

Note: a 1 in 2^203 chance means never, ever, ever, not in billions of years, not before the sun burns out, not before the entire universe ends.  If "never" is good enough for you, you can stop reading right now, because it actually gets worse.

And then you need to guess when (to within a few hours) that block is going to come up, because you need to pick a timestamp before you start hashing, and you can't change it after.  So, 1 in 2^203 isn't bad enough, it also has to happen at the right time.

And then the subsidy you claim has to be less than or equal to the subsidy accepted by the network at that time.  If your timestamp is towards the end of a leap year, you'd better halve it, just to be safe.

But wait, there's more.  Your block header also must include the exact difficulty that the network expects when the block is to be accepted.  You can't cheat and go high, you have to get it exactly dead on.

I got my first 0.08 BTC from the faucet.  It was supposed to be 0.02 BTC, but there was a bug that made it send four times.  Once I got my mining rig set up, like a week or two later, I sent it all back.

Sorry, this won't work, for four reasons:  Timestamp.  Difficulty.  Previous hash.  Subsidy.

No.  The article you link is just pointing out that nodes have no incentive to forward transactions.

Oh, of course.  But deleting the address list and pretending that you are a brand new node so that you can use the bootstrap mechanisms seems like a better approach than failing, whether silently or with a notice.

I would just delete addr.dat.  I don't have this problem, but I've had several corrupted address databases before, and deleting always works for me.

I would even suggest that as a good choice for the default behavior in the client.

Certainly not the first, and quite likely not the last either.

What if someone bought up all the existing dollars?

Slightly off topic, but where did you get that, and is it rated for continuous operation?

For XON and XOFF, you'd be better off using 0x11 and 0x13.  ASCII doesn't actually define flow control codes, which is odd considering how complete it is in other areas, but ASCII does define four "Device Control" codes, and people usually use DC1 for XON and DC3 for XOFF.  Pretty much every UNIX terminal responds to them too, which is how you can stop scrolling with CTRL-S and resume with CTRL-Q.

There are other named control codes in ASCII that may or may not be useful to you.  There is an enquiry code, an acknowledge code, a negative acknowledge code, an idle code, a whole set of separator codes (unit, record, group, file) and codes to indicate the start of a header, the start of the text, the end of the text, and the end of transmission.  A bunch of them have special meaning in UNIX too, like EOT (end of transmission) is CTRL-D, which hangs up your terminal and logs off, ETX (end of text) is CTRL-C which breaks, and SUB (substitute) is CTRL-Z which substitutes a new prompt for the running job.

Way back in the bad old days, the 8250 UART chip itself had only a pair of 8 bit buffers.  To send, you'd write your byte to the Transmit Holding Register and then set a bit in the control register, then the UART Would take over, generating the start signal, shifting each bit to the line, calculating the parity internally and signaling it (if set), and writing the stop signal (if set).  When receiving, it would do the reverse, listen for the start signal, shift each bit in, check parity (if set) and check for the stop signal (if set), and copy the shift register to the Receiver Buffer Register, then set a bit in the control register, and if you were really, really lucky, trigger an interrupt so that you didn't have to poll the damn thing all the time.

If a second byte came in before you had read the first one, one of them was just lost.  I think it was the newer byte, but I don't remember.  It's been a while.  Sending had similar issues, but wasn't quite as bad, because the chip would copy the THR into the shift register, so you only had to wait for as long as that took before writing the next byte, instead of having to wait for up to 10 baud periods for it to shift out to the line driver.

Over time, better chips like the 16450 and 16550 came out which had FIFO buffers, so that they could store up like 16 or 64 bytes at a time.  These were buggy as shit too, if I recall, but still a huge improvement.

In a modern system, you should be able to ignore all of that.  You should be able to call the read function in any given high level language and have it either return data, return null, or block until something comes along.  The OS should handle the hardware and buffering properly so that your read calls return everything since either the last read or since the open call.  Any computer should be fast enough not to have to worry about anything like that.

For the relatively small messages that will be involved here, you shouldn't need to worry about the buffers growing unreasonably.  It shouldn't take more than a few seconds to send a transaction request.  At 9600 baud 8N1, which is really slow, you can get out nearly a kilobyte every second.

What you will have to do is respect flow control signals coming in from other devices.  Your first implementation will probably be between two modern boxes running Armory, both of which should be able to handle maximum speed serial lines without any problems.  Looks like newer USB serial adapters can go up to 921,600 bits per second, which is probably faster than the the connectors on the null modem can physically handle without the signal turning to mush, but is still pathetically slow by computer I/O standards.  But, at some point, someone is going to build a little Arduino or other embedded system that they will want to use as a secure offline physical wallet.  Depending on the hardware they use it could even be a bit banging interface where the CPU literally spins in a loop raising and lowering an I/O line at the right times to generate the signals.  If one of those sends 00010101, it might really mean it.

There is only one coinbase per block.  The number of outputs in the p2pool coinbase increases with the number of shares earned*, but the p2pool difficulty adjusts too, so the number of outputs won't grow without limit.  Also, there is a hard limit to the number of shares counted in p2pool.

* Actually, with the number of addresses to be paid.  There can be fewer addresses paid than shares, but never more.

The block is a list of transactions.  All of the transactions are hashed together in a tree structure called a Merkle tree.  The root hash of that tree depends on the hashes of all of the transactions.  The block header includes that hash.

So, the work that miners do depends on the whole thing.  If you add a transaction, part of the Merkle tree will change, which means the root hash will be different, which means the hash won't match any more, and no one will accept your block as valid.

Also, if he were including transactions, no one would care, from the bitcoin point of view.

He isn't including transactions in the blocks because that would require access to the entire block chain, which is around a gig today, and growing.  By not including transactions, he only needs the hash of the current latest block, which is a couple dozen bytes.  The middle ground is to process the transactions at a central point that has the block chain, and then distribute them to the bots, but that is vastly more traffic, and to/from a central point, which makes it much easier to detect.

Ok, now this is where things get strange.

A working serial connection needs only three pins, TxD, RxD, and SG (ground).  If you want maximum compatibility, only use those.  If you need flow control, send XOFF to tell the other side to stop sending, and XON to tell the other side that it can send again.  If you use this system, you'll need to ensure that you don't send those bytes under other circumstances.  The encoding you use for transaction proposals should be fine, and if not, there are plenty of other coding schemes available that work fine for serial or other pipes with in-band control.

There are also several hardware flow control lines, RTS, CTS, DSR, DTR and CD.  Using them is better in some ways, but opens you up to strange cabling problems.  Historically, it has been hard to get everything to line up right, because both sides and the cable all need to follow the same scheme, and serial ports aren't nearly as standardized as one might think.  If you don't mind restricting yourself to only particular serial adapters/cables/devices, go for it.  Just keep in mind that they were designed for communication between a terminal and a modem

1) In Linux, look in /sys/class/tty/ .  They should show up as ttyS* and/or ttyUSB*

2) Lots of ways to do this.  You could just blindly dump the request out and see if you get a reply.  Or you could have each device listen all the time and send a SYN? poll every few seconds/minutes.  Or you could do something in between, and only attempt the handshake when you actually need to send.

3) Communication is totally bidirectional and non-interfering.  Both sides can talk at any time, but buffer space may be limited.  You should expect the need to support some sort of flow control, either XON/XOFF or RTS/CTS.

4) Yeah, pretty much.  The ASCII control characters are surprisingly useful for these things.

5) There probably isn't any point in having the node confirm before broadcasting, under most circumstances.  The wallet should be assuming that the serial device attached to it is hostile, so anything it sends should be safe to broadcast instantly.

6) I'm not sure if there is any signalling of ports in use, other than the open call failing.

Where all of your nonsense breaks down is that there is no possible fee that would get this guy to include your transaction because he isn't even looking at transactions.

I'd be willing to bet $100 of my own real money that this is a botnet.  The evidence so far points seriously towards a botnet that operates by distributing only the bare minimum of information (the previous block's hash) to the nodes, which then generate a valid block themselves and try hashes.  If anyone can provide convincing proof that this is something else, I will mail the first person to do so a check or send them the equivalent in BTC.

I actually comprehended what I said before I even said it.

If you had comprehended what I said, you'd have noticed that I proposed a decentralized rule to temporarily delay accepting blocks that are conspicuously missing the bulk of visible valid transactions on the network.

I have good reasons to think that this is a botnet (described earlier), but I don't really care who or what is doing this.  I do, however, care that we are paying him for work that he isn't doing.

You really should have read the whole thread.  Or at least my posts in it, because everything you said is garbage and has been addressed repeatedly in the past.

Pool members just hash the data.  The timestamp comes from the pool operator's software, not the members.

If it were an ordinary pool, it would indicate that there were too pools.

In my opinion, this is pretty strong evidence of a botnet that distributes only the bare minimum information to each node, which then creates the next block by itself.

You can't really include transactions in the blocks without having more or less the full block chain available, which takes up a lot of drive space and RAM, which would make the bot much easier to detect.  By handing out only the latest block's hash, the system is as close to stateless as it can be.  Each zombie just needs that, and then it can create the rest alone.