Bitcoin Forum
January 16, 2019, 01:28:46 PM *
News: The copper membership price will increase by about 300% around Friday.
  Home Help Search Login Register More  
  Show Posts
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 ... 241 »
101  Bitcoin / Development & Technical Discussion / Re: Why to write down your seed? regular InfoSec policies say never write passwords on: March 06, 2018, 09:11:55 PM
"infosec" password advice is given for contexts where the account can be cheaply recovered if the password is lost.  Not for cases where there will be very large monetary losses if its lost.  Infosec advice is also overly focused on physically proximal threats.  This is outmoded advice: anyone who has physical access to your computer can easily compromise you 1000 ways without the password, and there are a thousand times more attacks from attackers that have no physical access.

Your goal at the end of the day is to keep access to your bitcoins. This means you must balance risks. If you only care about the risk of theft, destroy your private keys now and no one will ever steal them...

Someone who can break into your home can hold you at gunpoint and get you to type in basically any password you know... if the attacker is in your home you probably have bigger problems then them finding a hidden seed.
102  Bitcoin / Development & Technical Discussion / Re: looked at bitcoind source and looks like a shitcode on: February 24, 2018, 12:46:44 AM
Throwing completely substancesless insults at quality work in order to fool people who couldn't tell for themselves into thinking that you're brilliant seems to be a favorite pastime for folks who feel insecure about their lack of competence adequate enough to accomplish anything themselves.
103  Bitcoin / Development & Technical Discussion / Re: segvan: Segwit vanity address & bulk address generator on: February 14, 2018, 04:23:45 AM
I’ve also been seriously mulling ideas for an online service which finds “vanity tweaks” for a private key held by a user—essentially, convenient results from rented time on powerful CPUs in the “cloud” (much though I loathe that word).  I’m curious as to how popular such a service could be.  Anybody interested?

Allow me to knock your socks off:

Say you have N people who each want to find a vanity tweak of their pubkeys which will roughly take M million tries to find.

You can find all N of them with just ~M million tries, instead of the N*M million tries if they were to do them themselves alone.

Here is how.  Each person has a pubkey P_i,   they all come up with uniformly random tweaks T_i.  They tweak their keys, and send these resulting public keys to the hashing server. They keep the tweak and original pubkey private.   They also send the string(s) they want to match. They stay connected.

The sever takes all the strings and compiles them into a single match expression (which can be matched in log() operations at worst, probably better).

Then the server sums all the tweaked pubkeys and grinds on it comparing the output with the omnibus matcher.

When it gets a hit  it then demands all clients except the one with the match to tell them the private keys for their tweaked keys (this reveals nothing about the original private key, since it's been tweaked).    It then sums up the tweak it found and everyone elses private keys and gives that to the lucky user.

Everyone remaining sends new tweaked pubkeys  (probably in the same message they sent their prior private keys).  They get summed and the process continues with the new basepoint.

If someone fails to send their private key, you kick them off and ban them and you lose that result because you cannot reconstruct the tweaks without everyone elses keys.

Implemented correctly this is completely secure.

You could even have the individual users perform their own grinding.  So if they all had computers of the same speed, they effectively get an N fold speedup in how fast they find solutions.

To discourage abuse you could require a new participant grind without submitting their own keys and patterns for a while... There found tweaks prove the work they did, once someone has done enough you can give them a token they can use to submit a pubkey and pattern(s) for matching, if that user fails to reveal, you ban it.  They can rejoin ... but they have to do free work to get a new code.

I haven't previously implemented it because the protocol minutia with tracking and banning and whatnot is a PITA and only the mathematical part is interesting to me. Smiley
104  Bitcoin / Development & Technical Discussion / Re: segvan: Segwit vanity address & bulk address generator on: February 13, 2018, 01:44:38 AM
You want this code:  it will be astronomically faster than your current code.

I believe when I previously implemented the techniques in this code my result was faster than vanitygen on a GPU.

It could also be made faster still with some improvements.  E.g. it doesn't actually need to compute the y coordinate of the points, so several field multiplications could be avoided in the gej_to_ge batch conversion.   It could also avoid computing the scalar for any given point unless you found a match. (E.g. by splitting the scalar construction part into another function which you don't bother calling unless there is a match).

