I think we're seeing some people submitting lots of tiny, trivial commits -- perhaps because they get more of the tipping pie.

I'm not sure how to combat that bad incentive....

Glancing at block explorers for Monero and ByteCoin... I'm not seeing crippling bloat right now. I see lots of very-few-transactions blocks.

Glancing at recent release notes for ByteCoin, it looks like transactions were not being prioritized by fee, which is a fundamental to getting a working fee market.

Have Monero and ByteCoin fixed the bloat problem, or did the transaction spammers just get bored and go away?

It is absolutely true! I heard the main guy even visited the NSA's headquarters in Fort Langley, Maryland!

Block re-orgs need some thought.

If I have chain A-B-C, and get IBLT's for an alternative chain A-B'-C'-D'...

... then the current memory pool won't work to try to reconstruct B' C' D'.

Using B and C to reconstruct B' and C' should work pretty well. Then the remaining memory pool transactions can be used to reconstruct D.

If any of the reconstructions fail, just fall back to fetching all of B' C' D'.

Then again, re-orgs are rare enough that always falling back to fetching full blocks would be OK.

That is exactly what the 'smartfee' code in the reference implementation does.

RE: where does the market information come from:

Like any market, it comes from the collective action of lots of individual decisions. Different wallet software has different fee policies, and there is already a little bit of "I sent a transaction using wallet XYZ and it took FOREVER to confirm, WTF?!?" (or "why does exchange/wallet/service ABC charge me such high transaction fees").

As wallets mature, I expect them to specialize ("Save on Fees! Use UberWallet!") and/or compete for best cost/speed/reliability/predictability.

The default for the reference implementation will be "follow the herd" -- but the price will be set by the minority of people 'at the margins' who REALLY want their transactions to confirm quickly or REALLY want spend as little as possible on transaction fees. They will set -paytxfee and/or -txconfirmtarget  to override the default behavior.

And "they" are likely to be high-volume-transaction-creators-- like exchanges (probably want their transactions to confirm quickly; fewer customer support calls) or watch-a-video-get-a-few-bits services (probably want to cut costs any way they can, don't care if their customers have to wait a while for a withdrawal to get confirmed...).

RE: sybil/isolation attack:

Again, not a likely attack. You would have to:
1) Find some high-transaction-volume service and identify all of their bitcoin-network-connected nodes
2) Control ALL of those nodes' connections (expensive to do reliably with the 'connect out to 8 random peers' rule) FROM THE BEGINNING OF TIME (well, beginning of when it started running the smartfee code).
3) Let that node see only extremely-high-fee transactions (there aren't very many of those, so you'll need to manage to control the node's connections for a while).
4) Expect the node's operator to send a lot of transactions and not notice that they were paying abnormally high transaction fees.

If you are running a high-transaction-volume service you probably already have several connections into the bitcoin p2p network because you have probably already been the target of a distributed denial of service attack....

Definitely not an issue for Bitcoin-Qt, because you're shown the total amount + fees you'll pay before every transaction.

... demonstrated in a completely artificial -regtest environment...

If you can Sybil somebody and control their view of the network, then it seems to me there are more potentially profitable attacks than "make them pay more in fees than they should."

But please feel free to demonstrate an actual, effective Sybil on the fee estimation code. bitcoincore.org is running a wallet-less bitcoind on port 8333 that generates the graphs at bitcoincore.org/smartfee/

(hacking into the web server to make it LOOK like the fee estimation code failed doesn't count, you have to manage to control it's p2p network connections and then manipulate the memory pool).

Smart (dynamic, floating) fees for the reference implementation wallet was pulled today:
  https://github.com/bitcoin/bitcoin/pull/4250

... and should appear in version 0.10.

The estimation code only considers transactions that are broadcast on the network, enter the memory pool (so are available to any miner to mine), and then are included in a block. So it is immune to miners putting pay-to-self transactions with artificially high fees in their blocks.

Right now if you use the default fee rules your transactions will take 2-6 blocks to confirm:
  http://bitcoincore.org/smartfee/fee_graph.html

The priority estimation code is even more broken; the reference implementation wallet will send a 56-million-priority transaction with no fee, which is nowhere near enough priority to get confirmed quickly:
  http://bitcoincore.org/smartfee/priority_graph.html

