[Bitcoin-development] GBT 2.0 wishlist

2014-04-29 Thread Luke-Jr
Let's try to get GBT 2.0 off the ground finally.. :) Here's some wishlist items/ideas: - Extremely low bandwidth use (binary protocol, with compression support) - UDP-based transport protocol? (so message order need not be preserved at the expense of latency) - Ability to instruct miners to

Re: [Bitcoin-development] BIP - Hash Locked Transaction

2014-04-25 Thread Luke-Jr
This one looks entirely useless (it cannot be made secure), and the assertion that it is necessary for atomic cross-chain transfers seems unfounded and probably wrong... Luke On Friday, April 25, 2014 6:49:37 PM Tier Nolan wrote: As part of the atomic cross chain system, outputs need to be

Re: [Bitcoin-development] BIP - Selector Script

2014-04-25 Thread Luke-Jr
I believe you meant to link here instead? https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki This looks reasonable from a brief skim over, but does not define any use cases (it mentions necessary for atomic cross chain transfers, but does not explain how it is useful for that -

Re: [Bitcoin-development] BIP - Selector Script

2014-04-25 Thread Luke-Jr
On Friday, April 25, 2014 8:02:41 PM Tier Nolan wrote: I don't think the cross chain system needs a BIP (except to justify this one). If cross chain transfer become popular, then it would be useful to ensure that clients are interoperable, but first things first. If the transactions aren't

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote: On 04/23/2014 09:00 PM, Tier Nolan wrote: The point is to have a single system that is compatible over a large number of systems. There is such system and it is called BIP32. On the other hand, in BIP64 we try to put a set of

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote: On 04/23/2014 09:44 PM, Luke-Jr wrote: Why do clients need to use the features in BIP 64? If Electrum doesn't want to use accounts, then it can just use account 0 for everything. Refund chains are As Andreas wrote earlier

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 7:57:46 PM slush wrote: On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote: Any wallet should import all the coins just fine, it just wouldn't *use* any account other than 0. Remember addresses are used to receive bitcoins; once the UTXOs

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote: On 04/23/2014 10:01 PM, Luke-Jr wrote: Yes, it should scan all possible (under the BIP-defined structure) branches regardless of which features it supports. So you suggest to scan for accounts, show balances but don't allow user

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote: On 04/23/2014 10:09 PM, Luke-Jr wrote: Scan all branches for UTXOs, then you have the balance for the wallet. Account balances are metadata, so cannot be known from the seed alone. If you want to have a way to restore accounts, you

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote: On 04/23/2014 10:32 PM, Luke-Jr wrote: f) I missed the part where BIP 32 redefined account to mean subwallet instead of what has traditionally been called account in Bitcoin. Ah, okay. The last time I saw Bitcoin-qt it was still

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote: On 04/23/2014 10:41 PM, Luke-Jr wrote: I don't see how. The user knows he has money in different subwallets. As long as he has a way to specify which subwallet he is accessing in single-subwallet clients, there shouldn't

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 9:06:26 PM Pavol Rusnak wrote: On 04/23/2014 10:54 PM, Pieter Wuille wrote: Would you consider software which scans all accounts as specified by BIP64, but has no user interface option to distinguish them in any way, view them independently, and has no ability

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread Luke-Jr
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote: On 04/23/2014 11:22 PM, Gregory Maxwell wrote: Hopefully it would be clarified as only a MUST NOT do so silently... I have funds split across two wallets and it WONT LET ME SPEND THEM sounds like a terrible user experience. :)

Re: [Bitcoin-development] Ubuntu LTS Packaging?

2014-04-12 Thread Luke-Jr
On Saturday, April 12, 2014 2:26:07 PM Oliver Egginger wrote: Hello, so far, nothing yet? See: https://launchpad.net/~bitcoin/ I'm developing currently a LiveCD for hot/cold wallet management on Ubuntu LTS basis. For critical vulnerabilities I have to provide timely updates. I have now

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Luke-Jr
://gist.github.com/luke-jr/9920788 -- ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Finite monetary supply for Bitcoin

2014-04-01 Thread Luke-Jr
on advanced category theory. I'm sure there are many applications to Bitcoin. On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr l...@dashjr.org wrote: On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote: Hi all, I understand this is a controversial proposal, but bear with me please. I believe

