Bitcoin Forum
July 24, 2016, 02:40:18 PM *
News: Latest stable version of Bitcoin Core: 0.12.1 [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 ... 227 »
481  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 28, 2015, 06:00:31 AM
There may be bug (or luck to find some number) and then creating bitcoins out of nothing. And nobody can verify.
That is the risk - the scheme relies on the security of ECDSA to protect the currency supply.
We're already relying on ECDSA to protect our balances from overt theft, so I'm not sure how much it actually changes the security model to also rely on it to protect our balances from covert theft via counterfeiting.
The reason I'm interested in amount blinding is that my current project is working out a multi-step plan to kill graph analysis. With the right plan and without blinded amounts we can kill graph analysis, but with blinded amounts we can drive a stake through its heart to make sure it stays dead.
We are also using SHA-256 and RIPEMD-160 hashes to protect our balances. So even ECDSA is broken our balances can be safe and then ECDSA replaced.
Pray tell how you will replace ECDSA when the coins are already assigned to keys for it?  (and when everyone and their sister constantly reuses addresses). A compromise of CT would mean that it was feasible to find discrete logs in this group, with that, anyone who learned your public key could recover your private key.  There are scenarios where the hashing, absent any address reuse, helps  (e.g. say the discrete log finding takes weeks)-- but it's important to not exaggerate the gains.

But indeed it isn't the ~quite~ same.

It's perfectly possible to construct schemes for private values which are unconditionally sound; meaning that there is no cryptographic assumption behind their inflation resistance, and a cryptographic break would only result in a loss of privacy.  I had previously thought that it was necessarily the case that any such scheme would have to be less efficient; but I have since realized my original reasoning for that was incorrect; though I do not (yet) know of a way to construct an unconditionally sound scheme which is anywhere near as efficient as CT;  but finding one is on my TODO list (though it falls below other improvements for CT privacy and network security that I'm working on).


482  Alternate cryptocurrencies / Altcoin Discussion / Re: [XMR] Monero Speculation on: June 28, 2015, 05:07:07 AM
I agree - any means to increase fungibility is a win. But based on my understanding of coinswap, this protocol would be human-centric? I.e., I'd have to arrange with some sentient thing (be it another human or a centralized service) to make it happen?
No, not at all-- it's just the norm to think about and describe protocols in terms of "people" making moves in a game.  All of this is automated and performed by computers.
483  Alternate cryptocurrencies / Altcoin Discussion / Re: [XMR] Monero Speculation on: June 28, 2015, 03:31:54 AM
(1) people who send BTC in the "ring signature sidechain" (RSSC), taint their BTC who are not entering the RSSC. If their identity is matched with the same identity as who put BTC in the RSSC, this person can become "flagged".
No, it's possible to trustlessly coinswap in and out of such a system, with no detectable connectivity.  And there are many reasons to use such a sidechain, such as improved smart contracting.  I consider improved fungiblity to be an essential basic feature.

Unfortunately, it's appears that it isn't possible to trustlessly swap in and out of monero because the developers of bytecoin didn't carry across smart contract functionality which they didn't understand.  Perhaps the capability could be added later.
484  Bitcoin / Pools / Re: [1500 TH] p2pool: Decentralized, DoS-resistant, Hop-Proof pool on: June 27, 2015, 03:25:04 AM
Getting similar blank spaces occasionally, before and sometimes after the new work for worker message.

Code:
2015-06-26 23:20:00.404942 P2Pool: 17643 shares in chain (17647 verified/17647 total) Peers: 11 (0 incoming)
2015-06-26 23:20:00.405063  Local: 3221GH/s in last 10.0 minutes Local dead on arrival: ~0.9% (0-3%) Expected time to share: 2.4 hours
2015-06-26 23:20:00.405120  Shares: 0 (0 orphan, 0 dead) Stale rate: ??? Efficiency: ??? Current payout: (0.0172)=0.0172 BTC
2015-06-26 23:20:00.405177  Pool: 2345TH/s Stale rate: 14.3% Expected time to block: 1.1 days
2015-06-26 23:20:00.593721
2015-06-26 23:20:01.071310 New work for worker! Difficulty: 895.466842 Share difficulty: 6639421.564846 Total block value: 25.095099 BTC including 636 transactions

