[Bitcoin-development] GBT 2.0 wishlist

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 inse

Re: [Bitcoin-development] BIP - Selector Script

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 a

Re: [Bitcoin-development] BIP - Selector Script

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 - Hash Locked Transaction

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 ha

Re: [Bitcoin-development] New BIP32 structure

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] New BIP32 structure

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 abi

Re: [Bitcoin-development] New BIP32 structure

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 c

Re: [Bitcoin-development] New BIP32 structure

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.

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

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 bal

Re: [Bitcoin-development] New BIP32 structure

On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote: > On 23.04.2014, at 21:55, Luke-Jr 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 t

Re: [Bitcoin-development] New BIP32 structure

On Wednesday, April 23, 2014 7:57:46 PM slush wrote: > On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr 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; >

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] New BIP32 structure

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

Re: [Bitcoin-development] Ubuntu LTS Packaging?

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

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

of harmony based on advanced category theory. I'm > sure there are many applications to Bitcoin. > > On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr wrote: > > On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote: > >> Hi all, > >> > >> I understand this

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

sing tonal numbers after all: https://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] Handling miner adoption gracefully for embedded consensus systems via double-spending/replace-by-fee

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 ea

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

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 differe

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

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 Produ

Re: [Bitcoin-development] New to this list

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] Procedure for non-tech contributions

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] On OP_RETURN in upcoming 0.9 release

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

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 mit

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

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] Embedded consensus system upgrade procedures

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] BIP0039: Final call

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 spec

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

On Friday, January 17, 2014 8:53:47 PM Jeff Garzik wrote: > 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 I disagree

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

On Friday, January 17, 2014 11:44:09 AM Wladimir wrote: > On Thu, Jan 16, 2014 at 4:23 PM, Luke-Jr wrote: > > https://github.com/bitcoin/bitcoin/pulls/luke-jr > > > > These are pretty much all well-tested and stable for months now. > > #3242: Autoconf improvements nee

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

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 > e-miners-r

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

ow of some nasty bug in master that should absolutely be solved > first, please tell. > > Wladimir https://github.com/bitcoin/bitcoin/pulls/luke-jr These are pretty much all well-tested and stable for months now.

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

On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote: > On Tue, Dec 31, 2013 at 01:14:05AM +0000, 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, > > >

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

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 th

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

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 cry

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

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 website. I personally am fine with the > > bitcoin f

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

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?

On Sunday, December 08, 2013 10:00:35 AM Drak wrote: > Also it's about time we hosted the Bitcoin Qt software at Github. They have > a releases feature where you can upload a packaged release (see > https://github.com/blog/1547-release-your-software). There are also no > adverts (another privacy le

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

On Sunday, December 08, 2013 9:03:38 AM Saïvann Carignan wrote: > Binaries: > Sourceforge is not encrypted, actually. Although binaries hosting / > sharing could be a separate subject discussed later I think. Encryption is useless here. We want everyone to be able to download Bitcoin clients. Bin

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

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 pr

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

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 popu

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

On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote: > On 11/14/13 3:01 PM, Luke-Jr wrote: > > I think we all know the problems with the term "address". People > > naturally compare it to postal addresses, email addresses, etc, > > which operate fun

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

On Thursday, November 14, 2013 11:11:26 PM Mark Friedenbach wrote: > "key id" (thanks sipa). > > I know it's a more technical term, but that is rather the point. It > was a fundamental error to call hashed-pubkeys "addresses" as people > either associate this with "account" or physical addresses,

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

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 s

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

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

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 d

Re: [Bitcoin-development] idea

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

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 ei

Re: [Bitcoin-development] Message Signing based authentication

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

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

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

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 applicabl

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

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 > networ

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

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 hid

Re: [Bitcoin-development] Proposal to replace BIP0039

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

On Wednesday, October 23, 2013 9:42:14 PM Allen Piscitello wrote: > That being said, it's a huge chicken and egg problem. No one wants to go > off the reference client since it could lead to working on a forked chain > as a miner or having bad data as a client. Thankfully, miners are incentivised

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

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

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 > co

Re: [Bitcoin-development] Blockchain archival

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 adj

Re: [Bitcoin-development] Making bitcoin traceability harder

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. Perhap

Re: [Bitcoin-development] Proposal: remove "getwork" RPC from bitcoind

On Monday, August 19, 2013 8:09:41 PM Frank F wrote: > I strongly object to removing the only mechanism that allows anyone to say > that bitcoin is p2p, in the truest sense of the word. Moves like this that > favor only the pool operators and private mining interests are signs that > bitcoin is hea