Another advantage of this code is that it is setup to allow an arbitrary base point.  This means you could use untrusted computers to search for you.

Sipa also has AVX2 8-way sha2 and ripemd160 that he might post somewhere if you asked.  An 8-way bech32 checksum generator should be really easy to do, though if your expression doesn't match on the final 6 characters you should avoid even running the checksum.
105  Bitcoin / Development & Technical Discussion / Re: Latest bitcoin core? on: February 09, 2018, 08:04:32 PM
I was going to run two nodes and had setup the addrindex patched node to run on a VM. Due to some disk constraints (speed, capacity) I ended up deciding I would just run the patched addrindex node and use whitebind and whitelist in my bitcoin.conf so nobody but I can connect. You raised a point about vulnerabilities. Do you think the addrindex node is protected if I use whitebind and whitelist?
You have to connect to the outside world somehow... you could run your gateway node with pruning, then it would only use about 3GB space or so.

Also, what about the incorrect results you saw? What did you see and was it from this version: bitcoin-0.13.2-addrindex?
Querying it on an address wihch had funds returned no results.  The addrindex code there was written by Pieter as a quick lark, before he realized it was a bad idea and abandoned it.  Other people picked it up and patched it forward but made no effort to improve it or investigate the issues I encountered with it.

Generally it's my expectation that anyone who uses something like addrindex is eventually going to be forced to us a centralized service provider like once the resource costs of an unpruned address indexed full node is beyond what they can support.  (The fact that you struggled with running two nodes suggests that you're within a factor of two of that already).
106  Bitcoin / Development & Technical Discussion / Re: Lightning Network & bigger amounts? on: February 09, 2018, 09:07:12 AM
In theory you can transfer the max-flow in a single go,  but software needs to support making payments on separate channels in order to do that atomically and people are working on that.   But usually atomiticity isn't required-- usually you can just make a couple of separate payments if you run into limits.
107  Bitcoin / Development & Technical Discussion / Re: Random Number On Blockchain on: February 09, 2018, 08:57:28 AM
The standard protocol is a commit and reveal protocol as mentioned above with hashes.  The problem commit and reveal protocols have is that the last party to reveal can jam the process if he doesn't like the result.   In some contexts thats harmless, in others its fatal.

The hash the last block's ID approach can be biased by miners.  Without knowing what the the result would be used for you can't argue that they wouldn't do it... if they could make themselves win a 100 BTC lottery for sure, ... it would be totally reasonable to orphan and throw out blocks to pull it off.    The earlier proposal to use "the last 64 blocks" doesn't help, the last block is sufficient-- it already commits to all prior blocks anyways.

You can attempt to reduce the holdup issue in a commit and reveal protocol by using verifiable secret sharing.  For example: Alice, Bob, and Charley  generate secret values a, b, c and using ECC compute and publish points  aG, bG, cG   -- these are their commitments.   Then each party generates a new random value r and sends one of the other two parties r and the other party their secret-r, and those parties publish rG and (s-r)G.  So for example, Alice sends r to bob, and (a-r) to Charley.  Bob and Charley publish rG and (a-r)G, and each of them can add the values and check that they equal Alice's commitment because aG = rG + (a-r)G; but the players all still know nothing about each other's secrets. Once the sharing is done, people can start revealing their secrets.  Alice reveals a, Bob reveals b... Charley decides he doesn't like the result and falls offline, but now Alice and bob can reveal the shares of Charley's secret...  Whoever remains can compute H(a||b||c).  Of course, if Bob and Charley are co-conspirators they can abort as soon as they get Alice's shares if they don't like the result. This approach generalizes to any threshold of participants.

These sorts of ideas can be combined.

But which combinations are interesting depends on the application. For example,  one case I've thought a lot about is making random values that people in the future can be pretty confident weren't rigged.