my logs have those from before, even days ago;  though not multiples.
485  Bitcoin / Development & Technical Discussion / MOVED: Why I can't send btc from multibit to greenaddress? on: June 27, 2015, 12:27:05 AM
This topic has been moved to MultiBit.

https://bitcointalk.org/index.php?topic=1100686.0
486  Bitcoin / Development & Technical Discussion / MOVED: Memory on: June 25, 2015, 11:56:31 PM
This topic has been moved to Technical Support.

https://bitcointalk.org/index.php?topic=1100351.0
487  Bitcoin / Technical Support / Re: Memory on: June 25, 2015, 11:56:15 PM
No offense intended, but you really need to read http://catb.org/~esr/faqs/smart-questions.html   as, for all the time you spend photoshopping the cute image you question doesn't offer a single one of the essential details needed to begin a useful answer.  Asking technical support questions is skill which you can improve and which is critically useful.

In particular--

1. What version are you running? Where did you get it from? Old versions have known memory usage issues which have been fixed, spending further time on this is pointless if you're running an old version. Likewise some parties distribute patched versions with different behavior.
2. What operating system are you on and what version?
3. How are you measuring memory usage?  People often confuse virt and actual used memory. Virt includes memmaped files.
4. Is your system exposed to the internet (e.g. could someone be DOS attacking it.)
5. What patches or settings are you running the software with and are you using the node for anything or just leaving it running?

FWIW, as an example my mining node which has been running a self-compiled copy of 0.10.2 continually since a day before 0.10.2's release on 64bit lLnux and standard dbcache seeings has a current resident size of 701MB.
488  Bitcoin / Bitcoin Discussion / Re: Gregory Maxwell threatens to sell his bitcoins and find other things to work on on: June 25, 2015, 01:53:00 AM
Egads, what a boggling thread. (I will not be sending a christmas card to the mean person that sent me this link! Smiley ).

Go read the context.  Someone was asking me why I'm not doing the some PR blitz to influence people's thinking.  My response was that I don't care to win people over, that if Bitcoin's survival depends on constantly making rescuing it with a political sales pitch and a mass market PR campaign then I think that would mean that its already a failure.  I don't actually believe it is a failure but I'm not frightened of it becoming one, though I'd think it would be a bit sad to have wasted many years chasing a windmill and for the world to lose this opportunity;  but that said, I can just leave if it goes the highly centralized route, and go work on something that still has a prospect of success-- there are just too many important things that need to be done.  I don't think there is anything "threatening" or anything about that.

I care a lot about defending, protecting, and nurturing the system, but not so much that I feel compelled to go around trying to reprogram people to get my way.  To even admit that doing so would be possible is an admission that the system cannot work.   So I'm happy to continue to just communicate frankly in the forums and means that I normally communicate in and see how the experiment pans out. Smiley
489  Bitcoin / Development & Technical Discussion / Re: [Crypto] Compact Confidential Transactions for Bitcoin on: June 24, 2015, 12:18:54 AM
Unfortunately, Andrew Poelstra was able to break the cryptosystem for this scheme's range-proofs.  The author is working on fixing it, and I'm hopeful for progress there. This may take a bit of time, so if you're looking for something to test right now the CT feature in the Elements/Alpha is the best that is out there  at the moment.
490  Bitcoin / Development & Technical Discussion / Re: Bitcoin Research Report, Part 1 on: June 19, 2015, 12:55:31 AM
Hi j0kie_smurf,

I welcome your enthusiasm and interest!  You probably want to do some more research on cryptosystems: The output from SHA256 really is 256 bits long. There is no primitive 256 bit type in C/C++ existing hardware, so this 256 bit function is returned using smaller types (e.g. 8 32-bit words).

