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-develop
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 mo
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
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.
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"). Howe
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
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 messa
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 mailin
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@l
, 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", &
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?
Th
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 cov
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 landscap
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
--
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 res
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 s
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!
- Sponso
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-deve
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 h
lue 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
r 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: Monda
fying. 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
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
client
fresh.
- 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/
Mat
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 fi
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 Devel
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
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
> 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 bl
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 A
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
uired 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:
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, SP
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
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
> 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
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.sourcefor
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 som
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
om/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. Eventua
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 f
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 bring
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
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
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 bi
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))
{
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 al
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 th
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-developmen
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
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
* So
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 hi
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 implementation
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-dev
g and there's lots of missing functions like
strncasecmp, _strlwr, _fileno and swprintf.
From: Wladimir
To: Amir Taaki
Cc: "bitcoin-development@lists.sourceforge.net"
Sent: Saturday, February 25, 2012 7:18 AM
Subject: Re: [Bitcoin-developm
I followed the instructions from build-msw.txt and am getting the same issue
from here:
https://bitcointalk.org/index.php?topic=45507.0
MSYS shell:
cd /c/db-4.8.30.NC-mgw/build_unix
sh ../dist/configure --enable-mingw --enable-cxx
make
$ make
./libtool --mode=compile gcc -c -I. -I../dist/..
BIP 21 had broad consensus among the major implementations:
https://en.bitcoin.it/wiki/BIP_0021
BIP 19 is a document to propose adding a new payment type to the scripting
system's template list.
https://en.bitcoin.it/wiki/BIP_0019
I haven't fully evaluated it completely but it seems solid. My o
's up to the people who are making this stuff to decide :)
On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki wrote:
BIP 20 really has no support among implementations such as Bitcoin-Qt,
Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing
GUI projects (all with some form o
BIP 20 really has no support among implementations such as Bitcoin-Qt,
Electrum, MultiBit or Bitcoin-JS. As the most active and visible user facing
GUI projects (all with some form of URI Scheme), their opinion carries the most
weight. To a lesser degree Bitcoin-Qt has the large majority of user
Matt Corallo posted a modification of BIP 20 in an earlier email and I asked
him if he wanted to become the champion of that BIP he submitted.
It is a modification of BIP 20 sans the alternative non-decimal number stuff.
https://en.bitcoin.it/wiki/BIP_0021
Right now, I will ask the GUI client
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 feeli
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 wi
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.
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
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 a
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 ha
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.ne
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.
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
- 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
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.
-
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-
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
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.
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-
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 Ta
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 t
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
---
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
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 ambig
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 pre
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
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 sta
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
wan
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
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
> 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 type
- 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
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
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"
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 ar
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-
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
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 necessa
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 updatin
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 numb
ng 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
his 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 perf
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 :)
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 contin
1 - 100 of 106 matches
Mail list logo
