Re: [Bitcoin-development] Project status

2011-08-29 Thread Luke-Jr
On Monday, August 29, 2011 4:10:01 PM Gavin Andresen wrote: Other things on the 0.4 TODO list: Can we get some form of the signmessage method in? -- Special Offer -- Download ArcSight Logger for FREE! Finally, a

[Bitcoin-development] Bitcoin-qt ready for merging

2011-08-31 Thread John Smith
Hi, Bitcoin-qt is now feature complete (including wallet encryption), and has been tested for a while by various people without any major problems. It is now in status of feature freeze. The project builds on Windows, MacOSX and Linux using qmake. Impact to the core bitcoin functions is still

[Bitcoin-development] Version 0.4 release candidate 1

2011-09-02 Thread Gavin Andresen
Bitcoin version 0.4 release candidate 1 is ready for initial testing; please grab the source from github and try to break it. The big, visible change is wallet private key encryption, which is NOT turned on by default. The big, invisible change is a reworking of internal critical section mutexes

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

2011-09-02 Thread Rob Meijer
Given that there was not a single response to my post, I gather there is no to little interest in an updated MinorFs that could be used by bitcoin on systems that support AppArmor (Ubuntu and OpenSuse). Nevertheless I've put down the initial set of specs for a rewrite of MinorFs for if anyone

Re: [Bitcoin-development] BitCoin and MinorFs/AppArmor

2011-09-03 Thread John Smith
On Fri, Sep 2, 2011 at 8:32 PM, Rob Meijer capib...@xs4all.nl wrote: Given that there was not a single response to my post, I gather there is no to little interest in an updated MinorFs that could be used by bitcoin on systems that support AppArmor (Ubuntu and OpenSuse). Oh yes there is

Re: [Bitcoin-development] Version 0.4 release candidate 1

2011-09-03 Thread John Smith
On Fri, Sep 2, 2011 at 8:12 PM, Gavin Andresen gavinandre...@gmail.comwrote: Bitcoin version 0.4 release candidate 1 is ready for initial testing; please grab the source from github and try to break it. The big, visible change is wallet private key encryption, which is NOT turned on by

[Bitcoin-development] Last try: Fixes for 0.4

2011-09-03 Thread Luke-Jr
Once more before I just give up on trying... These branches fix bugs still remaining in 0.4rc1: - bugfix_getwork_newblk_race - getwork_dedupe - boost_fs3 - gitignore Additionally, this branch adds a tolerance to human error typing in base58 with ambiguous symbols, and should be very safe to

Re: [Bitcoin-development] 0.4rc1 known bugs

2011-09-03 Thread Matt Corallo
On Sat, 2011-09-03 at 20:13 -0400, Gavin Andresen wrote: Quick status update on 0.4; I probably won't have time to tackle these properly before Tuesday: + sipa found what looks like a deadlock between the addr-handling and IRC-join-handling code. + UukGoblin reports a deadlock problem on a

Re: [Bitcoin-development] 0.4rc1 known bugs]

2011-09-04 Thread Pieter Wuille
On Sat, Sep 03, 2011 at 08:13:14PM -0400, Gavin Andresen wrote: Quick status update on 0.4; I probably won't have time to tackle these properly before Tuesday: + sipa found what looks like a deadlock between the addr-handling and IRC-join-handling code. I've compiled bitcoind with Gavin's

[Bitcoin-development] Pull request for getmemorypool RPC call