Alice and Bob can agree on their terms and generates the a private key as a hash of the agreement terms and a random value sends a bitcoin to their own keys A and B in block 1000.   Then after block 1000 they sweep their coins and reveal their keys and your random number becomes  H(blockhash || a_private || b_private).   This would make it difficult for the miner to bias without knowing A and B's keys, letting them steal the coins. A and B couldn't easily restate their random values because they're commuted in the chain, etc.

Another idea which I've not seen implemented is to use a slow sequential function on the block hash. So e.g. your randomness involves H(blockhash)  but you make H in that case some function that takes 20 minutes to compute.   You can argue that a miner might throw out a block solution to bias a result-- but if he can't even tell the result for 20 minutes after finding the block that is much harder.  I understand that Ben Fisch  has been working on finding functions for H() in this example which are cheap to verify, so others can check the results of that 20 minutes of computation without doing 20 minutes of computation themselves.
108  Bitcoin / Development & Technical Discussion / Re: How would it be know if a segwit thieft actually happened? on: February 09, 2018, 08:23:12 AM
Nullius and DannyHamilton are spot on.

It's sad that people are getting bamboozled by malicious disinformation on this subject.

The _exact_ same thing protects segwit outputs from being stolen by malicious miners as any other coin: Following the rules is part of what _defines_ mining.  A miner that steals an output hasn't mined as far as nodes are concerned, their blocks will simply be ignored (and the peers relaying them eventually banned).

Segwit is no different from any other consensus rule in this respect-- other than some were introduced later than others, but many have been introduced over time.

We didn't see these same sorts of malicious FUD with P2SH though it was exactly the same-- I guess because back then felons hadn't figured out how to monetize that sort of confusion.
109  Bitcoin / Development & Technical Discussion / Re: Latest bitcoin core? on: February 09, 2018, 08:09:33 AM
Old versions are old, they have known reliability and performance issues. 0.13.2 is vulnerable to DOS attacks (plus potentially other security issues, but I don't recall for sure), and it isn't getting updated for other changes so it will far further behind over time.   I would recommend at a minimum that you setup two nodes-- one on current software, one running your special code-- and make the one with the custom code connect only to the current software.  This way it's shielded from abuse that it might not be able to handle and it's easy for you to upgrade the external node.

As an aside, that address index patch that was floating around gave rare false results for me.  I suspect that it could lose entries when there were reorgs, but I'm not sure if that was the cause or something else.
110  Bitcoin / Development & Technical Discussion / Re: Dividing miner reward over a k-length jumping window on: January 09, 2018, 11:36:21 AM
As achow noted, fee sniping is a long known concern. The first active countermeasures were deployed a couple years ago in the form of anti-sniping locktime use.  Fee backlog also looks like it will work just fine to stabilize incentives, as expected.

Unfortunately no fee sharing scheme has been shown to be incentive compatible under reasonable assumptions.   The problem is that users can pay miners via mechanism other than (and in additional) to any visible fees that would be shared via additional tx outputs, or completely out of band payments.  Miners have accepted payments in this manner since 2011, so it isn't theoretical.  Any fee sharing scheme would create a very strong incentive to accept alternative payment (which isn't shared) and for users to offer a portion of their fees as alternative payment.

Danny's #1 makes no sense to me-- no one cares about a satoshi difference, just specify the rounding in a particular way and be done with it. That is a one line of code point that no one would care about.

The appropriate consenusus rule change would be to allow coinbase transactions to spend outputs including other immature coinbase outputs. From that simple and generally useful change alone arbitrary fee forwarding or sharing schemes could be implemented in a compatible manner... but we're still left with none that appear even remotely strategically stable.

111  Bitcoin / Development & Technical Discussion / Re: Pieter and Greg, Bech32, please on: December 22, 2017, 08:02:40 AM
Bitcoin Cash
Bitmain didn't come up with Bitcoin cash until months after this specification was done, and didn't make the name public until even later... if there was any intention of confusion there it could only have been on the part of bitmain and their contractors.  Similarly, B2X named themselves BTC1 long after.  Unfortunately we cant do anything about altcoins using intentionally confusing names and labels.

