Bitcoin Forum
September 20, 2018, 09:39:56 PM *
News: ♦♦ Bitcoin Core users must update to 0.16.3 [Torrent]. More info.
  Home Help Search Donate Login Register  
  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 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 238 »
661  Alternate cryptocurrencies / Altcoin Discussion / Re: Block lattice on: October 24, 2015, 08:30:15 PM
It appears (from the writeup) that you are unaware of sybil attacks?

The graph of transactions in bitcoin already functions like what you describe (except 'accounts' are single use txouts); Bram Cohen likes to call Bitcoin without the blockchain "bitpeso".  In Bitcoin the blockchain is overlaid on top of "bitpeso" to resolve "complex forks" (using your language) in a manner that allows someone to join the network and know which resolution is authoritative in a way which is both robust to sybil attacks and does not require membership (because a membership process would create control over the system).

In your description you appears to liberally conflate forks and double-spending.  In Bitcoin, double spending a traditional txout requires malicious behavior, just as you describe.  Blockchain forking in the absence of double spending is benign and no different to the "multiple resolution rounds" you mention from your resolution protocol but fail to describe detail sufficient to permit any analysis.
662  Bitcoin / Development & Technical Discussion / Re: Should websites refuse to send coins to an already used address? on: October 24, 2015, 08:16:26 PM
Two more.questions regarding to that:
1) It was known how to generate a new address without a ptivate key back in 2009? If I'm right, this comes from a modern BIP (deterministic wallets) Shocked
I invented it in 2011:  as a response to people reusing addresses because they didn't want to have private keys online. It was later standardized as BIP32.

2) I don't care about privacy, I prefer to have a working Donation address all the time rather than being 100% a ghost. :p
You may not currently care, and its your right to screw over your future self (which you may well be doing)-- but reuse also harms _other_ users in Bitcoin, who do care about privacy, and this degrades the fungibility of coins; since coins which are linked to this or that party are clearly different, and differently valuable than coins which are linked to other parties or are not linked.
663  Bitcoin / Development & Technical Discussion / Re: Should websites refuse to send coins to an already used address? on: October 23, 2015, 08:46:37 PM
Reuse of an address is the sole business of its owner. It's a matter of choice, for most people simplicity is the most important.
Pedantically, the reuse of address harms third parties... and the decision to send coins is the sole business of the sender. I don't think you can answer this questions with simplistic reductions to arguments about free choice: there are multiple people involved in the question, and their free choices may conflict.

I may sound paranoid, but the creation of a new address shouldn't never be done online and automatically. Creating a new private key every time you spend gives me chills.
New addresses can be generated without generating new private keys.

Monero, for example, has no address reuse at all in the blockchain-- it's required for the prevention of double spending there. It seems to do okay with it.  The original bitcoin software never addresses w/ pay-to-ip; and even with addresses in use it the practice of reusing is somewhat inexplicable from a technology standpoint: it _really_ screws up your privacy along with that of people you transact with, and you can't reliably tell which of the payments you had outstanding were confirmed.... I think if it had been realized that people would behave the way they do, it likely would have been prohibited in the Bitcoin system from the start.