2011-09-04 Thread Forrest Voight
(Moving here because forum thread at https://bitcointalk.org/index.php?topic=39088 didn't yield much discussion) Pull request: https://github.com/bitcoin/bitcoin/pull/476 Diff: https://github.com/bitcoin/bitcoin/pull/476/files This was originally a patch that returned bitcoin's memory pool as

Re: [Bitcoin-development] 0.4rc1 known bugs

2011-09-05 Thread Michael Grønager
Sorry, by bad - first clean checkout for quite a while (must have changed it earlier myself...). /M On 05/09/2011, at 14:42, Luke-Jr wrote: On Monday, September 05, 2011 3:25:47 AM Michael Grønager wrote: Findings - compile (I do not use the UPNP feature): in the makefile.unix I have to

Re: [Bitcoin-development] Building a node crawler to map network

2011-09-06 Thread Steve
While I'm asking questions I'll add one more regarding the getaddr message. Talking to myself here. I just sent this message then found this brilliant set of articles in the Dev Tech forum which answers the question very nicely: *https://bitcointalk.org/index.php?topic=41722.0

Re: [Bitcoin-development] 0.4rc1 known bugs

2011-09-06 Thread Pieter Wuille
On Sun, Sep 4, 2011 at 13:59, Pieter Wuille pieter.wui...@cs.kuleuven.be wrote: I've compiled bitcoind with Gavin's DEBUG_LOCKORDER, and fixed two potential reported deadlock issues (see https://github.com/sipa/bitcoin/commits/lockfixes). My mistake: these are not actual potential deadlocks,

Re: [Bitcoin-development] Building a node crawler to map network

2011-09-06 Thread Mike Hearn
Actually Steve, take a look at the bitcoinj mailing list today. Somebody has already built this and has it running. It's accumulating data at the moment, they'll announce it more widely soon. But I think there's no need to duplicate work.

Re: [Bitcoin-development] Building a node crawler to map network

2011-09-06 Thread Rick Wesson
I've got minna patches for nio based on bitcoinj. I've enumerated the network a few times and am working on a DNS seed service as well as some weather reports. Happy to start a branch when the committers are ready. -rick On Tue, Sep 6, 2011 at 12:42 AM, Steve shadders@gmail.com wrote: Hi

Re: [Bitcoin-development] 0.4rc1 known bugs

2011-09-06 Thread Luke-Jr
Got a fix for the encrypted-wallet mining issue: - unique_coinbase It depends on (and merges) the getwork_dedupe fix already common on pools and other miners who pay attention to the latest mining fixes. To merge: git fetch git://gitorious.org/~Luke-Jr/bitcoin/luke-jr-bitcoin.git \

Re: [Bitcoin-development] bitcoind multiplexing proxy - request/response routing problem

2011-09-08 Thread Steve
4a/ Serialize all request/response exchanges. i.e. request comes in from remote node, proxy aquires lock on the proxy-localdaemon channel and sends request. Channel remains locked until response is received or timeout (in which case remote node gets no response). Unlock channel after

Re: [Bitcoin-development] Alert System

2011-09-08 Thread David Perry
@Steve re Who knows, it might be the only way we'll ever hear from Satoshi again. That brings up a good point... Does anyone aside from Satoshi actually have the ability to send such an alert? Should we at the very least change the alert system to give such privileges to current devs and ensure

Re: [Bitcoin-development] Alert System

2011-09-08 Thread Luke-Jr
On Thursday, September 08, 2011 1:33:15 PM John Smith wrote: Be careful though, if you relay everything, it suddenly *does* have DDoS potential... Maybe require a proof-of-work then? -- Doing More with Less: The Next

Re: [Bitcoin-development] Alert System

2011-09-08 Thread theymos
The alert system will be very important if there are ever any critical problems in the network. For example, it is currently Bitcoin's only defense against an attacker with 50% of the computational power, where alerts would be used to tell people to stop accepting transactions. Displaying a

Re: [Bitcoin-development] Alert System

2011-09-08 Thread theymos
On Thursday, September 08, 2011 3:45 PM, Luke-Jr l...@dashjr.org wrote: I don't seem to recall this ever happening, despite Deepbit having over 50% multiple times now. An alert would have been issued if they had abused that position.

[Bitcoin-development] 0.3.23+patches bug: JSON-RPC leaves sockets around when not connected

2011-09-09 Thread Luke-Jr
On Eligius, I have two bitcoinds running on the same system: - a hub node, which is dedicated to relaying network activity between the hundreds of nodes Eligius peers with - a work node, which is dedicated to managing mining, and only ever connects to the hub node Lately, the hub node has

Re: [Bitcoin-development] Alert System

2011-09-09 Thread Christian Decker
Resending to mailing list as I replied directly... On Thu, Sep 8, 2011 at 11:03 PM, Christian Decker decker.christ...@gmail.com wrote: Will w...@phase.net wrote: In fact, I think the alert system should relay (note, NOT display) messages *regardless of the key used*, so it isn't yet

Re: [Bitcoin-development] Testing commits

2011-09-09 Thread Alex Waters
I expect that I will make a lot of mistakes, and probably ask too many questions - but I hope you can bear with me. I've been trying to keep a low profile as I get better acquainted with the project. I'm clearly in the company of some very smart people - and would like to keep it that way. I've

Re: [Bitcoin-development] Bitcoin-qt ready for merging

2011-09-11 Thread John Smith
Hello Alex, On Sun, Sep 11, 2011 at 12:20 AM, Alex Waters ampe...@gmail.com wrote: Can you please submit a pull request and testing plan? If these already exist, can you please link them here? What testing plan do you need? JS

Re: [Bitcoin-development] Bitcoin-qt ready for merging

2011-09-11 Thread John Smith
Alex, On Sun, Sep 11, 2011 at 7:45 AM, Alex Waters ampe...@gmail.com wrote: Hey John, It could be as simple as listing some things that you think could possibly break if qt is implemented. For example, check the UI for artifacts. I don't really know what could potentially need to be tested,

[Bitcoin-development] Difficulty adjustment / time issues

2011-09-13 Thread Gavin Andresen
Background: Timejacking: http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html And a recent related exploit launched against the low-difficulty alternative chains: https://bitcointalk.org/index.php?topic=43692.msg521772#msg521772 Seems to me there are two fundamental problems:

Re: [Bitcoin-development] Difficulty adjustment / time issues

2011-09-13 Thread John Smith
Fixing (2) is easier; incorporating a ntp library and/or simply removing the bitcoin mining code from the client but requiring pools and miners to have accurate-to-within-a-minute system clocks (or their blocks will be discouraged) seems reasonable to me. Incorporating NTP seems overkill.

Re: [Bitcoin-development] Project status

2011-09-13 Thread Luke-Jr
On Tuesday, September 13, 2011 10:43:27 AM Gavin Andresen wrote: 3) I'd really like to come to consensus on one or more 'multi-signature' standard transactions to enable much better wallet backup and security. More important in this area, IMO, is support for deterministic keychains in

Re: [Bitcoin-development] Difficulty adjustment / time issues

2011-09-13 Thread Luke-Jr
On Tuesday, September 13, 2011 11:06:37 AM Gavin Andresen wrote: Fixing (2) is easier; incorporating a ntp library and/or simply removing the bitcoin mining code from the client but requiring pools and miners to have accurate-to-within-a-minute system clocks (or their blocks will be

Re: [Bitcoin-development] Project status

2011-09-13 Thread Luke-Jr
On Tuesday, September 13, 2011 12:48:58 PM Douglas Huff wrote: On Sep 13, 2011 11:40 AM, Luke-Jr l...@dashjr.org wrote: Once created, they must submit the transaction to a staff member with the proper authority to bring it to the offline transaction-signing wallet (on a USB key), where it

Re: [Bitcoin-development] Project status

2011-09-13 Thread Douglas Huff
On Sep 13, 2011 11:40 AM, Luke-Jr l...@dashjr.org wrote: Once created, they must submit the transaction to a staff member with the proper authority to bring it to the offline transaction-signing wallet (on a USB key), where it is signed, and returned to this third wallet. I agreed up to this

Re: [Bitcoin-development] Request review: drop misbehaving peers

2011-09-15 Thread Stefan Thomas
A few thoughts: Should the DoS protection auto-disable if the node has less than a minimum number of connections? The idea being that if our node seems to be kicking /everybody /off the roster maybe there is something wrong with the protections. It would be nice if the node sent a message

Re: [Bitcoin-development] Request review: drop misbehaving peers

2011-09-15 Thread Gavin Andresen
I hate to get specific about potential attacks on a public mailing list, but I think the debate over what to do with non-standard transactions means we need to. I agree with Gregory; if there are NO rules about what transactions peers can send at you, then an attacker can trivially get around

Re: [Bitcoin-development] Request review: drop misbehaving peers

2011-09-15 Thread Mike Hearn
If I think you're trying to DoS me, why would I be nice to you? The issue is, what if I'm not trying to DoS you, but something went wrong? think response messages would just give an attacker another potential attack vector, and it is clear from the debug.log what triggers a ban. Only clear

Re: [Bitcoin-development] Request review: drop misbehaving peers

2011-09-16 Thread Joel Joonatan Kaartinen
Darn good question. If the protection fails, would it be better for it to 'fail hard', leaving people complaining bitcoin won't stay connected! Or fail soft, so you at least have a couple of connections. I think fail hard is better-- we'll immediately know about the problem, and can fix

[Bitcoin-development] 0.4.x stable branch

2011-09-18 Thread Luke-Jr
Gavin, Jeff, et al: A group of developers would be interested in maintaining 0.4 into the future as a stable branch (ie, bugfixes only). Would you be willing to plan on making the next mainline version after 0.4, being called 0.5, so we can release 0.4.1, 0.4.2, etc? If we prepare the git

Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS)

2011-09-18 Thread Alex Waters
http://www.python.org/dev/peps/ is a good reference if you're interested in seeing how PEPs work in action. I would be more than willing to maintain a similar index if that's what people want. Something to note is that Python does not use Git or GitHub (AFAIK). So we would need to update 001 to

Re: [Bitcoin-development] 0.4.x stable branch

2011-09-19 Thread Gavin Andresen
On Sun, Sep 18, 2011 at 7:30 PM, Luke-Jr l...@dashjr.org wrote: If we prepare the git repository + tags, would you guys be willing to make the actual release builds + source, and/or post such on the websites you administrate? Luke and various others in #bitcoin-stable My initial reaction is

Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS)

