It may also refer to this: https://bitcointalk.org/index.php?topic=62137.0;all

tl;dr: You broadcast a transaction; miners who consider it valid for inclusion (no double spends, adequate fees paid, etc) sign the transaction and broadcast that signature to the network; the recipient sees these signed Promises to Include.  If the miners who solved >60% of the last 1000 blocks (pick an appropriate threshold and window) approve the transaction it will almost certainly be included; thus you do not have to wait for 6 confirms.

This proposal could eradicate the delay, but I'm not aware of any current work to actually implement it.

+1 bitaddress.org.  Minimum futzing, paper is very reliable, and it prevents bulk-stealing your keys when you go to redeem them in the future.  You can also save a copy to USB if you want.

The sha1 f2e410251c8741ac65d29a1c6fb8ef6919b6ab8b hash is the same as everyone gets for version 1.5.  It's the sha1-sum of the actual web page itself.  This lets you verify that you have a legitimate copy of the page.  Yes, it works fine from a local copy.

Edit: More info about bitaddress here: https://www.bitaddress.org/pgpsignedmsg.txt

Linearly increasing the nonce works fine.  Each increment will generate a completely new SHA256 signature and is just as likely to get the string of zeroes that you need.

I'm not sure what you mean by iterations.  You can explain it if you'd like me to double check what you know. 

Fake transactions signed by the wrong key won't have the proper signature.  Everyone (relay nodes, miners) just drops them.

Shares are partial results - some leading zeroes on the signature, but not enough.  They show you're performing work.

You may want to read the white paper: http://bitcoin.org/bitcoin.pdf  .  It may answer some questions, but the source code may be the only answer to others.



Only the private key / signature is encrypted.  Public keys / addresses / routing numbers have minor privacy implications but it's not worth encrypting them for most people since you'd then have to decrypt to check your balance.



It is sent as a "transaction".  The network then floods it to everyone.  Computer B sees it if it happens to be connected.  The miners also see it, and add it to the list of transactions they are processing.  When they succeed (every 10 minutes on average), they then send the signed "block" to the network, which floods it.

In other words, the transaction exists independently at first, and then is included into a block.  Before inclusion, the transaction is "unconfirmed".  After inclusion the transaction has "n confirmations", where n is the number of blocks since it was included.



The transactions are simply listed in a prospective block.  A SHA256 checksum is made of the transactions.  That checksum, plus the signature of the previous block, the current time, etc, are called the "block headers".  The block must be "signed" by taking the headers and adding an arbitrary "nonce".  That combination is then hashed again and if it includes enough leading zeroes (the quantity determined by the "difficulty") it is considered a valid block.  If not, the miner changes the nonce and tries again until they find one that works.  When a match is found the complete block (headers plus transaction list) is flooded to the network and future miners include its signature in the next blocks they are creating.

Yes, though your node still needs to either a) verify all the transactions or b) trust the md5sum of the downloaded data.  Doing A is still going to take a while; B violates the ideal of decentralization.

The existing protocol can easily stream data fast enough for A.  If the current bottleneck is the network, the client just needs to download blocks with simultaneous streams from multiple peers.

Nope.  The source is there to encourage people to look at it.

Have you read src/doc/build-msw.txt ?

It should build under mingw.  I don't know if VS works.

To maintain database integrity it writes out a journal of the transaction to be peformed, syncs the disk, writes the transaction, syncs again, then deletes the journal.  This hits the disk much harder than a simple copy and it has to be done millions of times.

If you want more connections you can open the inbound port and people will connect to you.  If you want to force more connections you can edit MAX_OUTBOUND_CONNECTIONS in net.cpp.

If you actually want it to go faster, try the beta.  The database settings have been adjusted for better performance: https://bitcointalk.org/index.php?topic=74214.0

If you want to skip the download process you can download a blockchain from here:  http://eu1.bitcoincharts.com/blockchain/

The blockchain download speed is mostly limited by the time it takes the database to commit to the disk.  Extra connections won't help.

It's not a strawman.  I'm just emphasizing that some minimum standard is reasonable.  I'm sure we can come up with a method that will work.

Rather than having a minimum bar, why not make it a sliding scale?  For example:  you must include at least 20% of the top-10-percentile-fees (either since the last block or sliding-window) transactions?  As always, -5 or so to accommodate latency etc.  That would give you a lot of latitude to cherry-pick.  In many circumstances (only a couple transactions with high fees available) you would even be able to mine a null block and have it accepted.

