Bitcoin Forum
February 21, 2017, 05:34:33 AM *
News: Latest stable version of Bitcoin Core: 0.13.2  [Torrent]. (New!)
  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 ... 233 »
481  Bitcoin / Bitcoin Discussion / Re: Bitcoin maleabity attack - who made it and is it still running? on: October 08, 2015, 01:13:56 AM
Please explain (or reference an explanation) as to why malleability features would be quite useful.
For example, anyonecanpay sighash flag allows arbitrary parties to add funds to a transaction. It's what makes lighthouse possible, but every time someone updates the transaction the txid changes.

Also, I would like to understand why people care about old implementations that aren't being actively maintained by people who are following bitcoin.  Please explain why it matters what happens to these old implementations?  Why should you or anyone else waste effort to dig up these issues?
Because they are widely used (or had been historically-- we're getting to the point where .this is less true). Just blocking the transactions for non-trivial amounts of users does not yield a good experience, to say the least. Forcing people to constantly rev their software reduces decentralization-- and who precisely has the authority to go decide what is "old" or "actively maintained"?--if people are happy happy with what they're running, I am not eager to disrupt that.  I am also not eager to try to dictate how often authors of wallet software must revise their software (again, something that would reduce decentralization-- by pushing out development teams with less resources).  As to why you should care and go help move them along: it's cheap to do, and the failure to do so holds the ecosystem back.--- the same reason I've done so.

If you note the patch I linked to, my change was only a few characters--- why? because the code was already written a long time ago... but not activated due to waiting for the ecosystem to catch up; we're ready.
482  Bitcoin / Bitcoin Discussion / Re: Bitcoin maleabity attack - who made it and is it still running? on: October 07, 2015, 07:35:08 PM
The problem is that a known bug in the bitcoin protocol has festered for years.  If the "core" developers had been doing their job, this problem would have been fixed long ago.
There are a dozen different malleability vectors in the protocol as originally designed; some are quite useful and important intentional features-- others are not.  Though the harm from malleability is very moderate-- and because of the intentional features and the potential for ordinary double spends, wallets must have basically sane handling for it--, unwanted third party malleability is a nuisance. In Bitcoin Core's wallet the nuisance can be greatly mitigated by setting spendzeroconfchange=0.

Because of it being a nuisance all of vectors for malleability except for one were blocked as non-standard transactions in Bitcoin Core years ago.  The remaining one could not be simply blocked because it requires transactions to confine their signatures to a particular form-- low-S-- and all software was violating before the issue was known.  Because of this applying that final constraint would have blocked almost all transactions on the network-- something not justified for a nuisance level attack. Bitcoin Core changed constrain its own transactions to this form in 2013 but it has taken a long time for other software to update themselves. Fortunately, the final remaining type of malleability was ever so slightly trickier to exploit, so people haven't been doing so at scale. In the meantime a proposal was made, as part of BIP62, for a v3 transaction type where parties creating transactions could opt into the protective behavior if they were recent enough to support it. Unfortunately BIP62 is fairly complex and no one outside of a small group of contributors to Bitcoin Core have cared at all about advancing it.  So we've been breaking up parts of them and applying them to the consensus incrementally (e.g. BIP66).

Current git master Bitcoin Core enforces the requirement for all transactions it relays or mines, once this is in a release and widely deployed it will end this irritation; but it will also block most transactions from small portion of the network on software which is out of date or hasn't been updated to produces anti-malleability-friendly low-S signatures (on the order of 5% of all transactions now; due to ongoing efforts to harass parties to fix their wallet software).

I've called for assistance several times in identifying the origin of a list of lowS violating transactions in order to help speed deployment of this, but it seems that the Bitcoin community is a lot more interested in whining and throwing blame then stepping up and doing a little bit of the non-development work needed to get this deployed. Sad
483  Bitcoin / Development & Technical Discussion / Re: OP_CHECKLOCKTIMEVERIFY source code clarification on: October 06, 2015, 09:04:33 PM
It is saying that if this case weren't rejected then CHECKLOCKTIMEVERIFY could be bypassed by the signer, via making all their txins final.  To prevent this, _this_ txin is required to be non-final.  From a modularity/clarity perspective it's preferable if a script has only local effects (only looks at it's own input) unless more is needed.
484  Bitcoin / Development & Technical Discussion / Re: New transaction malleability attack wave? Another stresstest? on: October 06, 2015, 08:22:33 PM
If you are changing bitcoin core in response to this you are likely doing something wrong.

You can simply test anything here on your own too, just use two wallets in regtest mode and sign a transaction twice to get two versions.

Running this attack makes it hard to collect data on which signer software needs to be updated to produce lowS signatures-- which is important for fixing the behavior--, so it would certainly be preferable if it weren't going on. (... not like this thread actually gives a darn about fixing the behavior. Sad )
485  Bitcoin / Development & Technical Discussion / Re: New transaction malleability attack wave? Another stresstest? on: October 05, 2015, 11:28:14 PM
Yes, and that sounds like a good solution. Miners could mutate all transactions into their 'canonical' state before mining them. That way well behaved wallets aren't affected, and wallets creating weird transactions still have their transactions mined, but with a different txid.
This is a fine thing to do (though it requires first getting the amount of non-canonical producers down to a negligible amount, something I've been trying to accomplish for two years!); but it does not achieve the goals of BIP62,  which is to make transactions involving refunds safe... doing that requires that the solution not depend on miner honesty. Smiley Thus BIP62... that it fixes third party txid aggravation for a subset of transactions is a helpful side effect (though first/second party txid changes and malleability will _always_ remain in general, because it's a feature.. not a bug. And wallets do need to handle it sanely).

But it seems people are much more interested in whining here than working even the basic detective work to cut out the last of the non-canonical users on the network (which I've asked people to do _twice_ in this thread, and not a single message has made progress towards that).   Come on people,  don't prove Amaclin right about the Tragedy_of_the_commons comment. Smiley

486  Bitcoin / Development & Technical Discussion / Re: New transaction malleability attack wave? Another stresstest? on: October 05, 2015, 05:56:05 PM
Bitcoin concept is broken. Nobody can fix it. Point.
Not so! (well, if the concept is broken, after all it isn't due to the substance of this thread.)

You are asking something from the bitcoin core developers, but you are not paying them and even not contributing.
Is it correct behavior?
Harsher than I would have said; but there is a point there.  Often on these things what happens is that people who don't know have one view of the priorities, and people in the know have another. If someone's priorities differ they need to step up--- and sometimes that does happen but once they learn more their priorities change. Smiley See also table 1:  the greatest pain vectors of malleability can be avoided simply with careful wallet design.

In the case of BIP62 one of the reasons it has not progressed is that we haven't had enough review capacity to achieve confidence that such a broad scoping change would actually achieve its goals and not cause collateral damage-- especially because with "random pain" mostly answerable via wallet design-- the goal of it becomes making multstep contracts secure... which is something that can't be approximate.

BIP66 pulled forward part of BIP62 that was done and ready.

Folks here like int03h suggest that nothing has been done, but the opposite is true-- in terms of easily malleability on ordinary transactions, IsStandard-like-checks almost completely cover it. Every known vector of malleability has been closed off that way, except the one where common wallets still emit random forms. If we could enforce lowS as a standardness rule this issue would likely no longer be a source of intermittent annoyance for ordinary transactions. Bitcoin Core has been ready for that for roughly two years. But since we don't want a world where everyone is forced to run Bitcoin Core (much less the latest version of Bitcoin Core) reality is limited by what improvements people adopt.

People don't even need to be developers to help-- I posted a list of highS producing addresses, if we can identify more software which produces this form and get it fixed then we'll be well positioned to move forward. Why are people still whining here instead of sluthing? Come on-- I'm not even asking anyone to write code.

FWIW, virtually every cryptocurrency (including litecoin) has the same kind of issue, even some promoted as "immune to malleability"... Even most created after this issue was well understood in bitcoin have not bothered learning from it. That this property existed in Bitcoin is unfortunate but easily justifiable, that so many others have slavishly replicated  this well known poor behavior, even when the Bitcoin community knew exactly what was needed to stop it completely, is something else entirely.  My own published alternative network work, the Elements Alpha testnet sidechain, eliminated this whole class of issue in a very complete and robust way-- but its approach is not easily applied to Bitcoin because the deployment would be disruptive. Fortunately, for what people are currently complaining about nothing that complete is required.
487  Bitcoin / Development & Technical Discussion / Re: New transaction malleability attack wave? Another stresstest? on: October 05, 2015, 06:36:21 AM
I'm curious, why is `SCRIPT_VERIFY_LOW_S` not a standard verification flag?
Because it would block ordinary transactions from many implementations.

I have been nagging implementers on and off for a long time to fix their behavior.  In this latest round it looks like Strongcoin, Bter, Kraken, anything using pybitcointools (full of really scary broken crypto, nothing should use it), electrum (just fixed because ThomasV is awesome), were things I could easily identify.

It's been slow going-- even BIP62 only applied that restriction to flagged transactions.

If anyone feels like playing detective, here is a report someone else ran for me of addresses which were violating low-S (before the recent attacks): (leading number is how many times the pubkey was reused in the analysis window).

Getting more implementations to produce low-s for all their transactions would be very productive.
488  Bitcoin / Development & Technical Discussion / Re: Format for full file signatures on: September 26, 2015, 08:10:01 PM
Bitsig does not (yet!) include any PKI infrastructure possibilities, and is therefore not the first option
for large corporations that would create a trusted root certificate that is used to sign other certificates.

However, for decentralized users such a trusted root might not be very useful anyway.
Open source software is one such area.
PGP does not use a trusted root.

1Bitcoin uses shorter keys than PGP, which is an advantage over PGP.
RSA require longer keys than elliptic curves. RSA does the job,
but elliptic curves is a better algorithm when it comes to the key length.
PGP can use ECC too, for some time now.

Though for files the size of the pubkey keys and signatures is usually not very interesting.

However, downloading from different sources over different channels will increase your trust in the public key.
A cryptographic hash of the file works just as well for that purpose.  Though a network attacker near you can thwart any other unauthencated source you see.

Also, since a bitcoin address is short, it is easier to send with for example SMS.
A pgp fingerprint is short. Bitcoin addresses are very unfriendly to read over the phone due to mixed case.

If anyone else finds bitcoin full file signatures useful my hope is that the specified file format will be used
when new bitsig-aware software is crated, possibly with another ECC implementation.
Perhaps... but even ignoring the lack of PKI this design isn't good fit for files too big to fit in memory. Ideally you want a tree structured hashing scheme for that.
489  Bitcoin / Development & Technical Discussion / Re: Format for full file signatures on: September 25, 2015, 06:59:11 PM
Yes. Bitcoin uses digital signatures. It also uses addition. And linked lists.  Yet you don't see people going around replacing other things that use addition or linked lists with parts of bitcoin. Smiley

Providing a useful, secure, and usable system for authenticating files is vastly more than just having a digital signature, in the same way that creating a cryptocurrency is vastly more than just having software that can perform addition.

Getting it right involves satisfying numerous cryptographic, procedural, and user interface goals which are completely unrelated to Bitcoin.

A digital signature by itself is meaningless. Anyone can create one. Look at the signatures on your site... it's served over HTTP and you have these .bitsig files. Anyone who could tamper with the download in the first place could simply replace the signatures: so at least as it's being used there the signatures provide virtually no security.

Having evidence that the pubkey key being used is an authentic one is the hard part-- but this system seems to do nothing for that; and Bitcoin provides no answers for that--  in the design of Bitcoin keys are the exact opposite of persistent identity-- anonymous, ephemeral, and hopefully single use.

PGP, on the other hand, has extensive infrastructure for the verification of keys.

So that is the primary reason we use it rather than something homebrew.

Some other things to think about for anyone working on this...

Bitcoin works with transactions, which are necessarily small... but a good file signature system should have a structure that makes it possible to work with files much larger than memory.

As an aside-- looking at your codebase, I see that it contains a completely naive and quite slow implementation of ECC. This approach will bleed out information about the users' private key via timing, cache, and electro-magnetic sidechannels.  Mature cryptographic software (like GPG) avoids these sorts of vulnerabilities. I also see that it doesn't use derandomized signing. I'm glad to see there are some tests, but you should be careful-- a number of people have suffered serious losses of funds due to incorrect pubkey/address generation in rare cases that a few fixed tests vectors are unlikely to catch (e.g. rare corner case bugs in bignum libraries). Doing a real review of the cryptography in the project would be a ton of work... and I think it's unlikely anyone will do so, because there doesn't appear to have been a reason to reinvent the wheel in the first place (beyond your own education, which is super valuable, but not a great reason to create software for other people to use).

Separately, looking at the instructions tools seem to frequently expect users to provide secret data on the command-line. This will result in it ending up in the shell history on many hosts, as well as being easily visible to other processes. It's usually better to avoid that.  Brainwallets are generally really inadvisable and we've seen over and over that most users are unable to use them safely and as a result there has been a lot of loss, but especially the kind of non-hardened (no KDF) brainwallets that this software implements is especially irresponsible.
490  Bitcoin / Technical Support / Re: Any safe way to config RPC when running on TOR? on: September 25, 2015, 06:12:45 PM
Tor hidden service support can only connect to the specified ports in the tor configuration.

Additional your RPC is protected by the rpcuser/rpcpassword. The binding restriction is just belt and suspenders because, e.g. sometimes users copy their rpcpassword out of example configurations they find on the internet.

Just don't to anything too crazy-- like copy your rpcpassword off the net or reconfigure tor to allow connections to the rpc port-- and you'll be fine.
491  Bitcoin / Development & Technical Discussion / Re: Two Full Nodes, Same Router on: September 22, 2015, 01:20:49 AM
It appears that in order to run a full node port 8333 must be forwarded to that computer.
Not so.

Wouldn't it be nice if all problems were this easily solved. Smiley
492  Bitcoin / Development & Technical Discussion / MOVED: Using the Node.js API on: September 21, 2015, 03:57:26 PM
This topic has been moved to Service Discussion.
493  Bitcoin / Development & Technical Discussion / MOVED: need someone familiar with finite field arithmetic to write whitepaper on: September 20, 2015, 09:05:43 AM
This topic has been moved to Services.
494  Bitcoin / Development & Technical Discussion / Re: Reducing the orphan rate to 0 in a >100k TPS chain on: September 19, 2015, 10:28:38 PM
I think you're missing my point:  There is no reason to care about orphans absent double spends and incentive compatibility in mining.   If a scheme eliminates "orphans" without addressing the reasons anyone would care about them, then it's uninteresting.  Assuming efficient transmission they don't even appear to have a greatly adverse impact on goodput, as if the 'orphan' blocks carry mostly the same data you only need to send the insignificant amount of differential data.

E.g. imagine someone "solving" orphans by renaming them to bloopthrops; thus the system is orphan free. Smiley

495  Bitcoin / Development & Technical Discussion / Re: Reducing the orphan rate to 0 in a >100k TPS chain on: September 19, 2015, 09:25:56 PM
The reason to care about "orphaned" blocks is because you might believe a transaction is confirmed when it really won't be part of the eventual history.  This cannot be prevented in a system without predefined membership, because its always possible that there exist two conflicting transactions where both cannot be confirmed.  You can eliminate orphaned blocks by eliminating blocks and yet provide no improvement to anything that matters to anyone. Smiley
496  Economy / Services / Re: need someone familiar with finite field arithmetic to write whitepaper on: September 19, 2015, 08:57:25 PM
This isn't the soliciting people to write stuff for you subforum.  Please describe what you're doing (even informally) or move your post over to the marketplace/services subforum. (I'd just go and move it there now, except perhaps maybe you would like to describe it here).

If you describe it you may find someone has already written up substantially the same idea elsewhere; which would save a lot of time! Smiley
497  Bitcoin / Development & Technical Discussion / MOVED: how did I get a transaction stuck in the blockchain? on: September 17, 2015, 09:59:18 AM
This topic has been moved to Electrum.
498  Bitcoin / Development & Technical Discussion / MOVED: Do unforgeable p2p random numbers rely on max difficulty POW? on: September 16, 2015, 10:39:38 AM
This topic has been moved to Altcoin Discussion.
499  Bitcoin / Development & Technical Discussion / Re: Aggregate Signatures for protecting hotwallets (AKA Luke Wallets) on: September 11, 2015, 11:27:54 AM
What you're doing is normally called a threshold signature or multiparty signature.  An aggregate signature is usually used to refer to a scheme which takes tuples {message1, pubkey1, sig1}, {message2, pubkey2, sig2} and yields {[message1, message2], [pubkey1, pubkey2], sig12}.

In Bitcoin we have a multisignature scheme which is widely deployed and used by many parties-- any 3xxx address is likely this.  In Bitcoin our digital signature scheme is not ECDSA directly, but Script.   The pubkey people use is either a template for a program or a hash of a program which Bitcoin outputs are marked with,  the multisignature scheme is just to specify a program that includes multiple pubkeys and a OP_CHECKMULTISIG that expects multiple signatures.

There is some efficiency loss in this, but for thresholds less strict than N of N they gain a very useful property of recording in an irrefutable way _which_ of the parties signed.

In the second part of my presentation at  at 19 minutes in I present several useful criteria for candidate multisignature schemes under the mnemonice ACEUP:

Accountable -- authorized parties should be able to tell who signed after the fact and prove it to others.
Composable -- you should be able to take other people's threshold keys and make a threshold of thresholds, so that your own use of threshold security doesn't remove your ability to be a member of a threshold
Efficient -- the size and verification performance should be minimized
Usable -- the scheme should not require excessive round trips or other such burdens
Private -- The scheme should minimize disclosure of the access policy.

The Bitcoin CMS it's Accountable, potentially somewhat composable (though not with current software), not efficient, though usable, but not private.

If something is using schnorr signatures--then s = k - xe and a native multisignature is trivial (and implemented, for example, in libsecp256k1). I am quite confident we will just support that with Bitcoin in the future.
Though the native efficient multisig fails accountability, there is also work on other schnorr based schemes that retain accountability while meeting the other criteria which I mention in that ACEUP presentation.  Pieter recently implement one of them and presented on it:

At a first look it you may have reinvented (or be on the road to reinventing) the scheme of  but it's not clear to me--  in your example you don't make it clear how the decryption works. If you just have a single party (say party 2) that has the pallier decryption key then that party can decrypt a partial then recover the nonce and extract the group private key from the whole signature (or a users partial from the partial).  I think to be secure you must have distributed pallier key generation and distributed decryption which adds much complexity and a(n) additional round-trip(s).
500  Bitcoin / Development & Technical Discussion / Re: Why build on the longest chain? on: September 09, 2015, 01:06:49 AM
Bitcoin has a stronger security story if you assume that there are many alturistic miners (or lazy parties and a total absense of economically rational developers to sell them better software).

This kind of pattern has been discussed many times in the past with varrious variations, includling things like pay to bury a double spend (with a chain of locked transactions paying high fees).  Most of them right now only apply to fairly contrived cases involving mistaken fees, though as the subsidy goes down all fees end up high enough to trigger them.

Is it right to just assume the network is altruistic (or usefully lazy)? No -- if for no other reason than we've directly seen instances of miners intentionally act in ways to screw over users in order to make more profit. But I think it's also wrong to assume that it isn't alturistic at all.  And at that point we start leaving the realm of what we can reason about formally and enter the realm of things that can only be judged by expirence and which are more vulnerable to chance. This doesn't frighten me-- even in the much stronger systems the real world always undermine your most critical assumptions.

That said, we should try to deliver something that has the best security properties under the weakest possible assumptions.  The particular problem you've suggested here pretty much go away if transaction fees are mostly isotropic (which they would presumably be if transaction fees were efficiently allocated) and there is a standing backlog of transactions.

The harder case is the pay-for-reorg, and so far the best tool I've found to potentially improve that is the use of one-way-aggregatable signatures to make it computationally to extract a transaction that you only learned about from a block announcement and include it in your own block... but I think thats a fairly weak protection.

DannyHamilton suggests that there is coordination risk, but income maximizing behavior is a an awful good shelling point. Especially in a world where single miners have macroscopic shares of the hashpower, I'm not sure this risk of defection from rational behavior is a terribly strong protection-- but it is some protection.
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 ... 233 »
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!