SHA256 is not an encryption function, but a cryptographic hash (though its possible to build encryption using cryptographic hashes).  There is no encryption in the Bitcoin protocol (the only encryption used in the system is in the wallet).  The cryptographic constructs we use are openly developed, distributed, and widely reviewed. There would be no benefit in keeping their implementations secret, as a principle of modern cryptosystems is that they should be completely secure even when the attacker knows the process exactly (which is a good principle, because its often impossible to keep the attacker in the dark about the process in any case).

I'm not sure where you seeing the "only uses 20 bits" and such from, if you were able to show such a simplistic divergence from random from sha256 it would be a remarkable discovery. I suspect you've just misread the code on that point.

In any case-- I wish you luck on your investigations and learning. Cheers,
491  Bitcoin / Development & Technical Discussion / Re: [Crypto] Compact Confidential Transactions for Bitcoin on: June 18, 2015, 12:30:07 AM
To be honest, I think the muted response speaks for itself. This stuff turns out to be less important than I thought. Someone will eventually re-implement the same things from the paper (maybe Blockstream or Monero guys?). Multiple independent implementations are a good way to do crypto, because then they can be compared and tested against each other.

Oh don't feel let down. It's highly technical and many people don't understand it.   I'm certainly super excited about it, but balancing a bunch of things right now so I haven't had time to give more feedback than I have so far (thanks for so swiftly integrating that!).

When I first explained the concept behind coinjoin it went nowhere, I had to do substantial work to write a plain explanation and simplify it all down, before people paid any attention at all.   When there is an implementation and such you'll see more interest as well.

For whatever it's worth I consider your work important. Between the soundness and efficiency improvements I went from thinking the probability of deployment of CT in bitcoin proper (rather than just in sidechains) was low but non-zero to-- with your scheme-- a view that its even likely eventually. (assuming Bitcoin doesn't get usurped down a privacy unfriendly angle).
492  Alternate cryptocurrencies / Altcoin Discussion / Re: Anonymity in the Mini-Blockchain scheme on: June 17, 2015, 10:34:15 PM
@Maxwell: I was hoping to see a modified version of mini- blockchain scheme amongst your sidechains candidates or to say elements. Did you consider it at all?
And if you didn't, why? Is it because the mini-blockchain is not a secure ledger cryptographically? Or because it is not feasible to attach such a mini-sidechain to bitcoin?
I don't think it's all that interesting: It requires that you trust the miners implicitly for the history, and if you're willing to do that you can use SPV which is much more efficient. And, I say this as the person who originally proposed state commitments in 2011: https://bitcointalk.org/index.php?topic=21995.0

If, for whatever reason, one really is interested in an in-between mode: a side effect of elements alpha witness segregation is that you can sync the chain while skipping 2/3 (to 95% with CT) of the data, but still have perfect security for the utxo set.

The txout commitment schemes have a non-trivial cost for full nodes as the txout set becomes large, e.g. requiring on the order of 20 times the amount of I/O--  so a one time miner trusting init takes less bandwidth but then you have much higher IO and CPU ongoing; so it's not actually clear to me that they're a win; even ignoring the security trade-off... which is part of the reason that they haven't moved forward in the Bitcoin space.

Some of the other things in the miniblockchain stuff are just incorrect. Like it claims to not have transaction malleability; but it does due to the inherent DSA malleability. I don't recall other features you might have been looking for.
493  Bitcoin / Technical Support / Re: Bitcoin QT is extremely difficult to get working, prohibitive to Bitcoin users on: June 17, 2015, 09:05:51 PM
3-4 days to download the blockchain is not viable tho, we are losing a TON of potential nodes with such a sloppy client.
There is nothing sloppy here, the software is literally over a hundred times faster than it originally was, and much more reliable too-- in general. What it's doing is just fundamentally hard-- it is independently and autonomously verifying over 70 million transactions.  There are many recent improvements and more in the pipeline, and more that we know are possible but haven't started on yet... but nothing can magically make it fast and easy.  And these reasons, among others, are part of why almost all of the developers of Bitcoin Core are not in favor a >2000% increase in operating cost as a step function in the recent block size drama-- if you think it's bad now, try it with several times the load.
494  Bitcoin / Technical Support / Re: Bitcoin QT is extremely difficult to get working, prohibitive to Bitcoin users on: June 17, 2015, 08:59:04 PM
The problem here is that it seems that Core thinks that all of the nodes that it has connected are misbehaving. It calculated their banscore, and that is greater than the threshold set, so it automatically disconnects. It looks like it might not be connecting to any nodes because of this. Open help > debug window and tell us what you see next to "Number of connections" I think it is stuck at 28 weeks because that was the most recent block that the bootstrap.dat file had.
It's doing this because this persons state is corrupted and they have rejected the chain as invalid.  As far as its concerned these peers are just attacking it by feeding it invalid blocks.

