Bitcoin Forum
April 27, 2015, 10:32:23 AM *
News: Latest stable version of Bitcoin Core: 0.10.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 52 53 54 55 56 57 58 59 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 ... 197 »
481  Bitcoin / Development & Technical Discussion / Re: Is calendar time used in the Bitcoin network? on: September 22, 2014, 05:57:39 PM
Does that mean that if the Bitcoin protocol is changed so that all nodes check for double spending, then that would prevent a 51% attack?
Double spending is absolutely and completely precluded in a blockchain. Everyone always checks for double spending already, it's one of the rules.  I suspect you've missed this.

(I'd really recommend some quiet time trying to understand the system instead of so many posts.)
482  Bitcoin / Development & Technical Discussion / Re: BIP proposal: Automatic Wallet Backup scheme on: September 22, 2014, 04:19:13 PM
ASIC-8Tile - We are trying to get away from servers.
You misunderstand the sense in which I'm using 'server' there. In the sense I'm using it there is always a server (the counterparty to the client).
483  Alternate cryptocurrencies / Altcoin Discussion / Re: Monero Exploit Confirmed Independently on: September 22, 2014, 07:00:12 AM
Anonymint doesn't exactly come off well from his posts, but his ability to understand these things is probably unmatched.  He literally is probably the best person in the world to try to figure this kind of thing out.  G Maxwell would also top my list.
Anonymint spouts mostly a meaningless mishmash of technical terms; every once in a while a chance mixture may seem to make some sense technically, but I suspect the insight rests entirely in the reader in those cases. If you're listing both myself and he— your listmaker functionality may be in need of calibration.

I haven't stated that I've analyzed the system and believe it sound— it takes significant effort to stand behind such a claim, I haven't had the time, and this is also why I've not released any other software using it. (It's not that it's that hard, but it's a question of priorities. That its already in production, for better or worse, lowers it on my list: If it does turn out to be broken people are already screwed). The underlying RS scheme appears solid, but the exact application in Bytecoin has had less review.  But that I can't currently say I'm completely convinced it's solid doesn't at all prevent me from saying that claims otherwise so far presented sound suspect.
484  Bitcoin / Development & Technical Discussion / Re: Were mining pools originally considered on: September 22, 2014, 02:01:02 AM
and if they are in fact a desirable thing to have as part of the network.
Pooling for payment? The network doesn't care, thats a matter which only impacts the miners in question. But the common way that miners are implemented using "stratum" is actively harmful to the network and the security model of the Bitcoin system.
Curious here: What's harmful about stratum? Is it that miners have to trust the pool operator completely?
Not just that, though thats true too... it's only harmful to the miners themselves, it's foolish to mine with a centralized pool who could be stealing from you via skimming (or via 'hacking' incidents) but it only harms the miner who chooses to do it.

Stratum continues and cements a historical inertia of conflating pooling for payment (which encourages more small participants by reducing variance) with "selling your vote" on the valid state of the network, creating real centralization which is antithetical to the security model.

There is no technical reason why you can't form your blocks locally, according to your own preference and policy, but pay out the coinbase according to a pool's spec and get credited for that work.

This means that pools create a large centralization risk when there is no need for it to be so to get their benefit.  Indeed, it's arguable that miners can move so they're less of a risk than, say, cloud mining— but in practice miners do not move even when a pool is caught ripping people off (and certantly not quickly).
485  Alternate cryptocurrencies / Altcoin Discussion / Re: BCX and Monero - Setting The Record Straight on: September 20, 2014, 12:55:17 AM
Careful. Encryption could mean the one-time ring signature is not broken, rather the way it is implemented

Encryption does not mean signature, ring or otherwise. Two different concepts. There is very little encryption in the protocol, arguably none at all.

So I'm not even sure what the original quote means at all, other than a somewhat confused mishmash of "big words."

The only way I see to make sense of it is to interpret encryption as cryptography as fluffypony said and gmaxwell seems to have also inferred. But it could mean something else. When you invent your own definitions for words you can later say you meant just about anything.
I'm used to unsophicated people using "encryption" to mean cryptography. As you note there is no encryption in the protocol _at all_, (not just arguably, but unambiguously).  But no need to hang up on a pretty obvious claim over some pedantic word mincing— the meaning was clear enough to me.  If I misread— I'm sure BCX can comment.

A theft bug that cannot be fixed without breaking the system's privacy must be a cryptographic one. Thats a pretty strong claim which deserves some strong evidence. Other systems are using related cryptosystems, and would benefit greatly from knowing it was broken. BCX should publish his discovery.
486  Bitcoin / Development & Technical Discussion / MOVED: No block in 8 hours. on: September 19, 2014, 09:45:09 PM
This topic has been moved to Service Discussion.
487  Alternate cryptocurrencies / Altcoin Discussion / Re: BCX and Monero - Setting The Record Straight on: September 19, 2014, 06:43:28 PM
2) There is no break down in the encryption but in how it is implemented.
This is in direct contradiction to your original claim that it cannot be fixed without giving up on anonymity. I call bullshit.
488  Bitcoin / Development & Technical Discussion / Re: Using sipa's secp256k1 library to find a public key from a private key on: September 18, 2014, 11:03:00 PM
I think you want to use secp256k1_ecmult_gen() followed by secp256k1_ge_set_gej()
The XY returned by the second function is the public key.
Absolutely not. Those are not public functions.

secp256k1_ecdsa_pubkey_create(unsigned char *pubkey, int *pubkeylen, const unsigned char *seckey, int compressed)

Is correct... there is more information in the header that defines it.
489  Bitcoin / Development & Technical Discussion / Re: Were mining pools originally considered on: September 18, 2014, 03:34:15 AM
I am wondering if mining pools were originally thought about when Satoshi originally designed Bitcoin,

and if they are in fact a desirable thing to have as part of the network.
Pooling for payment? The network doesn't care, thats a matter which only impacts the miners in question. But the common way that miners are implemented using "stratum" is actively harmful to the network and the security model of the Bitcoin system.

mining pools are 'encouraged' because you can have a pool where no particular miner has the information to generate the block and collect the block reward themselves.
You have completely misunderstood the pooled mining process and how its security arises. No secrecy is required or would be in any way helpful. Pooling is secure because miners send failed lower difficulty attemps ('shares') that prove that they were attempting to mine blocks meeting particular criteria. This proves their work in an unforgable way and protects the pool from the miner. (But nothing protects the miners from the pool with centeralized pools, and pools have "lost" the miners funds many times in the past)

It's just an accident of history that hardware operators commonly completely give up control over their vote, blindly selling their computation to a third party... secure mining is perfectly possible while leaving the operators in control of their vote, just by agreeing to pay the earnings according to the pool's policy. (As is implemented in P2pool, but could also be equally accomplished for centeralized pooling systems too)

If with some other hashing mechanism it was enforced that the miners had all the information they needed to generate the block themselves, it would discourage pools because any pool member could 'steal' a block.
Incorrect. A block cannot be 'stolen' because it is immutable once authored. Every attempted block has an independant success probablity, and changing any part of the block results in a totally different block.

490  Bitcoin / Development & Technical Discussion / Re: Running a full node is starting to be a pain on: September 17, 2014, 07:10:47 PM
Yeah, I found that discussion a while ago, am a bit frustrated that nothing seems to be done about it.
Lots of things are being done about it, but they're not done yet. Wheres your contribution?
491  Bitcoin / Development & Technical Discussion / Re: Speed up the import of bootstrap.dat using mining hardware - is it possible? on: September 16, 2014, 06:44:52 PM
It seems that the complexity of the import algorithm is worse than linear with the number of transactions per block and/or the block chain size.
I have not looked at the code or read about the import process) does the import process involve many calculations of SHA-256?
Clearly you haven't: It's very nearly hlinear with the transactions.  There just were very few transactions in the past. There is a lot of sha256, but most of the import time is spent elsewhere. (ECDSA, writing out the database, etc.). There are some changes in the pipe that make it a fair bit faster.
492  Bitcoin / Technical Support / Re: How to run testnet and bitcoind on same server on: September 08, 2014, 01:42:59 AM
So if you are e.g. running sshd on the default port on the same IP address prepare to have serious CPU load from failed ssh login attempts.
Off-topic, I know, but a useful tip: Switch to ssh key auth only, the brute forcing tools detect that its hopeless and give up.
493  Bitcoin / Technical Support / Re: Im getting free BTCs mined to my wallet - WTF??? on: September 08, 2014, 12:34:49 AM
but who doesn't like free money, right? Of course you're going to pay attention to it.
It's not good news at all-- It's less than a half cent in value, you'll use about that much or more in marginal transaction fees just to include that input. The value to you is basically zero.  At the same time spending the dust will cause your wallet to interlink addresses, lowering your privacy.  Plus, on top of that, these transactions increase the size of the blockchain on disk and slow down the synchronization time-- making Bitcoin slightly less usable to everyone.