Re: [Bitcoin-development] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

2014-03-24 Thread Luke-Jr
On Saturday, March 22, 2014 8:47:02 AM Peter Todd wrote: To make a long story short, it was soon suggested that Bitcoin Core be forked - the software, not the protocol - and miners encouraged to support it. There's been at least one public miner-oriented fork of Bitcoin Core since 0.7 or

Re: [Bitcoin-development] moving the default display to mbtc

2014-03-13 Thread Luke-Jr
On Thursday, March 13, 2014 4:37:02 PM slush wrote: Display based on locale. Please don't bring locale into this. Bitcoin has always been intentionally locale-independent (hence BTC using xxx,xxx,xxx.xx format even in locales which swap the commas and periods). Localising display makes

Re: [Bitcoin-development] New side channel attack that can recover Bitcoin keys

2014-03-08 Thread Luke-Jr
On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote: How can we patch this issue? No need, it is not an issue for Bitcoin. Properly used, there is only ever one signature per public key. Luke -- Subversion Kills

Re: [Bitcoin-development] Procedure for non-tech contributions

2014-03-02 Thread Luke-Jr
On Sunday, March 02, 2014 11:02:14 PM Tom Geller wrote: Peter writes: MtGox does host the bitcoin wiki, so yes, the funds probably do go to a wallet held by MtGox in some fashion. The foolishness of sending a payment to a Mt. Gox-held wallet -- which is required to edit the wiki --

Re: [Bitcoin-development] New to this list

2014-03-02 Thread Luke-Jr
On Monday, March 03, 2014 3:34:27 AM Kevin wrote: Hello. I am a developer and I wish to contribute to bitcoin. Where is the best place to start? Unit tests. This will be valuable to the projects and also help you learn how things work.

Re: [Bitcoin-development] On OP_RETURN in upcoming 0.9 release

2014-02-24 Thread Luke-Jr
On Monday, February 24, 2014 11:06:30 PM Andreas Petersson wrote: Regarding 80 bytes vs smaller: The objectives should be that if you are determined to put some extra data in the blockchain, OP_RETURN should be the superior alternative. if a user can include more data with less fees using a

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Luke-Jr
On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote: On 02/12/2014 08:44 AM, Alan Reiner wrote: Changing the protocol to use these static IDs is a pretty fundamental change that would never happen in Bitcoin. But they can still be useful at the application level to mitigate

Re: [Bitcoin-development] Embedded consensus system upgrade procedures

2014-02-09 Thread Luke-Jr
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote: We have an embedded consensus system and we want to be able to upgrade it with new rules. This asserts a central authority and gives developers too much power.

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

2014-02-09 Thread Luke-Jr
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote: The proposed document is here: https://gist.github.com/sipa/8907691 Rule 3 4 are already enforced. AFAIK nVersion==3 transactions are not currently considered non-standard? Luke

Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread Luke-Jr
On Monday, January 20, 2014 5:42:37 PM slush wrote: Hi all, during recent months we've reconsidered all comments which we received from the community about our BIP39 proposal and we tried to meet all requirements for such standard. Specifically the proposal now doesn't require any specific

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-17 Thread Luke-Jr
On Friday, January 17, 2014 8:53:47 PM Jeff Garzik wrote: vendor hat: on BitPay sure would like to see CPFP in upstream. I think the main hurdle to merging was that various people disagreed on various edge case handling and implementation details, but no fundamental objections. Heck, even

Re: [Bitcoin-development] Bitcoin Core 0.9rc1 release schedule

2014-01-16 Thread Luke-Jr
, please tell. Wladimir https://github.com/bitcoin/bitcoin/pulls/luke-jr These are pretty much all well-tested and stable for months now. -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More

Re: [Bitcoin-development] Suggestion: allow receivers to pay optional fee for transactions without fees

2014-01-16 Thread Luke-Jr
On Friday, January 17, 2014 2:39:31 AM Christophe Biocca wrote: To clarify, there are proposals to make miners recognize this situation and account for it, only eligius is running it at the moment IIRC: http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-larg

Re: [Bitcoin-development] The insecurity of merge-mining

2013-12-31 Thread Luke-Jr
On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote: On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote: On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: that you are using merge-mining is a red-flag because without majority, or at least near-majority, hashing power

