Topic: Bitcoin 20MB Fork - page 13. (Read 154787 times)

Blending a pound of feces with a pound of pasta doesn't give you a kilogram of anything remotely edible.
What do you expect will come out of these mixers? Whitelisted coins?



So, how would you actually, in practice, create such a, ahem, "smart contract" ?

If you think coins can be blacklisted then you are very wrong. We already have mixers and if someone tries to "blacklist coins" there will be lots of services that will appear to help with that.


You missed the main point. Sending money to MP means losing possession of those money and GPG will not stop MP to run away it them, while a smart contract will make it impossible for anyone to not fulfill the contract since the coins will be locked and will be released only when the contract conditions are met.


It's fake money? You are starting to be delusional. Those will not be invested in themselves and into mining equipment. You are very wrong about them! This is not HashFail who's dick is sucked by Icetard.

Yea, I was about to point out that v3 blocks are a soft fork. Thanks for the write up though.



Deposit one pre-fork BTC, you get credited one post-fork BTC and one gavincoin that you can trade against each other.
Before the fork you withdraw one BTC if you have one post-fork BTC and one gavincoin in your account, after the fork you can withdraw them separately.
If the fork doesn't happen before a certain pre-defined block height all gavincoins in your account are invalidated and you can withdraw post-fork BTC you have in your account as regular BTC.

I asked, and you are correct. My bad.

It is a very cool method for consensus upgrades.
And, for general info, this is a graphical representation of the version 3 block roll-out in progress.

The prior forks did not happen at the 95% threshold, the changes were enforced starting at the 75% threshold.  There were two thresholds (75%/95%) to provide a two stage commit.  The reason for this is that the 75% threshold requires continually monitoring the prior 1000 blocks and it doesn't disallow older block version.  This provides a good upgrade path which minimizes disruptions but it requires continually monitoring the rolling percentage into perpetuity.  The second commit obsoletes old versions and removes the need to computing the rolling percentage (because if going forward all older version blocks are rejected then 100% of future blocks will be the new version).   So you get the best of both worlds but it really only makes sense for soft forks.   Remember is a soft fork new block versions are still valid to older nodes because they add new rules they don't remove or change existing ones.  A v3, v2, or v1 block all look identical to a client which only understands v1 rules.  It also has the added bonus of notifying the client 'hey there are newer rules you probably want to know about' in a decentralized manner.

As an example the block height was added to the coinbase field for v2 blocks.  While the % of v2 blocks on the network was <75% you could make a v2 block, not put the block height in the coinbase field and it would still be valid.   There would be no reason to do this and you would need to write new software which explicitly violates the BIP (because all existing software would be using v1) while changing the version.  It wouldn't happen accidentally but you could do it and the network would accept the block just fine (as long as it was at least valid for v1 rules).   As a side note, since nodes are unaware of future versions that also means right now you could mine a new block with version 1,837,888 an it wouldn't be rejected (as long as it otherwise follows current consensus rules).  If nodes are unaware of a new version but the block is still valid under the version they know they will validate it using their existing rules.  So miners can choose to start putting height in the coinbase field and they can indicate that support by using v2 in the version field.  They can't however force other miners to do the same thing.  The cool part is that since existing nodes also see these newer blocks as valid they have no risk in making the change.  

However once the rolling percentage reaches >75% with a version of 2, any v2 block without the height in the coinbase field would be rejected.  This is a pretty small risk because existing software would still be using v1 as the block version.   One would need to make new software intentionally use v2 as the block version and violate the BIP by not including the block height.   If you did all that your blocks would be fine when the rolling percentage was less than 75% but once it was 75% or more it would be rejected.  Most miners that were not 'v2 aware' would still be using v1 as the block version and with the rolling percentage less than 95% v1 blocks (with or without height in coinbase) would be valid.  'Bad v2' blocks (no height in coinbase) would be the only ones rejected.  This is what allows a safe and seamless upgrade path.  It allows miners to support a new change while at the same time avoiding a split in the network.  Only once the 'laggards' are such a small number that they are the only ones with something to lose is the update enforced.

