|
Yes, I did misplace the decimal point. I'm really good at that.
|
|
|
|
DeathAndTaxes: I'm normally impressed with your posts, but I think you've got some details wrong. First, RE: the orphan cost of transactions: Decker/Wattenhofer measured 80ms for a 1K bigger block. The math to compute orphan cost is: orphan cost = (block_reward+fees) * (1 - e^(-(1/target block time)*delta_time) Plugging in 25 XBT block reward, 600 target time, 0.08 delta time, and assuming no fees (to make the math easier): orphan cost = 25 * (1 - e^(-(1/600)*0.08) = 0.0033 So 3.3 millies per kilobyte is the orphan cost. Even if we assume Decker/Wattenhofer are off by a factor of two (we have made some improvements since they measured block propagation; better measurements welcome), default transaction fees (1 to 5 millies per kilobyte) are in the right ballpark to minimize orphan costs. the .1 default transaction fee does not come close to covering the orphan cost (edited: thanks foxpup). It should be fairly easy to get about another factor of about 10-20 reduction in orphan costs. And as I said in another thread, if EVERYBODY produces larger blocks then EVERYBODY bears the increased orphan cost, and the result is better for everybody . There is a fixed number of new bitcoins to be earned, regardless of the orphan rate; everybody's share of that fixed number will be the same if everybody has a slightly higher orphan block rate. But everybody will earn more fees, and their bitcoins will be worth more because bitcoins will be more useful. |
|
|
|
The fees can be lowered if the price rises too high. They have already been lowered several times for exactly this reason, and there's no reason to think it won't happen again.
Transaction fees are likely to go up (in dollar terms) for a while, until some engineering work is done to reduce the "orphan cost" for miners to include more transactions in their blocks OR mining pools / miners collectively agree to include more transactions for the good of the whole system. In the very short term, you can ask mining pool operators to create larger blocks. If they refuse, then switch your miners to a pool that does. If they all create larger blocks, then we get more transactions and more orphan blocks, but the cost of those extra orphan blocks is spread across everybody mining, so everybody gets just as many bitcoins (on average) as they would with smaller blocks. |
|
|
|
... if it would be possible to also have nLockSpace, which would lock a transaction to a specified set of x,y geo coordinates.
No. |
|
|
|
|
By the way:
I really like your proposal, ByteCoin. I think it captures the intuitive notion of "incentivize publishing blocks immediately as the best policy".
IF all proof-of-work-valid chains are relayed (and, as I said, my intuition is that they should be) then highest-number-of-transactionseconds seems like a very good criteria for resolving ties.
|
|
|
|
|
Unconfirmed wallet transactions are automatically rebroadcast by bitcoind/Bitcoin-QT until they are confirmed.
|
|
|
|
|
A surprising number of people will trade anything that has a price.
|
|
|
|
If this "80 msec delay" is the delay of the block being accepted by 51% of the nodes, then it means that most miners are loosing money by accepting a fee lower than 0.00333 BTC/KByte, which is the case most of the time.
This is because each 80 msec costs 25*80/1000/60/10 = 0.00333 BTC
Most of the current blocks have lower fees per Kbyte.
In turns this means that, if miners start acting rationally, a standard transaction cost should be at least USD 83 cents, with current exchange rate. Which in turns means if header-only-push is not implemented, the Bitcoin value cannot rationally be higher than 270 USD/BTC, since a 1 USD fee seems too much for most of the common payments.
Is this correct?
Yes. I am much more worried about transaction fees right now than "selfish mining". That is why I've been working on better fee estimation in the reference implementation. I agree with Mike-- we need better measurement, and we need to make "full-match merkle block relaying" the default to drive that 80ms number way down. |
|
|
|
|
Nice! Can you open source this?
Is the simulator accurately modeling how orphan blocks are (not) relayed?
It would also be useful to see total revenue, and total-revenue-expected-if-everybody-mines-honestly for both the entire network and the attacker.
|
|
|
|
I have several partly-formed thoughts. First, on "is there REALLY a problem" -- I think Ed Felten makes a good argument that, at least in the current world of mining pools, the incentives work to prevent "selfish" mining: https://freedom-to-tinker.com/blog/felten/bitcoin-isnt-so-broken-after-all/Related, I think it is important to remember that the current structure and behavior of the p2p networking code is NOT part of the fundamental consensus algorithm. It is easy to change, and, as I've said in the past, I would really like to see blocks and transactions being broadcast over some completely different networking protocol. I think there is a really interesting theoretical question that I don't know the answer to; I'll try to state it clearly: As the p2p network is currently implemented, nodes only have a partial view of competing best-chains, because nodes only relay the first node they see at a given height. If there are two blocks at the same height announced at approximately the same time, they propagate exponentially fast across the network in two waves, and only the nodes at the edges of where the waves meet will see both blocks. Given that network behavior, assuming no selfish mining, there is a strong incentive to announce your block as soon as possible, because in an exponentially fast race any delay is very likely to make you lose. There are lots of ideas for fixing selfish mining that rely on changing that behavior, and having nodes relay orphan blocks. I think it is important to remember that no matter what rules we SAY the network will follow, we can't stop individual nodes from implementing whatever rules they wish to follow; any solution that begins "If all nodes do THIS..." is not a solution. That applies to the behavior we have now about not relaying orphan blocks, too, of course. The interesting theoretical question I'm pondering: does the security of the Bitcoin system depend on the relaying behavior, or on how ties are resolved in block races? My intuition is that we SHOULD be relaying all orphan blocks, and should let each node decide how to resolve races, but before we talk about how to resolve races I think we should consider the incentives that arise from the current relaying behavior. |
|
|
|
I have done some financial analysis to see how fast an attacker can get benefit from this attack. Let's the total network hashing rate is stable. At the beginning of the attack, he will always loss some mining revenue as the diff is fixed and he will lose some blocks when he is trying to broadcasting his double blocks. And his attack will make the growth of blockchain slow.
If the attacker owns 30% of the network hashing power, according to the formula of on the paper ten, he will make the blockchain grows 1.8x slower than if not attacked. Assuming 50% of the block attacker broadcasts accepted, The revenue speed of the attacker will be influenced. He will loss 40% of his revenue if he had not attack, which is to make other honest miner mine even less and more slower. If the attack continues to next diff period, the attacker start to enjoy the benefit. He will earn more than 9% if he had not attack.
The attack invest 1.8*14=25 days time and 40% of the mining revenue (3600*25*30%*40%=10800 BTC, assuming still 25 btc per block), and he can earn more than 100BTC everyday, which earns investment in 111 days, during which time the whole community finds out his naughty behavior and make a hard-fork.
So, not a very wisdom attacker.
Please check whether my logic is right or wrong by independent calculation. Assuming the total net work hashrate is stable to make analysis simpler. First the attacker has to invest time and losing mining revenue to slow down other people, however the diff is fixed during the time, he is losing money to attack the network. The chain will grow extremely slower during the attack. The attacker suffers with other honest miner together, much longer than 14 days. If he is wealth enough and willing enough, Diff lowers, and he starts to harvest the benefit. However, the time to make his investment back is very long, and before he can earn back his investment, the community will have already make a hard-fork.
+1 This is the kind of analysis that I think we need more of before jumping to the conclusion that there is actually a problem that needs to be fixed. I'm not claiming that HorseRider is correct, but his logic looks plausible and I tend to listen harder to reasonable people who say things like "please check whether my logic is right". |
|
|
|
Is the bitcoin client able to handle 58,000 transactions per second and a blockchain terrabytes or maybe even petabytes in size?
Which "bitcoin client" ? The client-side of Multibit and electrum should have no problem handling that transaction volume. Only the transactions relevant to your wallet are sent to your machine when you are running those clients. The reference implementation can't handle that transaction volume today, but I 100% guarantee that version 11.11 which I 100% guarantee will be released on November 11'th, 2022 will be able to handle that transaction volume. I feel obliged to insert my standard disclaimer: Bitcoin is an experiment in progress. Only invest time or money that you can afford to lose, there is still a chance the experiment may fail for some reason we don't forsee. Past results are no guarantee blah blah blah. That said, I'm more confident than ever that the network will be able to scale up and remain decentralized. |
|
|
|
Thoughts?
Point 0 is just a workaround right? No; miners have a natural incentive to want to be closely connected to as many other miners as possible (to reduce orphan costs). RE: Evaluating sybil resistance: I would still like to see blocks and transactions being broadcast over another completely different networking protocol, either peer-to-peer or not. More diversity so we're not relying on the one p2p network would be great, and, depending on how it was implemented, might automatically bring sybil resistance. |
|
|
|
If that holds shouldn't Payment Protocol's use of CA be revisited?
No. If their anonymous credential scheme is successful (and I hope it is!), then the payment protocol should be extended to use it. The payment protocol is quite carefully designed so that replacing the public key infrastructure system is easy. |
|
|
|
The wealth is not in the "printed money" you are missing the point. The wealth is in the company that invests its time in the coin, and the people that will work for the coin.
Mmm. Maybe. That sounds a lot like the alternative local currency movement-- create a local currency that somehow expresses the local community's values. I'm probably just a too-logical, cold-hearted geek, but building community around a currency doesn't strike a chord with me. To me, community is about people, and a currency is just a tool for transactions. I guess an analogy would be a bunch of carpenters who build a community around some Extra Special brand of nails that they create and trade amongst themselves. |
|
|
|
You're right, I apologize. I just added libbitcoin to that list. |
|
|
|
|
RE: bitcoin-security mailing list: bottom line is I don't trust you. I think you have made irresponsible decisions in the past, and I don't trust that you would handle sensitive security issues responsibly. Happily there have been approximately zero cross-implementation security issues in the last six months, so it is more of a theoretical issue that you're not on the list....
RE: foundation phone call: I personally agree that fundraising for a vaporware wallet is less newsworthy than a 9 million dollar reputable VC investment.
RE: libbitcoin: when there is significant software using it and it has been "battle tested" a bit I'd be happy to mention it. But last I heard even Intersango was not using it because it was too slow/immature.
|
|
|
|
I went on FB search and typed in the following things, then sent it to EVERY page that came up:
Don't do that; spamming is evil. RE: hyper-complexity of the multi-coin paradigm: uhhh... Were you a postmodern lit major in college? I've got a pretty simple, but I think fairly accurate, view of money/wealth. I believe you can't create wealth just by printing money. You can create the illusion of wealth (and I imagine some Keynesians would argue the illusion is enough to lubricate the economy and somehow increase productivity and growth and wealth; lets set aside that argument). You can create wealth by making it easier for people to transact (and money is the world's best invention for doing that, barter is terribly inefficient). I'm still stuck on how y'all think altcoins create wealth. I don't see any of them being any easier to transact than Bitcoin. |
|
|
|
|
Please don't say "official client" -- there is no "official."
"Reference implementation" is more accurate.
Lack of SPV mode in the reference implementation is mostly due to lack of testing / code review resources.
|
|
|
|
|
Show Posts
