Bitcoin Forum
October 20, 2018, 02:03:00 PM *
News: Make sure you are not using versions of Bitcoin Core other than 0.17.0 [Torrent], 0.16.3, 0.15.2, or 0.14.3. More info.
  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 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ... 239 »
961  Economy / Service Discussion / Re: How to improve your Bitcoin accessibility. on: April 05, 2015, 10:13:29 AM
APIs like that can feed you completely bogus data, at their whim, like payments that never really happened, causing you to give away goods.  Even if you log the results, you can't even prove to third parties that the API lied to you.

Services like that often use third party 'dos mitigation' services that they had their SSL keys over to (and, of course, the security provided by SSL is paper thin in practice).

Like many things, these things are perfectly secure if you have nothing to lose... otherwise? not so much.

Bitcoin was design to eliminate the need for this kind of trust; too bad that so many have rusted to rebuild it in Bitcoin, rather than contributing to make the trustless infrastructure better meet people's needs.
962  Bitcoin / Development & Technical Discussion / Re: Is bitcoin-qt able to scale with large numbers of unconfirmed txIn? on: April 03, 2015, 09:57:48 PM
That's actually kind of awesome.  How do you set that kind of test up?  You feed a script of RPC commands to add tx?  
It's actually quiet easy right now.  Use the invalidateblock rpc to kill an old block. It will disconnect the blocks after it, one a time backing off the tip... and put the transactions in the mempool. (some set of the transactions will fall out because they're descended from disconnected coinbases, but most will be in there.)

Use reconsiderblock to fix your node...

This may get broken in 0.11 since Gavin has a PR to cap the mempool size during reorgs.
963  Bitcoin / Development & Technical Discussion / Re: Is bitcoin-qt able to scale with large numbers of unconfirmed txIn? on: April 03, 2015, 05:23:36 PM
I'm seeing some possibly unstable behavior when the unconfirmed tx pool gets very large.  Right now there are 4000 unconfirmed tx
Not that we're aware of, all the involved algorithms should be log() scaling. 4000 is not very large either. I've fairly recently tested with a good month's worth of blockchain in mempool at once. (Which does indeed cause some slowness, but its orders of magnitude more than you're talking about...)
964  Bitcoin / Development & Technical Discussion / Re: Interesting github forks? on: April 03, 2015, 05:18:35 PM
Something that I've wished for in Bitcoin core itself the last few days is an option to monitor the size ( in both transactions and kilobytes) of the memory pool of unconfirmed transactions.  I've been seeing it get up to 3000 or so and staying there for hours during the last few days, while some miners continue to turn in tiny 60k blocks that have a few dozen transactions at most.  

$ ~/bitcoin/src/bitcoin-cli  getmempoolinfo
    "size" : 320,
    "bytes" : 562732

or your friendly neighborhood debug console.

Since you weren't aware of the command, I'm guessing "seeing it" means bc.i-- take that with a huge heap of salt.
965  Bitcoin / Bitcoin Discussion / Re: Easy, Plug & Play Bitcoin Nodes (Bitcoin Core 0.10) on: April 02, 2015, 09:06:22 PM
RPI -- even rpi2 -- is really underpowered for supporting Bitcoin Core-- it's embarrassingly slow compared to other inexpensive ARM systems.  Just last week Gavin was arguing for unsupporting all 32-bit systems entirely; though I believe everyone else working on Bitcoin core disagrees, it's not great to be spinning up new systems which are at the very edge of whats supportable.  Not all arm cpus are equal, and you can easily have order of magnitude differences in speed with the same nominal MHz.

Many SD cards also have very low performance and write endurance. Esp with the low memory meaning the node cannot cache much, I would expect Bitcoin core will wear out the SD card somewhat quickly unless special optimizations are made to reduce the amount of write activity.

Because of the slowness of it, the vendor here ships with a "trusted" blockchain preloaded, instead of verified from the network. The result isn't easily verifiable, so your trusting that the source (or someone who has compromised their systems) isn't backdooring it in some way-- thats a risk even the developers of Bitcoin Core wouldn't ask you to take with the binaries they put out, Bitcoin core binaries get verified by a public reproducible build process.