2011-09-19 Thread bgroff
http://www.python.org/dev/peps/ is a good reference if you're interested in seeing how PEPs work in action. I would be more than willing to maintain a similar index if that's what people want. Would the multi-signature proposal be a good test case for BEP-0002?

Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS)

2011-09-19 Thread Gavin Andresen
New 'standard' transaction forms would be perfect candidates for BEPS. I think we aught to have a formal proposal to separate the protocol version from the client version, too. -- Does anybody besides me think maybe we should name them something other than BEP ? I'm worried we'll regret it in

Re: [Bitcoin-development] Newly introduced DoS

2011-09-27 Thread Luke-Jr
What about this one? @@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock() // Get prev block index mapuint256, CBlockIndex*::iterator mi = mapBlockIndex.find(hashPrevBlock); if (mi == mapBlockIndex.end()) -return error(AcceptBlock() : prev block not found); +return

Re: [Bitcoin-development] Newly introduced DoS

2011-09-27 Thread Gavin Andresen
@@ -1276,13 +1278,13 @@ bool CBlock::AcceptBlock()     // Get prev block index     mapuint256, CBlockIndex*::iterator mi = mapBlockIndex.find(hashPrevBlock);     if (mi == mapBlockIndex.end()) -        return error(AcceptBlock() : prev block not found); +        return DoS(10,

