Bitcoin Forum
August 03, 2015, 08:39:10 AM *
News: New! 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 ... 207 »
1  Bitcoin / Development & Technical Discussion / Re: Spam attack and miners choice of transactions on: July 31, 2015, 08:43:20 PM
Because the size of a block is limited, the approriate stratey (ignoring transaction dependencies) for miners to use is to order transactions by fees per byte and select in that order.

This is what Bitcoin Core already does.
2  Bitcoin / Development & Technical Discussion / Re: Q:Is there a deterministic private-public keypair generator w/o the BIP32 issue? on: July 31, 2015, 06:17:29 PM
I responded to this here:

But this is not currently compatible with Bitcoin (and due to the high verification costs for BLS signatures I dunno if I'd rank it pretty highly).

Isn't that what hardened keys are for? From BIP32:

One weakness that may not be immediately obvious, is that knowledge of a parent extended public key plus any non-hardened private key descending from it is equivalent to knowing the parent extended private key (and thus every private and public key descending from it). This means that extended public keys must be treated more carefully than regular public keys. It is also the reason for the existence of hardened keys, and why they are used for the account level in the tree. This way, a leak of account-specific (or below) private key never risks compromising the master or other accounts.

This isn't compatible with the question's requirement "can publish its master public key".
3  Bitcoin / Development & Technical Discussion / Re: Why Bitcoin Core doesn't tell you to encrypt your wallet by default? on: July 31, 2015, 05:34:17 PM
I would add the question, why does the encryption not encrypt the whole wallet? The way it is now says "It is ok for everyone to see all the transactions and addresses, but he is not allowed to send." Why is that? Every bank account encrypts all. And you dont let someone look into your fiat wallet normally too.

So why is it ok with bitcoin wallets.

A side effect would be that you don't have to enter the password each time you want to send a transaction. Though a timer should be implemented in case you let the wallet open and leave the computer.

This would be a massive pratical loss of security for most users.

With the current configuration, entry of the password is authorization to send funds. You can't send funds accidentally. No misclicks or fooling around, or someone telling you to press something over the internet can result in you sending funds without realizing it.  If someone grabs your computer out of your hands or uses it while you've stepped away they will not have access to your funds.

The keys (or their equivilents) are not kept in memory; so if your wallet is encrypted and your system compromised while you're aware of it, you can rescue things by copying off the wallet and NOT entering the key after the compromise. (I've spoken to two people who mentioned being rescued by this, in fact.)

You are not forced to enter the keys at every startup (further exposing them to key loggers or people seeing you typing them). And you are not discouraged from entering in a strong password because you must type it frequently.

Meanwhile, there are two costs:  One has basically no marginal cost:  someone who compromises your computer (or steals it-- if you're not using disk encryption--) can tell what addresses are yours; but they can already tell this from your debug.log, swap file, browser cache, and 1001 other small places that data about your activities on your computer are left around.

The second is that backups aren't private and probably should be encrypted or stored on an encrypted disk.  This could be addressed by seperately completely encrypting backups. ::shrugs::

The comparison to a back isn't really a good parallel. Any computer in the world can connect to your bank website.  Access to your wallet metadata is gated by physical possession of the wallet file, which one normally can't get without access to your computer or your backups and if someone has access to that you've already substantially lost your privacy.

4  Bitcoin / Development & Technical Discussion / Re: Why Bitcoin Core doesn't tell you to encrypt your wallet by default? on: July 31, 2015, 03:41:18 AM
Some additional thoughts/informations:
1) recovery phrase like the electrum does as greg mentioned (~bip39) in case you have lost your wallet (encrypted or unencrypted) requires a bip32 hd wallet: at the moment not supported by bitcoin core.
As an aside, BIP39 is a poor design which was explicitly disowned by one of its original authors. It should not be used as a reference for useful behavior.

If one decides to encrypt the wallet, all used private keys (`getnewaddress`, change addresses) where exposed plaintext over the wallet.dat file during the time between creation and encryption.
This is potentially misleading, as may sound to some like you're saying keys resulting from getnewaddress after encryption were also exposed but this isnt the case. Only keys from before the encryption were previously exposed, for the obvious reason.
5  Bitcoin / Development & Technical Discussion / Re: Why Bitcoin Core doesn't tell you to encrypt your wallet by default? on: July 29, 2015, 05:50:41 PM