So at this point the block height checking would be enforced but miners could 'opt out' by mining older version (v1) blocks.   This dynamic only exists for soft forks.  Existing nodes would treat v2 block coinbase fields just as the do v1 coinbase fields (unverified string).  This means to a v1 node it doesn't matter if the coinbase contains a height or not because the whole field is just ignored (for the most part).  In a hard fork an older node can't just 'ignore' that a block is greater than MAX_BLOCK_SIZE constraint.  So there is no way it can accept it unless it has been updated to consensus rules which are aware of the new version.  There is one major disadvantage so far.  If we only had a single commit all miners going forward would have to check the rolling percentage of block versions to know if the height is enforced in future blocks.  It could be enforced in one block, not enforced in the next three, then enforced for the next 400,000 and then suddenly not enforced all depending on how many v1 blocks are mined recently.   Obviously not a good idea to have future validation rules being dynamic for no reasons.  So to avoid that there is a second stage commit, once 95% of the rolling percentage is v2 blocks then v1 blocks are invalid as well.  At this point v2 blocks without height are already invalid and now any v1 block is invalid as well.  That means going forward all valid blocks will be both v2 and have the correct height in the coinbase field.  The nice thing is once that happens all the future logic can be simplified to enforcing the new standard (version number and new rules) on all blocks after the 95% threshold happens which makes the code simpler and reduces the risk of an accidental network split.  For v2 blocks that happened in block 227,835.  If you check the blockchain, all the blocks after 227,835 are v2 and all of them have correct height in the coinbase field.

Right now the same thing is playing out with v3 blocks that will eventually enforce strict DER encoding of signatures (BIP 66).
If <75% of prior blocks are v3 then DER encoding is not enforced on v3 blocks (yes right now a v3 block with non-canonical encoding would still be valid).
If >75% of prior blocks are v3 then DER encoding is enforced on v3 blocks (but one can still use non-canonical encoding on v2 blocks).
If >95% of prior blocks are v3 then v2 blocks are rejected (so all future blocks will be both v3 and have canonical encoding of signatures).

The two stage commit doesn't really apply for hard forks however.   With a hard fork you are altering existing rules not just adding new rules.   This means that older nodes will see the new block as invalid.   Not because it has a different version but because it violates an existing rule.  Once the network forks it is committed regardless.  If block 555,555 is 1.1MB then it will never be valid on existing nodes, it doesn't matter if that is the only block on its chain above 1MB and the next million blocks are all smaller because the entire chain is invalid to existing nodes.  As for why 80% vs 75%?   Well I am not sure 80% has been decided in stone, the whole thing is just a proposal at this point.  Maybe Gavin can comment, I would assume he went with a higher threshold since it is the first hard fork.

Interesting.  I see it all the time.  Start watching and look for it; I'll be interested to hear if actual observation agrees with your impression, then if it does I'll ask which state you live in.


Exactly.  That's why they DON'T stop you from spending the bill, even though they have to track its circulation.  They stop people from spending counterfeits, but not from spending bills that were stolen from somebody six months ago or used in a drug deal six weeks ago.  They want to know where these bills are circulating because it's a clue where the crooks are - but they're not trying to stop individual bills.


No.  The strawman version is where the store actually REFUSES your bill because it's on the list, and outside of actual counterfeits I've never seen that.  What I've seen is grocery store clerks have to write down the serial numbers on a clipboard and, because that's a pain in the ass for them, are happier if you pay with smaller bills - not because there's any risk that the larger bills won't be accepted at the bank, but just because writing down the serials is extra work.  

The most successful attack would probably be whitelisting rather than blacklisting.  Whitelisting is synonymous with licensing or at least closely related.

