I admire how you care about poor africans who cannot afford to pay 0.001BTC for transaction while "you"(your white horse) stole 3,000 BTC into your pocket.
?? You're confusing me with Cypherdoc and claims on hashfast? No, I only had a feeling that you support cypherdoc's ideas. I support Satoshi's ideas. |
|
|
|
I admire how you care about poor africans who cannot afford to pay 0.001BTC for transaction while "you"(your white horse) stole 3,000 BTC into your pocket.
?? You're confusing me with Cypherdoc and claims on hashfast? @iCEBREAKER: while its true of course that black markets have a high margin and so therefore can handle high transaction fees, my honest hope for Bitcoin is that it allows every person to "be their own bank". I hope that it is not solely useful as currency of choice for criminal activity due to high transaction fees. That betrays the promise of crypto-currency (IMHO) RE: sidechains and Lightning -- these are vaporware right now, and I have seen too many 100million dollar startups fail due to a great vaporware story. Products have failed because they promise V2 with all these features, so people choose to wait rather than buy V1. But if you rewind this thread about 6 months you'll see that I was an avid supporter sidechains and lightning. Even if the technical details are a slam-dunk, the organizational details may be problematic. We don't know if individual companies will be backing these functions and therefore be pressure points and behave just like CoinCafe has done for the completely legal action of posting an ad on Backpage -- that is, block it due to fear of litigation. There is TREMENDOUS power in a 1-hop (no intermediary) peer to peer network with no "sponsoring" company. The political pressure attack surface is basically zero. Its unfortunate that certain people can't see the wisdom of reasonable scaling until we are certain that these issues work themselves out in a manner the protects an individual's inalienable right to property and the transactions that implies. I'm agreeing with you that the stress test was in general a success. I mean some people had 12-14 hour txn waits (according to reddit posts), but in theory wallets will now be changed to suggest fees dynamically. But this was a very static situation -- the spammer was issuing txns at a well known fee so it was easy to outbid him (if you read reddit and knew what was going on, which you know most casual users won't do). But the the point of the spammer was to fill blocks, NOT to get his txns IN a block. However, the situation will be VERY different when there is sustained 110% demand by people who need their txns in a block. |
|
|
|
iCEBREAKER makes 2 posts IN A ROW without ever realizing they espouse mutually incompatible futures for bitcoin. The first talks about how fees will increase given limited supply of transaction space (block size) -- a fact that was never in doubt. And it includes an awesomely honest quote from MP (which others have already commented on) which basically espouses plutocracy -- rule by the rich (although "rule" in this context may be more that the rich do whatever they want and everybody else sucks it up). The second post talks about the growth and value of the "underground economy" (of which the black markets are a subset) and how technologies should be focused on it. However, the underground economy is characterized by lots of small transactions. The underground economy isn't going to fit in 1 MB, and can't afford high txn fees (please read Hernando De Soto, The mystery of Capital). The only thing that will fit the 1MB block limit profile are large settlements between banking institutions. The recent spam was a technical test and succeeded, as far as it went (we did not see the sustained mempool growth we will see when demand is consistently above 100%). But it was not a social test. Recently on reddit we are hearing exciting reports of 1000s of new customers (likely operating in the underground economy) getting their first bitcoin ($5 to $10 worth) for backpage advertisements. What if the message coming from them had been different? What if it had been: "This is unusable. I don't want to pay this $1 (aggregate of a minimum of 3 txns, 1 xfer to wallet, 1 to plausible deniability address, 1 to backpage) fee to get $5 of backpage ads. And its taking forever to see the bitcoin actually show up in my phone!" Frappuccino_doc's car insurance is about to go up. Because the Gavinmobile just got wr3cked, again.  EDIT: Great minds think alike:  The recent surge in Backpage BTC use proves how spot on Justus was with his Black Market blog post. Its obvious that BTC will change how we do commerce, no the other way around.
Agreed. Justus hit it out of the park with that one. Sigworthy quotes therein: |
|
|
|
 What's wrong here? block size decrease. really? He's just confused. He seems to want some kind of centralized control: I think it's time for miners to drop their max block size ASAP. Or maybe a better solution will be to simply up the min fees.
But then he (correctly) suggests that the miners should make these decisions. Yes, that's why Bitcoin has an intelligent/human component: the miners. Miners are supposed to make decisions to help filter the spam and low priority traffic, so the real transactions aren't affected. The simplest way to do this is to increase the minimum transaction fee.
Well then I guess by his own argument the miners are not finding any issue with the network as it is running today. Its not the MINERS that have an issue (or they WOULD change their block size), its Luke jr. (same would happen if block size got "released" to 20 or 100 MB -- not that I'm advocating for this, I'm advocating for compromise -- the miners simply would not mine gargantuan blocks. Except for one or 2 rogue miners who might do so every once in a while for the lulz) |
|
|
|
This is a prefect example of someone pulling casual, quickly written stuff from a public figure and using it to pump their own agenda. I mean we all argue about almost everything, but do you seriously think that any Bitcoin early adopter thinks that the overall long term global financial situation is peachy? If Gavin wanted to waste his time, he'd probably go back and edit this comment to say "since the first chapter of the financial crisis is over..." Of course, given Greece and China it looks like chapter 2 is just starting...  |
|
|
|
Don't worry. According to Mike Hearn Bitcoin can survive just fine with 4 or 6 (forgot which) copies of the blockchain worldwide. Is he right or wrong about that? Via what methodology would we test that hypothesis before arriving at a conclusion about its validity? Who cares? Before you ask that question you need to show reasonable likelihood that increasing the block size to 8MB will drop the number of full nodes to 4 or 6. Frankly, I think that a dramatic reduction of nodes is more likely if Bitcoin becomes a settlement network than if the block size is increased to 8MB. NOBODY will be interested in holding the data if they can't use the network, so the only full nodes will be those sponsored by the payment aggregators. These aggregators are also perfect locations for governments to apply identity and green address pressure, destroying fungibility. |
|
|
|
Not to start Cypherdoc foaming at the mouth but could the blocksize cap actually be worse than worthless given spammers and other attacks? The two ways I could think of are: 1. spammer posts txns that flood the network and then somehow invalidates, overwrites them (if you RBF by +1 satoshi would that use the same network bandwidth as a new txn, for just 1 extra satoshi?), or just expects that they age out before they hit the blockchain, saving himself the txn fee. 2. txns fill up expensive RAM for hours/days rather then be rapidly promoted to cheap practically-infinitely sized disk space (2 TB on a SSD just announced). |
|
|
|
You people are getting vicious and inane. Name calling like a pack of 8 year olds? On another topic: http://rusty.ozlabs.org/?p=515The obvious place to look is CheckBlock: a simple 1MB block takes a consistent 10 milliseconds to validate, and an 8MB block took 79 to 80 milliseconds, which is nice and linear. (A 17MB block took 171 milliseconds).
Weirdly, that’s not the slow part: promoting the block to the best block (ActivateBestChain) takes 1.9-2.0 seconds for a 1MB block, and 15.3-15.7 seconds for an 8MB block. At least it’s scaling linearly, but it’s just slow.
Not quite Peter R's calculated value, but indicative that there may be issues hidden in the code that do sum up to significant block delay. |
|
|
|
Very dangerous. ECB could respond by claiming all Y series notes not legal tender. Of course greece could presumably print other serial numbers easily. And it could invoke the nuclear option where all greek overseas bank accounts are frozen and ultimately confiscated. Where is qoute about double txn validation? Should be unnecessary... but Euros are fungible, are they not? They aren't exactly the same so there's a tiny possibility to break fungibility. Any serial # beginning with a Y was printed by the Greek central bank... other countries could give their citizens 1 week (say) to exchange any Y notes that made it across the border for equivalent value. You'd show up at any bank (say) with photo ID and the bills. Of course the press in Greece could probably be modified to change serial numbers pretty easily... |
|
|
|
Very dangerous. ECB could respond by claiming all Y series notes not legal tender. Of course greece could presumably print other serial numbers easily. And it could invoke the nuclear option where all greek overseas bank accounts are frozen and ultimately confiscated. Where is qoute about double txn validation? Should be unnecessary... |
|
|
|
Am I being sensitive or is this an unnecessarily spiteful reply from Greg Maxwell?: ...
You've shown that you can throw a bunch of symbolic markup and mix in a lack of understanding and measurement and make a pseudo-scientific argument that will mislead a lot of people, and that you're willing to do so or too ignorant to even realize what you're doing.
He sounds bitter. Oh boo hoo, poor Peter got mildly but most-deservedly flamed for spouting pseudo-scientific nonsense on stilts. He'll be in therapy for years!  Gmax is just understandably impatient with his job being made harder by the Gavinistas' endless defamation, exaggerations, BS, and agitprop: Gmax is not a punching bag; he's allowed to hit back when people accuse him of obstructionism for personal profit. The Gavinista whining about 'ad hom' in that context is spectacularly hypocritical. "I'll post the napkin pic illustrating Evil Blockstream's Snidely Whiplash scheme, then tsk-tsk Gmax for reacting with anything more than cool professional detachment...that'll show everyone what Awful People the core devs are!" But nevermind that, let's all weep for poor barbequed Peter. I'll send him some aloe vera lotion, care of the burn ward.  Gmaxes argument lives and dies on his assertion of 80ms block validation times. We now have to go off and independently verify this. Then we have to figure out the discrepancy between this number and the painfully slow sync times and 100% cpu use during sync. This work may discover inefficiencies and result in optimizations that have nothing to do with the holy war going on. Peter is looking at the system as a black box and analyzing its emergent properties. Gmax is looking inside the box. We need to resolve the contradiction. Regardless gmaxes argument was not a barbecue -- that would have happened if the math was flawed for example. In fact gmax's "argument" is just another guy making an unsubstantiated (but likely true) contrary claim. You know this because what if you run core and post "that's funny I am seeing 5 sec times"? What happens is gmaxes entire argument fails. Its sad that you can't tell the difference between an argument and an unsubstantiated claim. |
|
|
|
Am I being sensitive or is this an unnecessarily spiteful reply from Greg Maxwell?: ...
You've shown that you can throw a bunch of symbolic markup and mix in a lack of understanding and measurement and make a pseudo-scientific argument that will mislead a lot of people, and that you're willing to do so or too ignorant to even realize what you're doing.
Its a strategy (implemented unconsciously by many) to limit participation to the select few. Unfortunately it tends to create a situation where only similar personalities contribute which is where we are today with the core devs, Gavin excepted. I read his 21ms validation number but its weird because I was wondering just weeks ago why it was taking so long to sync a measly week of blockchain data and came to the conclusion that either the P2P code is complete garbage (compared to bittorrent for example) OR the validation cost is high (given my fan speed, I assumed it was validation). And if validation is so fast, why would these pools have custom code to skip it? It will be interesting to look at stats gathering mode he mentions. |
|
|
|
If the txn input states that block B is the UTXO then the invalid proof is simply to supply B, right? That's one way to do it, however even this can be shortened. Right now with all the blocks < 1 MB it's not really a big deal to supply the entire block to prove that the referenced transaction doesn't exist, but it'd be nice to not require the entire block especially for when blocks are larger. By adding a rule to new blocks that require all the transactions to be ordered by their hash, you don't need to supply the entire block to prove that the transaction doesn't exist. It would be good to have that ordering requirement in place before blocks are allowed to grow to make sure that fraud proof size is bounded. Makes sense... I'd recommend a quick line or two in your blog to explain that: "In order to reduce the size of the fraud proof needed to show that a transaction input does not exist, additional information must be added to Bitcoin blocks to indicate the block which is the source of each outpoint used by every transaction in the block. A node can provide the source block to the SPV client to prove or disprove the existence of this transaction. But with a few more changes we can provide a subset of the source block. This may become very important if block sizes increase. " |
|
|
|
Your modification to require the inputs to state which block it comes from is a clever way to reduce the addr does not exist proof. But I dont understand your subsequent complexity. If the txn input states that block B is the UTXO then the invalid proof is simply to supply B, right? |
|
|
|
|
What if there were too many txns for any one computer to hold and process? A full node could be implemented by a network of computers that trust each other but this would necessarily be costly and centralized. But a more common situation analogous to todays P2P bitcoin network would be that every node knows a fraction of the txn history and can make statements like these UTXOs are confirmed by X amount of work. Of course any node could request and verify the validity of any txn data it does not hold... so both of the above could coexist.
TL; DR Is it emotionally acceptable (as a holder of coins) that your node can't verify every txn that ever happened only those that it is interested in and so must rely on the network as a whole to validate the txns as a whole?
|
|
|
|
OK, let's try again. Ever heard of 'packet filtering?'
If you are the engineer you claim to be you know damn well how easy it would be to hide Bitcoin txns from a DPI DSP engine inside a HTTP image request, an audio or video stream, or of course via an encrypted connection. Please don't post arguments that you know are illogical but you think will convince others. It does not further the discourse. In my experiments with steganography many years ago, I find it cuts down available bandwidth by orders of magnitude. At that time it was unclear if it was even theoretically possible to hide things fully, although it was pretty clear that one could cause the waste of huge amounts of an attacker's CPU if you made him look. The utility I used most was 'steghide'. A while ago I looked it up again. The source code was still available but it had not been changed in years. In looking just now I notice that there is a French version of wikipedia which has an entry but I can find no English one and Google translate doesn't work on it. Weird. https://fr.wikipedia.org/wiki/SteghideActually, there is a point to be made that individual transactions could be hidden steganographically for spends no matter what the network transaction rate and it is kind of questionable whether the backbone itself could run fully steganographically hidden even with 1MB blocks under dedicated attack by funded and motivated attackers (who own the network.) Ideally I'd like to see it practical for the backbone network to be operation fully on side-channels which make no use of the global internet at all. In any real attack situation it is very unlikely that any infrastructure operator would enjoy the streaming class of network traffic that we know today. That is another reason I would like to avoid developing a reliance on real-time behavior (or even ~10 min/conf expectations) or structured block formations and so on. The Blockstream folks making mention of expectations in the days range gives me hope that they are designing for worst-case scenarios (which is exactly what I need to feel comfortable about storing significant value in Bitcoin.) Edit: BTW, I've got very little expectation that encrypted connections without government backdoors will survive indefinitely. No design that I trust for longer duration work will make that expectation. Its steganography to hide a bitcoin txn from a human inside a hidden channel. But its so simple to hide from a packet inspection engine I wouldn't even call it steganography... for example the "image" downloaded could look like random bits to a person (obviously not a meaningful image) but the packet inspection engine would not be able to determine that. |
|
|
|
One of the things that's missing from the block size debate is a usable threat model that would allow us to make objective and rational risk assessments of the various threats loosely defined as "centralization".
Before we know how worried we should be about larger blocks (potentially) reducing the number of nodes, we need to know exactly how an attacker benefits from this situation and what kinds of mitigating factors and/or countermeasures are applicable to each attack.
I haven't heard any kind of analysis along those lines yet.
Yes, excellent point. Because there is not much AFAIK. Really, the power is in the hands of the miners (mining pool operators), which is already ironically very centralized relative to nodes. Off the top of my head, fewer nodes would make it easier mount a Sybil attack to isolate a node or SPV client and then feed it incorrect data. |
|
|
|
Ever hear of Edward Snowden? Do you know what it means when someone in the 5-eyes says that they 'own the internet?'
As an infrastructure the global internet is no where nearly as robust as most people imagine. It can be much better, but there is little incentive and this is no accident. Most people cannot fathom designing in any other way but to maximize the capabilities granted by the owners of this resource and are dimly aware, if at all, how tenuous some of the capabilities are.
My sensibilities as an engineer and system designer had been to design for the worst plausible scenarios. In a great many cases this resulted in some wasted effort and some limitations. In a minority of cases it turned out that some of the worst fears were realized and my systems continued to perform to design. These minority of cases outweighed the majority by a mile. Part of the reason for this is that the super-systems did not become reliant on capabilities which the sub-systems were unable to deliver.
actually, i have. and he is precisely one of the reasons i think we're winning. the NSA and 5 Eyes, i believe, are going to lose in the long run precisely b/c Snowden's leak shows they can't secure data. everyone knows this now which is why Google and Apple have started encrypting as default, much to the chagrin of the gvt. and this is happening all over the internet. furthermore, with 21 Inc on the verge of releasing mini Asic chips that power devices, the chances for mass decentralization of Bitcoin goes up. also, the Internet has never had it's own monetary system or means of conveniently and cheaply paying one another in realtime. Bitcoin, for the first time in history, can provide that. OK, let's try again. Ever heard of 'packet filtering?' If you are the engineer you claim to be you know damn well how easy it would be to hide Bitcoin txns from a DPI DSP engine inside a HTTP image request, an audio or video stream, or of course via an encrypted connection. Please don't post arguments that you know are illogical but you think will convince others. It does not further the discourse. |
|
|
|
Once upon a time when gold was used as currency, silver was also used because you couldn't reasonably mint coin small enough to pay for things like a meal (I heard that this is also why the "bar tab" was invented -- when even silver became too valuable).
With Bitcoin, it seems like 1 Satoshi is small enough to ensure that a "silver to bitcoin's gold" does not happen. However, I think that this is untrue; 1 Satoshi is analogous to 1 atom of gold. The actual minimum bitcoin transfer can be estimated by the point where is becomes inconvenient or expensive to make the transfer. This varies by the individual but I feel it would be a transaction fee of somewhere between 1 and 10 percent.
So the Satoshi is not the smallest effective Bitcoin unit. The smallest practical bitcoin unit is something between 10 and 100 times the transaction fee.
I think that the result of an unscaled bitcoin blockchain is that small-payment niche will open up, allowing a scalable altcoin blockchain to gain market share (lightning network, centralized solutions, and sidechains may block this niche, to an unknown extent -- but note they didn't for gold). This cryptocurrency will begin as the "silver to bitcoin's gold", and a clever implementation might ride Bitcoin's coat-tails to adoption. If Bitcoin becomes extremely successful this new cryptocurrency will overtake it in daily use just like silver overtook gold. But what advantages will Bitcoin have over this new currency? Gold's advantage was essentially its greater value to volume (and weight) ratio. But (as with any crypto-currency), you'll be able to carry and transact large quantities of this new cryptocurrency just as easily as small. So Bitcoin will have no advantage. The new cryptocurrency will ultimately dominate transactions and market cap.
What do you think about this reasoning?
Very close, but no cigar. You miss the security gap. This is the real selling point for bitcoin. Silver and gold had very similar security profiles, with gold only being ever-so-slightly better (the value per weight). In crypto, each coin that has it's own chain has a distinctly different security profile. At this point, bitcoin is in the lead when it comes to security of the ledger. Unless this other coin offers better security, or at least very close to equal security, the scenario you theorize is not possible. It could happen, maybe, someday, but not currently possible. you may be the one missing something. what i think he was saying is that if Cripplecoin is allowed to remain in place even with the addition of SC's or LN, it won't be able to compete with a lighter nimble altcoin that has no such block limit. reason being, that some feel that SC's or LN, esp if Blockstream is allowed to continue it's financial confliction, will result in a centralized, settlement level, high tx value type unusable cryptocurrency only for institutions, geeks, and wealthy elite. that is, if it doesn't just outright die from small niche use. a truly scalable Bitcoin knock off w/o this confliction and centralization might be able to truly take off and fund the masses even at the level of microtx's. let's hope this isn't what has to happen. This is what gives me the fear: This coin provides an integrated BTC wallet on both PC and phone, simply by forking existing open source Bitcoin wallets and adding "new coin" code (so this is not much harder than creating standalone "new coin" wallets). The wallet allows you to make trustless anonymously exchanges between new coin and BTC. This is very easy to do technically: you add a special txn to the new coin which says "only valid if there is a Bitcoin TXN to this public address with N confirmations". Seller of new coin issues this its first, the Bitcoin seller issues its txn when it sees the new coin txn. If the Bitcoin seller's txn is not issued or confirmed, the new coin txn is invalidated (it remains on the new coin blockchain but becomes a no-op). |
|
|
|
|
Show Posts