It's great for people to run nodes; but you should run nodes in ways that don't introduce more single points of trust in the network;  adding more nodes that ultimately depend on trusting one person or another isn't much better than people just using the node that trusted party is running.
966  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 03:13:12 PM
I think that there must be evidence that these agents planted some or all the government's evidence that was used against Ulbricht." Given that it appears that defense made that argument under seal to the judge, and the judge rejected it, I'm guessing that there was no evidence of the sort.
That sounds like a question of fact, not of law. The judge may have erred in rejecting it.

In any case, I don't disagree with you; I was just presenting an alternative view (As you can see, I've defended your position in other posts.)-- I don't think the position I outlined is likely to go anywhere.
967  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 03:07:05 PM
Correction to my post.  It turns out that it wasn't the case that MTGox did nothing to piss off Force and Bridges; it seems MTGox earned their ire by failing to respond to a shakedown request: (ah, Magicaltux's email screenshots are inlined in the post above).

(Force asks for 250 BTC as part of a 'partnership', Magicaltux doesn't respond, he sends more emails... later the send an "I told you so" email; the same day they filed for the warrant to seize MTGox's funds)
968  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 06:25:50 AM
Oh yeah?  Haven't you ever heard about 'fruit from the poisoned tree'?  Force4 was the lead investigator.  Every bit of evidence is derived from his original efforts.  There is no evidence which does not come from the work product of a criminal whose efforts were per se adverse to Ross' position.  

How do you like them apples Legal Beagle?
Blackbird0's position is that there were multiple investigations. It's possible (I don't know the case well enough to know) that the other investigation was separate enough that that argument doesn't hold weight. You can see my prior post for another argument that depends less on that, but at this point in time it's not entirely good what good it will do. While the argument I gave might have sewn doubt for a jury, the jury didn't hear it and unless they're able to argue that this mess is of the right shape they won't get  a chance to try that argument in a trial court.
969  Bitcoin / Bitcoin Discussion / Re: DEA Agents in Silk Road Case Face Fraud Charges on: March 31, 2015, 06:06:22 AM
I don't think the agents made up "claims" or "crimes" that Ulbricht was supposed to have committed. But rather they committed crimes themselves, by stealing some BTC. I don't think anything that they did demonstrates that Ulbricht did not do what he was convicted of doing.

They did much more than steal some bitcoins according to the indictment. The investigators, in an effort to conceal their criminality and in bad faith did systematically conceal and destroy material evidence collected during their investigation. The investigators had administrator access to the Silk Road systems which they used to rob the silk road service and then framed the original owner of their admin account for the theft (and then, with another account, offered to conduct a "hit" against that admin to extract more money from DPR) in one of many (successful) extortion attempts they carried out over months-- spanning back long before the government had any idea who DPR might be (e.g. in April 2013 they believed it was "A.A."). Their unlawful actions were not limited to SR, e.g. Force ripped off a random user of the CoinMKT exchange to the tune of a quarter million dollars where he was moonlighting (against policy and in a conflict of interest) as their compliance officer. When Force's improper use of an administrative subpoena (to attempt to unblock his rightfully suspicious-flagged account) was reported to his  superior by Venmo (a payment processor subsidiary of Paypal) he responded by attempting to seize Venmo's accounts.

Lets put aside for a moment Force and Bridge's roles as law enforcement and read their indictment as though they were just private individuals. Considering their access, strongly established involvement (e.g. the money trail connecting _them_ to SR appears to be much stronger than the money trail connecting Ross to SR), established pattern of fraudulent and vindictive activities including framing C.G. for the theft of bitcoin; they'd make a nice direction to throw doubt at the prosecutions claims and support of Ross'  "it was someone else" argument.

Consider the counterfactual with the character portrait painted in their indictment in mind: If Force and/or Bridges had had the opportunity to take over the operation of SR (from which they could rip people off on a greater scale), would they have done so? I think the picture painted by the indictment says yes. If they had and Ross pissed them off, would they have framed him? I think the indictment says yes (or even without pissing them off: They seized MTGox's US accounts immediately after successfully getting their own funds out (to the detriment of everyone now suffering from MTGox's insolvency)). I think this is a much more powerful line of argument than "maybe magicaltux did it", at least. They destroyed evidence related to their own interactions with magicaltux (and appeared to have made a successful unlawful forfeiture against MTGox as part of their criminal activities). In the story told in the indictment, these parties had the motive, the means, and opportunity that would have permitted them to frame Ross in order to conceal their own criminality (or to protect someone else who was paying them more); and the defense was apparently prohibited from presenting this in the trial.