Re: [Bitcoin-development] Looking for GREAT C++ developer for exciting opportunity in bitcoin space

2013-12-30 Thread Luke-Jr
On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote: that you are using merge-mining is a red-flag because without majority, or at least near-majority, hashing power an attacker can 51% attack your altcoin at negligible cost by re-using existing hashing power. I strongly disagree on this

Re: [Bitcoin-development] RFC: MERGE transaction/script/process for forked chains

2013-12-17 Thread Luke-Jr
On Tuesday, December 17, 2013 10:41:30 PM Troy Benjegerdes wrote: I want to get some feedback.. I've used distributed version control systems for a long time, and the most useful feature is to be able to merge two different forks. So what's the equivalent of this for Bitcoin or other

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-08 Thread Luke-Jr
On Sunday, December 08, 2013 8:51:07 PM Drak wrote: Otherwise, who has admin rights to the code projects (github/sourceforge/this mailing list)? Those people have proven they can be trusted so far. Can someone explain how Sirius has proven the least bit untrustworthy? Luke

Re: [Bitcoin-development] Dedicated server for bitcoin.org, your thoughts?

2013-12-08 Thread Luke-Jr
On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote: 1) Who pays for it? Most obvious answer: Foundation. However there's currently a fairly clear line between the foundation website and the bitcoin.org http://bitcoin.org website. I personally am fine with the bitcoin foundation

Re: [Bitcoin-development] Move authorative source for BIPs to git repository

2013-12-05 Thread Luke-Jr
On Thursday, December 05, 2013 1:37:10 PM Wladimir wrote: Hello all, A while ago after discussion on the mailing list a repository was set up to store the BIP documents, as this is deemed a more secure solution than having them on the wiki: https://github.com/bitcoin/bips To prevent

Re: [Bitcoin-development] moving the default display to mbtc

2013-11-15 Thread Luke-Jr
On Saturday, November 16, 2013 12:41:56 AM Drak wrote: So a payment clears after one confirmation, but you might want to wait until the payment has been confirmed n times. Then at least you are not using the same word for two different meanings and you're using stuff more familiar in popular

Re: [Bitcoin-development] moving the default display to mbtc

2013-11-14 Thread Luke-Jr
On Thursday, November 14, 2013 11:45:51 AM Melvin Carvalho wrote: Would now be a good time to start thinking about changing the default display in the software. Perhaps initially it could be a dropdown display option, then at some point mbtc becomes the default? There's already a dropdown

Re: [Bitcoin-development] moving the default display to mbtc

2013-11-14 Thread Luke-Jr
On Thursday, November 14, 2013 10:07:58 PM Allen Piscitello wrote: Obviously the answer is to just display all fees and trading rates as BTC or MBTC (.005 MBTC fee? how cheap!). On a more serious note, the transition should definitely be thought out well as it could be very damaging to

Re: [Bitcoin-development] moving the default display to mbtc