Why precisely it rejected the chain is hard to say without a log of where the rejection happened, and even with those logs it can be hard to know why without more testing. This can be due to hardware errors, or due e.g. to antivirus software corrupting the database. (or bugs, but I am not aware of any that would cause chainstate corruption right now). The corruption can be resolved with a reindex, but without knowing why it happened it may just corrupt again before you even finish the reindex.

Unfortunately, Bitcoin is a fantastic hardware test. (The unfortunate part is that a surprisingly large amount of hardware is slightly flaky)
495  Bitcoin / Hardware / Re: HashFast announces specs for new ASIC: 400GH/s on: June 16, 2015, 05:40:24 AM
Yes you should vote for the plan, it matters.  If you go read the proposal you will see a listing of estimated recoveries they expect to get that total several million dollars on top of the cash they have on hand right now.  The company had a 3 million dollar insurance policy for example.  They are also in the process of suing Cypherdoc to recover 3000 BTC plus a few other things.  

I just found out about this and it blew me away.  When the crap hit the fan and hashfast refused to make good on their promises to early customers I'd down-rated cypherdoc-- after all, he traded on his reputation to convince others to buy and when it didn't go as he presented if his reputation didn't take a hit, what good is reputation as a signal?   Subsequently he convinced me that in spite of his paid shilling he was mostly just another victim of this mess and convinced me to remove the rating; the shilling was crappy, but everyone makes mistakes and his "losses" in hashfast surely were enough punishment.

Today I read that litigation and discovered that he actually received 3000 BTC for his shilling services plus other considerations (and even a refund on an order), and walked with it while so many of the rest of us got squat. What the ?!?! So much for just another victim!  I've gone and restored my negative rating, damn.
496  Bitcoin / Development & Technical Discussion / Re: Hash algorithm that cannot be implemented in ASIC ? on: June 15, 2015, 02:57:59 AM
I wonder if the network could somehow take psuedorandom data from the block chain and then use this to create a random hash algorithm. It's hard to imagine how this would be done without using a fixed set of algorithm patterns, though. Maybe each node could use the pseudorandom data as input into identical evolutionary algorithms that end up producing one acceptable hash algorithm. (Can a computer prove that a random algorithm is secure enough for PoW?)
The variable portion of the PoW algorithm doesn't have to be secure, one can sandwich the variable portion between a pair SHA-2 for strong cryptographic security. The anti-ASIC meat in between needs to be only sufficiently close-to-bijective and reasonably chaotic. No need to attempt a complete proof of that, just a decent test of in a subspace that there are no fixed-points.

https://en.wikipedia.org/wiki/Fixed-point_theorem

It's not as simple as that, e.g. I could grind the circuit generator to find 'random' hash algorithms which a heuristic solver of mine can answer much faster than naive execution.  There have been some altcoin POW proposals that failed pretty seriously to this.

It's also the case that whatever parameterization you create, someone can just create an ASIC specialized for it... if nothing else stripping excess IO pincount and other costs.  Keep in mind, CPUs are ASIC too, ones with incredibly complex, secret, patented designs-- which can be mass produced by their makers at a marginal price which is a tiny fraction of what they sell for... "Be careful what you ask for".

