Bitcoin Forum
June 19, 2024, 11:11:39 PM *
News: Latest Bitcoin Core release: 27.0 [Torrent]
 
  Home Help Search Login Register More  
  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 ... 156 »
1  Economy / Games and rounds / Re: CoinWallet.eu Stress Test Cancelled + Bitcoin Giveaway on: September 09, 2015, 02:57:14 PM
Why don't you spread the release of the keys out over a few weeks instead?
2  Bitcoin / BitcoinJ / Re: Should I trust Oracle? (Sun JDK -vs- Open JDK) on: August 05, 2015, 10:46:01 AM
The collections of identical keys are almost always due to hardware devices that generate a key on first boot, before they have any entropy. I doubt the JDK will ever be backdoored given the scrutiny it gets, but using Zulu or compiling OpenJDK yourself is not a bad mitigation if you're worried about it.
3  Bitcoin / Development & Technical Discussion / Re: Questions about Lighthouse Transactions on: April 22, 2015, 12:55:39 PM
The app itself lets you "revoke" a pledge i.e. double spending it back to yourself. That's pretty fundamental to the whole model and is why money doesn't get stuck if a project never makes it to the finishing line. It also keeps it low risk for the pledgor - if they suddenly need the money for some reason it's always available to them.

Without SIGHASH_ANYONECANPAY Lighthouse would still be possible, just with a much worse UX. Basically you'd have to inform the project owner of which output you wanted to use, and then once enough value was pledged, the owner would have to construct a transaction with everyones pledges in it and then pass it around for everyone to sign. It'd be a two step process - very ugly. With the malleability features it's "fire and forget", much easier.
4  Bitcoin / Development & Technical Discussion / Re: new paper: Securing Bitcoin wallets via threshold signatures on: March 10, 2015, 12:39:15 AM
The source is here:

https://github.com/citp/TwoFactorBtcWallet/

They've eliminated the trusted setup requirement.
5  Bitcoin / Wallet software / Re: Alternative clients in regtest mode on: February 18, 2015, 11:49:23 AM
Do those clients actually support regtest mode? BitcoinJ supports it because I implemented regtest mode for my own use, but I'm not sure if others ever really picked it up.
6  Bitcoin / Development & Technical Discussion / Re: Multi-language consensus library on: February 18, 2015, 11:47:36 AM
ScripterRon, rather than use JNI you could look at JNA. It will let you eliminate all the C code from your project and just call into the library with a regular Java interface. It's much more convenient.
7  Bitcoin / BitcoinJ / Re: Error in BitcoinJ? on: February 18, 2015, 11:46:09 AM
At the moment there isn't any way to fix this beyond telling the user to make sure their clock is correct. But you could just fetch the correct time from a trusted server, if this is really a frequent issue. E.g. just make an HTTPS request to google.com/gen_204 and then check the Date header.
8  Bitcoin / BitcoinJ / Re: Error in BitcoinJ? on: February 09, 2015, 01:18:50 PM
There is no error in bitcoinj. That field is meant to be in seconds, as a quick inspection of the usage sites would have shown you.

As you have discovered, your system clock is wrong and that's why blocks were being rejected. Bitcoin requires a correct system clock and always has.
9  Bitcoin / BitcoinJ / Re: What classes to use? on: January 18, 2015, 01:50:58 PM
Yep, that sounds right. You can inherit from AbstractWalletListener to avoid having to implement empty methods.

Unless you use an external index of the block chain, there is no way to know about transactions to an address without actually scanning through it.
10  Bitcoin / Wallet software / Re: TermWallet - Lightweight Command-Line Wallet using bitcoinj on: January 08, 2015, 03:09:37 PM
Cool! Tip sent Smiley

You might want to look at this project:

https://code.google.com/p/lanterna/

It could be used to create a pseudo-graphical updating list of transactions, like if you want to have your wallet running inside a screen rather than pure command line based.

If you made an installation procedure that didn't involve catting random shell scripts to a root shell, perhaps you could get it listed on bitcoin.org Smiley

11  Bitcoin / Development & Technical Discussion / Re: Bloom filter examples? on: January 02, 2015, 08:17:19 PM
You can look at the source of bitcoinj to see how it works, or read BIP 37.
12  Bitcoin / Development & Technical Discussion / Re: Thoughts on type safety and crypto RNGs on: December 27, 2014, 08:36:06 PM
(I thought it was really weird of Mike brought up manual memory management, I see I made an error in not correcting him.

Sigh. You know I have the deepest respect for you Gregory, but this is not the first time I get the feeling you're commenting on things I've written without having read them closely Sad

I said:

Quote
The main concern with Core is not that the code is insecure today, but what happens in the years to come

I know how the code is currently written. I first read it a few months after it was released, remember Wink But being concerned about an extremely common class of errors is hardly weird. Multiple people on this thread have brought it up.

My experience of working on several large C++ server codebases at Google is that it's quite possible to write robust code ... for a while. When you have a single thread, everything is written by one guy and all data is request scoped, the tools C++ provides can work very well.

But eventually one of the following happens:

1) Someone introduces multi-threading for better scalability, resource management, use of a blocking library etc, and accidentally writes code that races
2) Someone refactors code written by someone else and uninitialised data creeps in
3) Someone starts using a third party library that isn't written in the same way and requires manual heap management (like OpenSSL)
4) Someone profiles and decides to reduce the amount of copying that is going on

More generally: things change, teams change and software gets more complicated. Because nothing in C++ forbids manual memory management and some things require it, eventually it ends up being used. And some time after that, someone makes a mistake.