To make maple syrup, one takes a bunch of tree sap which is nearly impalpable and slowly cook it down until is is of a suitable form to use on waffles.  This slow consolidation until a body consists of higher valued players who can be pressured is exactly what I see as the most viable form of setup for a successful attack, and matches fairly well a 20x increase then subsequent doublings in block size as is the current proposal.  It results in a corresponding slow 'boiling off' of smaller value support infrastructure.

The key balance here would be to work slowly.  Right now Bitcoin is not a significant threat to almost anyone so there is time.  It's more important to preserve Bitcoin's primacy in the space than it is to forcible destroy it because sudden moves will panic the herd into alternate solutions, and many of these could be much more challenging to attack both because of numbers and different designs.

I've not mentioned the likely effectiveness of attacks on fungibility for some time so I will do so again here.  Please note that an attack such as telling TigerDirect that they must follow a licensing regime would have broad ramifications across the space.  I personally am very much against loss of fungibility on philosophical and economic grounds, but I'm still going to personally de-value a 'tainted' coin.  That is, a spend which is not usable at TigerDirect because it's history cannot be traced through licensed transference.

Edit:  Note that I have no interest in spending my BTC at TigerDirect, but I still de-value BTC which cannot be spent there.  Why?  Because the guy I try to pay with them himself may wish to spend them at TigerDirect and they will be worth less to him.  Fairly simple economics.

Nobody has really made a credible argument to me that the U.S. govt could not or would not require Bitcoin users, and especially of those at the corporate retail level, to adhere to licensing (and thus implement the aformentioned fungibility attack.)  I personally see it as modestly trivial and some moves in that direction happening already.  Were I contracted by Uncle Sam to design an attack on Bitcoin, I would certainly employ the attack I mentioned, and I absolutely would not pull the trigger prematurely.  Today, especially prior to Gavin's hard fork, is very premature.

I live in the U.S. and use $50 and $100 bills quite often and I've never had a cashier at any store or a teller at any bank write down the serial number.