No doubt the prosecution did their hardest to separate out  any potentially poisoned evidence, but these parties were the states only inside eyes inside silkroad. It seems unlikely to me that any of the later evidence was derived in isolation of their input, but regardless: it appears that they'd heavily spoiled the crime scene before any of the other investigators arrived.

What this actually means in terms of the actual law and procedures in the court, but I can't imagine that it would have had no effect on the jury unless they were prohibited from hearing it, nor can I really imagine them being prohibited from hearing it if it had been anything other than law enforcement agents (e.g. if it had just been other random criminals).  But they were. I can't imagine why the defense didn't delay the trial so that more of this information could be presented.

This information has certainly made a number of strange things I observed make more sense.

Edit: Ah, I see Ross' attorney has made a statement:   Seems that I called at least part of their approach, plus apparently the state used the existence of this other prosecution to suppress other evidence from being presented.  Hopefully Dratel will now move to have whatever relevant filings or orders were made regarding this unsealed, so we can get a more objective view of how much this prejudiced the case.
970  Bitcoin / Development & Technical Discussion / Re: trustless address lookup for thin-clients on: March 30, 2015, 04:17:38 PM
There is a recent study showing an attack that exploits the way bitcoin core handles addr messages and chooses peers.
That particular work is irrelevant here, Bitcoin core is intrinsically safe against the attacks this poster is describing. What SPV nodes do to different (and usually inherently less safe).
971  Alternate cryptocurrencies / Altcoin Discussion / Re: XMR vs DRK on: March 29, 2015, 06:45:16 PM
Cryptography has never been a significant part of cryptocurrency - even though it may share the first few letters. It works on a system of digital signatures.
It would seem that you actually do not understand what cryptography is in the modern sense.

A fundamental nature of information is that it wants to be freely copied everywhere to everyone. That any bit is equal and indistinguishable from any other bit of the same value and that any bit is eventually known to all who care.  Cryptography is all that technology by which we hope to confine and constrain the nature of information, to put up fences and direct it to our exclusive purposes, against all attacks and in defiance of the seemingly (and perhaps actually) impossible.  Digital signatures are cryptography by any modern definition and utilize the same tools and techniques (for example, a DSA signature is a linear equation encrypted with an additively homorphic encryption), and suffer from most of the same challenges as the message encryption systems to which you seem to be incorrectly defining cryptography as equivalent.  Moreover, the use of digital signatures isn't the only (or even most relevant) aspect of cryptography in cryptocurrencies-- e.g. the prevention of double spending of otherwise perfectly copyable and indistinguishable information in a decentralized system is a cryptographic problem which we address using cryptographic tools, and-- like all other practical cryptography-- achieve far less than perfect confidence in our solution. As are more modest ends like interacting with strangers but not being subject to resource exhaustion from them.

Far more so than other sub-fields of engineering, cryptographic systems are doing something which is fundamentally at odds with nature and share an incredible fragility and subtly as a result (and perhaps all are failures, we have no proof otherwise).

A failure to understand and respect these considerations has resulted in a lot of harmful garbage and dysfunctional software.
972  Bitcoin / Development & Technical Discussion / Re: Thinking about ways to make it more difficult to link IP address to txn creator. on: March 29, 2015, 04:15:34 PM
Actually, it seems the vulnerability has already been identified in 2013:
That isn't what Cryddit is describing at least not precisely, and of course that was fixed years ago. (The 97% thing is just because there are long forgotten nodes left running on old software that no one maintains; they likely don't have wallets.)