2013-11-14 Thread Luke-Jr
On Thursday, November 14, 2013 10:53:16 PM Alan Reiner wrote: I really like the XBT idea. It makes a lot of sense to match the ISO currency symbol (though the ISO guys will have to adjust the way they've defined the XBT). And I do agree that going right to uBTC and skipping mBTC makes sense,

Re: [Bitcoin-development] idea

2013-11-09 Thread Luke-Jr
On Saturday, November 09, 2013 8:16:07 PM Chris Evans wrote: maybe add an optional note field to transaction so the receiver knows who sent the btc This mailing list is for development discussion, NOT bug reports nor feature requests. Bitcoin does not currently support any built-in mechanism

Re: [Bitcoin-development] Message Signing based authentication

2013-11-02 Thread Luke-Jr
On Sunday, November 03, 2013 12:29:28 AM Allen Piscitello wrote: This was one of my concerns when implementing a scheme where you sign a refund transaction before the original transaction is broadcast. I originally tried to pass a hash and have the server sign it. However, I had no way to

Re: [Bitcoin-development] Message Signing based authentication

2013-11-02 Thread Luke-Jr
On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote: I actually had a use case in my case where it was possible, and that was the check I used to get around it, just configured it so that I always generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx. It was

Re: [Bitcoin-development] Message Signing based authentication

2013-11-01 Thread Luke-Jr
On Saturday, November 02, 2013 5:01:43 AM bitcoingr...@gmx.com wrote: In celebration of the 5 year anniversary of the Bitcoin whitepaper, we are delighted to introduce the Message Signing based authentication method. In brief, the authentication work as follows: Server provides a token for the

Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-27 Thread Luke-Jr
On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote: Currently bitcoinj gets a small but steady stream of bug reports of the form my transaction did not propagate. It's flaky because the library picks one peer to send the transaction to, and then watches it propagate across the network.

Re: [Bitcoin-development] Feedback requested: reject p2p message

2013-10-27 Thread Luke-Jr
On Sunday, October 27, 2013 10:52:25 PM Gavin Andresen wrote: If anybody has strong feelings about what the reject categories should be, then please take the time to write a specific list, I can't read your mind It might make sense to use the rejection reasons from BIP 22 where applicable.

Re: [Bitcoin-development] Payment protocol for onion URLs.

2013-10-25 Thread Luke-Jr
On Saturday, October 26, 2013 3:31:05 AM Gregory Maxwell wrote: One limitation of the payment protocol as speced is that there is no way for a hidden service site to make use of its full authentication capability because they are unable to get SSL certificates issued to them. A tor hidden

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-24 Thread Luke-Jr
On Thursday, October 24, 2013 5:29:18 PM thoma...@gmx.de wrote: I would like to propose a new BIP, that replaces BIP0039. BIP 39 is still a draft. Just suggest revisions to the author(s)... -- October Webinars: Code for

Re: [Bitcoin-development] Revisiting the BIPS process, a proposal

2013-10-21 Thread Luke-Jr
On Monday, October 21, 2013 7:38:37 PM Jean-Paul Kogelman wrote: 1) Should the protocol specification page also be codified into BIP(s)? Probably wouldn't hurt, but it'd likely need a rewrite in a more modular and formal form. 2) Should the current wiki pages be taken down / forwarded to the

Re: [Bitcoin-development] A critique of bitcoin open source community

2013-10-19 Thread Luke-Jr
On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote: I have a question regarding this part. I wrote a BIP for base 58 encoding / encryption of BIP 32 root keys. The BIP page states that we shouldn't add to this list ourselves, but should contact you for a BIP number. I have

Re: [Bitcoin-development] Blockchain archival

2013-09-07 Thread Luke-Jr
On Saturday, September 07, 2013 11:21:31 PM rob.gold...@astutium.com wrote: bitcoin protocol needs an archival system so the blockchain doesn't become too big to download Some people may want it all ... Balance at Point-In-Time summaries (say up to the penultimate difficulty adjustment)

Re: [Bitcoin-development] Making bitcoin traceability harder

2013-08-21 Thread Luke-Jr
Faré, Let me start out by noting that there are plenty of good ideas which could be implemented, but haven't been yet, and might take a long time to get to. There are only a couple handfuls of Bitcoin developers, and even fewer of us who are able to work full-time on Bitcoin development.

[Bitcoin-development] LevelDB in master

2013-08-16 Thread Luke-Jr
pushed three branches to https://github.com/luke-jr/leveldb : bitcoin-1.5 Our old/unreleased LevelDB 1.5 fork, for reference bitcoin Our LevelDB 1.7 fork, included in 0.8.x bitcoin-upOur LevelDB 1.7 fork, merged with upstream LevelDB 1.12 A diff from current master (Ripple LevelDB

Re: [Bitcoin-development] btc name server

2013-08-02 Thread Luke-Jr
Chris, First, an important point: addresses are not wallet ids. They are single-use destinations for a single transaction. It isn't intended that anyone should remember them, just that they should send them electronically (or with eg, QR- Codes). Bitcoin does not (yet?) have a person/wallet

Re: [Bitcoin-development] Opcode whitelist for P2SH?

2013-07-28 Thread Luke-Jr
On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote: What are your thoughts on creating a whitelist for specific opcodes that would apply to scripts serialized using P2SH, retaining the existing standard whitelist for scriptPubKeys? (I would still recommend dropping pay-to-pubkey and

Re: [Bitcoin-development] Linux packaging letter

2013-07-23 Thread Luke-Jr
On Tuesday, July 23, 2013 10:02:28 PM Scott Howard wrote: 1) It appears that the consensus of upstream developers is that any distributed binary should only be linked against libraries that the bitcoin developers have tested and audited since any compatibility bug is a risk to both the user