While there may or may not be such a 'blacklist' (and I'm not claiming to know whether or not such a thing exists), there are much easier ways to detect counterfeit U.S. currency. Two that come to mind immediately are UV light (blacklight) and the "counterfeit detecting" pens. As far as bills that were used in a crime, if a bill was used in a crime that doesn't necessarily mean that I had anything to do with that crime simply because that bill, through normal circulation, ended up in my wallet. If those bills were indeed 'blacklisted' they would be taken out of circulation whenever they reach a bank rather than being put back into circulation to possibly punish innocent people just because someone might have used them in a crime at some point in the past.

While I don't deny the possibility of such a 'blacklist' I've never seen any evidence of it personally (such as store cashiers or bank tellers writing down serial numbers or checking against a list) and it would be the least efficient and most error prone way possible to accomplish the goals that you claim the 'blacklist' accomplishes considering the alternatives.


According to you, that version of blacklists already exists in the U.S. since you claim there are certain $50 and $100 bills which are blacklisted because they are known to be counterfeit, stolen or used in a crime. If they're blacklisted and people are genuinely checking against this blacklist then the possibility certainly exists that if you were to come across one of those bills you wouldn't be able to spend it.

What are you even doing with bitcoin? Go play with dollars if that's what you've come to expect. Which protocol is "unauthenticated? IRC? You do realize we use GPG to authorize users right? You can't even speak in the channel unless you have decrypted a password with your key, or been granted voice by someone who already has. There isn't any community on the planet that is more focused on authentication and security than #bitcoin-assets. Why do you think I'm so crazy about promoting it.

That aside, regardless of where the deal is struck, be it on the forum or AOL instant messenger, GPG would still be used to sign the contract. Not that GPG alone is enough to be sure you'll be paid (not that you can ever be 100% sure, even when going through state-sanctioned channels), but we use a Web-of-Trust in order to help keep track of who trusts who. For example, MP has a score of 40 in my L2 (level 2) through 28 connections -- that is, 28 users whom I trust and who may assign a rating from -10 to 10 have rated MP, and those ratings all added up equals 40.


You just need to get in the WoT, rate the people you trust, and see if he shows up in your L2. Maybe you can talk him into using a 3rd party as escrow -- perhaps nanotube.

---

That's not real money. That 116 million exists only for the purpose of pretending to invest in derpy startups. It can't be used to buy real things like massages and dinners.

i got confused because you said addresses. blacklisting addresses is imho the same as blacklisting coins.

blacklisting persons can only happen on exchanges (and its already done - see coinbase)

I am sure that 21e6 that just announced a $116M investment round in order to bring mining to the masses will afford a couple of nodes that will support the large block size limit. If you think your boss MP can compete with them then you are simply lying to yourself.


Don't try to change the subject like everyone else. I haven't said anything about blacklisting coins. I said about blacklisting people/addresses. If you re-read my post again you will see that I have already answered to this matter: "Taking into account the history of the coins is simply retarded and will be done only by those that do not understand Bitcoin."

And yes. Since no cashier will ever tell you that it can't accept your money because they were involved in shady stuff the same will happen with Bitcoin.


I thought that at least 75% of the hashpower is needed in order to be able to broadcast v4 blocks so I don't see how can a miner or a group of miners can play along with the fork. Maybe you can explain it to me.


Isn't this a case for a smart contract on the blockchain? Both parties put money and when the conditions apply the money goes to either sides and until then nobody has control over the money so nobody can vanish with them.

Unless MP is firmly linked to a real-world identity that can be held legally responsible for non-performance, and I personally can prove in court that the counterparty on that IRC channel has the same legal identity, I will not be paying MP, over a fuckin' IRC channel no less, for any promises of any kind.

Come on, guys, we aren't supposed to be idiots.  Why would we deal with anyone via an unauthenticated protocol for future performance or delivery of anything?

These are good questions. If you are sincerely interested in striking a deal I'm sure MP can answer them. He's active right now; don't be shy!

When you actually pay for the car (check, cash, credit card) and take possession of it (by driving off the premises) it becomes your property and cannot be claimed by the seller's creditors.

Also, you have a non-performance claim if you are unable to take possession, and can get your money back in court (that is, you are recognized as having the same legal standing as the seller's other creditors). If you pay by credit card or check, this is easy.  Legally, it also applies to cash, but it is less easy to press the claim with cash payments, because records may be conveniently "absent" in that case.

Professional used-car dealers usually have much more involved rituals involving witnessed, signed contracts and cashier's checks or bank transfers.  

It already does exist. Thanks to things like GPG contracts it shouldn't matter too much that transactions might get nullified delayed longer than usual.


Hey speaking of which, you derps should put your money where your mouth is! Swing by #bitcoin-assets and ask for mircea_popescu. He will gladly sell you "gigablockcoins" or whatever in exchange for real bitcoin. The odds offered are currently 3:4 (you get 4 scamcoins for every 3 bitcoin paid).

well thats reasonable and acceptable...

how do you buy used cars?
in germany you should buy them with cash, because if the seller claims insolvency after you have paid by SEPA/SWIFT he keeps the car and the cash...

lol this should be fun.

Hah! Our government would never trust us with denominations that large; the biggest bill in circulation in the US is $100. Although larger deniminations have been printed for special purposes in the past, they have never circulated.  

Depending on the store, the cashier may have to write the serial number on a paper list, or may have to scan the bill through a reader.   I don't know whether the blacklist comparison is done by the accepting company, implying that the private sector has the whole black list available, or the list is sent onward to a financial center, implying that the financial centers and/or regulatory agencies have all those transaction records available.  Either implication is somewhat disquieting, but certainly no worse than the publicly readable block chain.  At any rate, I've never seen a real bill rejected on the basis of the comparison.

The only category of "immediate refusal" is if the bill is revealed to be a counterfeit. - something about which we needn't worry with Bitcoin.