I don't believe Cryddit is correct; but his description isn't precise enough for me to tell for sure.  I /think/ what he's saying is that I first tell all nodes a dust output that nodes won't mempool and likely won't get mined, then later I give nodes a transaction spending that transaction with an invalid signature. To most nodes this second transaction will be an orphan (spends an input they don't know about).  But Cryddit believes the recipient of the transaction will DOS ban you.   I think this is incorrect: first, if the transaction was mempool rejected then it wouldn't end up in their wallet unless it gets mined (in which case it would be available in the utxo set to all nodes), secondly even if it was in their wallet the wallet is not consulted for lookups on incoming transactions.  But perhaps Cryddit would be kind enough to clarify his thinking?

There are ways we know those dust txn could be used to reduce users' privacy though... send them to nodes that don't implement a dust check and then observe them rebroadcasting them when they don't get mined for a long time. This is part of why the anti-dust rules were implemented.
973  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 03:09:00 AM
Which has nothing to do with the claimed lack of deniability.  
Are you having a bad day? Your message seems needlessly antagonistic. (Edit: Ah you edited your post. ... OKAY, yea, tone can be hard to convey.)

That particular flaw is only somewhat related to deniability, although it's not unrelated.  Please refer to the prior conversion, I remarked that the specification was largely designed as a brainwallet scheme as one of the general negatives against it. You claimed this was inaccurate, assuming a particular model of use which is intentionally not mandatory, I clarified.

Say there exist two Bitcoin Core wallets encrypted with the same passphrase.  Can anyone use their keys to prove that they are linked? _No_. Any existing wallet you have the private keys for can be encrypted with any passphrase. There is no linkage created by using a particular storage scheme. Even to whatever extent that someone way convinced you were the owner of both because they personally found you in possession of two wallet files and the key,that proof isn't transferable-- they could have fabricated that evidence themselves.