Re: [Bitcoin-development] Deprecating midstate in getwork?

2011-09-27 Thread Jeff Garzik
On Mon, Sep 26, 2011 at 3:42 PM, Nils Schneider n...@nilsschneider.net wrote: I'd like to simplify the internal reference miner and remove all dependencies on cryptopp (it's the only place we use cryptopp instead of OpenSSL). Unfortunately, cryptopp is also used to calculate getwork midstate.

Re: [Bitcoin-development] Multisignature transations

2011-09-30 Thread Gavin Andresen
Does this mean dispute mediation (2-of-3) will not be supported? Not with this PULL-- I think wallet security and backup is a critical feature, so that is what this is for. I thought the plan was also to allow CHECKMULTISIG for smallish numbers of keys. groffer pointed out that might cause

Re: [Bitcoin-development] Multisignature transations

2011-09-30 Thread Gregory Maxwell
On Fri, Sep 30, 2011 at 1:21 PM, Gavin Andresen gavinandre...@gmail.com wrote: Accepting this does not preclude adding more 'standard' transaction types in the future. I think 2 of 3 is a _far_ more useful example than (a or b),  it is the prototype for a normal escrow transaction., and still

[Bitcoin-development] My thoughts on DoS code

2011-10-02 Thread Amir Taaki
Hey, The Zen of Python is relevant here: http://www.python.org/dev/peps/pep-0020/ In the face of ambiguity, refuse the temptation to guess. If a node incorrectly implements the standard then it should be shunned immediately. Not only is this more secure, but it will ensure long term

Re: [Bitcoin-development] Tests for Bitcoin QT

2011-10-04 Thread John Smith
Hello Brian, There are no unit tests for the Qt GUI code itself as of this moment. The tests for the bitcoin core are still there in src/tests ). You need to build them with the makefile, though. qmake is currently only used for the GUI executable. JS On Mon, Oct 3, 2011 at 11:04 PM, Brian

