Our merchant M might have hundreds or thousands different customers daily. So he has to produce and transmit hundreds, thousands special addresses to his customers.... Even with perfectly integrated QR-Codes this is not just fun.
Oh noes! We can't just use one invoice for everyone, but we have to make one special for each order. The horror... Seriously, can you guys stop feeding this troll? He has absolutely zero understanding of how bitcoin actually works, so he made up a bunch of nonsense in his head, and now he whines on the forums that his imaginary version doesn't work right. For example... In normal life we register the bank accounts of all our customers/merchants just once in our accounting system.
Bank accounts of merchants are printed on each letter/invoice.
With current BTC you have to change thousands of these entries ("addresses") daily.
Even for the same customer buying several things in different contracts.
Result is an error-prone MESS with daily thousand probabilities of errors.
Imagine that a customer/merchant might use in any case the wrong address.
How can that be repaired?
This is so full of fail that I'm not sure where to even start. I guess I could say that addresses don't delete themselves once used, but I think my words would fall on (willfully) deaf ears. |
|
|
|
|
I suspect that there are some in the chain, but I'm not sure how to search for them. These days, we (generally) use P2SH instead of plain multisig. In P2SH, the address shown is the hash of the redemption script, so just one address is shown (starting with a 3).
|
|
|
|
.95 and 4 are magic numbers. .95 needs to be very high, to allow an easy veto of the next increase. If miners want bigger blocks for some reason, they can certainly pad their blocks. This isn't a big deal, since roughly 6% of the network could execute the veto.
That's not true; you need 51% of the network to execute the veto because a majority can simply ignore blocks that don't use the full blocksize and thus trigger that rule. If this becomes a "us against the holdout miners destroying Bitcoin for the other miners" that's exactly what will happen. They could also reject votes. Or do far worse things. Bitcoin is based on the assumption that at least half of the network is honest. Most of it falls apart if that assumption is violated. |
|
|
|
My full reply: http://sourceforge.net/mailarchive/message.php?msg_id=31037850Something to keep in mind about the proposal is it is very carefully constructed to ensure that miners can't sway the vote. Remember that miners can always decide to decrease the blocksize by just mining small blocks; it's increasing the blocksize that is the issue. The proposal is very clear that miners can only increase the blocksize by proving to the community that there exist votes to increase it which is why simply doing nothing in the proposal is you voting to keep the status quo. If that weren't the case miners could simply block votes they don't like and force whatever increase they wanted. If just a few such votes exist representing just a small portion of the Bitcoins in circulation, the maximum blocksize will increase by a very small amount, if a solid consensus exists, the blocksize can increase by as much as the community wants. Finally the proposal is careful to take "lost coins" into account by making coins that haven't moved in more than 1 year have an increasingly smaller weight in the vote. It's a solid proposal and a democratic way of making a very tough decision. I think the trick is to make it easy to veto increases. My proposal was this (to be run during difficulty changes) : if ( sum_last_2016_blocks > .95*current_block_size_limit*2016 ) {
limit_delta = current_block_size_limit >> 4
new_block_size_limit = current_block_size_limit + limit_delta
}
Note that there is no provision for limit decreases. All increases are permanent. .95 and 4 are magic numbers. .95 needs to be very high, to allow an easy veto of the next increase. If miners want bigger blocks for some reason, they can certainly pad their blocks. This isn't a big deal, since roughly 6% of the network could execute the veto. Higher values of .95 mean less mining power is needed for the veto. Oh, nifty extra benefit, if the size increase is really warranted, those trying to veto will have to pay for it passing up fees. 4 is just a limit on the rate of growth. A bigger number may be wise here, since the opportunity for limit growth comes up so often. I hate to say it, but it really looks like this is yet another place where reality intervenes to make POS systems unworkable. |
|
|
|
The difficulty increases only every 2016 blocks. If a lot of hashing power comes online quickly, the network can find blocks faster, for a short time. The same thing happens in reverse if the hash rate drops for some reason.
ok I get that-but if the pools hold the coins that should not affect the price . is it not only if there are more sellers than buyers the price drops? if so where are they selling? it appears mtgox and other exchanges are having difficulty in getting fiat into them to sell in high quantities?. reg. You really need to learn to use the quote feature. I was just answering the difficulty question. The cause of exchange rate shifts is unknowable, no matter how many threads pop up asking about or blaming gremlins. P.S. The quantity sold is exactly equal to the quantity purchased. Shifts in price reflect a change in the relative desires to hold of the parties involved, only. |
|
|
|
How do you get a license tab sticker that says 2015? And also bitcoin on the sticker?
Not all states are necessarily annual. Typically, the year stickers have the license plate number they belong to if made for a specific plate, like when the plate is new, or when renewal is done by mail. No one ever looks at front plates, so putting the plate number (or a code that can be queried in a database) on the sticker keeps people from updating two cars for the price of one. |
|
|
|
It may also have to do with the fact that we are producing far more than 3600 bitcoins per day, in a sustained rate for several months now. At this moment, for example, we are at 176 blocks per day. Last week I believe we reached 200 blocks per day just before the difficulty change.
I did not know this? I thought the difficulty rate kept block production at 1 every 10 mins? what happens when asics really hit then?. reg
The difficulty increases only every 2016 blocks. If a lot of hashing power comes online quickly, the network can find blocks faster, for a short time. The same thing happens in reverse if the hash rate drops for some reason. |
|
|
|
|
` is also commonly called a backtick. I've even seen it called that by non-unix/non-technical people to disambiguate the thing on the keyboard and the thing in ASCII from a "proper" grave. In fact, I'm not sure that it is even technically a "grave" when it isn't attached to a vowel.
Similar problems come up with quotation marks. ASCII has "single quote" and "double quote", but again, they aren't "proper", so some people call those versions by those names to distinguish them from actual real "quotation marks".
|
|
|
|
Script written and running.
bitcoind seems to respond to a getblock request pretty slowly, so it will take a while to scan the entire blockchain...
Reading the block files directly would be much faster. |
|
|
|
I nearly shot beer out my nose when you called him "elite of bitcoin".
Hehe. I'm willing to call "elite of bitcoin" anyone who considers himself as such..  Then you rage against figments of your imagination. You should stop doing that. It is a very clear sign that your tinfoil hat is on too tight. P.S. Barring some catastrophic break in SHA, something that advances our knowledge of cryptography by a couple of decades overnight, there is no chance of a change in the POW system this year. Anyone that tells you otherwise is a deluded attention whore (Hi Dan!), or doesn't really understand how bitcoin works. |
|
|
|
|
That's debatable. But he certainly isn't important here.
I nearly shot beer out my nose when you called him "elite of bitcoin".
|
|
|
|
|
You don't actually know who Dan is, do you?
|
|
|
|
|
Getting the gitian build system working is not a trivial task. New releases are typically delayed for several hours while the dev team waits for more people with working systems to show up to verify the hash of the resulting binary.
If anyone is looking for a way to get involved and help the project, setting up another build environment and hanging out in the dev channel on release days would be a good way to do it.
|
|
|
|
How Much: calculating...
Let me remind you of @kjj idea, which I find interesting: When we do need to increase the limit, I would propose the following rules: Block max size increases iff at the time of difficulty change, the sum of the size of the last 2016 blocks is > (1814 * block_max_size). If size increase is indicated, block_max_size+=(block_max_size>>4). I'll leave the implications as an exercise for the reader. 1814 and 4 are magic numbers, they could be changed, but I suggest they not be any smaller than specified.
Though I would consider adding some high hard limit too (100MB-1GB) Upon further reflection, I now feel that 1814 is too small of a number. 1915 would be better, possibly even higher. In regards to all of the talk about banning encryption, I guess no one remembers the 90s any more. The cypherpunks won that battle in the past. The genie is out so far now that no one even remembers that there was a lamp before. |
|
|
|
You win the Orwellian of the day award for having successfully used every term you included in that rant as if it meant the opposite of its meaning.
What I want is for the network to be allowed to provide a service at a quantity and price that they and their customers find acceptable. You want to ration the amount of transaction processing miners are allowed to provide to their customers.
The fact that we don't know how much it costs to process a transaction is expected and irrelevant. Miners won't continue to mine if the benefit the receive does not exceed the costs involved, and users will not send transactions if the cost of doing so exceeds the benefit they derive. That's that that matters. If you don't believe this process works in the real world then you should really contemplate how it's possible for the providers of the products and services you consume every day to figure out the correct amount to produce and the correct price to offer it at.
There is always rationing. The question is how. In a mature system with a market, I'd let the market figure it out. That's what market are for, and that's what markets do. But we don't have a mature system, and we don't have a market. Not only do we not know what a transaction really costs, we don't have any way to find out. You are arguing as if I didn't believe in markets. I do, but I only believe in real markets. I have absolutely zero faith in the ability of a market that does not and can not exist to provide useful information. In the absence of useful information, it is prudent to be careful. Since backpressure on the transaction volume does not reasonably exist yet, and whatever actions we take will have serious long term consequences for the entire world, we should not just remove the limit, nor create dynamic rules that are too easy. When we do need to increase the limit, I would propose the following rules: Block max size increases iff at the time of difficulty change, the sum of the size of the last 2016 blocks is > (1814 * block_max_size). If size increase is indicated, block_max_size+=(block_max_size>>4). I'll leave the implications as an exercise for the reader. 1814 and 4 are magic numbers, they could be changed, but I suggest they not be any smaller than specified. |
|
|
|
The brick wall thing seems like a particularly silly analogy. People are already competing for block space with fees. Why are people doing that when block space is effectively infinite? Why are miners encouraging that when the fees are so meaningless in comparison to the subsidy? It seems like the car hit a wall of jello a couple of miles before hitting the brick wall. The brick wall is analogy is accurate because It's the difference between being able to send transactions and not being able to send transactions. Right now all the users who want to send Bitcoins can do so because the total demand is lower than the protocol limit. Once the blocks fill up we'll get to a situation that changes. If more than 5000 people want to send a transaction in the same 10 minute interval they won't all be allowed to do so, no matter how much they are all willing to pay in fees. The ability to use Bitcoin will be rationed to a fixed number of entities. What I want to know is, how much cheaper? How well will people innovate? Are people willing to pay enough in fees to keep mining going as the subsidy declines? What is the actual marginal cost of including a transaction? How will that change over time?
There are a lot of question marks between where we are and where we want to be. It seems imprudent to assume that they will all be resolved to our liking.
It's complete economic and historical ignorance to assume the best way to answer any of those questions is with central planning in the form of transaction rationing. Miners will mine if they can obtain a market price for their services that is acceptable to them. Users will initiate transactions if the price if sending transactions is acceptable to them. Not only is there no need to second guess price discovery by trying to calculate the marginal cost of handling a transactions and using that as the basis of a magic number in the protocol but also succeeding at such a strategy is probably impossible. I'm not sure why you think that there is some sort of free market for bitcoin transactions. I have a lot of confidence that someday there will be such a thing, but for the next couple of decades (and possibly for the rest of my life) there is not and will not be. Right now, every single transaction (with a couple of exceptions caused mostly by programming errors) is mined as a charity. There is also some indirect benefit to the miners, in that the network actually working makes their holdings more valuable, but there is nothing even slightly resembling a balance between cost and reward. To recap, we have no idea what it costs to process a transaction. Even without the block size limit, there is a limit to how many transactions can be processed by the network in a given time. There is a much smaller limit to how many can be processed economically. And there is a vastly smaller limit to the number that could be processed economically without the subsidy. We have no idea where these limits are, and they are all moving targets. If we were starting at 100% adoption, Moore's law would let computing power keep ahead of the game, and probably even pull out far ahead. But we aren't at the top of the adoption curve, we are at the bottom. In the short run, the vertical slope looming is going to kick all of our asses. There will be a period when the system won't be able to keep up with demand for reasons other than an artificial block size limit. God help us all if we've evicted all of the small miners (less than, say, 100 million readily available capital) from the network before that happens. I'm really not sure why I bothered to write this reply. Your want the network (people other than you, at least mostly) to have to provide a scarce resource in unlimited quantity, while you accuse me of advocating central planning for pointing out that the market that you need doesn't actually exist. |
|
|
|
Virtually every bitcoin user already uses third parties, and trusts them to some extent. Doing so is a trade, cost for risk. In the future, I expect it to be even more complicated. Imagine a credit card denominated in bitcoin. With that, you'd be paying for them to assume transaction risk for you, while right now the model is mostly the opposite with you getting a discount for assuming the risk that the third party may bail with your bitcoins. Right now trusting third parties is an optional choice that a user can make. In a scenario in which the demand for transactions exceeds the protocol-specified limit they won't have a choice - the only way average people will be able to use Bitcoin at all is to let a third party hold their coins for them. At this point Bitcoin is dead because it's become just another Dwolla or PayPal. Bitcoin's main innovation is not that you hold your own dollars. The mad scientist in me thinks that we should wait until the 1 MB limit is met and sustained for a while before we raise it. That way we'd get some real world experience with how the system (including the people!) react. Imagine an accelerating car driving into a brick wall. One day the number of users and transactions will be increasing exponentially and then suddenly the growing user base will be rationed to a fixed number of daily transactions. It won't matter how much the users are willing to pay in transaction fees or how much the miners are willing to provide a higher transaction rate - the network will be limited to a constant number of transactions. It's madness to blindly assume that Bitcoin will continue to be useful and in adoption after its use case is fundamentally reversed. Right now the demand for transactions is below MAX_BLOCK_SIZE, so effectively we have no limit. What we're looking at right now is how users and miners behave with "infinite" block sizes. Users are willing to pay fees, and the fee revenue grows proportionally with the transaction rate. We don't have to speculate about this because the real data is available. Allowing Bitcoin growth to suddenly hit an artificial limit really is playing mad scientist with what will be at that point a multi-billion dollar economy. Incidentally that kind of central planning is exactly what many people are adopting Bitcoin to getaway from and you're ready to pull the rug out from under them right when they least expect it. I can imagine all sorts of things. What I'd prefer is to have some data so that I can spend less time imagining. The brick wall thing seems like a particularly silly analogy. People are already competing for block space with fees. Why are people doing that when block space is effectively infinite? Why are miners encouraging that when the fees are so meaningless in comparison to the subsidy? It seems like the car hit a wall of jello a couple of miles before hitting the brick wall. Where you see a brick wall, I see a ramp. The way ahead gets steeper when we hit the block size cap, but nothing stops or explodes. If the demand for transactions stays steady or increases, then on-chain transactions will get more expensive, which makes off-chain transactions cheaper by comparison. What I want to know is, how much cheaper? How well will people innovate? Are people willing to pay enough in fees to keep mining going as the subsidy declines? What is the actual marginal cost of including a transaction? How will that change over time? There are a lot of question marks between where we are and where we want to be. It seems imprudent to assume that they will all be resolved to our liking. |
|
|
|
Without knowing exactly what you mean by "senderLastMod", I'm can only speculate. I'm hoping it is something that provides replay resistance, because that would mean that you decided to keep "secure" at the cost of "useful" and "decentralized".
Yes, it prevents replaying. Don't keep us from your wisdom. Say why such efficient txs are not "useful" and why are "centralized" Yup, a pony is an immature horse. Still more useful than a pegasus. No. It is thing that has all requirements of pegasus but only pony features. It is very common for people that don't understand the system very well (which you may or may not be) to vastly underestimate how much we got "for free" from our transaction -> transaction system. Because each transaction is unique, it has a unique hash, which means that the transaction redeeming an output from it is also unique. This means that each signature is unique, etc, etc. In short, a replay in bitcoin is just the same transaction again, not a new instance of "Move X from A to B". I'm not really keen on speculating about what senderLastMod means, and you don't seem inclined to tell me. Hopefully this means that you've solved some really hairy problems in distributed computing and are too busy writing your system to explain how it all works. More likely, you think that you can use either the index of the latest version of the ledger or a per-address sequence of some sort as the nonce that protects your signature. Both of these options have big problems in the real world. You seem like a smug little prick. Either you came by that bearing honestly, in which case I don't need to tell you where this scheme falls apart, or you are talking about things you don't really understand, in which case I don't want to tell you. I suspect the second, so I'll conclude with a hint. "transaction rate vs. convergence" |
|
|
|
Set the limit to 10+MB and its almost certain that 5 years from now nobody will be able to run a bitcoin node at his home PC, through a DLS connection, not to mention via Tor.
I agree that decentralization is a priority. Though I think at least up to 100MB (if avg tx fee> $.1) we are perfectly safe in that matter, if we abandon Tor. I would be very hesitant to abandon tor, and you should be too. A lot of people are concerned that miners will soon find themselves in legal trouble. I suspect their concerns are excessive, but what if they are right? Right now, we can run the entire system over tor, which essentially makes it unkillable. Until we are sure that we no longer need to be concerned about such things, or until a more efficient way to be unkilable comes along, we should not be making any changes which make truly anonymous operation harder. |
|
|
|
Give me a list of your 24 bytes, and I'll give you a partial list of capabilities you've thrown away. Without knowing your scheme, I'd guess that some subset of "secure", "useful", "decentralized" is not possible with the information you are keeping. Most likely, you've lost at least two of those.
<tx type, offsetSender, offsetReceiver, senderLastMod, amount> 1 + 5 + 5 + 5 + 8 = 24 This is simple pay to address transaction. I could probable make amount field even smaller and account offsets to until there are more than 2^32 simultaneous non-zero accounts. Without knowing exactly what you mean by "senderLastMod", I'm can only speculate. I'm hoping it is something that provides replay resistance, because that would mean that you decided to keep "secure" at the cost of "useful" and "decentralized". If we've had the scripting debate before, I'll just refer you back to that. I'm not sure how many people there are out there that think it wise to upgrade every node in the network all at once for every new transaction type. I thought that one was too many.
A scripting system lets everyone figure out what they need without needing any (new) help from the rest of the network. Writing new software for each transaction does in theory, allow more transaction types, and in that sense can be more "powerful", but it just isn't going to happen in a decentralized system. Do you also argue that no one should own a horse because a pegasus would be much better? In this case, the horse is just a pony, but the pegasus is still not real.
Reality check: Security, yes (including potential for denial-of-service attacks of various sorts).
But demonstrate a spiffy, compelling use of new opcodes on testnet and we'll talk about making them standard.
Yup, a pony is an immature horse. Still more useful than a pegasus. |
|
|
|
|
Show Posts