Re: [Bitcoin-development] Endianness (was: Linux packaging letter)

2013-07-23 Thread Luke-Jr
On Wednesday, July 24, 2013 3:54:25 AM Wendell wrote: Is there a substantial barrier to endian independence in the Bitcoin codebase? I got the obvious stuff ('endian' branch in my repo), but it still didn't work when I moved on. I haven't had time to try to figure out why not yet. Luke

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Luke-Jr
On Sunday, July 14, 2013 7:22:10 PM John Dillon wrote: Merged mining is not mining the coin for free. The total reward (ie btc + frc + nmc + dvc) should tend to equal the mining costs. But the value comes from demand, not costs. So if people demand it more it price will rise no matter how

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Luke-Jr
On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote: On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote: The issue is that unless there is a cost to mining a *invalid* block the merge mined coin has little protection from miners who mine invalid blocks, either maliciously

Re: [Bitcoin-development] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

2013-07-14 Thread Luke-Jr
On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote: On Sun, Jul 14, 2013 at 08:16:41PM +, Luke-Jr wrote: P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as well as (rewarded) Prime POW; maybe with no subsidy halving, to try a new economic idea as well ;) Your

Re: [Bitcoin-development] Proposal: MultiBit as default desktop client on bitcoin.org

2013-06-27 Thread Luke-Jr
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote: * Very real possibility of an overall net reduction of full nodes on P2P network Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or MultiBit node. :/ Jim, will MultiBit be adding p2p listening support? I'm

Re: [Bitcoin-development] Decentralizing mining

2013-06-14 Thread Luke-Jr
On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote: On Mon, Jun 10, 2013 at 09:23:14PM +, Luke-Jr wrote: Might as well just use higher difficulty shares (each one audited) for the same effect. Block proposals allow the miner to tell the pool its transaction set once (per txset change

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

2013-06-14 Thread Luke-Jr
Note that the earn a mixture of BTC and TBC, but not both in full volume only works for TBC because the price is by definition fixed with BTC. I'm not sure how you could implement something like this for an altcoin where the price is floating independently of Bitcoin.. that is, how you would

Re: [Bitcoin-development] Bitcoin addresses -- opaque or not

2013-06-11 Thread Luke-Jr
On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote: For the sake of argument let's say that opaque means that you can tell nothing about the address by examining the characters. This is true or false based on CONTEXT. Obviously, an implementation of transaction handling (eg, wallets)

Re: [Bitcoin-development] Decentralizing mining

2013-06-10 Thread Luke-Jr
On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote: # Protocol Work This is basically done. Basic idea is the miner makes two connections, their pool, and a local bitcoind. They always (usually?) work on the subset of transactions common to both the pool's getblocktemplate and their

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-06 Thread Luke-Jr
above. I could be totally misreading this thread, too, so please allow me some slack if I have! On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr l...@dashjr.org wrote: On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: scriptPubKey: data OP_TRUE ... Along with that change anyone

Re: [Bitcoin-development] Proposal: soft-fork to make anyone-can-spend outputs unspendable for 100 blocks

2013-06-06 Thread Luke-Jr
On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote: This doesn't work like you might think: first of all, the fees today are greatly subsidized - the actual cost to store data in the blockchain is much higher than most storage solutions. Secondly, only the miner receives

Re: [Bitcoin-development] 0.8.2 branch

2013-05-29 Thread Luke-Jr
On Thursday, May 30, 2013 2:54:00 AM grarpamp wrote: Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2) in which the like of release build stoppers or critfixes such as d315eb0 are included... for those tracking that level of defect without wishing to track all the growing post

Re: [Bitcoin-development] Modularizing Bitcoin

2013-05-26 Thread Luke-Jr
On Thursday, May 16, 2013 10:02:05 AM bitcoingr...@gmx.com wrote: One of the main goals will be to separate the wallet from the node, as we have already done with mining. How is this different from what Electrum has already done? Luke

Re: [Bitcoin-development] Modularizing Bitcoin