[Bitcoin-development] Transaction Delivery and Storage

2011-10-04 Thread Brian McQueen
I see the Contracts wiki page talking about, 1) Transactions passed around outside the P2P network ... 2) ... transaction ... not broadcast right away How are transactions created, stored and transmitted? How will they be brought back into the P2P network once they are out? B -- Make a Small

[Bitcoin-development] vtxPrev

2011-10-05 Thread Michael Grønager
Hi ! I am looking into enabling a split between thin clients holding the wallet and server(s) holding the blocks and txdb. To that end I am considering to simplify the WalletTx a bit and I came across the vtxPrev in the code. As I see it vtxPrev is only used for keeping a list of supporting

Re: [Bitcoin-development] Transaction Delivery and Storage

2011-10-05 Thread Mike Hearn
I imagine a lot of the things on the contracts page will be implemented by specialized software that interacts with the Bitcoin network directly. Transactions would then be moved around, for example, by having clients do HTTP POSTs of protocol buffers to servers that are listening and know how to

Re: [Bitcoin-development] Mac libboost_thread or thread-mt?

2011-10-05 Thread Douglas Huff
Bad update. Macports has a couple of boost packages. Install the newer 1.46 ones. -- Douglas Huff On Oct 5, 2011 1:43 PM, Gavin Andresen gavinandre...@gmail.com wrote: I updated src/makefile.osx and doc/build-osx.txt today, assuming that the MacPorts versions of dependencies will be used and

Re: [Bitcoin-development] Mac libboost_thread or thread-mt?

2011-10-06 Thread Brian McQueen
I added -mt and it compiles, but here is a surprise. I had to add libz.a to the makefile.osx. Sounds odd! Its coming from the crypto libs. On Wed, Oct 5, 2011 at 11:50 AM, Douglas Huff dh...@jrbobdobbs.org wrote: Bad update. Macports has a couple of boost packages. Install the newer 1.46

Re: [Bitcoin-development] Mac libboost_thread or thread-mt?

2011-10-06 Thread Eric Mockensturm
Brian, Yea, I vaguely remember going through all this when I first tried building it. If I recall you can statically link libz into crypto when you compile crypto. Or something like that. Maybe the default MacPorts crypto install does not do this. Eric -- Eric Mockensturm, Ph.D.

[Bitcoin-development] Help wanted: translations

2011-10-08 Thread Gavin Andresen
Reposting here from the forums: Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release Candidate 1 out, with a much-improved GUI. Bad news: all the translations for the old wxWidgets Bitcoin are obsolete, and the process for making translations is different. Is anybody willing to

Re: [Bitcoin-development] Help wanted: translations

2011-10-08 Thread Christian Decker
Damn, german is already contributed :-) Well I can still do the italian one and check german then. On Sat, Oct 8, 2011 at 11:13 PM, Gavin Andresen gavinandre...@gmail.comwrote: Reposting here from the forums: Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release Candidate 1 out,

Re: [Bitcoin-development] Help wanted: translations

2011-10-08 Thread Martinx - ジェームズ
Hi! I can translate it to Brazilian Portuguese. Best, Thiago On 8 October 2011 18:13, Gavin Andresen gavinandre...@gmail.com wrote: Reposting here from the forums: Good news: I'm just about to get a Bitcoin-Qt version 0.5 Release Candidate 1 out, with a much-improved GUI. Bad news: all

Re: [Bitcoin-development] Help wanted: translations

2011-10-08 Thread Luke-Jr
Please at least get Coinbaser merged for 0.5. It has had a lot of testing on Eligius for months, a landslide of support for the new JSON-RPC method (as requested), and I have even gone to the effort to document it. As I will no longer be using bitcoind for Eligius soon, I have little incentive

Re: [Bitcoin-development] Help wanted: translations

2011-10-10 Thread Luke-Jr
On Monday, October 10, 2011 5:22:28 AM Mike Hearn wrote: On Sun, Oct 9, 2011 at 1:12 AM, Luke-Jr l...@dashjr.org wrote: As I will no longer be using bitcoind for Eligius soon What will you be using instead? Isn't bitcoind a requirement for running a pool? Writing some custom software

Re: [Bitcoin-development] Help wanted: translations