[Bitcoin-development] LevelDB in master

ot included in this merge. I've 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 di

Re: [Bitcoin-development] btc name server

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 iden

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

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 pay-

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

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] Linux packaging letter

On Tuesday, July 23, 2013 11:23:27 PM Greg Troxel wrote: > I find it interesting that this is a "linux packaging letter". How much > of this applies to pkgsrc, FreeBSD ports, OpenBSD ports, and other > non-Linux packaging systems (pkgsrc supports Linux as on of 20 operating > systems, but is not a

Re: [Bitcoin-development] Linux packaging letter

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] libzerocoin released, what about a zerocoin-only alt-coin with either-or mining

On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote: > On Sun, Jul 14, 2013 at 08:16:41PM +0000, 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

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

On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote: > On Sun, Jul 14, 2013 at 07:33:06PM +0000, 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

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

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 matt

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

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'

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

Timestamping ("proof of existence") doesn't need a coin at all. Just collect all the hashes you need timestamped into a PoE merkle tree and add that to the merged mining MT. It's pretty simple and straightforward, just needs someone to implement it. On Saturday, June 15, 2013 12:09:09 AM Dennis

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

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 kn

Re: [Bitcoin-development] Decentralizing mining

On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote: > On Mon, Jun 10, 2013 at 09:23:14PM +0000, 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 > > transactio

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

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

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 thei

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

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 receive

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

> and it covers the size of the transaction, why would it matter if it is not > a payment? See 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 wrote: > > On Saturday, June 01,

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

On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote: > scriptPubKey: OP_TRUE > > ... > Along with that change anyone-can-spend outputs should be make IsStandard() > so they will be relayed. Data does not belong in the blockchain. People running nodes have all implicitly agreed to store the b

Re: [Bitcoin-development] 0.8.2 branch

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 pos

Re: [Bitcoin-development] Modularizing Bitcoin

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 runn

Re: [Bitcoin-development] Modularizing Bitcoin

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] (no subject)

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 t

Re: [Bitcoin-development] Tentitive port for FreeBSD

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 us

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

On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote: > On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho > > wrote: > > On 22 May 2013 16:07, Jeff Garzik wrote: > >> On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho > >> > >> wrote: > >> > Some out of band algo/hash could work so long as th

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

Bitcoin currently uses raw hashes extensively as UUIDs; whether the payment protocol should be influence by that or not, I've not given thought to yet. Some alt coins may share a blockchain, or even merely the genesis block (two currently do; despite one of those being a scamcoin, I think the po

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

This sounds similar to the "bitcoin2" branch I created a while back - basically a "next"-like branch, but for hardforking changes that refused to run without the -testnet option. There's so much non-hardforking code that can be written/tested, at this point, that I think it was and maybe is prem

[Bitcoin-development] RFC: c32d encoding

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 and

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

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

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

On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote: > On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr wrote: > > bitcoind is nowhere in the implementation of the miner end of BIP 34. > > Again, not strictly true. > > bitcoind's 'getblocktemplate' RPC

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

On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote: > On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr wrote: > > On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: > >> On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr wrote: > >> > I don't think anyone is

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

On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote: > On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr 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 B

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

On Saturday, March 23, 2013 4:16:19 PM Jeff Garzik wrote: > Users should not be impacted. Some ancient miners will produce > newly-invalid blocks (v1), that will get ignored. The easy solution > is to mine using a recent bitcoind (0.7 or later). If you are a miner > and need help upgrading to v2

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

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] 0.8.1 plan

On Sunday, March 17, 2013 2:20:14 AM Frank F wrote: > Well, he did make the bitcoin.org/may15.html page already. It would be > crazy to change that now. OTOH, the page's recommended config isn't really too ideal. While the new lock limit should be good for up to 2 block deep reorgs, I doubt merch

Re: [Bitcoin-development] 0.8.1 ideas

On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote: > On Mar 13, 2013, at 8:18 PM, Cameron Garnham 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 uncontroversial to r

Re: [Bitcoin-development] 0.8.1 ideas

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

Re: [Bitcoin-development] 0.8.1 ideas

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

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

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

ion of patched 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&#

Re: [Bitcoin-development] 0.8.1 ideas

r 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

[Bitcoin-development] 0.8.1 ideas

Here's a simple proposal to start discussion from... BEFORE block 262144: - Never make a block that, combined with the previous 4 blocks, results in over 4500 transaction modifications. - Reject any block that includes more than 4500 transaction modifications on its own (slight soft-fork) - (the

  1   2   3   >