Edit:  Or rather than allowing a null block, we could mandate that every block include at least one transaction if there are at least 5 outstanding.  Is it an undue imposition to include one free transaction if there are absolutely none that meet your include policy?  That provides a very strong incentive to include fees, and completely solves the null-miner problem:  Mystery can mine a null block if he wants to - but only in the few seconds after the a previous block that cleared out all waiting transactions, during which a null block is reasonable by any standard.

Yes, you will be orphaned if you set a "fee > 100BTC no exceptions" include policy.  It is not reasonable to demand that the network have no right to question your policy if you institute a bad one: the whole point is to stop people from excluding all txes.  We're trying to find a minimal method that won't affect any reasonable include policy, but it does create a requirement that you might have to do something.  A relay policy with no actual mandate is pointless.  As I said:  Checks and balances.

You're becoming a broken record.  Your point has been heard and is being taken into consideration.

This is an excellent argument for pools disallowing clients which aren't turning in enough results to justify their bandwidth.  If low hashrate clients (botnet or not) want to participate, they can have one guy get work and distribute it to the others.  Letting them collect 50BTC per null block to save the pool the awkward responsibility of turning away unprofitable workers is completely backward.

I consider gmaxwell's approach to be short-term.  It will probably solve the current problem - whoever this is will notice their blocks are being orphaned and do something to fix it - and while it's intrusive (it requires protocol changes), it has little chance of other collateral damage.

I'm looking at ways to solve it in a more general manner to improve the long-term security of the network.  My proposed change is much simpler but the consequences are complicated.  I don't think D&T's fears will actually happen in reality - I think the economic incentives will actually result in overall more fees being paid and more latitude for miners to set them - but it's not easy to model, and obviously we disagree.

I also don't consider it a foregone conclusion that it's a botnet.  They have to be on the network to receive prior blocks and transmit new ones.  Why would someone go 80% of the way when they could implement a 100% functional pool (or just use any public pool) and draw less attention?  I don't think it's a deliberate attack either because there are much better ways to leverage that much hashpower.

I have no idea what their motives are, and honestly it doesn't matter.  I just want to create the economic incentive where they must fully participate or not get paid, which will definitively, and permanently, solve the problem.

Of course you should be allowed!  That's well established as a miner's right.  Similarly it is also a relay node's right to exclude blocks they consider insufficient.  Check and slightly imperfect balance.

Relay nodes already enforce some minimum fees; those were actually reduced last year.  Right now it's probably best for free txes to be as low as possible - low friction will help growth in ways much more significant than some 0.01BTC fees.  That said I encourage you to institute this policy.  The completely homogenous one-formula-fits-all isn't good for the network.  I think we would be much better off with a gradient of minimum fees among miners instead of the very sharp instantly accepted / transaction limbo that we have now.

Even a 1 satoshi minimum would get people to at least start paying fees, and pave the road for the future where free/1-satoshi transactions are slow (just a few miners supporting them) and reasonable fees are required for fast processing.  It's probably helping your goals on the whole.

But I don't think we should make a universal mandatory minimum fee a rider on the fix for null blocks; that's really a separate issue.  In my opinion we should just try to solve the latter in a way that doesn't make the former worse or cause other collateral damage.

It's a real, though currently minor and not network-threatening, problem that needs a solution eventually.  It cannot currently be exploited for any real harm other than my indignation that some miners are being paid without doing their proper work.  This discussion is not about emergency damage control; we are just speculating and brainstorming ideas for how to adjust things in the future.

Better?

If people's trust depends on us being hush-hush about potential problems, even small ones like this, then the whole thing is hopeless.

In the long run open discourse and letting the light fall on every corner is much more trustworthy than trying to pretend it's a perfect system that will never need improvement.

If miners care, why aren't they already doing something about it?  People will send free txes as long as the system allows it.



100% chance of inclusion per block instead of 25%.  Or as I said later:  make the n based on the number of paid transactions, and let miners ignore the free ones if they want.



Sure, that's why the -5 exists: to give some buffer if there were a few very recent transactions.  It would only matter on very closely spaced blocks: normally you'd be including say 25%+ of transactions to meet a 10% quota and you'd have plenty of room.



How is that a good thing?  Miners should be encouraged to include as many recent reasonable-fee-paying transactions as possible.  Updating getworks isn't hard.

It's a DOS vulnerability, as discussed earlier, and it makes 51% attacks easier, even if the null-miners are not directly collaborating.

D&T:  We could also make it so that you have to include ( ( n * 0.25 ) - 5 ) of the last n paid transactions, and have a lower (or no) quota for free transactions.