2011-10-10 Thread Luke-Jr
On Monday, October 10, 2011 9:18:07 AM Mike Hearn wrote: As I will no longer be using bitcoind for Eligius soon What will you be using instead? Isn't bitcoind a requirement for running a pool? Writing some custom software designed to more efficiently create work. To

[Bitcoin-development] Please help test 0.5 release candidate 1

2011-10-10 Thread Gavin Andresen
Reposting from the forums: https://bitcointalk.org/index.php?topic=47586 I just tagged the git tree v0.5.0rc1. If you are able, please compile and help test. See the INSTALL file at the top of the source tree for instructions on compiling. Binary releases for at least unix and mac should be

Re: [Bitcoin-development] State of Bitcoin Development: October Brain Dump

2011-10-13 Thread Luke-Jr
On Thursday, October 13, 2011 9:32:48 AM Gavin Andresen wrote: • Tighten up block-time rules to fix the potential timejacking attack. Once again, this does not fix anything (they're already strict enough for the 2-week window), and just creates new problems. • Work on 'discouraging'

[Bitcoin-development] BIP process

2011-10-18 Thread Gavin Andresen
Amir started the get more formal about changes to bitcoin ball rolling by creating BIP 0001, starting from the Python PEP / BitTorrent BEP processes: https://en.bitcoin.it/w/index.php?title=BIP_0001 The idea is to use BIPs for changes that may or will affect every bitcoin implementation (not to

Re: [Bitcoin-development] BIP process

2011-10-19 Thread Alex Waters
• I propose that BIPs be wiki pages, with a social convention that the Author gets final word if any editing wars break out. ACK • If he's willing, I propose that Amir take the role of BIP editor. ACK • I think bitcoin is still too small to have a specialized bitcoin-ideas mailing

Re: [Bitcoin-development] BIP process

2011-10-20 Thread Christian Decker
On Thu, Oct 20, 2011 at 7:02 AM, Alex Waters ampe...@gmail.com wrote: • I propose that BIPs be wiki pages, with a social convention that the Author gets final word if any editing wars break out. ACK Does it have to be wiki pages if we're going through an editorial process anyway, and there

Re: [Bitcoin-development] Help wanted: translations

2011-10-22 Thread Nils Schneider
And is anybody willing to take the job of coordinating translation efforts, figuring out if Transifex is a good tool to use, and writing some documentation to make it easy for people to create and submit new translations? I have exported all .ts to transifex.

[Bitcoin-development] Determine input addresses of a transaction

2011-10-24 Thread Jan Vornberger
Hi there! As part of my green address endeavor, I'm currently trying to extend the 'gettransaction' call to include an extra field inputaddresses which should return a list of the Bitcoin addresses associated with the inputs of the transaction. I understand that this is not generally possible,

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-24 Thread Pieter Wuille
On Mon, Oct 24, 2011 at 10:29:57AM +0200, Jan Vornberger wrote: Hi there! As part of my green address endeavor, I'm currently trying to extend the 'gettransaction' call to include an extra field inputaddresses which should return a list of the Bitcoin addresses associated with the inputs of

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-24 Thread Gavin Andresen
So my first shot at this is to go through the inputs of a transaction and see if the scriptSig field has only two opcodes. If that is the case, I assume that it is of the structure sig pubKey and calculate the Bitcoin address from pubKey. But then I started to wonder if this is safe. Can this

Re: [Bitcoin-development] Fwd: bitcoin scope issue in main.cpp

2011-10-24 Thread John Smith
Yes, you're right, there is a lot of code is in the fun with knives category. JS On Mon, Oct 24, 2011 at 4:31 PM, Amir Taaki zgen...@yahoo.com wrote: Hahaha you mean like unitialised variables, inheriting from containers with non-virtual dtors (CScript) and delicious copy pasta coding

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-24 Thread Simon Barber
PKI would avoid the need for the trust aggregator to be consulted for each transaction. Obviously checking for revocation would be essential. The CA cert can state what kind of guarantee is available. Simon On 10/24/2011 09:25 AM, Mike Hearn wrote: You know, just thinking out loud...

Re: [Bitcoin-development] Help wanted: translations

2011-10-24 Thread John Smith
Those indeed seems weird... I'll take a look at it. JS On Mon, Oct 24, 2011 at 8:55 PM, Geir Harald Hansen opera...@bitminter.comwrote: Three quick examples of duplicated strings. There are many more. Some of the smaller ones may make sense to have duplicated several times in english as

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-25 Thread Jan Vornberger
Am Mo, 24.10.2011, 16:55, schrieb Gavin Andresen: So my first shot at this is to go through the inputs of a transaction and see if the scriptSig field has only two opcodes. If that is the case, I assume that it is of the structure sig pubKey and calculate the Bitcoin address from pubKey. But

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-25 Thread Joel Joonatan Kaartinen
On Tue, 2011-10-25 at 11:45 +0200, Jan Vornberger wrote: 1) Get something working reasonable fast to detect current green address style transactions. It's fine if it is a little bit of a hack, as long as it's safe, since I don't expect it to be merged with mainline anyway at this point. 2)

