Bitcoin Forum
October 05, 2015, 01:24:54 AM *
News: Latest stable version of Bitcoin Core: 0.11.0 [Torrent]
  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 ... 209 »
1  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.
2  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.
3  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.
4  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
5  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.
6  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.
7  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

8  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
9  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
10  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.
11  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.
12  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).
13  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.
14  Economy / Scam Accusations / Re: PSA: cypherdoc is a paid shill, liar and probably epic scammer: HashFast affair on: September 09, 2015, 12:33:17 AM
Another way to look at it--  is there anyone here who still would have done business with hashfast if they knew cypherdoc was going to get 10% of the purchase price, in advance of delivery, regardless if the delivery ever happened?  I don't really think so-- it certainly would have greatly upped the risk estimates. Getting some discount gear or a demo unit is one thing, but 10% for making some forum posts?  Thats alarmbell territory--  and yet cypherdoc knew this material information, and didn't share it.

Cypherdoc's contract was more reason to disbelieve the terms they were promoting that made their sales pitch so attractive in the first place:  Full refund of the Bitcoin's sent if they failed to deliver. They only works if you retain the coins... now it's possible that they could give him 10% and purchase at spot to prevent ending up with an unbacked liability, but at a minimum it would have resulted in a lot more critical questions. Doc also repeated as fact on reddit Icebreakers claim that his "job was to act as community liaison and help HF raise part of their NRE" that he knew the presale funds would be used to cover unfunded NRE, rather than the position of these costs having already been covered by outside investors. He surely didn't share _that_ fact with any of in his posts. I guess he had a few hundred thousand reasons not to, enh?

He continued his promotion without reservation while Simon happily made promises about refunds in the event of failure, even though his _job_ existed because these claims were impossible and the sales contracts were being made in bad faith.

The ludicrous 3000 BTC payment for a couple forum posts (regardless of if you think of it in terms of $350k or 10%) makes a little more sense if you consider that he was being paid to raise _investment_ rather than promote a product.  So sad for everyone else that Cypherdoc knew they wouldn't get the funds if people had a complete picture and understood the liabilities.  I guess thats more charatable than the prior leading theory that they were paying him so much in order to tunnel money out of the company.

Cypherdoc defends his unconsionable windfall here with "a contract is a contract, is it not?"-- but the customers of HF whom had far less access to information and were (AFAICT) deliberately mislead by Cypherdoc and others all had contracts which were not upheld, and under the law are some of the first in line for recovery in an insolvency. The technical details of the chineses walls drafted into documents to attempt to isolate people from their fradulent actions isn't of consequence to the people that got screwed,  no amount of contracting with me can enable Alice to help me rip-off Bob without creating liability for Alice in any sane system of law. The courts should have the thoughtfulness to see through the pretext here and recover all the available procedes from HF's bad business from all of the people involved in misleading people in the first place.
15  Bitcoin / Development & Technical Discussion / Re: Towards more consistent block times on: September 04, 2015, 12:30:18 AM
Yes, low variance hashcash is a well known thing.  But this is undesirable for Bitcoin (also a pereneial proposal).

Blocktime variance is a desirable and necessary element of the system!

Imagine a system where miners always produced blocks in X minutes, zero variance.  Then one day a conneivity burp happens and two blocks are formed. Then each is extended precisely in X minutes.  The network will be forever split and never rejoin!

So Bitcoin uses the variance to achieve convergence with increasing probablity over time.  If the variance is too low relative to the network topology the system will expirence longer and longer reorgs and eventually fail to reach consensus at all.

If some variance N fold reduced would be acceptable for converenge, one could just use blocks closer togeather to get the same variance... but then also have lower latency at the same time.

Seperately, the obvious way to construct what you're describing result in a system which isn't progress free, which would mean that larger miners would have an unfair advantage, which is also undesirable as it would be an additional centeralization pressure.
16  Bitcoin / Development & Technical Discussion / Re: Soft fork to implement SIGHASH_WITHINPUTVALUE on: August 31, 2015, 07:07:06 AM
Ugh.  Thats pretty awful to fix in a txout what the maximum fee for that txout,  you can easily end up making inputs really annoying to spend in the future.

Please, there is no need for something like this. A simple new checksig operation is much more tidy improvement (e.g. like the one in elements alpha that includes the txin value under the hash), and one will be proposed once the current softfork backlog can be cleared.

That anyone ever suggested something like this as a hardfork was purely the result of confusion.
17  Bitcoin / Development & Technical Discussion / Re: What is the status of BIP62? on: August 31, 2015, 07:03:10 AM
BIP62 is neither necessary or sufficient for micropayment channels;  CLTV is sufficient and nearly necessary.   Thats next in the pipeline;  unfortunately BitcoinXT has screwed up the soft-fork pipeline by getting a bunch of nodes deployed that produce super high version numberss, breaking the existing CLTV code... so people are working on revising those proposals now.
18  Bitcoin / Bitcoin Discussion / Re: Please list arguments against the idea of taking away Gavins' alert keys on: August 30, 2015, 08:04:30 PM
The alert functionality is nearly useless, and the usefulness it had has been outlived. No one ought to have the alert key.

At the same time, is also nearly riskless now that its already there-- anyone with the key can instantly terminate any announcement made with it and, if needed, permanently disable the alert system. Which is why when we proposed removing it, is wasn't hard for someone to argue otherwise.  In the next release of Bitcoin Core any participation at all in it will at least be optional (though default on):

In the elements alpha sidechain, alerts were replaced with multisignature... but I still hope in Bitcoin we remove the system entirely.  Theymos case of wanting to warn people about serious software issues could be accomplished by things like a transaction sending a specific (high vauled) coin to fees triggering a static message to tell users to check for notices.

The functionality creates inequality, it creates attack surface, its very infrequently used-- and when used appears to do very little good. But the biggest reason I'd like to remove it is that it promotes centeralized misunderstanding of the system. It is an incredibly weak functionliaty: a small collection of people can send a little text message to a (sadly) tiny portion of Bitcoin's users. Thats it. But many people can't help but believe that every system has someone in charge of it, and the alerts give them something to latch onto. As a result of alerts we've had to deal with frequent worthless suggestions like the alerts should be able to control system parameters (like fee settings and block size limits)... people who can't see shade of grey and think that because we'll tolerate a very mild messaging functionality that all sorts of other ill conceieved centeralization is okay.

In the altcoin space this has gone further-- e.g. there are several altcoins that use code based on the alert system to allow (or in peer coin's case-- require) the developer to use their single trusted private key to pin the identity of the chain, overriding the network's consensus process. It's an ugly path, and while the first step down centeralization road is easily argued to be harmless it would certantly save a lot of misunderstanding to clearly not be going down it.

19  Bitcoin / Development & Technical Discussion / Re: New Proposal to reduce space requirements for full nodes on: August 29, 2015, 07:50:55 PM
This is just the problem of the 0.11 implementation. Not a protocol issue. They will fix it in future version
Not even a problem-- the wallet support was just untested so it was disabled to avoid delaying the feature. It more or less worked from the very first patch (as 0.8 radically change the design of the software to accomidate that-- we've been working towards it for a long time).
20  Bitcoin / Development & Technical Discussion / Re: Miners should donate to Nodes on: August 29, 2015, 07:48:43 PM
Miners should send a little % of the fees of the block to all connected peers. Independently of the protocol.
Why would they choose to do that?

This has some MIM attack problems isn'it?
Yes, but even if that was resolved --- All that would seemingly do is incentivize people to sybil attack the network.
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 ... 209 »
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!