BTCxxxx instead of bc1xxxx
Last character of the HRP has to be completely out of the data charset. making it all case sensitive would reintroduce the mixed case errors (though not as bad if it was only the first chars, but just as you complained: special rules don't help the users if they don't know them)... and then you can't do things like have it optionally in all caps which is nice in some contexts, and can be pretty visually attractive too.

I am sorry that popping up with "constructive criticism" out of the blue without much in the way of reintroduction or community engagement probably seems more confrontational in the absence of regular positive contributions to the project's development.
Yes, there certainly was that effect, I was really kind of gut punched by your post and was sort of thinking you'd turned into a bcash shill Sad-- acknowledging it absolves it.  I'm sorry for being a bit quick to judge there. Don't be a stranger.
112  Bitcoin / Development & Technical Discussion / Re: Pieter and Greg, Bech32, please on: December 22, 2017, 06:31:11 AM
I will meet you halfway in positing that the human-readable prefix “btc” would be better than “bc”, at the expense of an extra character which transmits no data.
The HRP and data delimiter needs to be a character which is outside of the character set-- this is because the HRP can contain characters both in and outside of the charset, so to find the boundary we need the last character of it to be outside of the set.  The delimiter must also must be alphanumeric to preserve single click copy in many environments (including browsers).  So this left us with using one of bio1, or changing the character set to be more visually confusing and getting a different option.  In the vast majority of contexts the prefix is completely fixed by the application usage, so there is no possibility of confusion in any case.  

seems an homage to the old-style P2PKH addresses
Right, among the options it had that advantage and it was also the one that was least visually confusing.

that I hate it, I can’t handle it—I find it absurdly frustrating and error-prone.
This is what many people report, and even people that said they didn't mind it handled it much more slowly.  My general experience from when we stared on this was that people who said mixed case wasn't an issue changed their mind after actually trying to convey an address view spoken word or writing it down by hand with pencil and paper. ... Either they had never done it before or had done it infrequently enough that they'd already repressed the traumatic memories. I don't doubt that there are some odd people out there which never have any trouble with it, but I haven't encountered anyone yet who doesn't when actually tested on it.

I’ll admit, as a C programmer, I am a tiny bit annoyed by the Bech32 choice of alphabet.  It’s not in ASCII order!  The stupendous inconvenience of a lookup table is required for decoding
the table and its use however can be one line of code.  I think one line of code is a pretty good trade-off  for improved error detection.  The base conversion for bech32 and checksum code are each easily 1/10th the code/size of base58 handling too. I think the cost of a little lookup table is easily paid for by improvements in other areas. Smiley

(The mapping is such that the most likely confused characters tend to result in only a single bit-flip and the code is designed so that it is slightly stronger in those cases than advertised).

1. My regards to Pieter Wuille and Greg Maxwell:  I can tell that an excruciatingly detailed thought process about Bitcoin address formats went into that bit of engineering.  Somebody stayed up in the dark wee hours, pondering the philosophy of Bitcoin address formats.  Somebody aspired to consummate perfection in the art of Bitcoin address formats.  Well, you are probably also “odd”.  Coming from me, take that as a compliment.

Thanks, including a lot of testing with both people and machines, several CPU decades went into the design of the error correcting code... and in fact the techniques even required to be able to measure their performance are themselves novel and probably publishable innovations.   Not to mention extensive review and redesign with many other similarly crazy people.   We understood that introducing a new address format is a big step that can't be done often, and thought it would be appropriate and acceptable to really work hard on it.
113  Bitcoin / Development & Technical Discussion / Re: Pieter and Greg, Bech32, please on: December 22, 2017, 06:15:08 AM
At least, please consider the carbon-based units in the Bitcoin ecosystem.  Us, like you and me.
Bech32 is designed for human use and basically nothing else, the only consideration for QR codes is that all caps is also permitted.

For all your talk of human considerations you give a strong signal of having seldom actually used bitcoin addresses as a human.   1/3 type addresses are full of visually confusing characters and the case modulations are a pain to read and enter correctly.  In actual testing transfering bech32 addresses to another person is on the order of 5x faster with bech32 due to errors being made even in careful usage of base58-- more than the time itself transferring a base58 address is often insanely frustrating-- you read it, and ... nope, no idea where it's wrong, only that it's wrong -then you try reading the whole thing again and again and again.