2013-05-26 Thread Luke-Jr
On Thursday, May 16, 2013 10:55:44 AM Addy Yeow wrote: Is the number representing the count for the client nodes? I was curious of the count myself earlier this week and started to traverse down the network using getaddr message starting from seed nodes and found upward to 57k nodes running

Re: [Bitcoin-development] (no subject)

2013-05-25 Thread Luke-Jr
On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote: It might be an idea to have 'rule change' fixes and 'bug fix' releases go out separately Bitcoin is a consensus system. You can't run clients with different rules on the same blockchain/network - it just won't work! Maybe we're now

Re: [Bitcoin-development] Tentitive port for FreeBSD

2013-05-24 Thread Luke-Jr
On Saturday, May 25, 2013 3:36:46 AM Robert Backhaus wrote: Here is the link to the FreeBSD build system 'port' that I am planning to get committed when 0.8.2 is released. Any comments appreciated. The Makefile mostly just applies the users request for GIU/QR/UPNP. The major change is using

Re: [Bitcoin-development] UUID to identify chains (payment protocol and elsewhere)

2013-05-22 Thread Luke-Jr
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote: On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho melvincarva...@gmail.com wrote: On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote: On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho melvincarva...@gmail.com wrote:

[Bitcoin-development] RFC: c32d encoding

2013-05-15 Thread Luke-Jr
https://bitcointalk.org/?topic=205878 This encoding is designed so that it could replace Base58Check in new data, with the following goals in mind: - Impossible(?) to manipulate without completely changing it - Clearly identifiable prefix, regardless of data size - Cheaper to process (simpler

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

2013-04-13 Thread Luke-Jr
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote: Currently signmessage/verifymessage only supports messages signed by a single key. We should extend that to messages signed by n-of-m keys, or from the users point of view, P2SH multisig addresses. I think it would be wise to figure out HD

Re: [Bitcoin-development] A bitcoin UDP P2P protocol extension

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote: Introducing super-nodes with thousands of connected peers can greatly help here. UDP is connectionless. I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/ Luke

Re: [Bitcoin-development] Upcoming network event: block v2 lock-in

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote: I don't think anyone is mining using bitcoind 0.7 or later? slush, BTC Guild, ozcoin too I think, several others. Not for producing coinbases (where BIP 34

Re: [Bitcoin-development] Upcoming network event: block v2 lock-in

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote: On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote: I don't think anyone is mining using bitcoind

Re: [Bitcoin-development] Upcoming network event: block v2 lock-in