And all this to promote a ponzi scheme. Great.

If you're using bitcoin-qt you can use this to sweep away the dust in an efficient way that also helps gum up stupid 'taint' analysis by effectively coinjoining it off.
494  Bitcoin / Development & Technical Discussion / Re: [Want Feedback] Improved Stealth Address send/discovery method. on: September 07, 2014, 07:41:59 PM
What you're proposing there isn't new -- it's older than "stealth adresses", but it has many limitations which the current design was constructed to avoid.

The most important is the one you've noticed, but I think it's worse than you think it is:   It prevents any delegation of scanning because you cannot scan without putting one of you spending keys at risk.  This means that it's not ony incompatible with trezor and other hardware devices,  it's also incompatible with good wallet encryption which keeps your private keys out of memory when not in use.  Keeping spending keys offline is an important security practice, and it would be really terrible to have a design which prevented it.

It also prevents you from using a third party scanning service (at the cost of some privacy), meaning you can only use it if you download the whole blockchain yourself.

It creates an assumption that you have access to the private keys on the coins you're spending. In the case of a shared wallet, vault service, escrow, or coinjoin you do not (or only have some of them). If it relaxes which keys can be used for inputs, it would at least still support the coinjoins but require N fold more ECDH work for the scanner (as it much check each input).

It also makes the user pair mapping staionary. If I pay you some coins, and then later pay you some coins recieved to the same key... it'll use the same address, and thats bad for both our privacy. This also means that I cannot forget where I've sent funds without also forgetting my spending keys.