Quote
Basically, all i need is an operation that cannot be executed on an ASIC.
CPUs are asics. The specific thing you're asking for is deeply impossible. The best you could ask for is something where existing general hardware was not worse than specialized hardware, and that seems really likely to be impossible too, simply because by definition general hardware will have "fat". If nothing else it's perfectly fine for a miner to run at a error rate approaching 1% (sometimes more!) but you'd never design a CPU to operate under those conditions. Since mining, by definition seeks towards 0 profits, even small factors like 10x efficiency would easily make a general purpose part totally unusual-- but perhaps your question is not really related to mining. But then as I pointed out above, even if you were successful, the result might just be giving a free license to Intel and AMD, which probably wasn't what you wanted.

I can't say that it's impossible to do better than the work-function bitcoin has... but it's very easy to do substantially worse.
497  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 15, 2015, 12:35:55 AM
As a point of order; since this seems to be a common and oft-exploited set of misconceptions.

I think Gavin should de-hitch his wagon from Mike Hearn after hearing how Mike proposed centralized checkpointing. The blacklisting thing was his one free pass at a really horrible idea. Now it just looks like he doesn't get what Bitcoin is really about.
Or the proposals to add censorship to tor that _seriously_ pissed off the tor developers? Or the coin confiscation proposal? Or the near constant, first short recourse to centralized, authoritarian solutions-- at a level of consistency that it would be a comedy if it weren't so sad?

Quote
I can see why Gavin would utilize XT as an end-run around the political gridlock in core, and I also see that Mike Hearn has a unique perspective and background that is useful, but he should not be a core committer in my opinion. Gavin is the only person qualified to (provisionally) lead the project as far as I can see now, but I think "palling around with Mike Hearn" will be viewed with suspicion, especially if it's unnecessary. Why not just just add in the patch to Core and fork off if necessary?
Mike has never been a core committer-- he's only ever submitted a couple patches, in fact.  His work has been mostly on BitcoinJ, which is whats used by android wallet and multibit hd. He's certainly knowledgeable about the Bitcoin system, so I point this out only as a correction-in-fact not a judgement statement.