Now say there exist two BIP39 wallets sharing a mnemonic or sharing a password. Can anyone use their keys and the mnemonic data to prove that they are linked? Yes.  Because BIP39 generates a key using a one way function instead of encrypting a uniform value with (a requirement for working with short user generated strings), all usage of the same data will be linked. It may be surprising to people that using this facility (which, at best, only protects against fringe threats of the sort that one probably ought not worry about)  can leave them more exposed to other fringe threats.  It could be called 'denyable' relative to a single wallet for everything, but it's very much less denyable than two totally separate wallets, or two wallets encrypted with the same passphrase.  Likewise, its not possible to rotate your passphrase if you're concerned that it might have leaked... not without expiring all the keys (for which no facility really exists in the Bitcoin space if you've given any of those keys out).

The actual scheme here prevents the non-linkable usage even when used perfectly, because it's not possible to take a random unrelated private key and convert it into a mnemonic in this scheme; so the bad use by people actually does have an effect on everyone else. (Except by not using the 'deniability' feature at all and just keeping two totally separate wallets)

Stated another way; Absent the brainwallet anti-feature it's possible to have a scheme where a mnemonic exists and is easily computable for any combination of password and private key, and in such a scheme the existence of a mnemonic, password, and pair of keys does not automatically undeniably prove their linkage. You can't have that in a scheme which is designed to not need any persistent storage, however.  Probably not a big deal, but enough that I think its a bit sad and ironic to see people use something to gain the 'feature' of denyability when they would be better off not using it; the feature should probably be called "multiple wallets with less written down", which may well be interesting to people-- but probably an entirely non-overlapping set of people. Smiley
974  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 02:40:07 AM
The comparison to brainwallet is inaccurate.  Would you call bitcoin core's encrypted wallet a brainwallet?  Of course not unless you stretch the definition to the point of being silly.
You misunderstand. The lack of checksum enforcement on the mnemonic means that many people directly use the 'mnemonic' as a "brainwallet". The suggested uniform mnemonic encoding approach is completely non-normative. (This was an intentional design feature, and at one point a draft of the BIP basically advocated the usage; this was a quite controversial proposal, if you may note some of its former authors even had their names removed from it due to disputes about the construction; the state of the BIP was as far as the community was able to push the remaining authors away from that kind of dangerous construction; but its still possible to use it that way and many people do).
975  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 28, 2015, 12:10:42 AM
However, gmaxwell suggests that it is unreasonable to assume such ineffectiveness on the part of the ninjas and, once the secret master key is revealed, absurd for the suspect (after already admitting to owning the dummy wallet) to claim that the secret wallet is not his.
Just so.

I see nothing in the details which makes it weaker than a hypothetical KDF...
Nor do I.  The PBKDF2 looks technically sound to me (assuming the choice of a sound hash function) but then again I'm not a cryptographer.  I really don't know what gmaxwell was driving at with the "woefully weak KDF" comment.
The intensity of the PBKDF2 at 2048 iterations is almost completely ineffectual, it's likely not worth the code/implementation complexity.

For comparison, on my laptop bitcoin core chooses about 200,000 iterations for its wallet encryption (it dynamically picks a number that takes 100ms to decode)-- and it only uses one core (if we redo wallet encryption in a new format we'll be sure to fix that).

Part of it is because the application space of  BIP39 is unclear. If the keys are chosen securely then there is no gain from having a KDF (and no real harm in having a weak one, except for code complexity). If people use it like a brainwallet then given what we know about how users choose "random secrets" then the KDF is seriously inadequate; considering the infrequency of use and the huge attacker advantages (precomputation because brainwallet schemes cannot be effectively salted, and hardware advantages) you'd likely want something that takes several seconds on the best hardware the user has access to.

976  Bitcoin / Development & Technical Discussion / Re: Adding points on an Elliptic curve on: March 27, 2015, 10:41:59 AM
I see at least one error in your addition implementation (I can point it out if you really want, but I think if your goal is to learn, you will learn more if I don't; if your goal is to get something working I suggest rethinking your goal)..., What are you trying to accomplish?  If you want to make an implementation to actually use your approach (kludging together a result from semi-tech popular press books, rather than stepping back and understanding first principles) will be horrifyingly slow and likely end up broken or insecure.

If you're just trying to learn, you should probably step back and work on each component one at a time so you know exactly where your error is, and so you can gain some understanding. E.g. write tests for your field multiplies, field adds, write a test for your modular inverse (try lots of numbers, invert and multiply by itself to check the identity).  You don't necessarily have to have the answers to check against... check the algebraic identities.  e.g., for points:

A = G + G
B = A + G
C = B + G
D = C + G
B == D + -A
D == B + A
A == C + -A
A + C  == B + B
Infinity = C + -C.
A + D + -A == -D + D + D
... and so on.

Though it's perfectly possible to build a correct implementation with no known value vectors; if you really want them I would suggest I suggest installing (or getting web access to) sage (sagemath), as it has a fine implementation of elliptic curves on finite fields and can easily be used as a 'pocket calculator' to check your results: E.g.

sage: C = EllipticCurve ([F (0), F (7)])
sage: G = C.lift_x(0x79BE667EF9DCBBAC55A06295CE870B07029BFCDB2DCE28D959F2815B16F81798)
sage: G
( 55066263022277343669578718895168534326250603453777594175500187360389116729240 : 32670510020758816978083085130507043184471273380659243275938904335757337482424 : 1)
sage: G+G
( 89565891926547004231252920425935692360644145829622209833684329913297188986597 : 12158399299693830322967808612713398636155367887041628176798871954788371653930 : 1)
sage: G+G+G
(112711660439710606056748659173929673102114977341539408544630613555209775888121 : 25583027980570883691656905877401976406448868254816295069919888960541586679410 : 1)
sage: 8675309*G
( 66641067246008511739397675128206923493293851901978595085468284019495272794983 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)
sage: 8675309*G*0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72
(102906664656524967437285391368203362606397786797828404077808951036579554576623 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)
sage: 8675309*G*0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72^2
( 62036446572098911670458903520965529606848330631474128915637932959742841971720 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)
sage: 8675309*G*0x5363ad4cc05c30e0a5261c028812645a122e22ea20816678df02967c1b23bd72^3
( 66641067246008511739397675128206923493293851901978595085468284019495272794983 : 22882405661336615738255795181502754819791112635438119114432507482219105379189 : 1)

Though there are other high quality implementations of secp256k1 in C, ... since you seem comfortable using a C derived language, why not just use another implementation to get your test cases?
977  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs (im)plausible deniability on: March 27, 2015, 09:55:33 AM

You've got a "deniable" mnemonic written down, with a few bitcents in it.

The 'real' wallet is a word or two changed from what you've written down.

Ninjas bust in your doors and demand your keys. They find the mnemonic and aren't impressed by your cover-- they found your house due to your purchases at their dry cleaning cover operation and their records show you have hundreds of coins and transactions not reflected in the wallet they've found.

They torture you-- as ninjas are known to do-- but somehow you resist the lead pipe cryptanalysis.  Unfortunately for you, they also own a laptop computer with a fast gpu an in a fraction of a second they've found your other wallet just by searching a few billion nearby keys; alternatively they turn on your computer and find the missing word(s) in your swap file (most (if not all) BIP39 implementations have no ability to mlock their memory), or they find it loaded into some 'hardware wallet' and defeat the pitiful physical security with a flick of a jtag enabled throwing star.

Now they have your secret stash, you think: oh well, you're not worse off that if you hadn't used the deniability... But actually:

They tell you the penalty for the anti-ninja sources of funds they find in that wallet is death-- you plead "No, that wallet must be my _evil inlaws_, not mine!" but your claim isn't just implausible, it's absurd. The partial mnemonic is in your handwriting; weakly you protest "I'll tell the ninja overlord that you made me write it!" but there is no chance another randomly selected key maps to a mnemonic that anyone could possibly ever find, so the overlord will know both of those addresses started with the (same) mnemonic and couldn't have been produced the other way around. The first 'cover' one was well linked to your identity-- in your effort to make the cover more plausible you made the (undeniably) linked sibling more undeniable linked to you.

If instead the attempt at deniability were implemented as a difference between two keys and coded bijectively, using keyed permutations instead of hashing, such that for any pair of keys there was some set of words that encoded the difference between them; the story would still be sad (because the ninjas will likely run of of patience before you finish your cryptographic explanation) but perhaps less so-- they really could have picked any two random addresses, computed the linking words between them, and coerced you to write them down; perhaps your plea to the overlord would be heard. Smiley

Realistically, the deniability is operational security theater in any case. Virtually no users manage, nor does the software they use really support, operating with the kind of incredible fastidiousness required to sustain any level of real deniability against scrutiny stronger than a bored child. Preventing information leakage is insanely hard, far more so than most give it credit.  I shouldn't complain, stunts like this (and software that encourages it) results in many more coins being lost then they could possibly protect for theft. Everyone elses Bitcoins become more valuable as a result, ... hurray, I guess?   ::shrugs:: I protest a bit just because it's weird to see something called 'deniable' when its so undeniably linked to its sibling once you do know all of them.

Effectively BIP39 is a thinly veiled brainwallet scheme with a woefully weak KDF. It's prone to misuse, and when misused it picks up all the bad properties you might expect it to pick up.
978  Bitcoin / Development & Technical Discussion / Re: BIP39 mnemonics: checksum vs plausible deniability on: March 27, 2015, 07:01:04 AM
That deniability is less strong than you (and others) think.

Assume I do recover the full mnemonic (e.g. from sniffing if off your computer). Because the mapping is one way (it's not an efficiently computable bijection) I can trivially prove that all the private keys that I do happen to know of are all linked to (and derived from) the same mnemonic (fragment).
979  Bitcoin / Development & Technical Discussion / Re: Checklocktimeverify on: March 27, 2015, 06:56:43 AM
Just saw this, i think it's amazing. I'm wondering what it wasn't included in version 0.10.x?
Because it's not a finished proposal according to its author (and it was created too late for 0.10 in any case.)
980  Bitcoin / Development & Technical Discussion / Re: Will dynamic libraries of libconsensus and secp256k1 be distributed ? on: March 25, 2015, 08:36:43 PM
IIRC, only a very small portion of the consensus code is actually in the library right now. Quite a bit of work remains to be done to make it robust enough to deploy elsewhere.
Right and the API may well change, etc.   The current progress is just the first step.
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 76 77 78 79 80 81 82 83 84 85 86 87 88 89 90 91 92 93 94 95 96 97 98 99 ... 239 »
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!