Re: [Bitcoin-development] Determine input addresses of a transaction

2011-10-25 Thread Mike Hearn
Interesting suggestion! So if I understand correctly, greensig would be the signature generated from signing the transaction with the key of a green address? Sure. Or just a key. It wouldn't have to be an actual key used in the block chain. Sounds good - I guess I never thought in this

[Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-25 Thread Mike Hearn
scriptPubKeys that use OP_EVAL contain a hash of a script. If I understand correctly, that means to detect a transaction in a block that is relevant to your wallet, that means you need to pre-calculate every possible hash that might appear. For the case of a single payment, that's not a problem.

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-25 Thread Gavin Andresen
On Tue, Oct 25, 2011 at 6:49 AM, Mike Hearn m...@plan99.net wrote: scriptPubKeys that use OP_EVAL contain a hash of a script. If I understand correctly, that means to detect a transaction in a block that is relevant to your wallet, that means you need to pre-calculate every possible hash that

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-25 Thread Gregory Maxwell
On Tue, Oct 25, 2011 at 9:21 AM, Gavin Andresen gavinandre...@gmail.com wrote: You give the hash to whoever is paying you, and store the hash -- script  mapping when you do that (assuming you're not using a deterministic wallet; if you are, you probably just increment a counter in the wallet).

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-26 Thread Michael Grønager
I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the addr to tx mapping: vectorpairopcodetype, vectorunsigned char vSolution; if

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-26 Thread Gregory Maxwell
On Wed, Oct 26, 2011 at 4:58 AM, Michael Grønager grona...@ceptacle.com wrote: I think it is a very important feature to be able to extract transaction to/from you only from your private keys. In the standard transactions this is easily accomplished - in the case you only want to find the

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-27 Thread Michael Grønager
OK, let me try to explain what I see is the problem: So far we the bitcoin addresses are (for all practical purposes) a one-to-one mapping between a pubkey and uint160. This mean that your wallet is defined solely by your privatekeys (from which you can extract pubkeys and then uint160

[Bitcoin-development] Bitcoin Wiki

2011-10-27 Thread Amir Taaki
Anybody know how to contact MT about getting it back online? I still haven't finished copy-editing the BIPs and need access to them since there's a new one to be added. -- The demand for IT networking professionals

[Bitcoin-development] Multi-sig tx execution ideas

2011-10-28 Thread Alan Reiner
I just posted BIP 0010 to gist : https://gist.github.com/1321518 The goal is to provide a standard method for proposing how to spend multi-sig TxOuts, and collect signatures without actually having to understand BTC under-the-hood. I envision, even without any program installed,

Re: [Bitcoin-development] Detecting OP_EVAL scriptPubKeys that are to you

2011-10-29 Thread Gavin Andresen
RE: buying me and Gregory a shared beer: I would make a both of two btc-addresses script transaction using OP_EVAL. And post it. You would then not be able to know that you actually got a beer unless I told you so in a mail. But that transaction won't show up in my bitcoin wallet as

[Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Amir Taaki
Hey, Can we lock the version numbers to be the protocol version (which changes rarely) and instead use the sub_version_num field + revision number for individual builds? Satoshi 0.4 BitcoinJava 120311 bitcoin-js 6 Like so. Otherwise we will have version bumping insanity :)

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Christian Decker
I don't really get what you want to achieve with this. The protocol will be slow down evolution (hopefully) soon, while the clients will continue releasing at a similar rhythm. It took long enough to decouple the protocol version from being bumped each client release, now doing the inverse

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Amir Taaki
Point taken. About the sub_version_num though. I prefer to let the field by defined clients however they wish, with just a guideline suggestion that IDENTIFIER VERSION is a format they should follow. The idea being that different projects would have different release scheduling schemes and

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Christian Decker
Just for reference: https://github.com/bitcoin/bitcoin/pull/63 The issue resulted in my most useless pull request fixing two variables :-) I second the use of sub_version_num as a Client and Version identifier. Regards, Chris On Wed, Nov 2, 2011 at 11:33 PM, Amir Taaki zgen...@yahoo.com wrote:

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Luke-Jr
On Wednesday, November 02, 2011 6:33:12 PM Amir Taaki wrote: Satoshi 0.5 What is Satoshi 0.5 anyway? 0.5's server is bitcoind and GUI is Bitcoin-Qt; the wx GUI client is gone, which is more or less what Satoshi referred to in the past...

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Amir Taaki
Bitcoin is the protocol. The client protocol identifier needs a unique name. It is not a public name that anybody ever sees except protocol developers. For instance with libbitcoin, there might be several clients using it, but they'd all have the same protocol identifier. I think calling it

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-02 Thread Jeff Garzik
On Wed, Nov 2, 2011 at 7:22 PM, Christian Decker decker.christ...@gmail.com wrote: The mainline client (independently from the GUI) has been referenced to as Satoshi client. I personally like the name as a homage, but I guess it all comes down to the decision of the maintainers. That's how I

Re: [Bitcoin-development] Please help sanity test: Linux/Windows 0.5.0rc2 binaries

2011-11-04 Thread Gavin Andresen
If you wonder where the bitcoin-0.5.0rc2-linux.tar.gz went... I removed it because it is not sane (we need to teach the Qt build to statically link dependencies). Once the Mac and Linux deployment issues are fixed, expect a release candidate 3... -- -- Gavin Andresen

Re: [Bitcoin-development] Please help sanity test: Linux/Windows 0.5.0rc2 binaries

2011-11-04 Thread Douglas Huff
What's wrong with the mac build? I just built on 10.7 without any issues. -- Douglas Huff On Nov 4, 2011, at 4:29 PM, Gavin Andresen wrote: If you wonder where the bitcoin-0.5.0rc2-linux.tar.gz went... I removed it because it is not sane (we need to teach the Qt build to statically link

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Mike Hearn
BitCoinJ already sets the subver field to its name and version. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Christian Decker
On BitDroid I stopped updating the protocol version at 31700 and set the string to be both Version and Client, just like BitcoinJ :-) On Sat, Nov 5, 2011 at 3:32 PM, Mike Hearn m...@plan99.net wrote: BitCoinJ already sets the subver field to its name and version.

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Amir Taaki
From talking with Patrick Strateman (phantomcircuit), he suggested this idea (which I will elaborate more on in the BIP): User-agent strings are a good starting point, however they aren't easy for parsing so we'll make a small modification to them. We need a hierarchy from protocol, variant,

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Christian Decker
Sorry for shooting this approach down, but I'm against it. User-agent strings are an extremely bad idea as it would lead developers to start making communication choices depending on the client type. User-Agents in HTTP are only useful if the clients (browsers) do not adhere to a well defined

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Luke-Jr
On Saturday, November 05, 2011 12:17:58 PM Christian Decker wrote: Sorry for shooting this approach down, but I'm against it. User-agent strings are an extremely bad idea as it would lead developers to start making communication choices depending on the client type. This can be necessary in

Re: [Bitcoin-development] Lock protocol version numbers

2011-11-05 Thread Jordan Mack
If clients break the network protocol/do not comply properly with it, they should be disconnected and shunned. Hard love. We don't want any ambiguity in the protocol. However my feeling about the user-agent string is that it is a vanity item, but here we'd be enforcing a format that

Re: [Bitcoin-development] Difficulty adjustment / time issues

2011-11-07 Thread Pieter Wuille
On Tue, Sep 13, 2011 at 11:06:37AM -0400, Gavin Andresen wrote: Background: Timejacking: http://culubas.blogspot.com/2011/05/timejacking-bitcoin_802.html And a recent related exploit launched against the low-difficulty alternative chains:

  1   2   3   4   5   6   7   8   9   10   >