2013-03-23 Thread Luke-Jr
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote: On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr l...@dashjr.org wrote: bitcoind is nowhere in the implementation of the miner end of BIP 34. Again, not strictly true. bitcoind's 'getblocktemplate' RPC call used by some supplies the block

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-15 Thread Luke-Jr
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote: On Mar 13, 2013, at 8:18 PM, Cameron Garnham da2...@gmail.com wrote: For me, everyone signed up to bitcoin thinking that there was a 1MB / block limit. The lock limits were unexpected, and could be considered extremely

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
controversial changes. I figured 2 MB in 2-3 years was fairly uncontroversial. If not, let's scrap that idea for now. Luke-jr, any chance in getting you to revise your proposal to narrow the scope to things that don't need serious debate? It was a one-time start the conversation proposal. I expect what

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
clients *is by definition* a hard fork. Proposal: 1) Patch the pre-0.8 branches to support an increased lock count, whatever number is required to make sure that this problem never shows up again at the current block size (I defer to Luke-Jr and gmaxwell's numbers on this). This is a hard fork

Re: [Bitcoin-development] Blocksize and off-chain transactions

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote: Please note that it was not 0.8 that had issues, but 0.7(and downwards). While 0.7 and earlier do have issues, they also define the Bitcoin protocol. 0.8's failure to comply with the protocol is an issue.

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote: Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules which all verifying implementations must adhere to. I'm suggesting that we instead change the old codebase to do what we expected it to do all along (what 0.8

Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread Luke-Jr
On Wednesday, March 13, 2013 9:06:44 PM Andy Parkins wrote: On Wednesday 13 Mar 2013 12:56:29 Luke-Jr wrote: Here's a simple proposal to start discussion from... It seems to me that the biggest failure was not the development of two chains, but the assurance to users (by the client

Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Luke-Jr
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote: I'm sure it won't be long before Slashdot and a variety of sources start reporting on this event. Bitcoin has been in the media a lot lately, so this story is likely to get some attention. The blowback of this event is mostly

Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC

2013-03-11 Thread Luke-Jr
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote: From: Rune K. Svendsen runesv...@gmail.com On the Main tab in the Options dialog, it previously said a minimum fee of 0.01 is recommended. This amounts to about $0.50 at today's price. Change this to 0.001 to be more sensible. We

Re: [Bitcoin-development] [PATCH] Change recommended fee to 0.001 BTC

2013-03-11 Thread Luke-Jr
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote: On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote: On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote: Ok. I'll fork on Github. Looking at the source, and some Qt documentation, it should

Re: [Bitcoin-development] Blockchain as root CA for payment protocol

2013-02-09 Thread Luke-Jr
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote: Why don't you use namecoin or another alt-chain for this? Because namcoin tries to solve a different problem, DNS, whereas I want to establish an identity for a payment protocol. What is the technical difference here? Namecoin ties

Re: [Bitcoin-development] 0.8.0rc1 status

2013-02-08 Thread Luke-Jr
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote: Windows builds are varying with every compile, and I think I finally figured out why: we are not passing the -frandom-seed flag down into the leveldb build (I used objdump to dump two different binaries, and they differed only in

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:02:14 PM Mike Hearn wrote: Minor caveat, IMHO we should support all CAs used by the popular browsers. I would prefer using the user-accepted certs at the operating system level... --

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:16:03 PM Mike Hearn wrote: They could be included as well of course, but from a seller perspective the most important thing is consistency. You have to be able to predict what CAs the user has, otherwise your invoice would appear in the UI as unverified and is

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

2012-11-26 Thread Luke-Jr
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote: Obviously the state of the world with browsers is not that good... but in our own UAs we can do better and get closer to that. This effectively centralizes Bitcoin (at least in the eyes of many) and even if each competing client

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-06 Thread Luke-Jr
On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote: Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to be a good time for the core dev team to meet on the #bitcoin-dev freenode IRC channel to chat. I'd like to talk about: o Can we put together a TODO list to

Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-06 Thread Luke-Jr
On Tuesday, November 06, 2012 7:56:23 PM slush wrote: On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote: But more important to the success of BIP today, I think, is encouraging wider community participation. It's not about BIP process, it's possibly about content of particular

Re: [Bitcoin-development] Hosting of compiled bitcoin client

2012-10-14 Thread Luke-Jr
On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote: Given that sourceforge has shown to restrict access to a number of countries at the request of the USA This needs some clarification. If the USA has requested it, then presumably there's some legality involved, and our US developers

Re: [Bitcoin-development] Bitcoin Testing Project

2012-09-26 Thread Luke-Jr
On Wednesday, September 26, 2012 11:41:13 AM Daniel F wrote: on 09/26/2012 01:49 AM Wladimir said the following: I'm willing to write this. But I know these kinds of proposals always end in a big discussion about what should be and what should not be on bitcoin.org, however we should be a

Re: [Bitcoin-development] Segmented Block Relaying BIP draft.

2012-09-10 Thread Luke-Jr
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote: Here is a BIP draft for improving the block relaying and validation so that it can be done in parallel and so that redundancy can be removed. This becomes more beneficial the larger the block sizes are.

Re: [Bitcoin-development] Version 0.7 release planning

2012-08-02 Thread Luke-Jr
to enabled) luke-jr https://github.com/bitcoin/bitcoin/pull/1431 11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate) luke-jr https://github.com/bitcoin/bitcoin/pull/936 + + m) getmemorypool: longpolling support + luke-jr https://github.com/bitcoin/bitcoin/pull/1355 + + m) Refactor

Re: [Bitcoin-development] BIP 22 - getmemorypool

2012-07-30 Thread Luke-Jr
On Monday, July 30, 2012 8:26:12 PM Amir Taaki wrote: https://en.bitcoin.it/wiki/BIP_0022 Note that the Pooled Mining parts have already been moved to: https://en.bitcoin.it/wiki/BIP_GMPPM It just needs a number assigned (as the last part).

  1   2   >