We can't magically convert Bitcoin Core to a safer language with a stricter type system. We can anticipate that mistakes will happen, and try to put in place systems to automatically catch and handle them.

Quote from: petertodd
You might be interested to find out that Python is actually moving towards static types; the language recently added support for specifying function argument types in the syntax. How the types are actually checked is undefined in the language itself - you can use third-party modules to impose your desired rules.

This sounds somewhat like the Checker framework. It is a pluggable type system for Java. I'd like to see it adapted for Scala and Kotlin too. It has a number of very practical type systems that catch practical errors like mixing up seconds and milliseconds and other unit mismatches.
13  Bitcoin / Wallet software / Re: iOS Bread Wallet on: December 22, 2014, 06:43:55 PM
Does iOS not detect gated wifi networks already? Android pops up a notification when it spots one of these.

If you vend requests that use the payment protocol and Breadwallet supports it, then you should be able to receive transactions via HTTP(S) directly instead of via the p2p network.
14  Bitcoin / Bitcoin Wallet for Android / Re: Is Bitcoin Wallet for Android Hierarchical Deterministic? on: December 22, 2014, 06:41:46 PM
You can just use the WalletTool program from the bitcoinj source code with a wallet file.

Andreas told me he wants to be careful about exposing the seed words because it can break in various edge cases e.g. if you have an old wallet that has pre-HD keys in it and then you think all you need are the post-HD seed words. So it will take some effort and testing to get it fully right.
15  Bitcoin / Development & Technical Discussion / Re: Thoughts on type safety and crypto RNGs on: December 22, 2014, 06:39:22 PM
I would say that we've got very lucky with respect to Bitcoin Core:  Satoshi was a very careful developer who knew C++ very well and maximised use of its features to increase safety. The developers who followed him are also very skilled, know C++ very well and know how to avoid the worst traps.

The main concern with Core is not that the code is insecure today, but what happens in the years to come. Will the people who follow Gavin, Pieter, Gregory etc be as good? What about alt coins? What if a refactoring or multi-threading of some performance bottleneck introduces a double free? Anyway, not much we can do about this except try and make the environment as safe as possible. I've made some suggestions on how to do this in the past (auto restart on crash, use Boehm GC) and normally Gregory likes to point out possible downsides Smiley but I'm not super comfortable relying on "don't make mistakes" as a policy over the long run.

WRT RNG issues in Java, I'm not aware of any beyond the Android bugs, which were very severe but didn't have anything to do with Java as a language or platform. If there have been issues in Java SE I don't recall hearing about them. Bypassing in-process RNGs is still a good idea though.

Quote
You should not do crypto in JS or Java in the first place. In those languages, you do not have control about memory management. For example in JS, you have no control over how and were the browser stores your secret data (keys etc.). There is no way to enforce the physical deletion of private data.

It's also true of C (e.g. AES keys can persist in XMM registers for a long time after use). Although hexafraction is right that on HotSpot you can do manual heap allocations, it doesn't matter much. If an attacker has complete access to your address space then this is so close to "game over" that it hardly makes any odds whether there are multiple copies in RAM. Even if the password isn't lying around, they can just wait until it is. I'm not a big fan of spending time trying to "clean" address spaces of passwords or keys.

Note that for core crypto, it's looking more and more like long term everything will have to be done in assembly anyway. Pain.
16  Bitcoin / Bitcoin Wallet for Android / Re: Is Bitcoin Wallet for Android Hierarchical Deterministic? on: December 11, 2014, 01:07:22 PM
Yes it is since v4.0.

I think Andreas will expose the seed words at some point. Not sure what the delay is.
17  Bitcoin / Development & Technical Discussion / Thoughts on type safety and crypto RNGs on: December 11, 2014, 01:06:39 PM
I wrote an article about some of the failures in wallet randomness we've seen in the past 12 months:

  https://medium.com/@octskyward/type-safety-and-rngs-40e3ec71ab3a

It's a 6 minute read, but the tl;dr summary is:

1) Find ways to make the type systems you are working with stronger, either through better tools or better languages

2) Try and get entropy as directly from the kernel as possible, bypassing userspace RNGs

I should practice what I preach - bitcoinj could be upgraded to use the Checker Framework for stricter type checking, and we currently only bypass the userspace RNG when Android is detected. I'll be looking at ways to make things stricter and more direct next year.
18  Other / MultiBit / Re: bitcoinj - running support node on: December 03, 2014, 12:35:46 PM
Yes by running a regular full node you are contributing resources that bitcoinj based wallets will use (along with other SPV wallets like BreadWallet)
19  Bitcoin / Development & Technical Discussion / Re: Mobile wallets with BIP70 extended public keys on: December 03, 2014, 12:34:28 PM
Yes for now the wallet has to specify outputs explicitly. BIP70 doesn't have any kind of generation support in it at the moment. Besides, they are supposed to expire after a while to let wallets forget keys.

WRT NFC - you can also use Bluetooth to transfer the payment request. Andreas Schildbach's wallet and derivatives support this.
20  Bitcoin / Bitcoin Wallet for Android / Re: Transaction fee 0.00001 BTC on: November 30, 2014, 02:23:51 PM
Yep. The new lower fee is accepted by most miners, it seems.
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 ... 156 »
Powered by MySQL Powered by PHP Powered by SMF 1.1.19 | SMF © 2006-2009, Simple Machines Valid XHTML 1.0! Valid CSS!