The protection provided by an encrypted wallet is pretty thin: If a theif person has access to your computer they can add a key logger or the like and then the encryption will not protect you.

Many people forget their keys; especially when they set them before they have any coins at all-- and thus nothing to protect.

Though its hard to collect data, from what I've seen I believe that already passphrase loss events are much more common than wallet thefts prevented by (or preventable by) encryption. Further optimizing for key loss over theft doesn't seem wise to me.

There is, in fact, an argument that as a whole wallet encryption is an anti-feature: that it causes much more loss than it prevents.  The destinction is that loss from forgetting keys (though it's well established that this happens constantly with users) leaves the user feeling like it's their fault and that they were in control; while wallet theft leaves most users (who've not yet really taken responsibility for their system security) feeling like the software is at fault; and so it's socially useful because it leaves people worrying about something they feel like they can control.   I don't know that I buy the argument, ultimately as software authors we're responsible to provide software the best looks out for the users interest. In this case there is a real tradeoff and no magic answer.

Electrum makes the user write down a randomly generated recovery code and re-enter it; and it does a fair amount of work in the UI to prevent the user from just copy/pasting it. It's a good approach, though it's hard to tell how effective it is because one element of failure modes where the user feels they are at fault is that they tend to not report them.
6  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 29, 2015, 05:51:42 AM
Gavin says "Network usage should get cut in half as soon as we stop doing the simplest thing and re-broadcasting transactions twice."

He means using IBLT, and IBLT is so powerful that it can squeeze a 100MB new block announcement into 1MB, the size in use today. It is also less work overall than LN or SC. i.e. simplest.

It does need prototyping, testing and benchmarking, and the breakeven point is unknown. But like JR's node services payment channels, it is a Cinderella of software where the focus of attention is mostly elsewhere.
We have the block relay network protocol already. It avoids repetition of data for anyone who wants to use it (each already known transaction is replaced with a two byte reference. A 1MB block takes about 4000 bytes at relay time when all the transactions were well broadcast in advance.

Gavin's own comments was that IBLT probably doesn't not make sense with blocks under "hundreds of megabytes":
09:49 < gavinandresen> morcos: e.g. the IBLT work really doesn’t make any sense until blocks are in the hundreds of megabytes size range.
Given my expirence with an attempted implementation of the earlier block network coding proposal, I wouldn't be shocked to find there was no size at which using set reconciliation over the whole block was a win for normal connectivity and normal CPU speeds (as opposed to things like sattelite connectivity) though we won't know for sure until its implemented.  

Regardless, the data still has to be sent a first time-- which is why in terms of overall capacity (rather than latency) the greatest improvement available from fancier relay is a doubling of capacity from eliminating double transmission-- and this is the case with both IBLT and the relay network protocol. The relay network protocol reduces some bad incentives in mining (e.g. mining without validating or mining empty blocks for faster relay) but it not a silver bullet, nor is IBLT. (Though it does have the advantage of being simple, already existing, avoids some bad incentives against including censored transactions, and likely being much faster than IBLT for current block sizes: Already the relay network protocol is CPU bottlenecked with much of its delay just computing the hashtree (even with a fancy AVX sha256 implementation in the client)).  (At least for large block reed solomon codes, it appears even highly optimized implementations cannot run faster than a few megabits per second on current CPUs... the fountain code like IBLTs should be somewhat faster, but it's unclear how much, especially when operating at near their recovery limit--- the IBLT also requires a CreateNewBlock in the reciever which is currently slower than the whole block-relay-network-process...)

Lightning network and sidechains are not magical things, they're orthorgonal and not alternatives to relay improvements. But since you bring them up: They're both at a _futher_ level of development than IBLT at the moment; though given the orthogonality it's irrelevant except to note how misdirected your argument is...
7  Bitcoin / Development & Technical Discussion / Re: Semi-soft-fork to decrease the risk of tx malleability on: July 29, 2015, 05:21:54 AM
we have BIP66 but there are still many forms of malleability to be fixed.
BIP66 is not about malleability, really; BIP62 is.
Is this the real reason for BIP66, which you couldn't mention in April?
(Disclosure: consensus bug indirectly solved by BIP66)
The explicitly stated goal right in the BIP62 document was a reduction in dependence on OpenSSL for consensus; which the truth and nearly the whole truth all that was missing was that the concern was less theoretical than presented.  But yes, the unstated privately known consensus vulnerability was a driving force for clearing up that ugly corner with BIP66 immediately rather than mopping it up as a side effect of BIP62. Especially due to fact that BIP62's progress has been slow-- and had grown over complicated. The fact that BIP66 accomplished one of the necessary steps will make BIP62 or its logical successor easier to move forward.

If you note from the timeline that BIP62 had already been revised to accomplish a BIP66 like goal prior to us knowing about that specific vulnerability:  We were aware of the risk class in principle before having specific knoweldge with enough concern that we thought it was worth closing off.  Knowing that it was _actually_ exposed had only an impact on timing and sequencing; and only after it was clear that BIP62 was not rapidly converging (unfortunately, in spite of much progress on BIP62 we continued to find problems with it).

It's sad, there is a vastly superior-- simpler, more comprehensive, and with secondary benefits like enabling more degrees between full and SPV-- malleability 'fix' in elements alpha but I don't have any way to get it into Bitcoin, BIP62 is disappointing by comparison (brillant ideas welcome).
8  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: July 28, 2015, 05:43:11 PM
i'd like to revisit that thought experiment i introduced last week.

an anonymous person hard forks the current Bitcoin code with the only change being a lifting of the limit.  he provably destroys the commit key (a Bitcoin private key) over at github thru a op_return spend.  the result being a Bitcoin source code with no core devs and thus no ability to change it going forward.  would that be enough to carry Bitcoin forward for the next century?
This message is technically incohearent-- there is no such thing as a a "commit key", and "op_return spend" doesn't destroy information if there were; achieving what you suggest simply requires people stop upgrading (which is also part of the reason that we do not use automatic 'push' upgrades)----  but I certantly get the _intent_. and it's one I've forelorely expressed multiple time myself, going back years:

That it would be philosophically ideal and achieve the highest security properites if the system were completely involatile, defined by it's own mechnical construction, and any change to it would simply be a different system which people could voluntarily move to by their own free choice. Through this the system would be immune to whilm, political control, or subterfuge in a much stronger sense.

Sadly, that result currently appears to be pratically be beyond the scope of human engineering abilities-- or at least beyond the efforts expended on any software system I'm aware of thus far.

A particular point that I couldn't disclose the time cypherdoc initially made the argument was that the software the network was running at that moment was vulnerable:

We've had a pipeline of newly discovered non-public vulnerabilties in the Bitcoin protocol running almost all the time since 2012.  I don't have a great answer to that hard questions, but sadly burying our heads in the sand cannot work-- it would just result in a regular series of potentially devistating "emergency" changes, rather than a orderly, planned, resolution.
9  Economy / Services / Re: [4 BTC] AntMiner firmware job on: July 25, 2015, 06:19:49 PM
CGMiner is GPLed software. Antminer was obligated to distribute the complete cooresponding source to their modifications under the same license. If they failed to do so then antminer would be in violation of the license.

I see nothing wrong with whats being requested here.
10  Bitcoin / Development & Technical Discussion / Re: Deleting abandoned UTXO on: July 23, 2015, 04:08:38 AM
This may be possible with UTXO set commitments of some kind.
This is the argument for TXO commitments.  But it's a storage vs bandwidth tradeoff, instead of storing a (say) 64 byte UTXO entry you need a 2.5KB proof when its spent. It takes some pretty tortued assumptions about storage vs bandwidth costs to make this win unless you assume a very low probablity of being spent and only use the proofs for accurately predicted low probablity of spend transactions.
11  Bitcoin / Development & Technical Discussion / Re: Deleting abandoned UTXO on: July 22, 2015, 06:34:09 PM
1. 0-value outputs are not spendable
This would greatly reduce the scope of functionality introducable in future soft-forks.  E.g. CT like private values could no longer deployed, soft-fork increases in coin precision, etc.
12  Other / Off-topic / Re: Increase currency divisibility with soft-fork on: July 21, 2015, 04:47:38 PM
aztecminer, I'm afraid you might be failing these excercises:
13  Bitcoin / Development & Technical Discussion / MOVED: - obmen bitcoin on: July 21, 2015, 08:42:32 AM
This topic has been moved to Бизнес.
14  Bitcoin / Development & Technical Discussion / Re: One-time signatures to prevent double spends on: July 21, 2015, 02:47:02 AM
Hi Tonych, it's always good to have more crypto posts here.

This is normally called a single show signature.

If you search the #bitcoin-wizards logs for that term you'll see some instances of this proposal-- you might find it informative.

As you'll probably see in the logs, I disagree with the claims of this approach preventing doublespends. The result of it, at best, is similar to RBF scorched earth, which many people don't consider to be an improvement.

I also disagree with the claim that it in any way addresses nothing-at-stake; in particular it's already common for schemes to suggest that duplicate signatures void coins (which can be done just by system rules without a single show signature) and yet those schemes also do not solve the nothing at stake problem: you cannot punish someone who has left the system and they can produce their conflicting signatures long after leaving it.

There are some pratical concerns as well.  For example, now ephemeral data k must be securely stored and if lost result in loss of the key.  Signing devices must be carefully stateful and avoid repeated signatures.  If the user pays inadequate fees, they'll have no mechenism to revise their transaction to update them-- as even a completely benign double spend (e.g. one that pays the same destination) would result in key loss.

Less importantly, miners also have free pass to ignore the effects of this scheme and there is a simple non-trustless but private protocol possible to allow someone to have a third party privately mine their transactions. (You put up a 25 BTC bond with the miner, and give them the transaction hash you want them to mine, with a promise that you'll instantly give them the full transaction if they present you with a winning block or else forefeit your bond).

especially those that already have stealth addresses.
Stealth addresses are linearly related, and the relation is known to the paying party. So if I use the stealth address method to create two one show public keys for you and you sign with both of them, I can derrive your private key. I am not aware of a mechenism to securely generate 'stealth address' pubkeys for single show signature without bilinear groups. If not for this a single round trip schnorr treshold signature would be possible.  [I hope this point makes it clear how tricky working with an intentionally fragile cryptosystem is, as someone could have followed the suggestion in the original post without realizing that they were giving away their private keys.]

15  Bitcoin / Development & Technical Discussion / Re: You can have wallet.dat anywhere and with any name, now! on: July 20, 2015, 09:12:16 PM
This is an inconsiderate bump of a very old thread.

Interesting and I gonna to try it out later today. This will make file management easier and it seems I won't need to manually change filenames by renaming anymore.   Wink

Bitcoin Core has had the ability to set the wallet file name with -wallet= for years. There is no need to rename files, and hasn't been a reason to do so for longer than your account here has existed.  You cannot change the path because if you split the BDB recovery logs and wallet file itself onto seperate media you will end up with irreparabile data corruption if there is an unclean power off with (un)reasonable probablity.

16  Bitcoin / Development & Technical Discussion / Re: Safe(r) Deterministic Tie Breaking on: July 16, 2015, 03:48:56 PM
50% is still much better than very low change you have on a late broadcast; I believe one of the revised selfish mining attack papers presented something similar to your suggestion (the original one was just busted).

I've thought before to use a similar rerandomization metric but include some sigmoid function of time so that the randomization is decreasingly likely to reorder the blocks the farther apart they are... but I was unable to find something that I felt I could analyize.

    Break ties in favour of the earliest header
No, the earliest received block. If the header's time were used there is trivial attack where you relay the header as fast as possible and withhold the block.
17  Bitcoin / Bitcoin Discussion / Re: The Golden Ratio Attack. Blocks more than half full lead to mining monopoly. on: July 16, 2015, 03:36:45 AM
On the facts the above desciption doesn't describe behavior in the network at the moment-- e.g. backlog isn't there, and substantial amounts of the funds that went into the DOS attack paid for outputs, not fees.

The scheme you describe is scale-free; I see you clarified in later messages that you think the "solution" is dyanmic controls rather than a removal of limit but the bold increase blocksize response in your initial is quite confusing-- more than half your text is spent spinning hyperbole, it would have been much more useful to spend that text on describing what you're actually talking about.

Perhaps most importantly, it does not make a case that the attacker produces increased income relative to his hashpower.  Consider:

Lets imagine your mine with half hashpower. Lets imagine that a block can contain 6000 transactions.  Attacker has 1/2 hashpower.  Offered load is 4000 tx/block.

Attacker crafts 2000/tx block at 1coin/tx fee level. Making the rest match him (plus episilon, which we'll disregard).

His average cost for spam is 1000 coin/block (2000 * 1-rate).
His average income is 2000 coin/block (4000 * rate).  (He doesn't get income from his spam, he saves its cost however; see prior line)
His net income is 1000 coins/block, on average.

Now consider the consolidation of other miners:
Their average cost for spam is 0.
Their average income is 3000 coin/block (6000 * (1-rate)).
Their net income is 3000 coin/block.

Both groups have 50% hashrate, so the non-attacking miner has a fee income of three times greater the attacking miner per unit hashrate!

Normalized for hashrate thats 2000 vs 6000.

Lets instead imagine that there is also a backlog of fees episilon beflow the attackers floor, and he mines those instead of his own and that doing this doesn't somehow eliminate the floor effect:

Attacker average cost for spam is 1000 coin/block (2000*1-rate)
Attacker income is 3000 coin/block (6000 * rate)
Attacker net income is slightly under 2000 coins/block, on average.

Honest miners cost for spam 0.
Honest miners income is 3000 coins/block (6000*(1-rate))
Their net income is 3000 coins/block.

Again doesn't work.

We can work this for any other size, say  and attacker with 40%:

Attacker cost for spam is 1200 coin/block (2000*(1-rate))
Attacker income is 1600 coin/block (4000*rate)
Attacker net income is 400 coin/block

Honest miners cost for spam is 0 coin/block
Honest miner income is 3600 coin/block (6000*(1-rate))
Honest miner net income is 3600 coin/block.

Normalized for rate, thats 1000 vs 6000.


Finally, we already know that the system is not incentive compatible when a single party (or collaborating conspiracy) has more than 1/3rd of the hashrate:   (The results below 1/3rd require information asymetry advantages which are handwavy, but at 1/3rd or beyond no such asymetry is required)-- though such attacks are highly conspicious.

At best, this attack allows a sizable minority group of miners to engage in price fixing without running out of money, under the constraint that legitimate transactions are still wiling to pay enough to fill half the block.
Exactly, like anyone they can generate transactions to drive up fees; large miner hashpower gets a discount on fees; but they still lose funds; and everyone else shares the income.
18  Bitcoin / Bitcoin Discussion / Re: BurtW arrested on: July 15, 2015, 10:32:05 AM
Great news!
19  Bitcoin / Bitcoin Discussion / Re: Gadget claims to steal encrypted keys from 19" distance. Time for Paper wallet ? on: July 14, 2015, 03:07:20 AM
After reading this, I had a scary thought: what if hardware wallet companies made this technology easy to obtain and use, allowing anyone to compromise wallets on devices such as laptops, and in turn forcing Bitcoiners to purchase a Trevor or something similar.
Small hardware wallets tend to be more vulnerable to this sort of thing as they have much less room for adequate shielding, less CPU cycles to run hardened algorithims, and run at slower speeds that make observations easier.
20  Bitcoin / Bitcoin Discussion / Re: Gadget claims to steal encrypted keys from 19" distance. Time for Paper wallet ? on: July 13, 2015, 09:43:21 PM
Thanks for the clarification. But, it is not nice to argue that PaperWallets are unsafe just to back up electronic storage. PaperWallets are not supposed to be generated online and offline generations are quite safe. If someone dowaloads source code from Github and generates PapaerWallet in an offline (which I assume is not in the vicinity of this new gadget), then what is wrong with it ?
Nothing about this attack involves online anything.  It involves radio emissions of a device while it is generating keys or signing.  Use of the "paper wallet" only dramatically increase your vulnerablity to this rather fringe attack over behavior normally-- because the sofrware used for paperwallets is (as far as I've seen) never even constant time much less reduced-emi...

It is all over for cryptos based on this technology.
All _zero_ of them?

My take is that you would have to be James Bond to pull it off.
Pretty much. There are cases where it may be relevant-- consider security procedures for commercial cold wallets, but not for most people.
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 ... 207 »
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!