Then, related to the assumption of private key access, there is the issue that it it creates a bad coupling beyween the spender and the recivers pubkey types. If I start using some new kind of multisig script, or perhaps a hash based signature or something else to control my own funds, then suddenly there are all these addresses which I can no longer directly send to.

I'd originally thought it might be useful to _optionally_ support doing something like this, when the stars and moon align to make it possible... but the required bad security practices and huge slowdowns from having to do lots of extra ecdh to scan made it seem much less attractive. Plus there is a risk that the one side of the optional configuration doesn't exist and you get people unable to use different pubkey types, or people losing funds that were sent to them because their software won't notice the payments.
495  Bitcoin / Development & Technical Discussion / Re: Using OP_CAT on: September 07, 2014, 07:17:29 PM
You just have to have alice and bob prove that they know the discrete logs of their own pubkeys (e.g. they sign a message with it while setting up their exchange). Work through the algebra and you'll see why.

If you have logs for #bitcoin from last year, I walked through the somewhat different pay to contract case, which is I think mostly what you're referring to-- in that case you alwas make the contract key G*HMAC(message,pubkey) to avoid someone setting their pubkey to an alternative contract.
496  Bitcoin / Development & Technical Discussion / Re: Unique Ring Signatures using secp256k1 keys on: September 05, 2014, 09:15:44 PM
Could a ring signature set of several million people be created? Is there a limit to how many people mix together?
Only that it has linear scaling. Such a signature would be many megabytes in size and would take minutes to verify with state of the art ECC code.
497  Alternate cryptocurrencies / Altcoin Discussion / Re: New idea for security to sell - all malware obsolete on: September 05, 2014, 04:08:33 PM
People making extraordinary claims should provide extraordinary evidence.

Separately, No one has paid me for the great many ideas I contributed to Bitcoin and the cryptocurrency world— and most ideas, even good ones, are unworkable for boring engineering or user-factor reasons.
498  Bitcoin / Development & Technical Discussion / MOVED: Is it a bad idea to have a wallet with 10s of thousands of addresses? on: September 05, 2014, 04:05:42 PM
This topic has been moved to Technical Support.
499  Bitcoin / Development & Technical Discussion / Re: Using OP_CAT on: September 04, 2014, 10:19:28 PM
1a) implicit conversions between integers and bit strings with semantics depending on precise detail of OpenSSL implementation (word size, word order in a large integer, byte order in a word)
Not so. We proved there were no semantic leaks from OpenSSL in the numbers on the stack via exhaustive testing some time ago and removed all use of OpenSSL from the script code (except the calls out for signature verification, of course— so only signature verification and the accompanying signature serialization are handled by it).
1b) ostensibly allowing emulating iteration by mutual recursion of P2SH invocations
Also not so, very intentionally not.
500  Bitcoin / Development & Technical Discussion / Re: Peter Todd's OP_CHECKLOCKTIMEVERIFY on: September 04, 2014, 09:00:00 PM
We've already got good reason to expand the context to be at least the CTxOut's of previous transactions, and expanding it still further to include things like block hashes is a common request. If more such things were added I'd be inclined to formalize this notion of "Context" in the EvalScript() and so-on routines. Easy to see why you might not want to have to do that of course.
Including things which are not a function of the transaction changes the model pretty substantially though. There isn't too much that comes to mind as "would also break" but it seems like the sort of thing that may have subtle implications.

Well as we discussed before on -wizards, locktime usage with a timelock rather than a block height lock may create bad incentives for miners to skew timestamps anyway; might be a good idea to disable it entirely. Also, it's not the 2038 problem, it's later: nLockTime is unsigned.
Perhaps, but there really isn't a reason that the network couldn't soft fork in more strict time checking such that similar shenanigans would only really work if a supermajority of hashpower was in on it.  An argument against it is that people will use centeralized sources of time if you ask them for second level precision, but thats not fundamental.

I do somewhat wish the nlocktime time check were on the median of 11, which would make the funny business much less attractive— actually that could be a soft-forking change, since the median is strictly less than the block time.  Basically in that case lying about your time wouldn't help you specifically mine a transaction.
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 ... 197 »
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!