Re: [Bitcoin-development] Duplicate transactions vulnerability
I support BIP 30. I gave it a thought. The other ways of resolving this issue, all have various niggles. This is the best way. From: Pieter Wuille To: Zooko Wilcox-O'Hearn Cc: Bitcoin Dev Sent: Wednesday, February 29, 2012 4:47 PM Subject: Re: [Bitcoin-development] Duplicate transactions vulnerability On Tue, Feb 28, 2012 at 06:41:31PM -0700, Zooko Wilcox-O'Hearn wrote: > Could you spell out the attack explicitly? Presumably there aren't a > lot of people with the "malice energy" to perform the attack but not > to figure it out for themselves. I, however, have the "niceness > energy" to think about it for a few minutes but not to figure it out > for myself. If in your opinion it is realistically dangerous to post > it publicly, would you be so kind as to include me in the private > sharing of the explanation? It's not exactly a secret anymore, as the patch also references it. Russell O'Connor described the attack on his blog: http://r6.ca/blog/20120206T005236Z.html -- Pieter -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] JSON-RPC is BIP territory or not?
Hi, I got sent this BIP: https://en.bitcoin.it/wiki/BIP_DRAFT:_getmemorypool#JSON-RPC_Method:_getmemorypool What is your opinion on this? Is it BIP related? It is a implementation-specific non-bitcoin-protocol proposal. My understanding of BIPs is that they apply across bitcoin implementations and largely focus on the most generic use-cases (like the URIs) and the protocol. Things which affect all clients, and allow the system to function as a united whole. That BIPs especially focus on the protocol, and that something like this is outside the mandate of the BIP process. For instance, we could imagine a future scenario. Bitcoin-Qt is currently based off bitcoind's codebase. However wumpus built the client in mind with an abstraction layer to enable multiple backends (a good design). In our hypothetical situation, there are 3 different backend codebases using Bitcoin-Qt. I do not think a proposal to mandate a changing to Bitcoin-Qt's abstraction layer or a change in the UI placement would be appropriate BIP material. OTOH, many clients do need to make use of URIs and the BIP process is totally correct, as it standardises a behaviour which is needed for interoperability of the network and community. Thoughts?-- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 18 (or not?)
Hi, luke-jr withdrew BIP 16 and put forwards support for BIP 17. So now there's a consensus to move forwards. However he submitted BIP 18 to me today. From looking it over, I'm not even sure the idea is tenable nor see the purpose when we are adopting BIP 17. Personally I'd rather not see a high turnover in protocol design when something works (now that we have viable multisig transactions) even compromising on the position of a perfect design. https://en.bitcoin.it/wiki/BIP_0018 Usually for a BIP, someone submits it to me, I review to see whether the idea is technically sound (not making judgements on the validity), the community discusses the idea and I evaluate the support at the end to change the status. In general I try to accept all BIPs in the interests of fairness, rather than holding a vote or being the executioner. "Once the champion has asked the Bitcoin community as to whether an idea has any chance of acceptance, a draft BIP should be presented to bitcoin-development@lists.sourceforge.net. This gives the author a chance to flesh out the draft BIP to make properly formatted, of high quality, and to address initial concerns about the proposal. Following a discussion, the proposal should be sent to the Bitcoin-dev list with the draft BIP and the BIP editors . This draft must be written in BIP style as described below, else it will be sent back without further regard until proper formatting rules are followed." I don't think BIP 18 has followed this discussion before being accepted. Neither have many other BIPs as we're a small community, and so far we avoided this unneeded level of bureaucracy. However I think this is a good thing to do here. Should BIP 18 be accepted into the repo or not? "The BIP editor will not unreasonably deny a BIP. Reasons for denying BIP status include duplication of effort, being technically unsound, not providing proper motivation or addressing backwards compatibility, or not in keeping with the Bitcoin philosophy." "For a BIP to be accepted it must meet certain minimum criteria. It must be a clear and complete description of the proposed enhancement. The enhancement must represent a net improvement. The proposed implementation, if applicable, must be solid and must not complicate the protocol unduly." (quotes from BIP 1) -- Virtualization & Cloud Management Using Capacity Planning Cloud computing makes use of virtualization - but cloud computing also focuses on allowing computing to be delivered as a service. http://www.accelacomm.com/jaw/sfnl/114/51521223/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 16 changes (list inside)
Hi, Is this an accurate and precise summary of the changes needed for P2SH and BIP 16? == Block validation (starting with ProcessBlock) == * SigOpCount is now a LegacySigOpCount (CheckBlock) * Main body of AcceptBlock() and rest of ProcessBlock() is unchanged. * AddToBlockIndex() unchanged * Some nice efficient improvements to SetBestChain(), but not related to BIP 16 * ConnectBlock() has new SigOp calculation. * No important changes to FetchInputs()/ConnectInputs() == Script == * Solver has special case to check for TX_SCRIPTHASH. Returns hash of input eval script * Another Solver which a) returns signature of pubkey script or b) TX_SCRIPTHASH - finds redeem script in KeyStore and returns it. * ExtractAddress(es) * VerifyScript: ** After running input script (scriptSig), copy stack ** Evaluate script as normal ** if block date (fValidatePayToScriptHash) and output script (scriptPubKey) is P2SH: *** scriptSig must be only push operations *** evaluate last item of copied stack as a script using the copied stack as the stack * SigOpCount (used inside CBlock::ConnectBlock main loop) does scoring checksigs and multisigs. ** Newly added DecodeOP_N to normal SigOpCount == Address == * Set main hash160 data with a beginning byte (nVersion) of 0x05 -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Can I make a BIP 16 payment?
Hey, Just wondering why no-one has made one yet. Is there a reason why? I want to test it out. -- This SF email is sponsosred by: Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding request/reply id in messages
This is a bad idea. The bitcoin protocol is (mostly) stateless. Stateless protocols are more secure. From: Pieter Wuille To: Gavin Andresen Cc: bitcoin-development@lists.sourceforge.net Sent: Thursday, April 12, 2012 5:01 PM Subject: Re: [Bitcoin-development] Adding request/reply id in messages On Thu, Apr 12, 2012 at 11:41:05AM -0400, Gavin Andresen wrote: > On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt wrote: > > I would like to discuss the following bitcoin protocol improvement proposal: > > > > Adding request/reply id in all messages (in the message header, > > based on what was done for the "checksum" field) > > That seems like a perfectly reasonable protocol improvement to me. > Anybody else have an opinion? If there is a reasonable use for it, I have no objections. However: the bitcoin P2P protocol is not fully request-reply based, and trying to use it that may be be less intuitive than how it looks. For example, doing a second identical "getblocks" request will not result in more "inv" replies, as the client prevents retransmits. This is not a large problem, but maybe such an extension should also include an extra "denied" message, which is sent if the client is unwilling to answer (and may also be used to report transactions that are not accepted into the memory pool, for example). -- Pieter -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Adding request/reply id in messages
Jeff elaborated the problems very well, but I just want to add this: Your change is essentially relying (trusting) the server to track a piece of information (your state). Anytime you start depending on another node in some way, it is opening yourself up to be exploited. Nodes should be doing their owning state maintainance, not relying on external parties. I am very much against the change. As someone who has implemented the complete bitcoin protocol, I had no problems implementing the blockchain download. In fact, I dislike that nodes have to store the last inventory they sent as part of a getblocks in order to trigger the next round. It's be better if there was no state whatsoever. From: Jeff Garzik To: sirk...@gmail.com Cc: bitcoin-development@lists.sourceforge.net Sent: Thursday, April 12, 2012 6:12 PM Subject: Re: [Bitcoin-development] Adding request/reply id in messages On Wed, Apr 11, 2012 at 2:39 PM, Christian Bodt wrote: > Hi, > > I would like to discuss the following bitcoin protocol improvement proposal: > > Adding request/reply id in all messages (in the message header, > based on what was done for the "checksum" field) > > The original reason is that I found it very hard to implement robust > blockchain downloading as we are missing context information: > The download protocol relies on the other peer sending one (or more) "inv" > reponse(s) to "getblocks" and sending the "hashContinue". > But if the other peer doesn't send a response to getblock, send a partial > response to getblocks, mixes it with some unrelated blocks inventories > or doesn't send the "hashContinue" it is very hard to detect and handle > (e.g. ban the peer and switch to another). This could cause some DoS > attacks by misbehaving peers. If the peer is misbehaving, then disconnect. Your protocol change does not offer any clear benefits in this area, as these sorts of attacks/misbehaviors/bugs are still just as possible, and just as damaging (or not). Just disconnect the strange peer! > The problems are that 1/ we don't know how many "inv" messages to wait for > after "getblocks" and 2/ we don't know how to distinguish between result of > "getblocks" and spontaneous "inv" notifications. > The same is true for "addr" messages (it is both a notification and reply) > but this is less of a problem as a lack of response to getaddr > doesn't constitute a DoS. > > The idea would be to add a new "requestid" field in messages and define the > following: Stateless protocols have a lot of value. They are easiest to implement, and easier to prove correct. Existing clients like ArtForz' half-a-node, variants of which are deployed all over the place in bitcoin-land, rely on the stateless-ness to one degree or another. Stateful protocols, too, have their problems as well. One must add code to help remain "synchronized" between local and remote states, which your suggested change only hints at. NFSv4 and RPC have a long history of dealing with stateful-ness issues. Obviously bitcoin P2P is nowhere near as complex, but the history of NFS development offers several lessons applicable to your proposed change. Overall, IMO your listed reasons for needing this major change (stateless->stateful) do not really justify the change. Handling initial block download can be accomplished in a number of ways, and peer(s) may crash or return odd results. You must handle these cases properly, regardless of the presence of req/reply id's. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] AreInputsStandard() mistake
Hey, Only a small thing - I think the first check in that function should be an assert. There is a problem if that function is called a coinbase tx. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Trusted identities
look at the first line of the if statement
// Check for conflicts with in-memory transactions
CTransaction* ptxOld = NULL;
for (unsigned int i = 0; i < tx.vin.size(); i++)
{
COutPoint outpoint = tx.vin[i].prevout;
if (mapNextTx.count(outpoint))
{
// Disable replacement feature for now
return false;
// Allow replacing with a newer version of the same transaction
if (i != 0)
return false;
ptxOld = mapNextTx[outpoint].ptx;
if (ptxOld->IsFinal())
return false;
if (!tx.IsNewerThan(*ptxOld))
return false;
for (unsigned int i = 0; i < tx.vin.size(); i++)
{
COutPoint outpoint = tx.vin[i].prevout;
if (!mapNextTx.count(outpoint) || mapNextTx[outpoint].ptx !=
ptxOld)
return false;
}
break;
}
}
From: Peter Vessenes
To: Peter Todd
Cc: bitcoin-development@lists.sourceforge.net
Sent: Thursday, April 26, 2012 6:11 PM
Subject: Re: [Bitcoin-development] Trusted identities
These are interesting thoughts, karma for bitcoins essentially.
I would like CoinLab to publish a 'cost of subverting 1-n transactions with 90%
probability' metric soon, and I think it would help everyone to understand what
that number is.
When we started out, you probably needed to wait 5 blocks for $10 or $20 of
bitcoin value transfer.
Now, I'd happily accept a $1k transaction with 1 confirmation.
More difficulty shortens the safe time we can transact large volumes in, which
is good for the network.
I'm not sure of the current implementation of replacement transactions, can
anyone on the core team speak to this? Can I replace transactions, or is that
part of the spec unimplemented or deprecated right now?
Peter
On Thu, Apr 26, 2012 at 8:49 AM, Peter Todd wrote:
It recently occured to me that we can use the public nature of the block
>chain to create trusted identities, for a specific form of trust.
>
>Lets suppose Alice has some bitcoins held at bitcoin address A. She
>wants to establish trust in the "identity" associated with the ECC
>keypair associated with A, for instance for the purpose of having other
>users trust her not to attempt to double spend. Since the trust she
>seeks is financial in nature, she can do this by valuing the identity
>associated with A, by delibrately throwing away resources. A simple way
>to do this would of course be to transfer coins to a null address,
>provably incurring a cost to her.
>
>A more socially responsible way would be for her to create a series of
>transactions that happen to have large, and equal, transaction fees.
>Bitcoin makes the assumption that no one entity controls more than 50%
>of the network, so if she makes n of these transactions consecutively,
>each spending m BTC to transaction fees, there is a high probability
>that she has given up at least n/2 * m BTC of value. This of course is
>all public knowledge, recorded in the block chain. It also increases the
>transaction fees for miners, which will be very important for the
>network in the future.
>
>Now Bob can easily examine the block chain, and upon verifying Alice's
>trust purchase, can decide to accept a zero-confirmation transaction at
>face value. If Alice breaks that promise, he simply publishes her signed
>transaction proving that Alice is a fraudster, and future Bob's will
>distrust Alice's trusted identity, thus destroying the value needed to
>create it.
>
>In effect, we now have a distributed green address system.
>
>Now Alice could try to mount a double-spend attack on a whole bunch of
>people at once, hoping to have them all accept the transaction. However
>as it is the "just trust them" model works pretty well already.
>
>
>A good usecase for this idea, beyond the obvious fast payments
>application, is a distributed anonymizer. Alice can now publish her
>request to anonymize coins, and other trusted identities can make their
>bids. If Alice accepts a bid from Bob, she will want Bob to send her the
>anonymized coins *prior* to her transaction going through, thus breaking
>the temporal connection between the transactions. Now Alice can give Bob
>the signed payment transaction, and Bob can submit his payment
>transaction to the network first, knowing that Alice isn't going to try
>to rip him off. Bob can also have a trusted identity which signed the
>contract for the anonymizer transaction, and similarly if he rips Alice
>off, she can publish it for the world to see.
>
>A more subtle effect, is this makes sybil attacks more difficult. To
>pretend to be a thousand identities is going to now require 1,000 * n
>coins, and attempting to pull this attack off inherently strengthens the
>bitcoin network. Obviously we can apply this principle to other things
>like tor nodes as well.
>
>--
>http://petertodd.o
[Bitcoin-development] bitcoin.org luke-jr/multiclient branch
Hi, Can we pull this? It's been there for almost 20 days now. https://github.com/bitcoin/bitcoin.org/pull/32 My comment: "As a first step, this should probably be pulled right away and then any improvements can be made after. Lets get the ball rolling rather than debating the colour of the bike-shed! http://hackerspaces.org/wiki/The_Bikeshed_Anti-Pattern Although I agree with Mike Hearn - far better would be a grid of 4 columns and X rows. Each box has a linkable title, a picture and then 850 word blurb from the project. I mean where would libbitcoin fit in here? I'd want to say the design philosophy behind it and that there's Python bindings - a circular peg that doesn't fit in the square boxes of this table. Although whatever, that's not important. I'm just happy to see MultiBit, Electrum and Armory get exposure." Anyone that wants to see what it looks like can add this to their hosts file: 176.31.24.241 bitcoin.org Then navigate to http://bitcoin.org -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] new bitcoin.org clients page
Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
Are we looking at the same list? Because here is the order I added: Bitcoin-Qt, Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a refresh of your browser. Also about the descriptions: yeah I know. I think it's better to put this up first and then have everyone submit their own descriptions and screenshots. Otherwise it'll be a nightmare to coordinate until everything is perfect. I did message you on IRC today but maybe you were offline. I didn't copy paste the Armory description from the website because it really sounds too spammy like a sales pitch. Here I was trying to give an even handed balanced overview of all the clients. For each client I was trying to empaphise a 'theme'. Bitcoin-Qt is stability. Armory is advanced. Electrum is convenient. MultiBit is ease of use. ____ From: Alan Reiner To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Monday, April 30, 2012 7:23 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page Hey, looks good! I'm glad to see them sorted alphabetically :) A couple comments: I don't think the entries for "wallet security" and "backups" accurately describe Armory. Wallet Security should say "Encrypt/Offline" or something to to that effect -- after all, offline wallets are the holy grail feature of the Armory. And backups should say something like "One-time Printable" if it fits within the box. Otherwise, I really like the layout and design. Although despite the fact I enjoy being first on the list, I think Bitcoin-Qt should still go first. It is the "reference" client, and I think it's relevant that it is the "de-facto" client for the majority of users, and the one with the most quality control and stability. -Alan On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki wrote: Check it :) https://github.com/bitcoin/bitcoin.org/pull/34 > >-- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP to improve the availability of blocks
This is optimisation where it isn't needed. Bandwidth is not the bottleneck of the Bitcoin system. It is the immense time needed to validate the blockchain. And clients should never send blocks first. They always send an inv packet, then you request the block. It is a disruptive change and brings little. We don't need to optimise every aspect of Bitcoin :) Just focus on the big bits that matter, while keeping everything working with minimal changes. For instance say we did this and to maintain backwards compatible, we introduced a new message called "hash+block". Now there are 2 code branches that must be maintained - urgh. From: Wladimir To: Rebroad (sourceforge) Cc: bitcoin-development@lists.sourceforge.net Sent: Monday, April 30, 2012 7:26 PM Subject: Re: [Bitcoin-development] BIP to improve the availability of blocks On Mon, Apr 30, 2012 at 6:40 PM, Rebroad (sourceforge) wrote: >My proposal is that in addition to the size (which is advertised in >the header), the hash is also advertised in the header (of a block). >This would help nodes to determine whether they wanted to reject the >download. (e.g. if it already had a block matching that hash). This of >course wouldn't prevent a rogue node from sending an incorrect hash, >but this would aid in saving bandwidth amongst behaving nodes. > I suppose it would make sense for clients to be able to reject blocks that they already have, if that's not currently possible. The other part of the proposal is to allow nodes to request upload and >download blocks that have already been partially downloaded. > >This could be done by modifying the existing methods of upload, >download, or by adding a new method, perhaps even using HTTP/HTTPS or >something similar. This would also help nodes to obtain the blockchain >who have restrictive ISPs, especially if they are being served on port >80 or 443. This could perhaps also allow web caches to keep caches of >the blockchain, thereby making it also more available also. > You don't need a BIP if you want to somehow fetch the (initial) block chain outside the bitcoin protocol. You could download it from some http server or even pass it along on an USB stick. Then with a simple client change you can import it: https://github.com/bitcoin/bitcoin/pull/883 . Currently, without this functionality, nodes with restrictive (or >slow) internet have some options, such as going via a tor proxy, but >due to the latency, the problem with multiple receptions of the same >block still occur. > If you're behind such a slow internet connection, and concerned about every bit of bandwidth, it is better to run a lightweight node. For example, Electrum. Even if you could reduce the wasted bandwidth a bit by puzzling around with partial blocks, the download will still be substantial (and that's going to get worse before it gets better). Wladimir -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in. On Yahoo mail (which I use for spam/mailing lists), to do reply all involves clicking a tab, scrolling down and clicking Reply All. Normally I instead go through the steps of reply, delete To, re-enter bitco... select drop down, click send. Anyone know how to make reply all the default in mutt? And how can I exclude it from re-including my own email when I do a group reply so I don't get the same email again. - Original Message - From: Jeff Garzik To: grarpamp Cc: bitcoin-development@lists.sourceforge.net Sent: Wednesday, May 2, 2012 7:29 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page On Wed, May 2, 2012 at 12:58 PM, grarpamp wrote: >> Try "Reply to All" > > That puts the sender in 'to' and list in 'cc', > which dupes to the sender and eventually > blows out the to and cc lines as everyone > chimes in and doesn't trim. 'reply to' solves > most of that. assuming the list sw can do it. "Reply-To" Munging Considered Harmful http://www.unicom.com/pw/reply-to-harmful.html -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] new bitcoin.org clients page
This discussion about ordering is absolutely retarded. Once the list fills up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt first and the others ordered however. That was nobody can try to game the system (it remains unexploitable). If there are no objections, then I am going to merge this branch. The forum thread is divulging into a mess all over the place, and this conversation can go on forever discussing the silly fine details: http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem: You suggest creating something new for your hackerspace, like a bikeshed. But now all anyone will discuss is its colour. No bikeshed will be built. Armory & MultiBit, are you OK with that description? I will check with ThomasV about Electrum. From: Gary Rowe To: "bitcoin-development@lists.sourceforge.net" Sent: Wednesday, May 2, 2012 8:34 PM Subject: Re: [Bitcoin-development] new bitcoin.org clients page How about keeping it simple? Bitcoin-Qt * Requires the entire blockchain * Standalone client * Designed for continuous operation * Available for Windows, Mac, Linux with installer * Developed in C * Website: https://bitcoin.org MultiBit * Requires a reduced blockchain * Standalone client * Designed for occasional use * Available for Windows, Mac, Linux with installer * Developed in Java * Website: http://multibit.org Armory * Requires the entire blockchain * Dependent client of Bitcoin-Qt * Designed for occasional use * Available for Windows (64-bit only), Mac, Linux (self-build) * Developed in Python * Website: http://bitcoinarmory.com/ Electrum * Requires no blockchain * Dependent client of Bitcoin-Qt (on server) * Designed for occasional use * Available for Windows, Linux (self-build) * Developed in Python * Website: http://ecdsa.org/electrum/ Bitcoin Wallet (Android client) * Requires a reduced blockchain * Standalone client * Designed for occasional use on mobile * Available for Android only * Developed in Java * Website: https://play.google.com/store/apps/details?id=de.schildbach.wallet&hl=en On 2 May 2012 20:25, Amir Taaki wrote: This is like the most annoying thing about email. Often with group emails, we'll be having a conversation then someone will click reply instead of group reply and the convo will go on for a while. Eventually I'll realise the persons are missing and add them back in. > >On Yahoo mail (which I use for spam/mailing lists), to do reply all involves >clicking a tab, scrolling down and clicking Reply All. Normally I instead go >through the steps of reply, delete To, re-enter bitco... select drop down, >click send. > >Anyone know how to make reply all the default in mutt? And how can I exclude >it from re-including my own email when I do a group reply so I don't get the >same email again. > > > > >- Original Message - >From: Jeff Garzik >To: grarpamp >Cc: bitcoin-development@lists.sourceforge.net >Sent: Wednesday, May 2, 2012 7:29 PM >Subject: Re: [Bitcoin-development] new bitcoin.org clients page > > >On Wed, May 2, 2012 at 12:58 PM, grarpamp wrote: >>> Try "Reply to All" >> >> That puts the sender in 'to' and list in 'cc', >> which dupes to the sender and eventually >> blows out the to and cc lines as everyone >> chimes in and doesn't trim. 'reply to' solves >> most of that. assuming the list sw can do it. > >"Reply-To" Munging Considered Harmful >http://www.unicom.com/pw/reply-to-harmful.html > > > >-- >Jeff Garzik >exMULTI, Inc. >jgar...@exmulti.com > >-- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > > >-- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://
[Bitcoin-development] Bitcoin intro and talks in Berlin (11th May at 20:00)
c-base is holding a day on p2p technologies on the 11th. From 20:00 will be the section on Bitcoin. If you want to do a talk, then email me (gen...@riseup.net) and I’ll add you to the schedule. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 33 - Stratized Nodes
Hi, Please check out my proposal, https://en.bitcoin.it/wiki/BIP_0033 I want to use the existing Bitcoin protocol to provide this functionality in order to maintain compatibility. This proposal does not affect current Bitcoin clients, but allows the parallel system to operate alongside and sometimes intersect with the main Bitcoin network in a positive way. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 33 - Stratized Nodes
A bloom filter seems like an interesting idea. However this proposal is concerned mainly with the initialisation stage, whereas this bloom filter is for pushed blocks. This proposal still updates new transactions and blocks in the same way, and it's not inconceivable to later use a bloom filter to make that part more efficient (although it's questionable if pushing this server side would be a good idea as it would now need to track an additional client state). From: Mike Hearn To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Wednesday, May 16, 2012 5:46 PM Subject: Re: [Bitcoin-development] BIP 33 - Stratized Nodes Thanks for getting this started. With regards to the specific proposal, I don't believe it's the best option and still plan to eventually implement the original design outlined more than a year ago in this thread: https://bitcointalk.org/index.php?topic=7972.msg116285#msg116285 Namely that you use a new protocol command to set a Bloom filter on a connection. Only transactions matching that filter will appear in relayed inventory. Blocks that are requested will arrive as a header plus transaction/merkle branch pairs. Clients are expected to maintain and track the block chain as per usual, but instead of downloading the whole chain and then dropping the irrelevant transactions, that filtering is done server side. By strengthening or weakening the Bloom filters you can choose your preferred point on the privacy/bandwidth-usage spectrum. It is a fairly simple change to the Satoshi and BitcoinJ codebases but still allows clients to gain confidence in their balance by examining the chain, and this is true even in the presence of a hijacked internet connection (you can't trust pending transactions that way, but you can still trust confirmed transactions). The filters would be applied to each data block in each script rather than having a specific knowledge of addresses. In this way you can select for things like multisig outputs or outputs which don't use addresses / pubkeys to authenticate. I could write a BIP for this alternative protocol if somebody else wants to implement it. I was going to wait until I had time to do both BIP and implementation, but I think some simple optimizations to BitcoinJ can keep its performance good enough for the short term. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 33 - Stratized Nodes
> 1) This is cool and useful (but see 3) > 2) This is significantly less secure than validating an entire blockchain; > it's certainly worth working out some use cases here in more detail than just > a sample conversation. More on this below > 3) What about discovery? Will a client now have the chance to look for > NODE_STRATIZED clients on IRC? How do you envision a stratized server decides > which transactions to relay/store? Or is it just a caching layer in front of > a high quality blockchain service? If it is just a caching service, the > question of cache hits / misses is an interesting one as well. Stratized nodes do discovery as normal. Service nodes are explicitly chosen like IRC servers are for IRC clients. > 4) What are the economic motivations to run a stratized server? Other than > cheating people of course. None. Same as BitTorrent super-nodes, Tor relays or email servers. People don't need economic motivation for everything. > 5) Seems like a 'send me everything for this source address' is going to save > a lot of roundtrip conversations for what I imagine the most common request > will be. That's a bad idea. I prefer to keep each request minimal to prevent resource starvation and simplify the protocol (while shifting the onus onto the client). Also the history can be resolved with multiple services while the data is being downloaded and sorted. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fw: Punishing empty blocks?
That's a cool idea. Very meta. From: Peter Vessenes To: Stefan Thomas Cc: bitcoin-development@lists.sourceforge.net Sent: Monday, May 28, 2012 4:54 PM Subject: Re: [Bitcoin-development] Punishing empty blocks? One of the issues here though is that it would be nice if miners published their own tx rules -- it might be hard to impute them from data. I had started a thread about this on bitcoin.org some time ago, and I don't recall what the general outcome was. I had imagined an open service whereby a miner could publish a short string in their conbase tying to the service and the service would have different metadata, including the miner's transaction guarantees. We offered to host this before, and would still be willing to host such a service. Peter On Sat, May 26, 2012 at 7:52 AM, Stefan Thomas wrote: Zooko is spot on - slower confirmations will give people a reason to set >higher fees. As soon as fees reach a level where they matter, even >botnet operators will be looking into ways of including transactions for >some extra profit. > >In the meantime slightly slower confirmations aren't a problem. Consider >that even if it takes four blocks to get your transaction included >instead of one, once it is included, you still benefit from every new >block in terms of security. So if you're looking for six confirmations >for example, even a three block delay will only be a 50% delay for you. >And of course there are techniques for instant transactions which >continue to be refined and improved. > >As for the proposed solutions: Punishing 1-tx blocks is complete and >utter nonsense. It's trivial to include a bogus second transaction. > >Any additional challenges towards miners like hashes of the previous >block are at best useless. If I was running a botnet, I'd just grab that >hash from a website (pretty good chance Blockchain.info will have it :P) >or mining pool or wherever and keep going undeterred. At worst they may >affect scalability one day. You might imagine a peer-to-peer network of >miners who for cost reasons don't download all blocks anymore, but >verify only a percentage of them at random. They might then exchange >messages about invalid blocks including a proof (invalid tx, merkle >branch) why the block is invalid. This is just one idea, the point is >that assumptions about what a legitimate miner looks like may not always >hold in the future. > >Finally, there is an ethical aspect as well. If a miner wishes not to >include my transaction that is his choice. He has no more an obligation >to sell his service to me than I have to buy it from him. If I really, >really want him to include my transaction I will have to offer to pay more. > >If we as developers think that confirmations are too slow or that more >blocks should include transactions, then the right measures would be: > >- Educating users about the relationship between confirmation speed and fees >- Raising the default transaction fee > >Every market has a supply curve, so it is economically to be expected >that there will be some miners who don't include transactions, simply >because they are at that end of the supply curve where it is not worth >it for them to sell their service. All markets must have a certain >tension - there must be miners who don't include transactions for there >to be users who want their transactions included more quickly. In other >words there must be somebody not confirming if confirmations are to have >value. If you interfere with that all you'll accomplish is keep >transaction fees below market level, which will make the transition from >inflation-financed hashing to transaction-financed hashing more painful >and disruptive. > >Cheers, > >Stefan > > >-- >Live Security Virtual Conference >Exclusive live event will cover all the ways today's security and >threat landscape has changed and how IT managers can respond. Discussions >will include endpoint security, mobile security and the latest in malware >threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Peter J. Vessenes CEO, CoinLab M: 206.595.9839 Skype: vessenes Google+ -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo
Re: [Bitcoin-development] Near-term scalability
Forcing users to switch addresses per received payment to work around a bad fee system would be a braindead decision. You might love software and playing with web plugins, but not everyone does. Artists like Rap News can right now simply throw up an address and begin accepting donations. That's a hugely powerful and impactful selling point for Bitcoin. I don't really see these problems as a concern. Stefan made an excellent post which touched on this, in that miners have an incentive to keep block sizes low so that their blocks propagate. The real problem here is not about block propagation but the user experience. The way I see it, Bitcoin is becoming more specialised over time and part of that process is abstraction. In the past we all used the Satoshi client for mining, merchant functions, validating blocks and personal uses. These are rapidly diverging, and managing the blockchain is not something that user clients should be doing. Mike is right when he says the network only needs a few thousand nodes to function fairly. I am not worried about Bitcoin becoming corrupted because of it being a network "by bankers for bankers" because unlike the conventional finance industry, there are no artificial barriers to entry beyond the base cost. This network would always be competitive and strictly operate based on market dynamics. Case in point: http://en.wikipedia.org/wiki/Coase_theorem With strict property rights and zero (or low) transaction costs, the allocation of a system does not matter. The system will make efficient use of its resources. I don't see why a cabal would try to corrupt Bitcoin at expense to themselves when a new competitor can enter the market and undercut them. It's why we expect the ROI on mining to be 0 or negative. I figured out that if you trust data from a blockchain service and only accept data with multiple confirms from each connected service, then you can trivially calculate the probability of being fed corrupt data (assuming a fixed chance per server). In this way, the model is a fault tolerant byzantine system. The chance of being manipulated falls expontentially as you add more servers. And these services can be made highly scalable if you see my BIP 33. https://en.bitcoin.it/wiki/BIP_0033 From: Mike Koss To: Stefan Thomas Cc: bitcoin-development@lists.sourceforge.net Sent: Friday, June 15, 2012 7:37 PM Subject: Re: [Bitcoin-development] Near-term scalability Grouping mempool transactions based on fees of the group seems an unnecessary complexity; it makes it harder to predict if an isolated transaction has enough "juice" to be included in the next Block. Given your point about economic actors adapting to conditions, would it not be simpler to use a individual "fee per byte" priority algorithm and let transaction generators distribute their fees accordingly (and more predictably)? This simpler algorithm will prune arbitrary transactions sub-optimally, but has the benefit of being more understandable and predictable from the point of view of transaction generators. On Fri, Jun 15, 2012 at 9:56 AM, Stefan Thomas wrote: Thanks Mike for the writeup - I'm very sad to have missed the discussion >on IRC since fee economics are probably my favorite topic, but I'll try >to contribute to the email discussion instead. > > >> (4) Making the block size limit float is better than picking a new >> arbitrary threshold. > >Fees are a product of both real and artificial limits to transaction >validation. > >The artificial limits like the block size limit are essentially putting >a floor on prices by limiting supply beyond what it would otherwise be. >E.g. the network could confirm more transactions theoretically, but the >block size limit prevents it. > >The real limits are the bandwidth, computing and memory resources of >participating nodes. For the sake of argument suppose a 1 TB block was >released into the network right now and we'll also assume there was no >block size limit of any kind. Many nodes would likely not be able to >successfully download this block in under 10-30 minutes, so there is a >very good chance that other miners will have generated two blocks before >this block makes its way to them. > >What does this mean? The miner generating a 1 TB block knows this would >happen. So in terms of economic self interest he will generate the >largest possible block that he is still confident that other miners will >accept and process. A miner who receives a block will also consider >whether to build on it based on whether they think other miners will be >able to download it. In other words, if I receive a large block I may >decide not to mine on it, because I believe that the majority of mining >power will not mine on it - because it is either too large for them to >download or because their rules against large blocks reject it. > >It's important to understand that in practice economic actors tend to >p
Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients
Why though? The bottleneck is not network traffic but disk space usage/blockchain validation time. - Original Message - From: Mike Hearn To: Jeff Garzik Cc: Bitcoin Development Sent: Friday, June 15, 2012 3:43 PM Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV clients > Yes, the format is something that must be hashed out (no pun > intended). Need input from potential users about what information > they might need. Matts point that a branch-per-transaction may duplicate data is well made, that said, I suspect a format that tries to fix this would be much more complicated. How about see this project as a three part change? First step - add the mempool command and make nodes sync up their mempools on startup. Second step - if protocol version >= X, the "block" message consists of a header + num transactions + vector instead of the full transactions themselves. On receiving such a block, we go look to see which transactions we're missing from the mempool and request them with getdata. Each time we receive a tx message we check to see if it was one we were missing from a block. Once all transactions in the block message are in memory, we go ahead and assemble the block, then verify as per normal. This should speed up block propagation. Miners have an incentive to upgrade because it should reduce wasted work. Third step - new message, getmerkletx takes a vector and returns a merkletx message: "merkle branch missing the root + transaction data itself" for each requested transaction. The filtering commands are added, so the block message now only lists transaction hashes that match the filter which can then be requested with getmerkletx. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Near-term scalability
> less expensive. This is no more "real" or less "artificial" then an > imposed licensing fee or the like and it is not subject to market > forces. Sure, the market is not always efficient nor desirable. This seems more like a social question though about choice and information. I do strongly feel that users should have more control over their technology, and a say in how Bitcoin operates. It is our job to present the choices and inform them to make good decisions. If we think how to implement this with a social component of the users operating the network rather than hard and fast rules, I think that's the preferrable way. Part of the problem is that Satoshi didn't totally anticipate the growth of the network. The block reward (the subsidy) is too high, which is why transactions can afford to be so cheap. What would happen if blocks required a cumulative fee of XN BTC for N transactions before being accepted? - Original Message - From: Gregory Maxwell To: Amir Taaki Cc: Sent: Friday, June 15, 2012 8:43 PM Subject: Re: [Bitcoin-development] Near-term scalability On Fri, Jun 15, 2012 at 2:38 PM, Amir Taaki wrote: > Forcing users to switch addresses per received payment to work around a bad > fee system would be a braindead decision. You might love software and playing > with web plugins, but not everyone does. Artists like Rap News can right now > simply throw up an address and begin accepting donations. That's a hugely > powerful and impactful selling point for Bitcoin. And that use case does not need fast confirmations! This is making the point. >there are no artificial barriers to entry beyond the base cost. This network >would always be competitive and strictly operate based on market dynamics. The users of bitcoin can collectively choose how expensive operating a full node is by accepting validation rules that allow it to be more or less expensive. This is no more "real" or less "artificial" then an imposed licensing fee or the like and it is not subject to market forces. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
Introspection/command discovery is nice, but I would prefer it to be immediately done in the first version exchange so no assumptions as to how a network is operating need to be made. I like the idea of a flat list of commands. It might make sense to have "meta"-commands that alias to groups of commands. i.e "original" for the current core subset up to (and including) "pong". The aliases could exist in a text definition file which is held on github or bitcoin.org/ - Original Message - From: Jeff Garzik To: Bitcoin Development Cc: Sent: Saturday, June 16, 2012 2:13 AM Subject: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist Outside of major features advertised network-wide in nService bits, P2P protocol lacks a good method of enumerating minor features or extensions. The version number increment is coarse-grained, and is not self-documenting. A simple extension which lists supported commands is added, as demonstrated in this pull request: https://github.com/bitcoin/bitcoin/pull/1471 Another option is for verack to return this information at login, eliminating the need for a separate command/response. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] SatoshiDice and Near-term scalability
Did anyone try sending them an email asking them to stop or offering help to fix their site? What did they say? I'm sure they would try to be accomodating. - Original Message - From: Jonathan Warren To: bitcoin-development@lists.sourceforge.net Cc: Sent: Saturday, June 16, 2012 4:35 AM Subject: Re: [Bitcoin-development] SatoshiDice and Near-term scalability Yes, I measure mainnet confirmation times on a regular basis. http://bitcoinstats.org/post/tx-confirmation-times-June2012.png Before fairly recently, fee-paying transactions never took anywhere close to this long to be confirmed. Jonathan Warren (Bitcointalk: Atheros) -Original Message- From: Jeff Garzik [mailto:jgar...@exmulti.com] Sent: Friday, June 15, 2012 1:17 PM To: bitcoin-development@lists.sourceforge.net Subject: [Bitcoin-development] SatoshiDice and Near-term scalability Hard-fork requires a very high level of community buy-in, because it shuts out older clients who will simply refuse to consider >1MB blocks valid. Anything approaching that level of change would need some good, hard data indicating that SatoshiDice was shutting out the majority of other traffic. Does anyone measure mainnet "normal tx" confirmation times on a regular basis? Any other hard data? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
> I'm just afraid that the currently simple P2P protocol will turn into a zoo of complicated (and potentially buggy/insecure) interactions. This is my biggest fear too. I would rather be extremely conservative in making any changes to the protocol unless absolutely needed. That includes the bloom filters which take away the fact that Bitcoin is stateless. I was discussing this with another developer who mentioned something interesting: that always in the lifecycle of system's development, you see increasing complexity during its initial lifecycle as the field is being explored. At some later point, the technology matures and becomes standardised. At that point enough is known that the system snaps together and the cruft can be cut away to reduce the system down to core principles. It's an interesting viewpoint to consider. I do however advise erring on the side of caution. Maybe there needs to a minimum schedule time before a new extension can be added to the protocol (except security fixes). If we're not careful, the protocol will become enormously huge and kludgy. However maybe as that developer pointed out, trying to stall the inevitable is slowing the long-term evolution of Bitcoin down. From: Wladimir To: Andy Parkins Cc: bitcoin-development@lists.sourceforge.net Sent: Saturday, June 16, 2012 10:42 AM Subject: Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist On Sat, Jun 16, 2012 at 10:16 AM, Andy Parkins wrote: >It's less of a problem in a (nearly) stateless protocol like Bitcoin. > It's currently (nearly) stateless, however it would be short-sighted to think it will stay that way. State is being introduced as we speak; for example, connection-specific filters. I like the idea of a capabilities command; as time goes on and the ecosystem >of thin/spv/semi-thin/headers-only/blocks-on-demand/reverse-search- >blockchain/memory-pool-query clients becomes more varied, it's going to be >more an more important. The particular example that occurs is thin clients >connecting to the network are going to want to ensure they are connected to >at least one non-thin client. > Which is a perfectly reasonable requirement. However, one could simply standardize what a 'thin client' and what a 'thick client' does and offers (at a certain version level), without having to explicitly enumerate everything over the protocol. This also makes it easier to deprecate (lack of) certain features later on. You can simply drop support for protocol versions before a certain number (which has happened before). With the extension system this is much harder, which likely means you keep certain workarounds forever. Letting the node know of each others capabilities at connection time helps somewhat. It'd allow refusing clients that do not implement a certain feature. Then again, to me it's unclear what this wins compared to incremental protocol versions with clear requirements. I'm just afraid that the currently simple P2P protocol will turn into a zoo of complicated (and potentially buggy/insecure) interactions. So maybe a capability system is a good idea but then the granularity should be large, not command-level. The interaction between protocol versions and capabilities needs to be defined as well. Does offering "getdata" at protocol version 10 mean the same as offering it at protocol version 11"? Probably not guaranteed. The arguments might have changed. So it's not entirely self-documenting either. Wladimir -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist
As the only person to have created and maintaining a full reimplementation of the Bitcoin protocol/standard, I do think Bitcoin is filled with arbitrary endianness and magic numbers. However it is a tiny and simple protocol. The big problem is not implementing the Bitcoin protocol, but the fact that once you have created a codebase, you want to perfect and fine-tune the design. During the meantime, the Bitcoin protocol is being changed. Change to the Bitcoin protocol is far more damaging to people that want to implement the protocol than any issues with the current protocol. That's not to say, I disagree with changes to the protocol. I think changes should be a lot more conservative and have a longer time frame than they do currently. Usually changes suddenly get added to the Satoshi client and I notice them in the commit log or announcements. Then it's like "oh I have to add this" and I spend a week working to implement the change without proper consideration or reflection which ends up with me having to compromise on design choices. That is to remain compatible with the protocol. However it is not my intent to slow down progress so I usually try to hedge against that kind of feeling towards conservatism. - Original Message - From: Jeff Garzik To: Wladimir Cc: bitcoin-development@lists.sourceforge.net Sent: Sunday, June 17, 2012 5:19 PM Subject: Re: [Bitcoin-development] Proposed new P2P command and response: getcmds, cmdlist On Sat, Jun 16, 2012 at 4:42 AM, Wladimir wrote: > Which is a perfectly reasonable requirement. However, one could simply > standardize what a 'thin client' and what a 'thick client' does and offers > (at a certain version level), without having to explicitly enumerate > everything over the protocol. > > This also makes it easier to deprecate (lack of) certain features later on. > You can simply drop support for protocol versions before a certain number > (which has happened before). With the extension system this is much harder, > which likely means you keep certain workarounds forever. > > Letting the node know of each others capabilities at connection time helps > somewhat. It'd allow refusing clients that do not implement a certain > feature. Then again, to me it's unclear what this wins compared to > incremental protocol versions with clear requirements. > > I'm just afraid that the currently simple P2P protocol will turn into a zoo > of complicated (and potentially buggy/insecure) interactions. What is missing here is some perspective on the current situation. It is -very- easy to make a protocol change and bump PROTOCOL_VERSION in the Satoshi client. But for anyone maintaining a non-Satoshi codebase, the P2P protocol is already filled with all sorts of magic numbers, arbitrarily versioned binary data structures.. already an unfriendly zoo of complicated and potentially buggy interactions. There is scant, incomplete documentation on the wiki -- the Satoshi source code is really the only true reference. I see these problems personally, trying to keep ArtForz' half-a-node running on mainnet (distributed as 'blkmond' with pushpool). In an era of HTTP and JSON, NFS and iSCSI, bitcoin's P2P protocol is woefully backwards, fragile, limited and inflexible when it comes to parameter/extension exchange and negotiation. Even iSCSI, that which is implemented on hard drive firmware, has the ability to exchange key=value parameters between local and remote sides of the RPC connection. Calling the current P2P protocol "simple" belies all the implementation details you absolutely -must- get right, to run on mainnet today. Satoshi client devs almost never see the fragility and complexity inherent in the current legacy codebase, built up over time. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Berlin Bitcoin Hackathon
This is happening in Berlin if anyone is around: http://bitcoin-hackathon.com/ I am happy to host if space is needed. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase
It would be nice if Bitcoin was engineered this way from the start. The amount of workarounds, special cases and code bloat to deal with the fact that txs are non-unique was a massive headache for me. From: Mark Friedenbach To: Jeff Garzik Cc: Bitcoin Development Sent: Friday, July 6, 2012 6:56 PM Subject: Re: [Bitcoin-development] BIP 34: Block v2, Height in Coinbase On Fri, Jul 6, 2012 at 9:49 AM, Jeff Garzik wrote: On Fri, Jul 6, 2012 at 12:45 PM, Peter Vessenes wrote: >> The proposal is simple, and it's a small change for miners, I imagine. >> >> My question is: why? >> >> I worry about stuffing too many requirements on the coinbase. I suppose >> the coinbase is easily extendible if we run out of bytes, but I think I'd >> like to see some more discussion / good / bad type cases for making this >> change. What do we get over just the prev_hash by doing this? > >With the existing setup (sans height in coinbase), you might not have >unique transactions, with all that entails. > But those issues are solvable through other, non-backwards incompatible means. For example, mandate that a refers to the first such pair that is not already spent. No? Mark -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Wallet for Android
Hey, I just saw this added to the clients page. One of the conditions we set for that page was that all the clients must have the entire sourcecode available for review, and users should be able to run it from the sourcecode. Is the sourcecode for this client available for review? I couldn't find it. Otherwise, we should make a separate section for non-opensource clients. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Wallet for Android
OK thanks. I just went and made those sections then saw your posts. Anyway we have a section for proprietary clients now. Please tell me if anything looks disagreeable, http://bitcoin.org/clients.html One thing I'm going to do is randomise the positioning order within sections upon refresh. - Original Message - From: "m...@henricson.se" To: bitcoin-development@lists.sourceforge.net Cc: Sent: Monday, July 9, 2012 11:19 AM Subject: Re: [Bitcoin-development] Bitcoin Wallet for Android Sources are available here: http://code.google.com/p/bitcoin-wallet/ Mats Quoting Amir Taaki : > Hey, > > I just saw this added to the clients page. One of the conditions we > set for that page was that all the clients must have the entire > sourcecode available for review, and users should be able to run it > from the sourcecode. Is the sourcecode for this client available for > review? I couldn't find it. > > Otherwise, we should make a separate section for non-opensource clients. > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Random order for clients page
Took me a while, but finally got it working. Entries on the clients page are randomly ordered when the page is generated. https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 We should regenerate the page every 2 days. This gives fair exposure to all the clients listed. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Random order for clients page
JS randomisation is bad. People shouldn't need JS to view a webpage. Only you have a problem with this page. I don't see why Bitcoin-Qt needs to be first either when it dominates the front page. It is perfectly fine as it is. You are not a developer of any alternative clients, and this is a webpage for Bitcoin clients. I have made a change to remove a source of disputes, and make the process more fair and equal. Your suggestion to remove the clients page is your bias towards thinking that there should be only one Bitcoin client that everyone uses (the one which you contribute towards). If you want to suggest removing the clients page, then fine, lets also remove all reference to Bitcoin-Qt from the front-page and turn it into a http://bittorrent.org/ style website. Fact is that the other clients are rapidly becoming stable and mature, and the ecosystem is diversifying. The argument that the other clients were not up to scratch held maybe a few months ago, but not now. - Original Message - From: Gregory Maxwell To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Monday, July 9, 2012 5:04 PM Subject: Re: [Bitcoin-development] Random order for clients page On Mon, Jul 9, 2012 at 11:54 AM, Amir Taaki wrote: > Took me a while, but finally got it working. > Entries on the clients page are randomly ordered when the page is generated. > https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 > We should regenerate the page every 2 days. This gives fair exposure to all > the clients listed. If you had authored this as a pull request rather than making the change unilaterally I would have recommended leaving it so the reference client was always first. I also would have suggested that it use JS randomization instead of jekyll in order to get more even coverage, though I think thats a more minor point. Some people were concerned when this page was created that it would just be a source of useless disputes. I think its becoming clear that this is the case. I think the cost of dealing with this page is starting to exceed the benefit it provides and we should probably consider removing it. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Random order for clients page
This page really does matter to alternative clients. If you measure the click through statistics, then they are a significant portion of the traffic. By removing this page, you are directly stunting Bitcoin's growth. The only thing that's changed between now and this morning is: - Addition of Bitcoin Wallet for Android - Randomisation of entries I actually got permission from everyone involved before making the page.If you want to remove the page, then we should see a vote by: - laanwj - gavin - sipa - jgarzik - BlueMatt - Diapolo - luke-jr - you - jim from multibit - gary rowe - ThomasV - me - etotheipi - Andreas Schildbach - justmoon - Mike Hearn You're proposing to remove the page. You know, and I know and I know that you know that nobody visits the Wiki. Your proposal is not "move to Wiki" really but remove from bitcoin.org. Keep bitcoin.org for Bitcoin-Qt only which is against the stated goals of the rest of your team members (gavin, sipa, jgarzik). Have you tried the new clients? I've tried all 4, and they are all well written. Try the new version of Electrum, https://gitorious.org/electrum/electrum - it's more featureful and secure than Bitcoin-Qt what with deterministic wallets, brain-wallets, prioritising addresses, frozen addresses, offline transactions - none of which Bitcoin-Qt has. MultiBit is also very good with QR integration and the ability for merchants to quickly set themselves up. It's full of guiding help text, and has this paradigm to allow people to work with keys. Bitcoin Wallet for Android has one of the best bitcoin UIs I've seen and is extremely well thought out in how the user navigates through the software. The Bitcoin network could function perfectly fine with Electrum nodes and miners. You would still have miners and we wouldn't have the problem now with huge blocks because miners would be economically incentivised to keep blocks small. But that's another discussion. Technically speaking, the randomisation is fine now. It achieves its intended effect, as the page is regenerated daily. This does not need to be a source of arguing. I see no problem with having this page be a neutral overview of the main clients (as we all agreed together in the beginning): - Source must be public, and users must be able to run from source. - Description should be non-spammy and neutral sounding. Cover the negative aspects. Randomisation of the order simply makes that fairer. Alphabetical is not a good option (as others have suggested) because it can be gamed. There is absolutely no reason to remove this page unless you think bitcoin.org is only for Bitcoin-Qt which is against the wishes of gavin, sipa, jgarzik, and the long-term stated goal of bitcoin.org as a neutral resource for the community. - Original Message - From: Gregory Maxwell To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Monday, July 9, 2012 6:46 PM Subject: Re: [Bitcoin-development] Random order for clients page On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki wrote: > JS randomisation is bad. People shouldn't need JS to view a webpage. JS randomization doesn't imply needing JS to view the page. It implies needing JS to see it in random order. You could also combine it with the server-side randomization if you care about non-js being non random, though I don't think it matters. As others have pointed out I don't generally think the randomization is good in principle, but if its done it should at least achieve its goals. > Only you have a problem with this page. I don't see why Bitcoin-Qt needs to > be first either when it dominates the front page. It is perfectly fine as it > is. I'll let other people speak for themselves, but I did consult others before reverting your last batch of changes. More generally, we have pull requests in order to get some peer review of changes. Everyone should use them except for changes which are urgent or trivially safe. (Presumably everyone with access knows how to tell if their changes are likely to be risky or controversial) > You are not a developer of any alternative clients, and this is a webpage for > Bitcoin clients. I have made a change to remove a source of disputes, and > make the process more fair and equal. Your suggestion to remove the clients > page is your bias towards thinking that there should be only one Bitcoin > client that everyone uses (the one which you contribute towards). I'm strongly supportive diversity in the Bitcoin network, and some alt client developers can speak to the positive prodding I've given them towards becoming more complete software. If I've said anything that suggests otherwise I'd love to be pointed to it in order to clarify my position. Unfortunately none of the primary alternatives are yet complete, the network would be non-fu
Re: [Bitcoin-development] Random order for clients page
By that time in the future, when there are many clients, there should just be a flat list or no list at all. - Original Message - From: Nils Schneider To: bitcoin-development@lists.sourceforge.net Cc: Sent: Monday, July 9, 2012 6:33 PM Subject: Re: [Bitcoin-development] Random order for clients page I don't think that's a good idea as it can easily confuse or annoy users when things move around. The ordering should be preserved as much as possible so users can remember where they found a client they liked (e.g. 2nd row, 1st column and screenshot with light and blue colors). Making them search the entire page is inefficient and will just get worse once there are many clients on the page (and I think that's the goal). On 09.07.2012 17:54, Amir Taaki wrote: > Took me a while, but finally got it working. > > Entries on the clients page are randomly ordered when the page is generated. > > https://github.com/bitcoin/bitcoin.org/commit/6850fc8c83494d6ec415ea9d36fb98366373cc03 > > We should regenerate the page every 2 days. This gives fair exposure to all > the clients listed. > > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bitcoin.org - remove hackathon
Hi, Can I remove the hackathon from bitcoin.org and put up the conference instead? -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org - remove hackathon
OK, pull request seems good. FYI we lost money on last year's conference, and are hoping to break even this year. The only people to make profit will be nefario and anyone else we give a share in it (people who help realise it). Otherwise money made goes towards next year's conference and paying for things to make a better conference (like Gavin wanted to attend but couldn't afford a ticket). It is not a commercial event, and I've been pushing to keep the sponsorship and community parts highly separated. Like I really do not wish to sell a speaker slot, but if I have to (to pay the bills) then it will be obvious due to scheduling and disclaimers that speakers are sponsors. - Original Message - From: Luke-Jr To: bitcoin-development@lists.sourceforge.net Cc: Jeff Garzik ; Amir Taaki Sent: Tuesday, July 17, 2012 2:09 AM Subject: Re: [Bitcoin-development] bitcoin.org - remove hackathon On Monday, July 16, 2012 11:47:02 PM Jeff Garzik wrote: > Vladimir does raise a fair point, though. Hackathon seems appropriate > for bitcoin.org as it is focused on dev-related activities. (full > disclosure: speaking at bitcoin2012.com) The conference might or > might not be. The conference does seem community focused, so I don't > object to it being on bitcoin.org... But if consensus prefers > otherwise, that's OK too. IMO, bitcoin.org is more community-focussed anyway. How often do devs use the site, compared to GitHub etc? Someone else made a pullreq for Bitcoin Magazine; I suggest(ed) that for-profit organizations should be asked to pitch in some way or another. Who should organize that, I don't know. If Bitcoin Consultancy/Amir is behind the conference, I suggest their/his development contributions should be sufficient in that respect. > PS. This seems like material for pull requests, which is preferred > over mailing list email + git push. When working on the satoshi > client, we all ACK each other's pull req for anything beyond the > trivial. I concur, this should be discussed in a pullreq. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Berlin Hackathon
Video from the event: http://www.youtube.com/watch?v=EQ2rb4pHH1g The Hackathon is over, thanks for all the participants and sponsors! I had loads of fun, and there were lots of great ideas flying around! Thanks especially to: - IN-Berlin, for providing the space to hold the hackathon! - Sponsors: bitstamp.net, bitcoin2012.com and localbitcoins.com - Room77 (the restaurant at the end of capitalism), for hosting the afterparty and the burgers & pampero - Jury: yossarian + other people who attended the presentations The results - winner first 1. Offline transactions for BitcoinJ/Android bitcoin wallet: Andreas Schildbach and grazcoin - Ability for Android Wallet to do offline transactions 2. Bitcoin Pong: genjix - Multiplayer pong, where you can win (or lose) bitcoins 3. acceptbit.com: Jeremias Kangas and Stefan Thomas - an ultra-safe merchant tool, where you can accept payments without sharing your private keys 4. BitcoinJ Multisig: yellowhat and PK - way to do multisig transactions for BitcoinJ/Android 5. Double-spend monitor: genjix - tool to monitor double spends 6. Bitcoin-autosave: Mike Hearn - BitcoinJ improvements (Mike did also loads of other stuff, and helped with winner project too) 7. Live-calculator: genjix - Tool for btc accepting restaurants 8. Bitcoin mages: genjix - Strategy game, where you play for bitcoins 9. Embed block message: genjix - simple tool for embedding messages in block chain Source code genjix: https://gitorious.org/bitcoin-hackathon acceptbit.com: https://github.com/kangasbros/electrumpos Bitcoin Wallet: https://github.com/livne/Bitcoin-Wallet-for-Android (branch hackathon) Other Participants, send jeremias your bitcoin addresses please The next hackathon will be organized before bitcoin london conference, Wed 12th and Thur 13th september, london. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org - remove hackathon
Yes, but then they should not be sponsors. There's a very good reason why Wikipedia does not have advertisements. That is, the fear of advertisers influence on the neutral content. It is inevitably a corrupting influence. I want a good fun conference like the hackathon we just held. - Original Message - From: Andreas Petersson To: bitcoin-development@lists.sourceforge.net Cc: Sent: Tuesday, July 17, 2012 11:25 AM Subject: Re: [Bitcoin-development] bitcoin.org - remove hackathon Am 17.07.2012 11:17, schrieb Amir Taaki: > Like I really do not wish to sell a speaker slot, but if I have to (to pay > the bills) then it will be obvious due to scheduling and disclaimers that > speakers are sponsors. > > Personally, i really don't mind sponsored speakers. If they have somewhat relevant topics they keep the event from becoming a "circlejerk". for example i would really like to hear about payments innovation outside bitcoin. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Electrum mailing list
https://lists.sourceforge.net/lists/listinfo/electrum-discuss -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Conference: Call For Papers open
Hi, I'm opening the call for papers. It's about time to move forwards with this already. Sorry for the delays. Email proposals to gen...@bitcoin2012.com Speaker list: https://sites.google.com/a/bitcoin2012.com/homepage/speakers -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Merge branch on github
Hey, https://github.com/bitcoin/bitcoin.org/pull/46 I tried to keep it professional, and non spammy. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] OP_RESEVERVED and IsPushOnly
Meh, probably harmless, but... As best I can tell, OP_RESERVED does absolutely nothing (a NOP). CScript::IsPushOnly(...) counts this as a push operation. -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] script tests - invalid script in script_valid.json?
Hi! Is this a valid script? ["1 0 1", "WITHIN NOT"] The first value (1) is tested to make sure it is between the lower (0) and upper (1) value. This evaluates to true, placing on the stack a single byte of [01]. NOT then inverses this to a 0 byte false value of []. What am I missing here? Thanks -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] script tests - invalid script in script_valid.json?
oh, bitcoin... Thanks justmoon :D - Original Message - From: Stefan Thomas To: bitcoin-development@lists.sourceforge.net Cc: Sent: Sunday, July 29, 2012 1:33 PM Subject: Re: [Bitcoin-development] script tests - invalid script in script_valid.json? OP_WITHIN is lower-bound-inclusive, but upper bound exclusive, so 1 0 1 WITHIN is false. bool fValue = (bn2 <= bn1 && bn1 < bn3); https://github.com/bitcoin/bitcoin/blob/master/src/script.cpp#L854 On 7/29/2012 6:31 PM, Amir Taaki wrote: > Hi! > > Is this a valid script? > > ["1 0 1", "WITHIN NOT"] > > The first value (1) is tested to make sure it is between the lower (0) and > upper (1) value. This evaluates to true, placing on the stack a single byte > of [01]. NOT then inverses this to a 0 byte false value of []. > > What am I missing here? > > Thanks > > -- > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ___ > Bitcoin-development mailing list > Bitcoin-development@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] script tests - invalid script in script_valid.json?
Yep, I want to chip in and also express my gratitude for these useful tests. I sent a personal email to Gavin before. I plan to make some more complex tests by combining several of the simpler ones. - Original Message - From: Gavin Andresen To: Stefan Thomas Cc: bitcoin-development@lists.sourceforge.net Sent: Sunday, July 29, 2012 9:52 PM Subject: Re: [Bitcoin-development] script tests - invalid script in script_valid.json? > Is there interest to port more tests (P2SH, checksig, checkmultisig, > block verification, maybe even DoS rules) into data-driven format? It > might be something that I'd like to help with if pull requests in that > direction are welcome. Yes, more tests are definitely welcome. check*sig tests are tricky, because they have to refer to previous unspent transactions and private keys (so require a particular block chain to test against). Brilliant ideas on a simple data-driven format welcome. block verification tests would be great; a collection of good/bad block chains, starting from a common chain (maybe the testnet3 tesnet-in-a-box chain) would be very useful for regression testing. -- -- Gavin Andresen -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 22 - getmemorypool
Hi, luke-jr wants me to split this BIP into 3 separate BIPs because he says that other devs felt it was too unfocused and covered too many topics. However this discussion took place on IRC, and I never saw any of it to ascertain what happened (BIP 1 says drafts should be evaluated on the mailing list). I think a discussion of BIP 22 perhaps did happen on the mailing list, but I don't remember it. Sorry if that's the case. Anyway before granting the permission to allow this proposal to be pared down, and new BIPs granted for the non-core parts of this proposal, I want to know what people think. I'm not a miner myself, so I'm prescient of my lack of knowledge in the topic. https://en.bitcoin.it/wiki/BIP_0022 Thanks -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
The format for "mempool" packet is missing. I'm guessing that it is an empty message, right? Might be good to add that. - Original Message - From: Jeff Garzik To: Bitcoin Development Cc: Sent: Thursday, August 16, 2012 6:32 PM Subject: [Bitcoin-development] BIP 35: add mempool message Consensus was we should do a BIP for all P2P changes, so here it is... feedback requested. https://en.bitcoin.it/wiki/BIP_0035 Abstract --- Make a network node's transaction memory pool accessible via a new "mempool" message. Extend the existing "getdata" message behavior to permit accessing the transaction memory pool. Motivation --- Several use cases make it desireable to expore a network node's transaction memory pool: * SPV clients, wishing to obtain zero-confirmation transactions sent or received. * Miners, downloading existing network transactions after a restart. * Remote network diagnostics. Specification --- 1) Upon receipt of a "mempool" message, the node will respond with an "inv" message containing MSG_TX hashes of all the transactions in the node's transaction memory pool. An "inv" message is always returned, even if empty. 2) The typical node behavior in response to an "inv" is "getdata". However, the reference Satoshi implementation ignores requests for transaction hashes outside that which is recently relayed. To support "mempool", an implementation must extend its "getdata" message support to querying the memory pool. 3) Feature discovery is enabled by checking two "version" message attributes: a) Protocol version >= 60002 b) NODE_NETWORK bit set in nServices Backwards compatibility --- Older clients remain 100% compatible and interoperable after this change. Implementation --- See https://github.com/bitcoin/bitcoin/pull/1641 -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
My thoughts: The extension is simple. It's only really useful for the use-cases listed if the majority of nodes implement it. As I view the proposal, it is perfectly simple and uncomplicated. If it's implemented, then I suggest to just increment version and make it part of the protocol. On the flipside it is another notch in complicating an already diffuse protocol, but it seems a rather benign offense in that regard compared to other changes (past and future). - Original Message - From: Pieter Wuille To: Jeff Garzik Cc: Bitcoin Development Sent: Thursday, August 16, 2012 6:56 PM Subject: Re: [Bitcoin-development] BIP 35: add mempool message On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote: > Consensus was we should do a BIP for all P2P changes, so here it is... > feedback requested. > > https://en.bitcoin.it/wiki/BIP_0035 I like the idea of being able to query the memory pool of a node; the implementation is straightforward, which is good. Maybe effectively using the command can be added? I suppose it is interesting in general for nodes to get a memory pool refill at startup anyway. > 1) Upon receipt of a "mempool" message, the node will respond > with an "inv" message containing MSG_TX hashes of all the > transactions in the node's transaction memory pool. > > An "inv" message is always returned, even if empty. I'm not sure about this last. What is it good for? inv packets can always be sent, even not in response to others, so it is not that this gives you an acknowledgement the mempool is updated? > 3) Feature discovery is enabled by checking two "version" message attributes: > > a) Protocol version >= 60002 > b) NODE_NETWORK bit set in nServices This seems safe, although it forces other full implementations that want to expose protocol version 60002 (or later) to also implement this. What do they think about this? I would like to suggest to allocate an extra service bit for this. We still have 63 left, and this is a well-defined and useful extra service that was not yet provided by any earlier node. Doing that would also mean that mempool-providing survices may be discovered before connecting to them, as the service bits are carried around in addr messages. Any opinions about that? -- Pieter -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 35: add mempool message
MSG_MEMTX solves the issue of not knowing whether a given inv is in response to a "mempool" command or not. I don't buy the argument that always sending a response "inv" makes things easier because code should always be able to handle misbehaviour from the remote node (ommiting the "inv"). However I would argue that it is good to have it, as it makes designing flows of logic much easier (first send this, wait for response, do this, ...). - Original Message - From: Stefan Thomas To: bitcoin-development@lists.sourceforge.net Cc: Sent: Thursday, August 16, 2012 8:21 PM Subject: Re: [Bitcoin-development] BIP 35: add mempool message > This seems safe, although it forces other full implementations that want to > expose protocol version 60002 (or later) to also implement this. What do they > think about this? BitcoinJS will implement it, it's a useful feature and there is no reason not to support it. Two comments from my end: - This is just a thought, but I wouldn't mind using a new inv_type for this, e.g. MSG_MEMTX. I could conceivably see a future where broadcast and relay txs are stored in a very fast local cache whereas the general mempool is stored in a slower data structure. By being able to distinguish incoming getdata requests I can save a few milliseconds by querying the right storage right away. Might also help with things like telling apart broadcast/relayed transactions from the response to a mempool request for purposes like DoS scoring etc. Not a big deal by any means, but I also don't see a downside to it. inv_types are not a scarce resource, we have four billion of them available. For now clients would just treat MSG_TX and MSG_MEMTX interchangeably. - If a node doesn't have anything in it's mempool it sends back an empty inv message. This is either ambiguous (if other things also send empty inv messages in the future) or arbitrary (why should an empty inv be associated with a mempool request of all things.) Instead why not respond with an inv message that contains a single element of type MSG_MEMTX and hash 0. That would a very direct way to indicate that this response is associated with a mempool request. I'm not married to either suggestion, just trying to add my perspective. One thing you notice when reimplementing Bitcoin is that Bitcoin's protocol leaves out a lot of information not for space reasons, but because the reference client's implementation doesn't happen to need it. Sometimes however this locks other clients into doing things the same way. If we can make the protocol a bit richer, especially if this doesn't cost any extra bytes, then we should consider it as it might help some implementation down the road make a neat optimization. On 8/16/2012 7:56 PM, Pieter Wuille wrote: > On Thu, Aug 16, 2012 at 01:32:04PM -0400, Jeff Garzik wrote: >> Consensus was we should do a BIP for all P2P changes, so here it is... >> feedback requested. >> >> https://en.bitcoin.it/wiki/BIP_0035 > I like the idea of being able to query the memory pool of a node; the > implementation is straightforward, which is good. Maybe effectively using the > command can be added? I suppose it is interesting in general for nodes to > get a memory pool refill at startup anyway. > >> 1) Upon receipt of a "mempool" message, the node will respond >> with an "inv" message containing MSG_TX hashes of all the >> transactions in the node's transaction memory pool. >> >> An "inv" message is always returned, even if empty. > I'm not sure about this last. What is it good for? inv packets can always be > sent, even not in response to others, so it is not that this gives you an > acknowledgement the mempool is updated? > >> 3) Feature discovery is enabled by checking two "version" message attributes: >> >> a) Protocol version >= 60002 >> b) NODE_NETWORK bit set in nServices > This seems safe, although it forces other full implementations that want to > expose protocol version 60002 (or later) to also implement this. What do they > think about this? > > I would like to suggest to allocate an extra service bit for this. We still > have 63 left, and this is a well-defined and useful extra service that was > not yet provided by any earlier node. Doing that would also mean that > mempool-providing survices may be discovered before connecting to them, as > the service bits are carried around in addr messages. Any opinions about that? > -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/
[Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level. General category names for different accounts is much more human than numbers, and you can still use incrementing numbers if you prefer. -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers
ok, also what is the reasoning behind serialising points using a compressed format before going into the hash function? I'm looking at the sec1-v2.pdf and the compression format is a little confusing. I think the octet string for X is 32 bytes (using q = curve.order) and secp256k1 is a prime field so we follow step 2.2.1 From: Pieter Wuille To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Monday, December 3, 2012 2:54 PM Subject: Re: [Bitcoin-development] BIP 32 HD wallets, accounts should be labels not numbers On Mon, Dec 3, 2012 at 2:49 PM, Amir Taaki wrote: Can this be amended? I think it makes much more sense to allow people to input labels not numbers at this level. > >General category names for different accounts is much more human than numbers, >and you can still use incrementing numbers if you prefer. > There is no way to iterate over all strings. The intention is that a wallet application can detect a new account that becomes in use (e.g. during disaster recovery), so the accounts get assigned incrementing numbers. I wouldn't mind adding the ability to do "non-standard derivations" using arbitrary strings, if this recoverability property is not desired. -- Pieter -- Keep yourself connected to Go Parallel: BUILD Helping you discover the best ways to construct your parallel projects. http://goparallel.sourceforge.net ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] message dissemination
cool paper: http://phys.org/news/2013-01-algorithm-message-dissemination-decentralized-networks.html#jCp -- Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft MVPs and experts. SALE $99.99 this month only -- learn more at: http://p.sf.net/sfu/learnmore_122412 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] BIP0032
Yeah, I tried implementing it based on the document there and the code that is available in sipa's repo on GitHub but it's not enough. I'm waiting until there is an implementation of this concept before moving on it. From: Michael Gronager To: bitcoin-development@lists.sourceforge.net Sent: Monday, May 27, 2013 2:39 PM Subject: Re: [Bitcoin-development] BIP0032 Which again means that the statement regarding Audits through the Master Public key, M, is wrong - only incoming and outgoing transaction of _publicly_ derived wallets will be part of the audit... Privately derived wallets cannot be obtained, though you could, without loss of security, share also the addition points from privately derived wallets: (m/i')*G, but there is no concept of a single public master key. == Audits: M In case an auditor needs full access to the list of incoming and outgoing payments, one can share the master public extended key. This will allow the auditor to see all transactions from and to the wallet, in all accounts, but not a single secret key. == -- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Try New Relic Now & We'll Send You this Cool Shirt New Relic is the only SaaS-based application performance monitoring service that delivers powerful full stack analytics. Optimize and monitor your browser, app, & servers with just a few lines of code. Try New Relic and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_may___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Enhancement Proposals (BEPS)
I adapted the Python PEP 0001 to Bitcoin (its license is public domain): https://en.bitcoin.it/wiki/Bitcoin_Enhancement_Proposals https://en.bitcoin.it/wiki/BEP_0001 BEP 0001 is open to additional authors and revisions. Ideally these should go in a github.com/bitcoin/beps/ repo. Lets have a standardisation track for changes to the protocol. -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] 0.4.x stable branch
>Eventually, when there are a bunch of bitcoin implementations to >choose from, I think bitcoin.org should look like bittorrent.org -- it >should become a forum for developers to exchange ideas about the >direction of bitcoin. > >Gavin Andresen Thanks for your support. This is a noble ideal and will ensure bitcoin's eventual success by serving as a neutral platform for discussions. One step I've taken in this direction is to setup a process for proposing changes to the bitcoin protocol. See my other email to this list and this url: https://en.bitcoin.it/wiki/Bitcoin_Enhancement_Proposals The first proposal BEP 0001 is copied from Python's PEP 0001 and is a good starting point. I've marked it as a draft since it's only a non-working proposal. After that with mutual consent and discussion, we can move it to active status and start to think about setting up an arbitration committee. We should in general favour long discussion over voting. The Wikipedia model for resolving issues through hammering out details is superior to debian with a cycling board of voting members. The bittorrent page looks like a good future ideal to model ourselves off of and the EP pages too: http://bittorrent.org/beps/bep_.html BEP 0001 needs review and comments. As you can see, bittorrent did the exact same thing here (copying the PEP process) with success: http://bittorrent.org/beps/bep_0001.html genjix / Amir Taaki -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS)
Good idea. How about BRC? Bitcoin Request for Comments? Otherwise I like the sound of BERs, but it doesn't matter too much the name. - Original Message - From: Gavin Andresen To: bitcoin-development@lists.sourceforge.net Cc: Sent: Monday, September 19, 2011 6:57 PM Subject: Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS) 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 two years when a google for "BEP003" takes you to the BitTorrent EPs instead of the BitCoin EPs. Maybe "BIP" == Bitcoin Improvement Proposal or "PEB" == Proposal to Enhance Bitcoin or "BER" == Bitcoin Enhancement Request I think I like "BIP" (PEB sounds like a diet soda, and I don't know if BER should be pronounced "bear" or "beer"). I generally don't care about names, but it seems like a little planning now might save some confusion later. And I don't want the BitTorrent folks to get pissed off at us for 'stealing' their acronym, either. -- -- Gavin Andresen -- BlackBerry® DevCon Americas, Oct. 18-20, San Francisco, CA Learn about the latest advances in developing for the BlackBerry® mobile platform with sessions, labs & more. See new tools and technologies. Register for BlackBerry® DevCon today! http://p.sf.net/sfu/rim-devcon-copy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS)
Hey, Names aren't too important and people were in favour of BIPs. I've moved them from BEPs to BIPs (Bitcoin Improvement Proposals). - Original Message - From: Daniel F To: Gavin Andresen Cc: bitcoin-development@lists.sourceforge.net Sent: Friday, September 23, 2011 9:45 PM Subject: Re: [Bitcoin-development] Bitcoin Enhancement Proposals (BEPS) > Does anybody besides me think maybe we should name them something > other than "BEP" ? > > I'm worried we'll regret it in two years when a google for "BEP003" > takes you to the BitTorrent EPs instead of the BitCoin EPs. this is an excellent "painting the bikeshed" question, so i cannot resist participation :) imo, anyone who has any business looking at the beps (which would generally be technically-minded people), will be smart enough to google for "bitcoin bep003" to find what he's looking for. so i don't see an issue, whatever acronym we end up using. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] My thoughts on DoS code
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 compatibility between different implementations. Gavin argues that being a bit lenient makes it easier for people working on other implementations. I'd argue the opposite being the only person that's working on a full node implementation. Lucky I know my way around the code, so I don't have to guess. But if I did not things would be much harder. Imagine you're trying to interact with this protocol and then randomly it will suddenly disconnect you because of accumulated errors that have been building up. Everything should be strict, explicit, unambiguous and loud. I propose a new message type: "error" Payload is a uint64_t error_code and var_str reason. Before disconnecting a node you can send it an error message. The error_code is the main class of error- i.e version_sent_twice. Reason is just an implementation specific string that can add context. Other possible fields: uint8_t seriousness (debug, info, warning, error, fatal) uint8_t action_taken (disconnect, blacklist, .etc) -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: bitcoin scope issue in main.cpp
Hahaha you mean like unitialised variables, inheriting from containers with non-virtual dtors (CScript) and delicious copy pasta coding (PushMessage, bignum and serialize stuff). No need to worry about that :) From: John Smith To: theymos Cc: bitcoin-development@lists.sourceforge.net Sent: Monday, October 24, 2011 6:02 AM Subject: Re: [Bitcoin-development] Fwd: bitcoin scope issue in main.cpp Yes, I know that. It compiles. If we pulled all the 'This is legal in C++' tricks in the bitcoin source it would be even less maintainable and readable than now. But whatever... JS On Sun, Oct 23, 2011 at 10:51 PM, theymos wrote: It's legal for a scope to define variables with names that conflict with >the names of variables in higher-level scopes. > >-- >The demand for IT networking professionals continues to grow, and the >demand for specialized networking skills is growing even more rapidly. >Take a complimentary Learning@Cisco Self-Assessment and learn >about Cisco certifications, training, and career opportunities. >http://p.sf.net/sfu/cisco-dev2dev >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > -- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- The demand for IT networking professionals continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Bitcoin Wiki
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 continues to grow, and the demand for specialized networking skills is growing even more rapidly. Take a complimentary Learning@Cisco Self-Assessment and learn about Cisco certifications, training, and career opportunities. http://p.sf.net/sfu/cisco-dev2dev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Lock protocol version numbers
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 :) -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
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 it'd be restrictive to lock people into the popular major.minor system. So for the current bitcoin to find out the version number of other clients (if it was needed), it would have to parse the number from the string: "Satoshi 0.5" Although there would be little reason for this with a sane protocol versioning scheme. If we're agreed then I'll start on that BIP. From: Gavin Andresen To: Amir Taaki Sent: Wednesday, November 2, 2011 9:34 PM Subject: Re: [Bitcoin-development] Lock protocol version numbers Good idea. Sounds perfect for a BIP On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki wrote: > 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? -- -- Gavin Andresen-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
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 Satoshi is apt homage to the person who made the original client reference protocol. Satoshi BitcoinCommunityOriginal ... Take your pick. From: Luke-Jr To: "bitcoin-development@lists.sourceforge.net" Cc: Amir Taaki Sent: Wednesday, November 2, 2011 10:46 PM Subject: Re: [Bitcoin-development] Lock protocol version numbers 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...-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
Cool thread. I enjoyed reading that :) Thanks for sharing. From: Christian Decker To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Wednesday, November 2, 2011 10:42 PM Subject: Re: [Bitcoin-development] Lock protocol version numbers 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 wrote: 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 it'd be restrictive to lock people into the popular major.minor >system. > > >So for the current bitcoin to find out the version number of other clients (if >it was needed), it would have to parse the number from the string: > > >"Satoshi 0.5" > > >Although there would be little reason for this with a sane protocol versioning >scheme. > > >If we're agreed then I'll start on that BIP. > > > > >From: Gavin Andresen >To: Amir Taaki >Sent: Wednesday, November 2, 2011 9:34 PM >Subject: Re: [Bitcoin-development] Lock protocol version numbers > >Good idea. > >Sounds perfect for a BIP > > >On Wed, Nov 2, 2011 at 5:23 PM, Amir Taaki wrote: >> 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? > >-- >-- >Gavin Andresen > > > >-- >RSA(R) Conference 2012 >Save $700 by Nov 18 >Register now >http://p.sf.net/sfu/rsa-sfdev2dev1 >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
>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, gui, flavour, build /Satoshi:314700/bitcoin-qt:0.4/ How does that sound? In BitcoinJ's case: /BitcoinJ:0.2/AndroidBuild:0.8/ Thoughts: - Do we need a freely defined comments field? /BitcoinJ:0.2[iPad; U; CPU OS 3_2_1]/AndroidBuild:0.8/ /Satoshi:314700/bitcoin-qt:0.4[Ubuntu Oneiric]/ From: Christian Decker To: Mike Hearn Cc: Amir Taaki ; "bitcoin-development@lists.sourceforge.net" Sent: Saturday, November 5, 2011 2:45 PM Subject: Re: [Bitcoin-development] Lock protocol version numbers 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 wrote: 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 >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Lock protocol version numbers
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 some cases. What happens when some popular client is > found with a subtle bug, and cannot otherwise be differentiated from other > similar-functionality clients? I have found User-Agent very valuable when > dealing with the wide variety of miner bugs when I have enabled new > functionality/behaviour on Eligius. I can agree with this point though. 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. Fail hard and fast. However my feeling about the user-agent string is that it is a vanity item, but here we'd be enforcing a format that everybody can understand and read. Lets say with libbitcoin- I'm sure that users of libbitcoin would like to have their client name in the string somehow. This was we can quickly understand which code-bases are being used and all the variants that exist build on those code-bases. Together with system information (how many Linux users are there?) and various system settings (how many 32bit users are there), and so on. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] subvertx - bitcoin command line utilities
Hey, Thought you might enjoy this/find it useful. https://bitcointalk.org/index.php?topic=50994.0 Some tools for messing around with the network. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 0001 now active
I put the status for BIP 0001 to active now. Let me know if there's any disagreements with this. I'm on Freenode under the nickname genjix -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent
Hi, https://en.bitcoin.it/wiki/BIP_0014 Thanks to Gavin Andresen for proof reading and suggesting clarifications. Thanks to Patrick Strateman for suggesting the hierarchical format and pointing out some flaws of browser user-agents to me. The timeline is written in the past tense since BIPs are meant to be readable in the future for explaining why we took certain decisions with bitcoin. A nice cache for future historians when bitcoin is ubiquitous ;) The next version 0.6 should be the protocol version which becomes peeled off from the current client. There are still some changes migrating into the protocol that need to be finished. -- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent
Nice. I'll check with justmoon when I hopefully meet him at the conference. If all is OK, hopefully 0.6 will be the last protocol version bump for a while. From: Mike Hearn To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Saturday, November 12, 2011 7:31 PM Subject: Re: [Bitcoin-development] [RFC] BIP 14 - Protocol Version and User Agent Looks pretty reasonable to me. If Gavin changes the mainline client to use this format I'll change BitcoinJ as well. It'll need a bit of API work so clients are sure to set it up properly. On Thu, Nov 10, 2011 at 10:16 PM, Amir Taaki wrote: Hi, > > >https://en.bitcoin.it/wiki/BIP_0014 > > >Thanks to Gavin Andresen for proof reading and suggesting clarifications. >Thanks to Patrick Strateman for suggesting the hierarchical format and >pointing out some flaws of browser user-agents to me. > > >The timeline is written in the past tense since BIPs are meant to be readable >in the future for explaining why we took certain decisions with bitcoin. A >nice cache for future historians when bitcoin is ubiquitous ;) > > > >The next version 0.6 should be the protocol version which becomes peeled off >from the current client. There are still some changes migrating into the >protocol that need to be finished. > > >-- >RSA(R) Conference 2012 >Save $700 by Nov 18 >Register now >http://p.sf.net/sfu/rsa-sfdev2dev1 >___ >Bitcoin-development mailing list >Bitcoin-development@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/bitcoin-development > >-- RSA(R) Conference 2012 Save $700 by Nov 18 Register now http://p.sf.net/sfu/rsa-sfdev2dev1___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] [BIP 15] Aliases
I wrote this pre-draft: https://en.bitcoin.it/wiki/BIP_0015 It's merely a starter for discussions. Aliases are a way to lookup bitcoin addresses so I can type gen...@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
OK, my thoughts. My order of preference is: web service, server service, DNS TXT records. FirstBits + Vanitygen is out of the question in my mind. Not robust enough. I like web service since anyone can trivially set one up. You can provide a PHP script and a text file (that users edit) that people upload to XFreeWebHost and then they're instantly set to go. Setting up a web host is very easy nowadays- as easy as click click click. The other ideas are not so easy. Also HTTPS + CA is the most secure of the bunch. I'm curious to hear any other ideas too. Thanks. - Original Message ----- From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" Cc: Sent: Monday, December 12, 2011 10:21 PM Subject: [BIP 15] Aliases I wrote this pre-draft: https://en.bitcoin.it/wiki/BIP_0015 It's merely a starter for discussions. Aliases are a way to lookup bitcoin addresses so I can type gen...@genjix.net instead of 1jkddsjdskjwnk2j3kj232kjdkj -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
> I'm confused about the problem we're trying to solve. I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is useless. Then I remembered FirstBits, went to my terminal and typed 1brmlab. I got their bitcoin address from the website and copied that, then opened my terminal and pasted that in to send 1 BTC. And these proposals for Namecoin, would make bitcoin implementations dependent on unproven technology. HTTPS/DNSSEC have been around a long time and are responsible for many mission critical systems. There's a lot of momentum behind those projects. Namecoin by contrast, could die tomorrow. And it isn't a big deal that they're centralised. This is a convenience for end users and does not affect the core system much. tl;dr: usability -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
lol, way to miss the point nanotube. FirstBits *is* useless, but not for the reasons you specified. But simply because the resources it needs rises exponentially as the number of participants in the network grows linearly. The point is that if FirstBits were built into the implementation, that would allow me to simply send to 1brmlab. The proposal here is not for a website where people can lookup bitcoin addresses, but a shared naming scheme between bitcoin implementations. Here's the story again: > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall a picture of their QR code and a bitcoin address. I don't own a mobile phone so the QR code is > useless. Then I remembered FirstBits, went to my terminal and typed > 1brmlab. I got their bitcoin address from the website and copied that, > then opened my terminal and pasted that in to send 1 BTC. In our revised history, I simply send 1 BTC to brmlab BOOM. Club Mate - Original Message - From: Daniel F To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Tuesday, December 13, 2011 2:32 AM Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases > I was in brmlab and wanted to pay 1 BTC for a Club Mate. They had on the wall > a picture of their QR code and a bitcoin address. I don't own a mobile phone > so the QR code is > useless. Then I remembered FirstBits, went to my terminal and typed > 1brmlab. I got their bitcoin address from the website and copied that, > then opened my terminal and pasted that in to send 1 BTC. ok, imagine if firstbits didn't exist. instead of going to firstbits, you would have gone to your terminal, opened up brmlabs website, and copied the address from there? there may be some arguments for name-> address translation, but i'm sorry to say, that your example is not one of them. if anything, it seems to suggest that firstbits is completely useless, since it saves approximately zero effort. -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
Maybe I wasn't clear enough in the document, but this is the intent with the HTTPS proposal. gen...@foo.org Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system responds with a bitcoin address. Whether the system gives you a new address from a pool of addresses, or contacts the merchant behind the scenes is implementation defined. I'll clarify it later. This is the relevant line: string strRequestUrl = strDomain + "/bitcoin-alias/?handle=" + pszEncodedNick; Between HTTPS service and server service, I lean slightly towards HTTPS (automatic encrypted connection, CAs + all benefits of DNS). But still interested in arguments in favour of a server service (daemon answering queries). - Original Message - From: Gavin Andresen To: Jorge Timón Cc: "bitcoin-development@lists.sourceforge.net" Sent: Tuesday, December 13, 2011 1:06 PM Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases I agree with Mike Hearn and Christian Decker-- paying to 'someb...@foo.com' should become, behind the scenes, a HTTPS query to https://foo.com/something. If you just want to (say) donate to eff.org, then paying to '@eff.org' aught to work nicely. And if namecoin ever takes off you'll pay to 'someb...@foo.bit'. It seems to me that if it was DNS-based, the address should be something like 'somebody.bitcoin.foo.com'. But I think it is unlikely people will setup and run a custom DNS server just to support bitcoin payments. -- -- Gavin Andresen -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Systems Optimization Self Assessment Improve efficiency and utilization of IT resources. Drive out cost and improve service delivery. Take 5 minutes to use this Systems Optimization Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
This is maybe the best idea. I added it: https://en.bitcoin.it/wiki/BIP_0015#IP_Transactions Things I like about this: - IP transactions are useful, but have a security flaw. This mitigates their security problems. - The code for IP transactions is already in Satoshi client. If other clients want to add IP transactions, then it can be done with minimal fuss/bloat. I feel that for any protocol extension, less is more. The less code needed, the better the extension. Not always but generally we want to avoid bitcoin protocol bloat which *will* happen far in the future. The only way to mitigate how spaghettified the standard will be in the future, is by careful cautious planning now. - We can have a proxy node running 24/7 for us, serving our public keys in lieu of us. From: theymos To: bitcoin-development@lists.sourceforge.net Sent: Thursday, December 15, 2011 7:59 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases Bitcoin already has code and a protocol for transactions to IP addresses. Why not reuse that for dynamic address lookup? Just a few changes are necessary to enable complete u...@server.com handling: - Extend the protocol so that "reply" messages can be signed by a fixed public key - Extend "checkorder" messages so they can specify an account to send BTC to. Or standardize on how to put the account into the message field. - Enable DNS lookups for IP transactions. The DNS-only proposals could also be used here to avoid having to use the IP transaction protocol sometimes. The public key for signing "reply" messages can be gotten from TXT records. This will be safe with DNSSEC and Namecoin. With plain DNS Bitcoin could take a SSH-like approach and ask the user to verify the public key the first time it is used, remembering it later. DoS attacks are already handled by the IP transactions code: the same IP address is always given the same bitcoin address until it pays to that bitcoin address. -- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/ ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- 10 Tips for Better Server Consolidation Server virtualization is being driven by many needs. But none more important than the need to reduce IT complexity while improving strategic productivity. Learn More! http://www.accelacomm.com/jaw/sdnl/114/51507609/___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Fwd: [BIP 15] Aliases
You have to be seriously joking to call the bitcoin protocol elegant. A message based system over TCP with constantly changing endians that needs to lookup its own IP address on several websites is not elegant. It is functioning, not elegant. Also it is kind of dick to come guns blaring and start insulting slush who runs one of the biggest mining pools and is working on electrum, and sipa who develops the satoshi bitcoin. Khalahan said: > Namecoin is a peer-to-peer generic name/value datastore system Namecoin has the same problem as DNS. From the document: "The disadvantage of DNS TXT records is that updating a record takes time. This encourages people to not use new addresses per transaction which has certain security issues." From: Rick Wesson To: Andy Parkins Cc: bitcoin-development@lists.sourceforge.net Sent: Friday, December 16, 2011 5:41 PM Subject: Re: [Bitcoin-development] Fwd: [BIP 15] Aliases Its a negative example -- in that the IETF does not specify anything in the PATH part of the URI. The scheme, sure, but not in the path, there are many types of URI schemes ( start with RFC 2396 ) There is significant upside to having your own scheme and having apps understand how to integrate with it. Frankly, having just one client (I understand there are more) is an artifact that hinders acceptance and participation. If you want to go the route of https then specifying a scheme is your path forward I still believe that it is experience that is leading this thread down the rat-hole of CGI and HTTP requests. The stuff isn't magic, it is just what you are used to. Review the bitcoin protocol, there is an elegance there -- not found in the https schemes proposed thus far. CGI isn't a protocol, nor does it address usability/identity issues. Providing a mapping from u...@authority.tld addresses usability and identity. I'd like to see an elegant transformation, specifically I take to task anyone that advocates https://authority/foo/user?tx=1zhd789632uilos as elegant. -rick On Fri, Dec 16, 2011 at 9:10 AM, Andy Parkins wrote: > On 2011 December 16 Friday, Rick Wesson wrote: >> On Thu, Dec 15, 2011 at 4:07 PM, slush wrote: >> > I really like this proposal with standard URLs. All other proposals like >> > DNS mapping or email aliases converted to URLs with some weird logic >> > looks strange to me. >> >> wow, really. Maybe you could review some RFCs, there are thousands of >> examples where some really smart engineers chose the exact opposite >> path which you propose below. > > Could you point me at an example? > > > Andy > > -- > Dr Andy Parkins > andypark...@gmail.com -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] [BIP 15] Aliases
I think IBANs are not such a good idea. Note that as someone who has spent the last year of my life dealing with hundreds of bank transactions a day and interacting with the banking system (both on a technical, systematic and personnel level), the entire system is a gigantic mess. The banks are in fact looking to us for answers. That's why we (Bitcoin Consultancy) were invited to the SWIFT conference to join their panel on bank 2.0. I don't even mind the maxim "take everything the banks have done and do the complete opposite" :) I invite anyone who is skeptical to read the ECB's specification on SEPA payments. It really is an example of a system made to work alongside legacy systems that rely on inefficient people. The interchange fees are dependent on a totally arbitrary test of merchant indifference and various antitrust regulations. These systems are usually built not by engineers or hackers, but by finance people. IBAN has no place in bitcoin IMO. I don't mean to sound too critical, but I'm skeptical of its usefulness. Especially when we already have bitcoin addresses with their own checksums- what value do IBANs add? Nothing except negatives. From: slush To: Khalahan Cc: bitcoin-development@lists.sourceforge.net Sent: Friday, December 16, 2011 7:54 PM Subject: Re: [Bitcoin-development] [BIP 15] Aliases Khalahan, honestly, using namecoin for aliases is (for me) clean example of over-engineering. I mean - it will definitely work if implemented properly. I played with a namecoin a bit (as my pool was the first 'big' pool supporting merged mining), but I think there's really long way to provide such alias system in namecoin and *cleanly integrate it with bitcoin*. Don't forget that people who want to do lookup need to maintain also namecoin blockchain with their bitcoin client. It goes against my instinct of keeping stuff easy. For example, yesterday I implemented HTTPS lookup for addresses into my fork of Electrum client. I did it in 15 minutes, it works as expected, it does the job and the implementation is really transparent, becuase implementation is 20 lines of code. There's no magic transformation, no forced "?handle=" parameters or whatever. And I don't care if somebody provide URL https://some.strange.domain/name-of-my-dog?myhandle=5678iop&anything_else=True And everybody can do the same in their clients, in their merchant solutions, websites or whatever. Everybody can do HTTPS lookup. But try to explain DNS, Namecoin, IIBAN, email aliases to other programmers... Those IIBAN - well, why not. At least I see the potential in PR. So far I understand it as some teoretic concept which is not supported by anything else right now. Give it few years until it matures and then add IIBAN alias to Bitcoin client too. Maybe I'm repeating myself already, but the way to go is to make aliases as easy as possible, so everybody can implement it in their own solution and thus practially remove the need of using standard bitcoin addresses for normal users. Using some superior technology, which is hard to implement or even understand won't solve the situation, because it will ends up with some reference implementation in standard client only and nobody else will use it. slush On Fri, Dec 16, 2011 at 6:23 PM, Khalahan wrote: >Namecoin is a peer-to-peer generic name/value datastore system. >Don't forget it's not limited to .bit usage ! So, directly mapping things to .bit url would not be the optimal way of using namecoin. > > -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Protocol extensions
Has anyone considered 'snapshot' frames (blocks). Message to node: getsnapshot: hash Node responds with a 'block' message. Then the hash for that particular snapshot is hardcoded into the sourcecode. It would replace the checkpoints and use the last hash in that list. Validating blocks is pretty fast right up until block 135k, which is where time taken balloons and starts become exponentially slower. As blockchain grows linearly, resources needed grows exponentially if you think about it. From: Alan Reiner To: bitcoin-development@lists.sourceforge.net Sent: Sunday, December 18, 2011 6:06 PM Subject: Re: [Bitcoin-development] Protocol extensions The whole point of having headers built at a constant size and generation rate is to minimize the amount of data needed to "understand" of the blockchain while simultaneously maximizing integrity/security in the presence of untrusted nodes. Barring the 50%-attack, you only need a couple honest nodes out of 50 to stay safe (as long as you're waiting for your 6 confirmations). In fact, I would argue that a full node (Satoshi client), has the same level of security as a headers-only client... because they both base all their verification decisions on computations that end with comparing hashes to the longest-chain headers. In the case that an attacker figures out how to isolate your node entirely and start feeing you poisoned blocks, then you are vulnerable with any kind of node, full or lightweight. I don't see where the reduced security is. The only issue I see is that a truly light-weight, headers-only node will be having to download an entire block to get one transaction it needs. This would be significantly alleviated if nodes can start requesting merkle-trees directly, even without merkle-branch-pruning. If a node can ask for a tx and the tx-hash-list of the block that incorporated that tx, he can easily verify his tx against his no-need-to-trust-anyone headers, and doesn't have to download MBs for every one. As for blockchain pruning... I think it's absolutely critical to find a way to do this, for all nodes. I am swayed by Dan Kaminsky's scalability warnings, and my instinct tells me that leaving full verification to a select few deep-pockets nodes in the future opens up all sorts of centralization/power-corporation issues that is contrary to the Bitcoin concept. It is in everyone's best interest to make it as easy as possible for anyone to act as a full node (if possible). As such, I believe that the current system of minimizing TxOut size is the right one. TxIns take up 0 bytes space in the long-run when taking into account any blockchain pruning/snapshot idea (except for nLocktime/seq transactions where the TxIn might have to be saved). -Alan On 12/18/2011 12:09 PM, theymos wrote: On Sat, Dec 17, 2011, at 05:27 PM, Jordan Mack wrote: >I don't like the idea of a header only client, unless this is just an interim action until the full block chain is downloaded in the background. Development of these types of clients is probably inevitable, but I believe that this breaks the most fundamental aspects of Bitcoin's security model. If a client has only headers, it cannot do full verification, and it is trusting the data from random anonymous peers. >A headers-only client is much better than trusting anyone, since an attacker needs >50% of the network's computational power to trick such clients. For everyone to keep being a full node, hardware costs would need to constantly go down enough for all nodes to be able to handle enough transactions to meet demand. If hardware doesn't become cheap enough quickly enough, either some people would be unable to handle being full nodes, or the max block size wouldn't rise enough to meet demand and transaction fees would become noncompetitive. -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Learn Windows Azure Live! Tuesday, Dec 13, 2011 Microsoft is holding a special Learn Windows Azure training event for developers. It will provide a great way to learn Windows Azure and what it provides. You can attend the event by watching it streamed LIVE online. Learn more at http://p.sf.net/sfu/ms-windowsazure ___ Bitcoin-development mailing
Re: [Bitcoin-development] BIP language on normative behavior
A few weeks back I was in discussion with the IANA on getting a bitcoin URI accepted in the standard. As a prerequisite I had to read 5 huge documents. I did not end up writing that RFC. Skilled developers have even less time than I do. While this particular RFC is really nice for keeping ambiguity at bay, it is one of many small rules that bring marginal improvements. "Rule creep" (like feature creep) starts off with good intentions but degenerates into a situation like Wikipedia or any other system with a heavy bureaucracy that can use the rules for lawyering against you. We want to encourage skilled developers to help set the standards and participate in discussions. Beyond using good grammar and using the correct formatting (and I even help with those), I defer on the site of trusting common sense and human judgement :) However this is a good RFC, and I will advise any future BIP contributors to read it. It offers good suggestions. About what Luke says: I kind of agree with him. The intention was to specify software stacks rather than end applications. This allows us to more carefully track software evolution and behaviour throughout the network. bitcoin-qt need not be tied to the Satoshi code-base and may in the future use other core systems through its intermediary layer. BitcoinJava has given rise to a bunch of other application like Android Bitcoin and MultiBit- however they are both BitcoinJava derivatives. However BIPs are a community consensus thing. It depends on the mutual consent of everybody and if there is a commonly agreed sentiment against the wording of an Accepted (or even Active) BIP then it can be amended ad-hoc. The purpose of BIPs is to enhance development by 1. providing a stable system environment for programmers to work towards an accepted standard 2. serve as an equaliser for smaller groups (the third party clients vs the current behemoth client) by giving them a voice or platform. And they can only function by those who want them to function. But personally, I really do think splitting bitcoin-qt into XXX and bitcoin-qt is a smart idea. Starting from lowest to top part of the system is smart: http://www.useragentstring.com/pages/Firefox/ Mozilla/5.0 (Windows NT 6.1; WOW64; rv:6.0a2) Gecko/20110613 Firefox/6.0a2 Mozilla is the application suite (Mozilla Thunderbird, Mozilla Firefox, ...) Gecko is the rendering engine Firefox is the end application In the original intention for BIP_0014, that would map to: /Gecko:20110613/Firefox:6.0a2/Mozilla:5.0/ With something like WebKit, it becomes easy to see why that would be useful. You can suddenly do a network wide scan of all browsers using WebKit, rather than having to maintain a database of all WebKit enabled browsers. So if this is contentious. Then discuss. I'll update the BIP according to what everyone decides they like. :) From: Gregory Maxwell To: Bitcoin Development Sent: Monday, December 19, 2011 10:29 PM Subject: [Bitcoin-development] BIP language on normative behavior I've been arguing with Luke-JR on IRC about the interpenetration of BIP_0014— Gavin's recent commit uses the same version string for the GUI interface and the daemon mode. Luke believes this is a _violation_ of BIP_0014 and an error in judgement on Gavin's part, and a failure to conform to the community adopted standard. I believe Luke is mistaken: that BIP_0014 actually don't have mandatory requirements for what you put in the version field and even if it did, that they are in fact the same software and should have the same name. I don't think an agreement is likely on the second point, but the first point highlights some ambiguity in the interpretation of BIP language. E.g. What is permitted vs encouraged vs required. There is well established standard language for this purpose: https://www.ietf.org/rfc/rfc2119.txt I strongly recommend that all BIPs be written using the RFC2119 keywords where appropriate. -- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development-- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Bitcoin-development mailing list B
Re: [Bitcoin-development] BIP language on normative behavior
OK, give me a shout on IRC. It is a lot of work though, so be prepared. Bring bags of patience :) From: Luke-Jr To: Amir Taaki Sent: Wednesday, December 21, 2011 1:07 AM Subject: Re: [Bitcoin-development] BIP language on normative behavior On Tuesday, December 20, 2011 7:59:00 PM Amir Taaki wrote: > A few weeks back I was in discussion with the IANA on getting a bitcoin URI > accepted in the standard. As a prerequisite I had to read 5 huge > documents. I did not end up writing that RFC. I also contacted the IANA about getting the bitcoin URI spec accepted on their index, however never heard back. If you want, please have whoever you discussed it with get in touch with me. Either way, please be sure whatever they index is compliant with the spec on the wiki as-is (especially not being BTC unit specific, as this is clearly non-scalable). Luke-- Write once. Port to many. Get the SDK and tools to simplify cross-platform app development. Create new or port existing apps to sell to consumers worldwide. Explore the Intel AppUpSM program developer opportunity. appdeveloper.intel.com/join http://p.sf.net/sfu/intel-appdev___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] upnp isnt working
hey, so sipa/gmaxwell proposed on irc that maybe upnp is not working anymore but there isnt any way to test. well i made an alternate chain, and ran the daemon on my vps. sometimes it accepts connections, sometimes not. It's all very patchy. anyway just putting this out there -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] version::addr_recv/addrMe does what?
Hi, What is the purpose for this field? Can I safely ignore it? Currently it isn't used and I can't imagine it being too useful. If you want to discover your own IP address from it, then that's ripe for abuse. Maybe it could be used in conjuction with your own IP lookup mechanism kind of how the clock works. What is the main reason for this field existing? -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Meeting 21:00 UTC #bitcoin-dev Freenode IRC
This meeting is to discuss the new OP_EVAL changes coming to bitcoin. A good summary of the past discussion so far by justmoon can be found: http://privatepaste.com/4088b049af Hopefully this can become a weekly thing. For now this is to discuss and inform about the coming changes to bitcoin. -- Where: Freenode IRC #bitcoin-dev When: 21:00 UTC (16:00 New York time) until 22:00* What: OP_EVAL Bitcoin is starting decentralising as any healthy free thinking community should. Projects are thiving and the economy is growing. New ideas are being realised and will edge out old models disruptively. My hope is that we don't all become fractured. By having weekly regular meetings, projects can harmonise in lock step. Concepts and algorithms can be proposed and debated. You'd be surprised what having a scheduled regular platform can achieve. A soap-box on an island in central waters. For me, I don't have time to wade through IRC discussions, forum posts and mailing lists. At least if the important things are discussed in one place it makes bitcoin development and the system more accessible. Before meeting: - A wiki page is created for in advance of a weekly meeting. - Announced on forums/mailing lists. - Throughout the week talking points are added to the meeting page. After: - Log of discussion is posted online. - I will type an accessible summary for the community at large on http://bitcoinmedia.com/ - Next weekly meeting is scheduled. Amir Taaki *We can go over this hour, but this is to stop meetings dwindling off topic into banal banter and stay focused. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Meeting 10 Jan 2012 at 21:00 UTC
Hey, Will get around to that write-up. Here is the page for next Tuesday: https://en.bitcoin.it/wiki//10_Jan_2012 Feel free to add talking/discussion points to the agenda. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Pull 748 pay to script hash
https://github.com/bitcoin/bitcoin/pull/748/files I'm reading a diff of a now defunct OP_EVAL proposal with the current pay to script hash one. It might be better for code review if the old pull is reverted and then this one re-requested. That will make it easier to see the real changes. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Pull 748 pay to script hash
OK, here is one thing: what is the purpose behind counting the number of sig ops after you have executed the script in ConnectInputs? Seems like it would be too late then. - Original Message - From: Gavin Andresen To: Amir Taaki Cc: Bitcoin Dev Sent: Saturday, January 7, 2012 10:48 PM Subject: Re: [Bitcoin-development] Pull 748 pay to script hash > It might be better for code review if the old pull is reverted and then this > one re-requested. That will make it easier > to see the real changes. I count the 1 major merge then 8 commits to fix bugs or tweak things... I just tried reverting them and stopped when I got scared I'll accidentally revert a fix we do want to keep. Instead, I updated my gavinandresen/master github branch to the state of the tree just before the OP_EVAL merge, so for code review purposes you can look at: https://github.com/gavinandresen/bitcoin-git/compare/master...pay_to_script_hash There are unrelated 0.6 pulls in those changes, too, but it should be pretty obvious what is what. -- -- Gavin Andresen -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] IRC meeting Tuesday tomorrow 21:00 UTC
Hey, I made a list of things to ask about: https://en.bitcoin.it/wiki//10_Jan_2012 Feel free to add things to the agenda. Those are just random things I wanted to discuss. -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] bitcoin.org SOPA/PIPA blackout
How is this not the most important world issue right now? EVERYTHING is under threat. Go nuclear to show our nerd-rage. Everybody blank your personal sites too. Americans, take to the streets. World, go scream at the US embassy. -- RSA(R) Conference 2012 Mar 27 - Feb 2 Save $400 by Jan. 27 Register now! http://p.sf.net/sfu/rsa-sfdev2dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout
Bunk argument. This is an issue that affects bitcoin directly. Wikipedia has far more need to remain neutral and apolitical than bitcoin ever does- you've read Satoshi's politically charged whitepaper or seen the genesis block quote. http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action The Wikipedia community decided on a full and global blackout. Bitcoin should do the same in unison with the rest of the web- sites like Reddit, 4chan and Wikipedia. It's funny / almost comical how you consign this to being just another issue or case of moral alarm. Sad. - Original Message - From: Jeff Garzik To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Sunday, January 15, 2012 10:37 PM Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki wrote: > How is this not the most important world issue right now? > > EVERYTHING is under threat. Go nuclear to show our nerd-rage. > > Everybody blank your personal sites too. Americans, take to the streets. > World, go scream at the US embassy. There are always issues that raise ire and moral outrage. I would rather that bitcoin.org stay apolitical -- our users will appreciate this in the long run. -- Jeff Garzik exMULTI, Inc. jgar...@exmulti.com -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fuzzer?
Hey, I heard there is a fuzzer in the works? Where can I find more details of this? I'm going to write one for libbitcoin, but if one already exists then I'd rather build on and use that. Something simple like: - Set previous block hash, set current target - Start hashing - Connect and send to specified host (i.e localhost) That way I can force re-organisations and stress the blockchain algorithm. Should be trivial for me to build, but worth asking anyway :) Thanks -- Keep Your Developer Skills Current with LearnDevNow! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-d2d ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] GetBlocksToMaturity
Why add 20 to COINBASE_MATURITY there? The underlying protocol accepts spent transactions at 100 (COINBASE_MATURITY) so this seems more like a measure to put people off spending until 120 confirms. If you are determined enough to hack your client, you can still spend before 120 but after 100. Why is this? Did Satoshi overestimate how many competing races there would be between mined blocks?-- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] GetBlocksToMaturity
Actually now I'm thinking- I reckon it is so that your transaction gets accepted by the network when it is sent out. At around 20 confirmations, you can be sure that the rest of the network also has 100 confirmations off the original mined block. Otherwise at 100 confirms, you may have a chain ahead of everyone else or there might be a temporary network partition (islanding) that causes another fork to get built up, then when they rejoin, not everyone has 100 confirms... From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" Sent: Friday, January 27, 2012 4:33 PM Subject: GetBlocksToMaturity Why add 20 to COINBASE_MATURITY there? The underlying protocol accepts spent transactions at 100 (COINBASE_MATURITY) so this seems more like a measure to put people off spending until 120 confirms. If you are determined enough to hack your client, you can still spend before 120 but after 100. Why is this? Did Satoshi overestimate how many competing races there would be between mined blocks?-- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] BIP 0020: URI Scheme
BIP 0020 is the old URI scheme BIPisized. ATM it is Draft status. I do not know enough about the discussion back last year to know whether to move it to Accepted status or not. My feelings are that having a re-decision (even if it was accepted last year) is healthy since it makes no sense to have a standard before a standardisation process existed. For now, it is Draft status until there's a general agreement. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Quote on BIP 16
Gavin said: "Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr (or possibly even longer) I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable." How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
Re: [Bitcoin-development] Quote on BIP 16
2 compressed pubkeys - Original Message - From: Amir Taaki To: "bitcoin-development@lists.sourceforge.net" Cc: Sent: Sunday, January 29, 2012 4:52 AM Subject: [Bitcoin-development] Quote on BIP 16 Gavin said: "Part of the controversy is whether really long bitcoin addresses would work-- would it be OK if the new bitcoin addresses were really long and looked something like this: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr (or possibly even longer) I've argued no: past 70 or so characters it becomes a lot harder to copy and paste, a lot harder to scan an address with your eyes to see if you're paying who you think you're paying, harder to create a readable QR code, harder to upgrade website or database code that deals with bitcoin addresses, etc. There is rough consensus that very-long addresses are not workable." How could you have a 70 byte long address without a P2SH scheme? Is this a mistake? -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Fw: Quote on BIP 16
(oops sorry greg- replied to you by mistake) That address he gives is 77 characters/bytes (same thing). What I'm asking is how can it be so small. I know that it's encoding a script, but then I started trying to imagine what kind of script and to me it seems that 2 public keys are too large for those 77 characters when encoded. That is the example quoted on the forums: 57HrrfEw6ZgRS58dygiHhfN7vVhaPaBE7HrrfEw6ZgRS58dygiHhfN7vVhaPaBiTE7vVhaPaBE7Hr Could it be a mistake? - Original Message - From: Gregory Maxwell To: Amir Taaki Cc: "bitcoin-development@lists.sourceforge.net" Sent: Sunday, January 29, 2012 5:19 AM Subject: Re: [Bitcoin-development] Quote on BIP 16 On Sat, Jan 28, 2012 at 11:52 PM, Amir Taaki wrote: > How could you have a 70 byte long address without a P2SH scheme? Is this a > mistake? ... No it's not a mistake. P2SH _prevents_ needing long addresses. Lets unpack the acronym "pay to script _hash_". Hashes only need to be 128-256 bits in size or so to have acceptable security, so you don't need something longer than that for paying to a hash. Note that gavin is saying 70 characters, not bytes. Without some form of P2SH then only way for you to make a personal choice of asking people to pay to a two-factor protected account or two a multiparty trust that manages the finances of an organization is using some form of "P2S", pay-to-script. In other words, you'd have to have an address that encodes a full script specification for the sender to pay to, instead of just encoding its hash. As a result these addresses would be much longer (and potentially very long). The minimum size of a two address involving encoded script would be on that order, but they get bigger quite quickly if you add more options to the script (actually 70 sounds quite small, it should be more like 100 for a minimum two pubkey script). In addition to the unworkability of very long addresses as described by gavin (amusingly I am unable to copy and paste the quoted example in one go) a P2S solution has several problems which you might consider more or less important: (1) They are highly vulnerable to invisible substitution. E.g. I can trivially take a P2S address, change one or two characters and get a script which is redeemable by anyone. With P2SH you have to do computation which is exponential in the number of unchanged digits to get a look alike address. (2) The sender is fully responsible for fees related to the enlarged transactions. Even if _you're_ willing to take the txn-processing time and fee burden of a 30 person joint trust address, random e-commerce sites will not be and will randomly reject your addresses. (3) They create another input vector for non-trivial data which must be inspected and validated, potentially presenting an attack surface. (4) They leave the complicated (long) release rules in the transaction outputs. When a transaction is mined we can't be sure if it will ever be redeemed. The outputs are unprunable. In a future world where many nodes prune output space is far more important than input space and it would make sense to require more fees for it because we're never sure how long it would need to be stored (making it an attractive target for someone who wants to make Bitcoin unusable by spamming it with worthless data). P2SH reduces output sizes to the absolute minimum without inflating the total data size. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] Controlled block generation in fuzzer for testing blockchain
I added the ability to do controlled generation of blocks to gavin's fuzzer https://github.com/genjix/bitcoin/tree/fuzzer bitcoind -daemon bitcoind setfuzzpreviousblock 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f bitcoind setgenerate true It will start hashing the block with the previous hash field set to 0019d6689c085ae165831e934ff763ae46a2a6c172b3f1b60a8ce26f and the target as 0x1dff On completion it will dump the hex value of the block to debug.log and exit. You can then feed that block to your implementation in whatever controlled manner you wish (i.e with libbitcoin I made a simple tool in a few lines to read the hex and send it via the network in localhost). If anyone wants the libbitcoin tool then let me know and i'll paste it over on IRC. -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
[Bitcoin-development] All pre-BIP BIPs are not valid
Hi all, Luke Dashjr is telling me that BIP 20 was accepted as Final a year ago (before the BIP process existed). https://en.bitcoin.it/wiki/Bitcoin_Improvement_Proposals I respectfully disagree. I find it nonsensical to have a BIP to have been accepted before the BIP process existed. My feeling is that a BIP needs to go through the proper formalised motions in public before becoming accepted. The URI Scheme did not go through these motions. I did not know it was even accepted, and at least 2 implementations have objected to the standard as is. This is problematic because a standard is meant to be consensus building not enforcement from above. Ergo I am going to say: NO BIP EXISTED BEFORE THE BIP PROCESS. NEW BIPS ARE ALWAYS DRAFT STATUS. BIPS CHANGE STATUS AS SPECIFIED IN BIP 0001 Luke claims I do not have the ability to specify those conditions above. If there are any objections then please tell me. I did not get to observe the process for BIP 20, therefore I am not accepting it. Anybody is welcome to submit a competing BIP to Luke's BIP 20 (as has happened with BIP 16 and 17). -- Try before you buy = See our experts in action! The most comprehensive online learning library for Microsoft developers is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3, Metro Style Apps, more. Free future releases when you subscribe now! http://p.sf.net/sfu/learndevnow-dev2 ___ Bitcoin-development mailing list Bitcoin-development@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/bitcoin-development
