|
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....
|
|
|
|
Edit: With respect to CryptoNote and Monero, I do see merit in the argument that the fee penalty alone may not be enough to constrain blocksize; however when combined with the difficulty increase requirement the picture changes. As for the specifics of the Monero blockchain there are also other factors including dust from mining pools that led to the early bloating, and we must also keep in mind the CryptoNote and Monero also have built in privacy which adds to the blocksize by its very nature.
Yes, its complicated— but it's also concerning. The only altcoins that I'm aware of which have diverged from the current Bitcoin behavior in this front, and did so with the benefits of all the discussions we've had before being available to them, have been suffering from crippling bloat. 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.
|
|
|
|
Can't somebody build a web-service that detects when transactions enter it's memory pool, looks at the transactions fees, and then examines when these transactions enter the block-chain and analyses all of this data to provide a more accurate estimate of required fees which would be based on real market data? Maybe have some sort of api that wallets could use? Or does this exist?
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. |
|
|
|
It's fairly easy to manipulate actually; sybil attacks are not that hard to do. (there's evidence they're being used against people accepting zeroconf) I demonstrated a 1BTC fee tx due to the estimator failing. Right now there is a cap of 100mBTC, but obviously that can drain your wallet pretty quickly.
... 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.htmlThe 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_codingSo 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).
|
|
|
|
We are currently working on a countermeasure. In particular we wonder how
reducing from eight to four entry nodes would effect the bitcoin network.
We also think to decay the connections based on the number of transactions
(for example renewing half of the entry node connections after each
transaction). It might be interesting to include a proof of work for
creation of connections, but this would create a compatibility issue.
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").
|
|
|
|
It does seem to be the case that building things that work in the real world, not jus in laboratory conditions, takes time.
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. |
|
|
|
My rationale though is that we shouldn't need to do this by hand. It should be default behavior if paying a fee is the only valid way to make 100% sure that transactions are handled in a timely manor.
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. |
|
|
|
There's a real debate to be had; name calling just makes it impossible.
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. |
|
|
|
In order to acquire a certificate (which you need to sign the payment requests with), you must leave your personal details at a CA.
Your full name, your email, where you live, even your phone number.
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.php2. 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? |
|
|
|
|
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: Another "Troll" here:
On the minus side of the ledger, Gavin omitted to mention the X.509 privacy-destroying functionality for the unaware that has been implemented as the default behavior of the "payment protocol" in 0.9 clients.
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? |
|
|
|
|
Show Posts