[I make these points as points of correctness, not to further argue it-- I think warning is more prudent, and will also have the effect of educating on this matter).
664  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 23, 2015, 05:16:04 PM
Although the CIYAM Wallet is not currently being used (except for testing by myself) I am wondering if I could get some help to change my ECDSA signing (assuming it isn't correct).

The code is here:

I'd appreciate a link to let me know how to fix it if it isn't right.

(can it be done using OpenSSL or do I need to include the Bitcoin ECDSA code to get it right?)

It can be done using OpenSSL,

The code from Bitcoin core for this-- back when it used OpenSSL for signing:

        BN_CTX *ctx = BN_CTX_new();
        const EC_GROUP *group = EC_KEY_get0_group(pkey);
        BIGNUM *order = BN_CTX_get(ctx);
        BIGNUM *halforder = BN_CTX_get(ctx);
        EC_GROUP_get_order(group, order, ctx);
        BN_rshift1(halforder, order);
        if (BN_cmp(sig->s, halforder) > 0) {
            // enforce low S values, by negating the value (modulo the order) if above order/2.
             BN_sub(sig->s, order, sig->s);

(You might also want to look to using libsecp256k1 for signing in the future, not only does it handle this for you, it is sidechannel attack resistant and OpenSSL is not for this curve, it's also likely much better tested code than OpenSSL for this particular application.)
665  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 23, 2015, 12:15:48 AM
Thanks for your reply.

One standard issue in cryptography that I was alluding to was the necessity of having canonical forms, so that signatures (which use hash functions) work properly after a message is mangled by the network.  This problem was obvious when encrypting messages sent over email, e.g. PGP and PEM (early 1990's). Another standard (but more subtle) issue is the opportunity for covert channels, which need only be low bandwidth before they can effectively leak a private key.  Thus an experienced cryptographer would have understood there might be a problem and could have looked for it. Indeed, in the case of bitcoin the problem was noted back in October 2012, as I pointed out in an earlier post.
Absolutely, though its worth noting that while canonical encodings like DER are known and specified, virtually nothing enforces them. Bitcoin, from day one, has used a canonical encoding (DER)-- unfortunately, the underlying implementation in OpenSSL had undocumented behavior where it also accepted invalid DER until a couple months ago. (likewise, (all?) other similar libraries, such as bouncy castle behaved likewise-- this wouldn't have been escaped by not using OpenSSL). I spent some amount of time looking for precise DER implementations and BER implementations for reference test points in libsecp256k1 and was unable to find _any_ open source software which precisely implemented (no more accepted or rejected than specified) them. Even OpenSSL's recent fix for their behavior was not to correct their parser but instead to attempt to round-trip the encoding, which is not a guarantee. (You can see this list for some of the crazy things the OpenSSL parser, as an example, would accept.).

(And FWIW, the whole Bitcoin network has filtered these encodings everywhere for several years,  even though it required quite some wallets (like Armory and MTGOX) change their behavior).

But that deals with serialization, I am aware of no evidence that anyone has observed the algebraic malleability of ECDSA prior to us, and no evidence that anyone else took any action against it (now or previously).

As far as leaving serialization elements out of protocols, great care must be taken there too as there have been many vulnerabilities created by leaving things out. For example, the original PGP fingerprints hashed the modulus and exponent (but not their potentially non-canonical serialization), but also as a result had no delimitation so someone could move some bytes of your modulus into the exponent until they found a key they could factor, and then they'd have a weak key with the same fingerprint as you.

Signatures being covered under identifying hashes is ubiquitous, e.g. x509 certificate chains work just like bitcoin in this respect; and this interacts poorly with cert blacklisting due to malleability.

In any case, I don't want to belabor this, but you were really harsh and critical where I think the reality is almost 180 degrees out:  Bitcoin suffered from undocumented behavior in third party code; the outside world while somewhat aware of problems from non-canonicality has largely not acted on it-- Bitcoin Core is a leader in responsive and responsible handling of this, and our efforts resulted in the discovery of an additional form which appears to have not been known/discussed previously), which our ecosystem (out of all the ECDSA users in the world) appears to be the only ones at all protected against.

I really don't care much what armchair jockies on the forums (not specifically referring to you) think, and so I don't usually expend a lot of resources bragging... but to have someone be really harsh on a matter where I think our response has shown considerable innovation and leadership is, at least a little, bit frustrating!

Also, the closing of a low/high-s covert channel would not be significant until deterministic signatures were used. In this regard, I note the date on RFC6979 is August 2013, which is after the bitcoin dev's were aware of the problem.
It is unclear what you mean by "would not be significant", but the matter is largely orthogonal-- 6979 or not, implementations that do not heed the lowS behavior specifically will produce non-lowS signatures at a half the time per signature, leading to most of their transactions being blocked.  No wallet that I'm aware of has ever provided a "resign" button that might break through-- and when wallets do create new transactions they usually use a new random selection of coins, so 6979 would also produce a new signature. Even if they did provide a "resign" and used a random signature, once your transaction has more than a couple inputs the probability that it would pass a lowS test becomes very very low.

RFC6979 does not really close a covert channel either, alas, it is impossible to determine if a device is using 6979 without access to its keys and a malicious device could use 6979 99.99% of the time but then sometimes change to a kleptographic method (perhaps triggered by the message itself).   The RFC does eliminate the strong need for a good RNG at signing time --  a common implementation problem-- and make review/auditing somewhat easier.

I did a little searching around to see if I could find a non-bitcoin example of the problem, but didn't find anything, probably for the reasons above.   This may not help you with regard to the HSM vendor, but as a customer of such a device I would not want to have an obvious potential covert channel, even if the output could be "fixed" by software in a nearby computer, since if the nearby computer could be trusted there would be no need for the HSM in the first place.  (Comment inapplicable if said HSM always outputs high-S.)

Unfortunately if the device has free choice of its nonce (which having control of low/high S implies) then it has a high bandwidth covert channel.  E.g. produce the nonce as H(ECDH(attacker_pubkey, pubkey) || message_to_be_signed). More elaborate versions of this allow the embedding of additional data, beyond just leaking the current private key. Even if something constrains the choice of nonce, a malicious device can do rejection sampling to turn get N bits of covert channel out of the nonce by doing 2^n computation-- low vs high isn't different except by being computationally cheaper to use.   So, I'm not sure I'll be able to sell it in terms of covert channel suppression, but it's worth a try. Thanks for the suggestion.

666  Bitcoin / Development & Technical Discussion / Re: Should websites refuse to send coins to an already used address? on: October 22, 2015, 11:42:45 PM
Warning about it, at least, would be productive-- as there has been a fair amount of loss from people accidentally using the wrong address (in addition to the other ways reuse causes systemic harm).  If you mean "already used" ever, then prohibiting it requires a forever growing database, which isn't all that scalable.

A middle ground would be warning (or refusing) any that the site itself had previously sent to; and I think there was general agreement to do that kind of warn on (wallet local) reuse in bitcoin core in the past.
667  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 22, 2015, 07:49:33 AM
Boy what a bad loser you are. End users will read these notes:
Don't look at me: I had no idea mangled the release notes. Thanks. No one working on Bitcoin core has any control over, but I'll report it now that you've brought it to my attention.

you are just being a lazy programmer who thinks it would be easier to kindly ask anonymous bitcoin users not to generate massive amounts of UTXOs rather than to implement code that solves the issue on the protocol level. If you now say that dust threshold is meant to defend against UTXOs then stop complaining about people who make UTXOs and are willing to pay the price (whatever it is).
I didn't contact you, you started this thread with a bunch of accusations and ranting, because -- apparently-- you weren't willing to "pay the price".

And no, just because there is a fine on something doesn't make it appropriate to do just because you're willing to pay the fine.

now get back to work
Please do not address anyone on this subforum in this manner. None of the developers of Bitcoin software owe you anything, and this sort of disrespect is most unwelcome.
668  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 21, 2015, 10:32:45 PM
That "mild" denial of service attack is likely to be perceived as a failure of the bitcoin system when it is experienced by a new bitcoin user.  This is particularly true if the sender makes two transactions in rapid succession from a balance of "old" coins, where the second transaction uses a change address from the first transaction.  This leads to counter-intuitive behavior, since the naive user believes he had all the necessary funds in hand, only to discover that the second transaction "bounces".

I suggest placing more emphasis on what bitcoin users experience, even if it means a little inconvenience for some developers.  
It's not users vs developers-- it's users vs users that are in question here.

In the case of the attack you cannot respend unconfirmed coins without issues while an attack is going on, in the case of lowS enforcement with half of your transactions will randomly get stuck (and never get unstuck, holding your coins hostage). Both are bad experiences for the user. I think the latter is considerably worse: any system's abstractions leak from time to time. Bitcoin isn't a system of "account balances", and for good reason. 99% of the time wallets can simulate that it is, but sometimes the fact that it isn't matters more (and even in ordinary use, the fact that it isn't has significant impacts on fees that can be worth the user's attention).

In the case of the former, it has been a non-issue until recently because no attack of this specific type was going on-- though, of course, we knew one could begin at any time (and immediately deployed all non-disruptive fixes);  in the case of the latter software was chaining over time-- but some users will just find that their preferred software just never gets updated for it; good luck sweeping their funds into another wallet with half (or more) the transactions getting stuck. Some users will try to install fixes but end up with malware instead and have their coins stolen, etc. While there was no attacks waiting for the migration to conforming to happen naturally was an approach which was intended to mitigate total disruption (and I believe it did)-- absent amaclin's demonstration it might have gone with virtually no disruption at all.

At every moment in this process we were thinking about protecting the user's experience and the value of the Bitcoin system to them-- from anticipating an issue no one had thought of before, to implementing, testing, reviewing, deploying fix code-- nagging other developers to fix their software, etc. All of these things took considerable work.  Simply saying "ah ha, today, this new rule is enforced due to this currently hypothetical attack: deal with it!" would have been much simpler.   Sometimes there is just a genuine conflict between different harms.

There was plenty of time to have fixed this a long time ago with an orderly phase-in.
What you are complaining about _is_ an orderly phase in, and is why only ~5% of transactions were affected instead of most of them.

I'm still waiting on a hyperlink to a _single_ ECDSA implementation that dealt with ecdsa inherent malleability prior to Bitcoin's. You argue that it was a standard problem with a standard solution, if so it cannot be too much effort to find an example. [I'm not just asking for didactic purposes, I'm concerned about a HSM vendor that is uninterested in changing their behavior, and if a non-bitcoin example exists it would be helpful (but I could not find one).]

perfect moment to say: BIG THANK YOU for your continuous and well thought contributions and work on bitcoin core.
the core team has earned my trust over a long term and clearly deserves it (this includes other too).
(well i might disagree about blocksize but hey, i doubt there is anything in this world where anybody agrees with me)
Thanks! it's good to hear comments like this.
669  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 21, 2015, 09:59:16 PM
WTF are you talking about? What you might see as abusive is by no means an objective evaluation of the situation. Keep your petty feelings to yourself. As a core developer you should not allow yourself to give in to your emotions. It is your job to find a solution to the UTXOs because that number will increase EITHER WAY. With or without abuse.
Data storage has a cost. The field you are putting bitcoin unrelated data is a public key field, it isn't Hyena's-file-sharing-field. It's used to set the rules for coins to be spent in the future. When you start cutting me a paycheck you can start dictating what my job is, but under no condition will it ever be to aid you in your quest in externalizing your data storage costs onto Bitcoin users.

and the change to the relay fee was absolutely release noted
FALSE. Stop lying in my face. When I searched the release notes there were no indication to the minrelaytxfee config parameter and the default value that might have changed as a result. It is pathetic to see you try to cover up this mess. Be an adult and admit that the release notes were lacking that info.

Perhaps you should get control of your emotions before posting? It might help prevent you from making errors,  I think release notes are clear on this, and it was also covered in the release candidate release notes.

For the avoidance of any residual confusion, let me quote from them here:

Notable changes
Minimum relay fee default increase

The default for the `-minrelaytxfee` setting has been increased from `0.00001`
to `0.00005`.

This is necessitated by the current transaction flooding, causing
outrageous memory usage on nodes due to the mempool ballooning. This is a
temporary measure, bridging the time until a dynamic method for determining
this fee is merged (which will be in 0.12).

(see, as well as the 0.11
release notes, in which this value was suggested)

Not only was it covered in the 0.11.1 and 0.10.3 release notes, but the 0.11.0 notes recommend users make the same change for themselves manually.

you missed an important part from the release notes.
I await your apology with abated breath.

or else I suspect we wouldn't be enduring your vicious invective.
your petty childish emotions. Calling my activities vicious?!
invective (noun)
1. insulting, abusive, or highly critical language

Be grateful to me for highlighting the UTXOs issue because when a malicious user starts to abuse this vulnerability you will not have a chance for a reasonable debate.
You may be suffering confusion on this point, the dust limits are a fix and don't require having any debate with you (reasonable or otherwise); economic thresholds that discourage the creation of uneconomic to spend (or unspendable) txouts-- and were it not, you would have no cause to complain. And indeed, the protection it provides is not absolute, but it doesn't need to be.  If you send hazardous materials through the post you might get caught, or you might not. But the odds are enough to provide all that is needed to keep you from harming the system. You will not be the first person to intentionally harm a shared resource to brag about how bold and brave you are for revealing issues, it's nonsense-- but also irrelevant, nodes can happily go on blocking your transactions regardless.

I suggest you take your "weakness demonstrations" to the local law enforcement office and helpfully show them how breakable their windows are... Be sure to tell them how grateful they should be for you highlighting their vulnerability. I think they are likely much more equipt to provide you with the education most suited to your current needs.
670  Bitcoin / Development & Technical Discussion / Re: Why are transaction malleable in the first place? on: October 21, 2015, 09:32:22 AM
This is a standard problem in cryptography and has a standard solution. In other words, it is a bug in the bitcoin protocol and implementation.
I invite you to provide us with a hyperlink to a _single_ ECDSA implementation that dealt with ecdsa inherent malleability prior to Bitcoins existance (or our implementation of the fix in Bitcoin Core).
The bug and its obvious solution have been known to the bitcoin developers for over three years.
And fixed in Bitcoin Core all this time too!

They have been acting like an animal caught in the headlights of an oncoming car, frozen with fear.

LOL.  I can assure you, there is no fear involved.

The only effect of this kind of third party malleability has on ordinary Bitcoin payment activity with competently written wallet software is a fairly mild denial of service attack (blocking payments using unconfirmed coins) and mild cosmetic issues; irritating, no doubt, but not more than that. There exists (or used to) less well written wallet software that misbehaves more severely, but there is no rescuing of that-- and it's up to each user what wallet software they run. Because of prior malleability attacks via closed off malleability vectors we're fairly experienced with what the effects of malleability are, to the extent that there has even been an academic paper written on the subject.

So-- to set the stage, we have a fix to a denial of service attack (S-flip ECDSA malleability) which was discovered by Bitcoin Core contributors and had never previously occurred on the network at any scale, but where deploying the fix would deny service to all users until they changed software. Deploying the fix, which was implemented, tested, and included in Bitcoin core for a long time requires only miners changing their software to enforce it and presumably could be done in a couple hours if there were a need. (and whom could have done so at _any_ time, regardless of what Bitcoin Core did-- even against our advice, ... and with trivial effort, since we'd already written it and integrated it but left it off.)

Bitcoin Core changed behavior to the fix compatible form and encouraged others to do so, it also implemented and tested the filtering but left it off so as to not deny service the vast majority of users. Through continual efforts to encourage parties to upgrade we reduced impacted transactions that down to around 5% before anyone performed the particular attack... and at that point we activated the fix in Bitcoin Core on the basis that 5% disrupted completely is better than 100% bothered whenever the attacker feels like it.  

At the same time, virtually every alt-coin; most developed completely after this issue was known, including many that have no relation to the Bitcoin codebase (and even at least one that specifically advertised itself as being malleability immune!)-- remain vulnerable.  

Meanwhile, what have you done to aid any of this?  As far as I can tell absolutely nothing.  You complain about leadership-- I think that's nonsense and that we've acted prudently, professionally, and intentionally... but, ignoring this disagreement, if you think it's more "leadership" is needed, why are you exhibiting a total failure to provide it?  Is it that you are "frozen with fear", enh?   Roll Eyes

Please, if you're going to continue with this style of barely informed insults and personal attacks, I'd prefer you remove yourself from this sub-forum.   Or better, why not save some of your attacks for those people throwing similar insults at Bitcoin Core, calling it reckless for actually moving forward with the fix at this time?  One of things I find most fascinating about human behavior is that no matter how diametrically opposed people's views are their ability to unify behind being shitty towards people who _give_ them things for free seems to known no bound. Tongue

I'm sorry if I created the impression the problem would not have been solved if the core devs had done nothing.  That was not my intention.  I should have written more clearly.
Indeed,  if the core devs had not implemented a fix, they would have simply been bypassed. Perhaps this would even have been a good thing.  (I am one of the people who believes that multiple implementations of bitcoin are essential for its future growth and that the present mono culture is ecologically untenable.)

In one breath you say "mono culture is ecologically untenable", but yet you attack a strategy that is specifically constructed to be inclusive and avoid unnecessarily driving out implementations with fewer resources behind them out of the ecosystem.  You recognize that technically anyone could have fixed it, yet ignore your own completely failure to do so (or, seemingly, anything else productive in this context)-- in our case, we had a specific intention to preserve diversity in the ecosystem by not forcing updates on other implementations and their users, but you have no such excuse, arguing that it should have been done years ago. Remarkably, I find the seeming lack of logical consistency in your arguments more offensive your incivility. Smiley
671  Bitcoin / Development & Technical Discussion / Re: A quick idea, mining tokens on: October 21, 2015, 08:44:46 AM
Step 1. Monopolize tokens
Step 2. Totally control system.
Step 3. Profit.

The reason Bitcoin is decentralized is not insignificantly because anyone can enter or leave at any time without permission.  You can close off attacks by requiring a permission system (even soft ones like modulating the difficulty) for mining of some kind or another, but you open up other ones.

And as you note, what you suggest would kill hashrate-- you don't describe a personal incentive to secure the system but rather an incentive to hope other people do while you sit back and enjoy the benefits. ... and if they don't? oh well-- you participating wouldn't make much difference, and it would just be more cost to you.
672  Bitcoin / Development & Technical Discussion / Re: Dust threshold changed without any mention in 0.11.1 on: October 21, 2015, 07:32:57 AM
If you are not using the Bitcoin currency except incidentally but instead abusing the system to store data there are no promises that you're going to have a good time. It's not in the users of the system's general interest to accept an eternal data storage cost on your behalf.

As mentioned above, there is no explicit "dust threshold"-- it's determined by the minimum relay fee rate.  In particular, the number "540" you were expecting was certainly never announced;-- and the change to the relay fee was absolutely release noted; and important for keeping nodes from blowing up in the short term-- yes, a somewhat lower value would have also worked but the relay fees were out of wack (adjusted predicatively down when the prices was at almost three times the current and going up) and the minimum bump might have been met immediately by the attackers (who can update their behavior much faster than people can upgrade software).

Above you write that you are creating unspendable outputs-- this is _specifically_ one abuse of the system dust threshold was intended to discourage; so it sounds like it's working as designed now.

But by all means, feel free to not upgrade your software or change its behavior... it's not the action of your own software that will inhibit you-- all it does it tell you quickly and cleanly so your transactions don't get stuck, it's the action of everyone else that inhibits the abuse. And it is quite effective, or else I suspect we wouldn't be enduring your vicious invective.

If someone is looking for a safe dust approximation without any relayfee intelligence, the original level of 5460 base units is probably a better expectation.
673  Alternate cryptocurrencies / Altcoin Discussion / Re: Zero Knowledge Transactions on: October 17, 2015, 06:41:58 PM
1. Plagiarize the work, shared freely, of Adam Back, Shen, Denis, myself, and others (and in my case even implemented in a high performance implementation).

2. Ask for twenty grand in donations.

3. Profit.

Here's a hint to someone who might think of funding this stuff, "just in case":   Non-contributiors being paid for what is primarily your work is incredibly demoralizing-- doubly so when they don't even add anything to it (not even a good implementation); if you want to kill science and engineering in this space go ahead and fund more vaporware scams.

Science needs to happen in the open. I'm also very supportive of people being paid for their work, but they need to actually do work, not just sell snakeoil to others.  This community often does a much better job at funding scams than people who reliably contribute.
674  Bitcoin / Development & Technical Discussion / Re: New transaction malleability attack wave? Another stresstest? on: October 15, 2015, 11:57:34 PM
This is very close to hardfork.
Yes. I do understand that it is not a hardfork in strict terms.
I don't agree, not even in the most lax of terms.

It's a standardizes rule,  and already on the order of 95% of transactions were already conforming.  If a wallet produces a non-conforming transaction anyone in the world can mutate it to the conforming form.  Even absent the auto-mutation, when it doesn't work-- it fails safe: you can still receive transactions, but your sends may not work; and you can either update your software or find someone/something to mutate them for you. It's likely that due to 'helpful' mutation and non-upgraded nodes and miners the remainder will continue to get confirmed (with delays) for some time... and that 5% remaining should drop as electrum and armory get updates out.

I would have preferred to continue to wait to activate the filtering, which has been implemented and waiting in Bitcoin core for years now, until even more users were upgraded... but the ongoing attacks made that a poor trade-off:  There is no reason that the creators of 95% of the transactions should suffer attacks because we were worried about inconveniencing the remaining 5%.   I also called in this thread multiple times for help driving that 5% down to nothing and no one else cares, so-- how much can the negative impact matter when basically none of all the noisy people in this thread cared to lift a finger to help mitigate it?

All the other avenues for "nuisance mutability" that we're aware of were closed long ago, some of those also required getting wallets to update, but far fewer wallets were broken with respect to those rules. Fortunately, until recently, no one who wanted to attack had bothered figuring out how to perform this particular attack (as it's ever so slightly tricker-- can't just be done by stuffing an extra byte in a transaction); unfortunately that didn't last, and so we got to lose huge amounts of effort dealing with this and creating a small amount of additional collateral disruption instead of working on other things; the result will likely also delay the deployment of CLTV some due to difficult in getting miners to update twice in rapid succession... but thats life.
675  Bitcoin / Development & Technical Discussion / Re: New transaction malleability attack wave? Another stresstest? on: October 15, 2015, 07:11:15 AM
Are there any negatives to this fix?
I suggest reading this thread.

Seriously. such an embarrassment.  So much grunting and flinging of poo and people don't bother to read messages of actual substance.

676  Bitcoin / Development & Technical Discussion / Re: Fees for full nodes? on: October 15, 2015, 12:37:14 AM
Currently, pruning is not the solution. You should be able to operate a full node with pruning. That means you need to be able to exchange UTXO information and an UTXO hash has to be stored in the block header.
You can operate a full node* with pruning, what you're going on to describe there is UTXO commitments which are totally unneeded for pruning and are of unclear cost, unclear value, and unclear implications.

Unclear cost: rehashing the utxo set for every block, even if maintained in a high overhead efficient data structure is a multiplicative IO cost on running a full node.  Making the initial cost cheaper is essential, but at what runtime penalty is it acceptable?  is 20x acceptable?  If the utxo set is constantly changing, how do people synchronize it from you?  do you have to hold old versions? does a peer have to fetch it only from a single other peer?

Unclear value:  starting off a utxo commitment means you have only SPV security. If you were happy with SPV security; why not run SPV in the first place and dispense with the intermediate step. The answer is that it's only SPV of the history, but where is the dividing line? When someone today says how do you know that the system's creator didn't secretly mint himself a trillion coins-- the answer is because your own node verified it wasn't so.

Unclear implications: with no incentive to not run a committed bootstrapped node, is there any reason to believe the old history would even be _available_ to someone who wanted to do a full security initialization?

(*And in Git master Bitcoin Core relays blocks and transactions, and gives full wallet functionality, minus rescan when pruned.)
677  Bitcoin / Development & Technical Discussion / Re: Feature that should be added on: October 14, 2015, 05:18:27 PM
But you can't fall under the trap of keeping Bitcoin Core as a super limited software with basic features forever if you want to give people an incentive to run full nodes. Sure, it should stay basic and extremely solid, but make it more usable and user friendly as well.
AFAIK franky1 has nothing to do with the development of Bitcoin Core (yet).  We'd love to have more features (and actually there are many very advanced features that are not available most other places... there just are not as many "middle tier" features), but people need to step up and contribute. Most of us are completely saturated just keeping the with the increasing demands on the network.

You can use Bitcoin Core offline-- I do and have for years. It's just not super user friendly to do that.
678  Bitcoin / Development & Technical Discussion / Re: A mistake in (Satoshi's github account) on: October 14, 2015, 02:49:58 AM
Because s_nakamoto@1a98c847-1fd6-4fd8-948a-caf3550aa51b  was never an account on github anyone could add that as one of their email address to claim these commits-- just stupidity on github's part.
679  Bitcoin / Development & Technical Discussion / Re: New transaction malleability attack wave? Another stresstest? on: October 08, 2015, 05:43:32 PM
The is an easy rule-of-thumb to spot high-S signatures.  For example, the following sig is high-S
This test is not quite precise, so implementers of bitcoin software shouldn't implement the test this way. Smiley The threshold is not a power of two, so no tidy hex digit sniffing can be precise.
680  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: October 08, 2015, 05:41:10 PM
Does it mean that x and a are to be communicated privately (off-chain) from sender to recipient of coins? Anything else that is communicated privately?
Also, are commitments required for outputs only or you need to include input commitments as well in your transaction data? If including input commitments, I wonder if it makes sense changing their blinding factors, not just copying them from source outputs.
x is private by virtue of being the conveyed by an ECDH key negotiation. No external communication is required.  (E.g. go build elements alpha, and give me an address from it and I'll send you some coins!).

They're required for outputs only, and technically only when there are multiple outputs. Inputs are already known to be in range by virtue of having been created as outputs.
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 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 80 81 82 83 84 ... 238 »
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!