(the smart fee code estimates priority, too).

Release notes from doc/release-notes.md in the source tree:

Transaction fee changes
=======================

This release automatically estimates how high a transaction fee (or how
high a priority) transactions require to be confirmed quickly. The default
settings will create transactions that confirm quickly; see the new
'txconfirmtarget' setting to control the tradeoff between fees and
confirmation times.

Prior releases used hard-coded fees (and priorities), and would
sometimes create transactions that took a very long time to confirm.


New Command Line Options
========================

-txconfirmtarget=n : create transactions that have enough fees (or priority)
so they are likely to confirm within n blocks (default: 1). This setting
is over-ridden by the -paytxfee option.

New RPC methods
===============

Fee/Priority estimation
-----------------------

estimatefee nblocks : Returns approximate fee-per-1,000-bytes needed for
a transaction to be confirmed within nblocks. Returns -1 if not enough
transactions have been observed to compute a good estimate.

estimatepriority nblocks : Returns approximate priority needed for
a zero-fee transaction to confirm within nblocks. Returns -1 if not
enough free transactions have been observed to compute a good
estimate.

Statistics used to estimate fees and priorities are saved in the
data directory in the 'fee_estimates.dat' file just before
program shutdown, and are read in at startup.

It seems to me having miners share 'near-miss' blocks with each other (and the rest of the world) does several good things.

As Greg say, that tells you how much hashing power is including your not-yet-confirmed transaction, which should let merchants reason better about the risk of their transactions being double-spent.

If the protocol is well-designed, sharing near-miss blocks should also make propagation of complete blocks almost instantaneous most of the time. All of the data in the block (except the nonce and the coinbase) is likely to have already been validated/propagated. See Greg's thoughts on efficient encoding of blocks:  https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding

So there could almost always be no advantage to working on a smaller block rather than a larger block (it would be very rare to find a full-difficulty block before finding-- say-- a 1/100'th difficulty block).

Near-instant block propagation if you 'show your work' should give un-selfish miners an advantage over miners who try any kind of block withholding attack. And it should make network convergence quicker in the case of block races; miners could estimate how much hashing power is working on each fork when there are two competing forks on the network, and rational miners will abandon what looks like a losing fork as soon as it looks statistically likely (based on the previous-block pointers for near-miss blocks they see) that they're on the losing fork.

We can do all of this without a hard fork. It could even be prototyped as an ultra-efficient "miner backbone network" separate from the existing p2p network-- in fact, I'm thinking it SHOULD be done first as a separate network...

The best way to understand reference implementation accounts is to think of bitcoins like real, physical coins.

Like how a bank works:

When you deposit coins in your account, they are credited to your account. And then mixed in with all the other coins the bank gets.
When you withdraw, you get coins from the Big Old Pool of Coins-- not the coins you put in, necessarily.

That said: general consensus among core devs is that the accounts feature should go away. It is not appropriate for "enterprise-scale" multi-user use (never optimized for that case, doesn't do ACID transactions with whatever back-end database you're using for customer information, etc etc etc).

And it doesn't do what most people seem to WANT it to do (act as multiple wallets, keeping coins separate).

Excellent!

I've been accused in the past of "not caring about privacy" -- when I do care a lot about privacy. But I am not a privacy researcher, and I have a deep respect for how difficult it is to create a truly privacy-preserving system.

I'm very happy that somebody who is an expert is thinking about, and working on, countermeasures.

I haven't been paying to the whole "cloud hashing" thing, but it seems to me a great cover for an old-fashioned Ponzi scheme.

1. Take investors BTC, "buy" gigahashes of mining.
2. Pay them back for a while using new investor's BTC.
3. Once you've got enough investors, take the BTC and run.
  (maybe claim "oops, sorry, got hacked")

I'm not saying CEX.IO is a tarted-up Ponzi scheme. I have no idea.

I'm just asking how everybody who is giving them money knows that they aren't a Ponzi. Or aren't selling the same hardware twice or three times, operating a kind of 'fractional reserve' system (that will eventually fall apart).

Excuse me in advance if this has been discussed and I'm just missing something (e.g. a variation on Greg Maxwell's exchange auditing scheme might work: e.g. "they publish all the blocks found and an auditable merkle tree of all customers and how much hashing power each has").