Bech32 largely solves that both because it is MUCH easier to read correctly, less visually confusing, and because when you make just a single mistake it can tell you where it is.

The Base58 pattern with a fixed prefix is very visually distinct

BC is considerably more visually distinct; and it's something the Bitcoin network can stick with-- presumably forever.

cue for cryptocurrency

Some of the most popular alternative cryptocurrencies do not use base58, including Ethereum-- it uses hex.

trashing that visual distinction
Any new scheme would need to use a different prefix apart from 1 and 3, and would get confused with other cryptocurrencies.  Morever, other cryptocurrencies squat 1 and 3  (bcash and litcoin p2sh for example) and, in fact, will falsely accept Bitcoin addresses and vice versa with disastrous consequences.

string with an approximate known length starting with 1 or 3 has worked for us so far.
It cannot be that, and even if it were, those values are now ambiguous.

If we have to learn it all over again, can it be something we already know?  Why "BC" for Bitcoin?  Could we have capital "BTC" or "XBT" followed by mixed case data.
BC is self explanatory, BTC gets confused with currency units and amounts, and it's longer-- more tying, more room for errors.

but now 2-letter acronyms for each cryptocurrency project.

The HRP can be any length, there doesn't need to be any such 2-letter.

Please give us an encoding that spares us the confusion of having the lowercase letter L and the number 1 all in the same code.  I'm sure I will

We did, the character set does not include "1", "b", "i", or "o"; which is the unique selection which minimizes the number of visually confusing pairs, at least given the NIST visual confusion data we had available to us at the time. ..-- I find it really disappointing that you wrote this long complaint without knowing even this....

A few weeks after publishing BIP173's draft it some academic paper came out where they generated the visual/typing confusion data that I really wanted at the start but which no one had; -- but by then people had wildly started deploying it, even before it had been extensively reviewed... this seems to be a reoccurring problem in Bitcoin.  I haven't rerun the optimizer with the new data, I really really doubt it would reject different characters (the new data is pretty similar) but the permutation might have been somewhat different with it.

Please let us keep our mixed case.  Trust us, we've got capacity for it,
I don't trust, I verify and the mixed case results in worse than a 2x slowdown sharing addresses between humans even when no errors are made, and it greatly increases the number of errors made too.

my glasses, maybe try both?  It didn't work?"... I hope it's easy to see how this is actually more frustrating.

Mature software will tell you _exactly_ where such errors are located, especially if they involve a charset mistake, but even errors beyond that. There should be very little hunt and peck with BECH32, and in my experience there isn't any at all.

with a much greater damage coefficient than 1 over 4 billion, so changing how addresses look doesn't reassure us or feel like progress, rather how it feels is it steepens our learning curve.
Your entire post seems to be motivated by a profound confusion about why this was motivated.  A new address format was _required_ for native segwit outputs, avoiding a new one isn't possible.   Given that we needed a new one we wanted to make it as user friendly as possible, and actually studied user behavior to achieve this.

Incidentally, the 1:2^32 odds of falsely sending to a wrong address is greatly increased by the many retries when people mess up base58 addresses and make speculative corrections... but bech32 wasn't designed to improve the detection of wrong strings (in fact, it only achieves 1:2^30 protection against totally random correct-charset strings) but instead designed to be more pleasant to use by being able to hint where errors are located and not degrade on retry.