Gavin does not lead the Bitcoin Core project-- the project lead is Wladimir and has been for some time (and I mean this in actual documented agreed on roles, and not just in terms of activities), and Gavin has been largely inactive for the last year (I don't say this to complain-- he was very busy with troubled times at the Bitcoin foundation).


hey Greg, do you even understand the concept of "financial conflict"?  if 6 of the Fed Bd of Governors were to set up a for profit company that directly benefitted from the institution of a particular new rule applied to US monetary policy, what would you say to that?
btw, Spinoffs is not my project; it's PeterR's.  i haven't commented in that thread for probably a year or so.
marcus and his character assassins like to argue that Bitcoin should be a "settlement currency".  
how can it ever be a settlement currency when it's use is currently confined to a small group of users?  let alone when the Blockstream plan is to shunt the vast majority of tx's to SC's or LN preventing our transition to mining paid for by tx fees?
it's a ludicrous economic plan that will cause Bitcoin itself to wither and die.  but when your business model depends on SC consulting fees it will be quite lucrative; in USD.

You have some comparison a bit backwards there, there are other people lobbing for a sudden rule change to the system-- against substantial controversy and out from under the preferences of a substantial minority (e.g. your poll shows a quarter in opposition) whos interest you might want to explore.

Two of the Five people with commit access to Bitcoin core (or a half dozen out of a hundred contributors) created Blockstream to build some important tech that we the space need (and had been lamenting it's non-existence for a long time before we went and found a way to fund doing it!). As the primary technical innovators in this space (certainly if you exclude altcoin work) we can be assured good consulting incomes so long as we keep doing good, important, quality work-- regardless of what happens with SC or LN... and we have a _long_ backlog of powerful technology that we couldn't release for use in Bitcoin without it just ending up in an altcoin before the prospect of sidechains.  But no matter what you protest, you cannot stop LN or SC from existing in some form or another; and they offer advantages Bitcoin by itself fundamentally cannot: e.g. LN can give _instantly_ irreversible payments-- think of all the applications that hold of on using Bitcoin for lack of that; but it's not possible in the plain Bitcoin system.  Look at CT-- we can't just go and try that in Bitcoin and figure out how to advance it, prior to SC there was no avenue to adapt to new needs without picking switching from Bitcoin to a competing currency. None of these things have anything to do with block size, and-- in fact, both SC and LN _strongly_ prefer the biggest blocksize the network can handle.  What they can't tolerate, however, is Bitcoin being very centralized-- and I don't think your own interests can tolerate that either (assuming you still own some Bitcoin).

I bring up spinoffs beyond it just being an honest question because it was your argument on these points-- why worry about what happens to bitcoin when we can create some altcoin that enriches the existing bitcoin holders.  I don't know how much this perspective influences your position here, arguably a spinnoff perspective would strongly prefer original bitcoin would fail, it it would just transfer ownership into a new network before people notice and buy up their coins on the cheap as the developers of counterparty did. ::shrugs:: It's easy to throw rocks about conflicts of interest. But the reality is that the arguments I've presented are straightforward, coherent, extend long before any plausibly argued conflict of interest, and are shared to some degree or another by almost everyone in the technical space, including ones which no amount of fevered imagination can construct a coherent conflict of interest story.

(And at least in my case you know who I am, what business I'm in, what my history is, heck I've even shared details of my employment contract with you---- this is not the same for most other people. But even with that opacity, it's easy to find "shadows" of conflict of interest, if someone wants take your approach of claiming any that can be claimed whenever it supports an argument)

Though back to your question, if you've given up on spinoffs as a salvation-- what do you think is going to make Bitcoin competative against the eventual altcoin that actually gets the formula right and makes significant, no compromise, technical advantages over Bitcoin--- and probably doesn't bother to cut you in on it?  Keep in mind, most of the people we hope will some day use Bitcoin haven't even been born yet.  Unless we fail and sully the potential for cryptocurrency in the public's mind, this is only the very beginning of a long history.

498  Economy / Speculation / Re: Gold collapsing. Bitcoin UP. on: June 15, 2015, 12:23:02 AM
lots and lots of big words.  never any justification for preventing Bitcoin from fulfilling it's original vision:
Your selective quoting ignores how this was a response to a 'how could this possibly work at all'.  I've used the same kind of response to "omg flooding network! how could that possibly work! it's completely non-scalable!" -- to point out that even non-scalable can achieve some remarkable stuff.  This doesn't answer any particular question about the exact tradeoff that works, but works to wake people up.  Particular because before Bitcoin the alternative was exclusively centralized systems so when you show that if you don't care about decentralization (which you must not if you question the value it provides compared to all that came before) then it can reach arbitrarily high scale.

We can't hope to guess at what anyone from back then would think about the current state of the world, though we do know that e.g. the current mining ecosystem would have been regarded as a system failure from the original precepts; and we also know that decentralization and autonomy were principle motivations for the creation of the system in the first place.

While I'm here, hows your Bitcoin Spinoffs project going, Cypherdoc?
499  Bitcoin / Development & Technical Discussion / Re: Bitcoin GPLed because of GMP? on: June 14, 2015, 05:43:52 PM
I'm trying to build that great secp25k1 library (https://github.com/bitcoin/secp256k1) but it needs USE_NUM_GMP defined, and it has to link to GNU Multiprecision Library which is GPLv2? What's going on here?
secp256k1 is self contained. GMP is optional. Releases of Bitcoin Core do not currently use GMP.

Libsecp256k1 is still unreleased experimental software. Our use of it in Bitcoin core is intentionally very narrow (only for signing, always checked against OpenSSL). I would not advise using it in a production consensus system currently. If you're interested in using it-- you could help support its maturation to full release by supporting review of the software.
500  Bitcoin / Development & Technical Discussion / Re: Confidential Transactions, Content privacy for Bitcoin transactions on: June 14, 2015, 01:15:34 AM
as far as I understand both sidechains and blocksize increase will need a hardfork.  There might be some grand compromise where both sides agree to let the other sides project in.  
Thats a complete misunderstanding, and I have no clue where you could have gotten it from-- can you specify so I can go hunt down that location and get them to fix it?  PM please-- this is offtopic for this thread.
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 ... 227 »
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!