Yes. I think most people believe that successful technology companies spring up very quickly, but in my experience most (all?) of the "overnight successes" were busy working for years before finding the winning combination of features, user interface, market, etc.

New 'estimatefee' and 'estimatepriority' RPC commands were just pulled into Bitcoin Core.

And I threw up a web page that updates estimates with every new block found:  http://bitcoincore.org/smartfee/

Assuming I got the crontab correct, daily fee/priority estimates will be archived there starting tomorrow.

The hard-coded setting for "high priority" is just wrong (it is much too low for the number of free transactions competing to be included in blocks these days).  The "smart fees" pull request fixes that, and will (by default) only send a transaction for free if it is pretty darn sure it will confirm quickly.

That is like 9/11 conspiracy theorists saying "there is a real debate to be had!"  ... after they repeatedly fail to listen to rational arguments ("Jet Fuel doesn't burn that hot! It cannot melt steel!" ... after being patiently told about the physics of furnaces: burning in a heat-trapping chamber).

I still haven't heard any rational arguments on how the payment protocol is worse for privacy. If piotr_n makes one, please let me know.

You are going back on my ignore list, because you have no idea what you are talking about.

Maybe if I use simple, easy-to-follow steps I can convince you that you are wrong:

1.  Copy and paste this URL into your web browser:
  http://www.comodo.com/home/email-security/free-email-certificate.php

2. Click on the "Free email certificate: sign up now" button (the big orange one).

3. Enter whatever name you like, and a valid email address (an anonymous one, if you like) and a revocation password.

I just used "knownothingtroll@mailinator.com" to make sure it actually does work to give a fake name, anonymous email address (and no address or phone number).

Done deal, you've now got a certificate-authority-signed X.509 certificate for an anonymous email address that you can use for the payment protocol.

That wasn't so hard, was it?

See https://github.com/bitcoin/bitcoin/pull/4250 and https://github.com/bitcoin/bitcoin/pull/3959

A future release will automagically figure out the right fee (or will figure out it doesn't need a fee) to get into a block quickly (or slowly, if you want to pay lower fees and are willing to wait).

As for your original question: set the -paytxfee command-line option for current Core releases and you WILL always pay a fee.

Login as ubuntu, password "ubuntu"

I think, if I remember correctly.

Wait... no, maybe not.  According to the README there, you need to ssh in using the private key in the ssh_key.tar file. That super long "password" is not a password, but is the ssh public key.

In another thread marcus of augustus says:


I'll break my rule about feeding trolls again to debunk for about the hundredth time the myth that the use of X.509 certificates in the payment protocol is bad for privacy.

It is not.

If you are in a customer/merchant situation, the customer's privacy is not affected AT ALL. The merchant's identity is in the X.509 certificate, the customer is as anonymous as always (which is very often "not anonymous", because the merchant needs to know something about the customer to deliver their product).

If you are a merchant, then part of the PURPOSE of the payment protocol is to provide a cryptographically secure, verified-in-some-way identity.

If you are a merchant and want an pseudanonymous then that is easy: set up an anonymous email address and then get a free email certificate from any of the certificate authorities that provide them.

If you have a philosophical hatred of X.509 and certificate authorities... then please invent a better identity verification system and get the world to adopt it. The payment protocol is specifically designed to make it easy to slide in a better system.

(but if you have a philosophical hatred of X.509 then what are you doing posting here at bitcointalk, whose security relies on the very X.509 certificates you find so despicable? There ARE alternatives, you should go hang out in forums.i2p or a Tor-based forum...)

I'll break my "don't feed the trolls" rule:

You need two things to get private bitcoin transactions:

1) An anonymous connection to the Internet.  Bitcoin Core does a good job of this, working nicely through Tor and/or as a hidden service (thanks to Pieter Wuille for writing that code).

2) A privacy-aware wallet.

The Bitcoin Core wallet needs to be completely rewritten, not just for privacy but to get rid of the Berkeley DB dependency, implement HD keys, implement multisig, CoinJoin, etc etc etc....

Nobody has stepped up to do that, so it hasn't happened; in fact, we are going in the opposite direction, moving wallet functionality out of Core (and we might eventually drop wallet functionality entirely to concentrate on transaction validation and blockchain handling).

Why do you ask?