If you let us move forward with you on a new address format, while maintaining our beloved Base58 (our CPU's still love us and are happy with the long division and the extra work parsing the mixed case),
embedded systems trying to implement bignum libraries for base conversion certainly don't "love" it. (though this can be avoided with even more complex code).

Would keeping mixed case shorten the code enough to make extra room to pretend (for the sake of error correction) that each character has 64 possible symbols?  We could dedicate another character or two to the checksum to make up for it.

No, it doesn't work that way, and the mixed case is a massive slowdown in actual use by humans.  Of course, computers don't care-- but computers don't care -- the addresses are for human friendlyness, not for computers.

Having two characters BC represent Bitcoin also feels political, as though it is an effort to pretend that there aren’t alt coins with significant merit.
First, Bitcoin invented this field and if you feel that its natural privileged from doing so is "political" then I really don't see a need to continue discussion with you.  If you don't want to put Bitcoin first that's your decision and not something I mind, but don't you dare demand that people who have more or less dedicated their life to it to do worse work on Bitcoin in order to facilitate whatever competing systems that you prefer.

Secondly, we actually made significant design considerations specifically to facilitate altcoins. Earlier versions of the design restricted the HRP to the same character set as the data, and so there was no character set that wouldn't have permitted many altcoins from using their favorite monikers (e.g. no LTC given our charset due to the use of L).  We wanted implementer of multicurrency software to be able to use the same code for many systems; while we're not going to degrade things for bitcoin we actually did go out of our way to design something that was very generic and inclusive-- even though doing so is probably not the best competitive approach for Bitcoin... it probably would have been better to set it up so altcoins would require incompatible code so software would be less likely to implement support for them. Too bad you're too blinded to see it.

on that 1MB of block space

I guess you missed this part of nullius' reply?

114  Bitcoin / Development & Technical Discussion / Re: CoinJoin: Bitcoin privacy for the real world (someday!) on: December 12, 2017, 11:18:03 PM
In order to further incentivize work in this space there is now a multisignature escrow bounty fund:
Just a note in case anyone was watching the address: three weeks back the outputs to this address were consolidated in order to take advantage of low fees on the network and to simplify sweeps of further bitcoin spinoffs (as signing for 65 inputs is a bit of a burden); the consolidated funds were moved back to the same address, minus a nominal amount of fee (about 2sat/byte).
115  Bitcoin / Development & Technical Discussion / Re: How to use properly secp256k1 library on: December 09, 2017, 09:13:11 PM
Reviewing the libsecp256k1 now I understand better the code. I noted that for the scalar there is a representation 4x64 bit, while for the field element only 5x52 (or 10x26). There are some safety reason or these representations make effectively faster the operations? Why there is only an asm version of the fe_mul and not of the fe_add too?

The overcomplete representation reduces the number of carries needed between limbs, so it makes the operations faster.  The fe_add should already be more or less optimal when written in C-- it's a trivial function in part because it doesn't need to handle any carrying at all.

It's possible that some other representation might be faster yet, esp if using SIMD.
116  Bitcoin / Development & Technical Discussion / Re: List of people who have had commit access to Bitcoin Core on: November 27, 2017, 05:15:41 AM
Has there been any formal announcement about revoking Gavin & Jeff's commit access?
Not so, WRT Gavin:   AFAIK similar applies to Jgarzik. (Too bad, I wish it hadn't been removed years ago so that it could be removed now with a public condemnation of his ICO scam)
117  Bitcoin / Development & Technical Discussion / Re: Payment No. 1: A Closer Look at the Very First Bitcoin Transfer on: November 07, 2017, 05:13:12 AM
/tx/0437cd7f8525ceed2324359c2d0ba26006d92d856a9c20fa0241106ee5a597c9]look at when those 50 bitcoins were mined to that address[/url] you can see that it came from block #9, and blocks 1 through 14 were mined a day before the bitcoin software was even released (meaning, technically, bitcoin had a 700 BTC premine!).


Block 1 has a timestamp of 2009-01-09 02:54:25.   The announcement of Bitcoin's release is timestamped Thu Jan 8 14:27:40 EST 2009, which is more than 7 hours before block 1.

Please fix your post before we have to endure more years of people repeating unsupported speculation and outright untruths about the history of Bitcoin.

None of the other super-early Nakamoto bitcoins were ever spent.
You have no idea which if any other blocks he mined, -- the only reason you think you do is due to garbage "scholarship" like your own that can't even manage to compare two dates.
118  Bitcoin / Development & Technical Discussion / Re: Simplicity new language for blockchains on: November 01, 2017, 12:51:34 AM
SegWit introduced script versioning so maybe they will be able to deploy Simplicity using that -- which means without a hardfork. But I guess the jury is still out on that one, otherwise they would have explicitely mentioned that in the whitepaper.

::sigh::  People think weird stuff.   The paper does not talk about Bitcoin integration in any detail, as it is massively premature for that.

But adding a new script system is a softfork, it's always been a softfork. It's pretty much the most softforky thing you can imagine, and moreover it's already been done before!  P2SH replaced Script with a nested copy of Script..  In that case the nested thing was the same as the outer thing, but there was no technical reason it couldn't have been different.

119  Alternate cryptocurrencies / Altcoin Discussion / Re: SegWit2x seriously losing support? on: October 14, 2017, 01:30:29 AM
Unfortunately, much of the #NO2X crowd still doesn't seem to understand backward compatibility. Many of them continue to repeat the falsehoods that "soft forks are backward compatible" and "BIP148 was backward compatible." The reality is that soft forks can be incompatible and that BIP148 was very likely to be incompatible.

Thanks for actually being thoughtful, though I think it is a little more subtle than you suggest:  BIP148 would have been backwards compatible IF and Only if hashrate became compatible with it.  The people arguing that it was compatible were not, I think, trying in any way to be dishonest but rather were pretty convinced that hashrate would be compatible with it when it activated (regardless of this view being justified) and to whatever extent they had doubts any failure they would attribute to hashrate not doing what it was supposed to do (regardless of this view being justified...).

I think this is an unreasonable risk and to this day I don't understand why quite a few other people thought it was an acceptable one.  But, on the other hand, they were right that hashpower would (effectively) go along with it.

Every other point I agree with, in particular your comments on the timeline of it.  I think though that I would conclude that they took a gamble and won, elsewhere we might applaud them with tremendous foresight as we often do for people successful primarily through chance... Smiley  OTOH, what they were gambling with was the safety and stability of a shared resource that we all count on...

The intervention of 2x unfortunately substantially eliminated one of the main payoffs proponents of BIP148 probably anticipated:  Rejecting the notion that miner forced capacity hardforks were something we needed to respond to on an immediate basis, thus allowing us to make more progress with less drama.  Maybe we'll be there after November.

I think the thing we should worry about isn't recriminations about BIP148 but what are reasonable expectations for consensus upgrades to Bitcoin.  I don't think it's reasonable to expect them to happen, generally, on a time frame of less than years.  It certainly isn't the case for internet infrastructure protocols like BGP, which are easier to upgrade than Bitcoin...  If a chance is well understood and widely supported, then sure Bitcoin can deploy them faster, but I think our base expectation should be years.   I think this is the fundamental disconnect that fed a lot of fuel to the short timeframe of BIP148.

120  Bitcoin / Development & Technical Discussion / Re: Trojan - SegWit2x on: October 13, 2017, 10:13:36 PM
Did you see the last post/response? Seems like a legit answer:
jgarzik replied 9 days ago • edited
This is a privacy feature. See discussion at PR #109 for more.

This feature defaults to advertise (privacy=off).

Users may optionally disable advertising (privacy=on).

There is historical precedent with Internet browsers:

Users also rightly requested privacy features like this due to past attacks:

I wonder why Jeff Garzik would tell such a transparent lie.  It only seems like a legit answer if you don't know how things work. Although he has locked the discussion there so no one else can point this out, nothing stops us from discussing it over here.

All his nodes continue to send subver: "Satoshi:1.15.0"  to everything that connects to them, trivially identifying them.  A a result his change has no privacy gain what-so-ever and serves exclusively to undermine the anti-partitioning logic in the Bitcoin node software; leaving users open to unwanted connections that reduce their safety and reliability. This fact couldn't have been missed, especially since the explicitly cited "Bitcoin Classic" identified itself exclusively via subver.

[FWIW, because I'm calling Jeff out on a serious breach of ethics here I think it's important that he have an opportunity to respond, so I am also emailing him a link to this discussion. Edit: Done]
Pages: « 1 2 3 4 5 [6] 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 ... 241 » is not available or authorized for sale. Do not believe any fake listings.
Sponsored by , a Bitcoin-accepting VPN.
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!