Let's try to get GBT 2.0 off the ground finally.. :)
Here's some wishlist items/ideas:
- Extremely low bandwidth use (binary protocol, with compression support)
- UDP-based transport protocol? (so message order need not be preserved at the
expense of latency)
- Ability to instruct miners to
This one looks entirely useless (it cannot be made secure), and the assertion
that it is necessary for atomic cross-chain transfers seems unfounded and
probably wrong...
Luke
On Friday, April 25, 2014 6:49:37 PM Tier Nolan wrote:
As part of the atomic cross chain system, outputs need to be
I believe you meant to link here instead?
https://github.com/TierNolan/bips/blob/bip4x/bip-0046.mediawiki
This looks reasonable from a brief skim over, but does not define any use
cases (it mentions necessary for atomic cross chain transfers, but does not
explain how it is useful for that -
On Friday, April 25, 2014 8:02:41 PM Tier Nolan wrote:
I don't think the cross chain system needs a BIP (except to justify this
one).
If cross chain transfer become popular, then it would be useful to ensure
that clients are interoperable, but first things first. If the
transactions aren't
On Wednesday, April 23, 2014 7:29:04 PM Pavol Rusnak wrote:
On 04/23/2014 09:00 PM, Tier Nolan wrote:
The point is to have a single system that is compatible over a large
number of systems.
There is such system and it is called BIP32.
On the other hand, in BIP64 we try to put a set of
On Wednesday, April 23, 2014 7:49:38 PM Pavol Rusnak wrote:
On 04/23/2014 09:44 PM, Luke-Jr wrote:
Why do clients need to use the features in BIP 64? If Electrum doesn't
want to use accounts, then it can just use account 0 for everything.
Refund chains are
As Andreas wrote earlier
On Wednesday, April 23, 2014 7:57:46 PM slush wrote:
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:
Any wallet should import all the coins just fine, it just wouldn't *use*
any
account other than 0. Remember addresses are used to receive bitcoins;
once the UTXOs
On Wednesday, April 23, 2014 8:01:16 PM Tamas Blummer wrote:
On 23.04.2014, at 21:55, Luke-Jr l...@dashjr.org wrote:
Any wallet should import all the coins just fine, it just wouldn't *use*
any account other than 0. Remember addresses are used to receive
bitcoins; once the UTXOs
On Wednesday, April 23, 2014 8:04:03 PM Pavol Rusnak wrote:
On 04/23/2014 10:01 PM, Luke-Jr wrote:
Yes, it should scan all possible (under the BIP-defined structure)
branches regardless of which features it supports.
So you suggest to scan for accounts, show balances but don't allow user
On Wednesday, April 23, 2014 8:16:45 PM Pavol Rusnak wrote:
On 04/23/2014 10:09 PM, Luke-Jr wrote:
Scan all branches for UTXOs, then you have the balance for the wallet.
Account balances are metadata, so cannot be known from the seed alone.
If you want to have a way to restore accounts, you
On Wednesday, April 23, 2014 8:35:50 PM Pavol Rusnak wrote:
On 04/23/2014 10:32 PM, Luke-Jr wrote:
f) I missed the part where BIP 32 redefined account to mean subwallet
instead of what has traditionally been called account in Bitcoin.
Ah, okay. The last time I saw Bitcoin-qt it was still
On Wednesday, April 23, 2014 8:43:57 PM Pavol Rusnak wrote:
On 04/23/2014 10:41 PM, Luke-Jr wrote:
I don't see how. The user knows he has money in different subwallets. As
long as he has a way to specify which subwallet he is accessing in
single-subwallet clients, there shouldn't
On Wednesday, April 23, 2014 9:33:48 PM Pavol Rusnak wrote:
On 04/23/2014 11:22 PM, Gregory Maxwell wrote:
Hopefully it would be clarified as only a MUST NOT do so silently...
I have funds split across two wallets and it WONT LET ME SPEND THEM
sounds like a terrible user experience. :)
On Saturday, April 12, 2014 2:26:07 PM Oliver Egginger wrote:
Hello,
so far, nothing yet?
See: https://launchpad.net/~bitcoin/
I'm developing currently a LiveCD for hot/cold wallet management on
Ubuntu LTS basis. For critical vulnerabilities I have to provide timely
updates. I have now
://gist.github.com/luke-jr/9920788
--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
on advanced category theory. I'm
sure there are many applications to Bitcoin.
On Tue, Apr 1, 2014 at 9:12 PM, Luke-Jr l...@dashjr.org wrote:
On Tuesday, April 01, 2014 7:00:07 PM Pieter Wuille wrote:
Hi all,
I understand this is a controversial proposal, but bear with me please.
I believe
On Saturday, March 22, 2014 8:47:02 AM Peter Todd wrote:
To make a long story short, it was soon suggested that Bitcoin Core be
forked - the software, not the protocol - and miners encouraged to
support it.
There's been at least one public miner-oriented fork of Bitcoin Core since 0.7
or
On Thursday, March 13, 2014 4:37:02 PM slush wrote:
Display based on locale.
Please don't bring locale into this. Bitcoin has always been intentionally
locale-independent (hence BTC using xxx,xxx,xxx.xx format even in locales
which swap the commas and periods). Localising display makes
On Wednesday, March 05, 2014 4:21:52 PM Kevin wrote:
How can we patch this issue?
No need, it is not an issue for Bitcoin.
Properly used, there is only ever one signature per public key.
Luke
--
Subversion Kills
On Sunday, March 02, 2014 11:02:14 PM Tom Geller wrote:
Peter writes:
MtGox does host the bitcoin wiki, so yes, the funds probably do go to a
wallet held by MtGox in some fashion.
The foolishness of sending a payment to a Mt. Gox-held wallet -- which is
required to edit the wiki --
On Monday, March 03, 2014 3:34:27 AM Kevin wrote:
Hello. I am a developer and I wish to contribute to bitcoin. Where is
the best place to start?
Unit tests. This will be valuable to the projects and also help you learn how
things work.
On Monday, February 24, 2014 11:06:30 PM Andreas Petersson wrote:
Regarding 80 bytes vs smaller: The objectives should be that if you are
determined to put some extra data in the blockchain, OP_RETURN should be
the superior alternative. if a user can include more data with less fees
using a
On Wednesday, February 12, 2014 8:27:52 PM Mark Friedenbach wrote:
On 02/12/2014 08:44 AM, Alan Reiner wrote:
Changing the protocol to use these static IDs is a pretty fundamental
change that would never happen in Bitcoin. But they can still be
useful at the application level to mitigate
On Sunday, February 09, 2014 5:12:14 PM Peter Todd wrote:
We have an embedded consensus system and we want to be able to upgrade
it with new rules.
This asserts a central authority and gives developers too much power.
On Sunday, February 09, 2014 11:33:02 PM Pieter Wuille wrote:
The proposed document is here: https://gist.github.com/sipa/8907691
Rule 3 4 are already enforced.
AFAIK nVersion==3 transactions are not currently considered non-standard?
Luke
On Monday, January 20, 2014 5:42:37 PM slush wrote:
Hi all,
during recent months we've reconsidered all comments which we received from
the community about our BIP39 proposal and we tried to meet all
requirements for such standard. Specifically the proposal now doesn't
require any specific
On Friday, January 17, 2014 8:53:47 PM Jeff Garzik wrote:
vendor hat: on BitPay sure would like to see CPFP in upstream.
I think the main hurdle to merging was that various people disagreed
on various edge case handling and implementation details, but no
fundamental objections.
Heck, even
, please tell.
Wladimir
https://github.com/bitcoin/bitcoin/pulls/luke-jr
These are pretty much all well-tested and stable for months now.
--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More
On Friday, January 17, 2014 2:39:31 AM Christophe Biocca wrote:
To clarify, there are proposals to make miners recognize this
situation and account for it, only eligius is running it at the moment
IIRC:
http://bitcoin.stackexchange.com/questions/8390/are-there-any-pools-or-larg
On Wednesday, January 01, 2014 4:53:42 AM Peter Todd wrote:
On Tue, Dec 31, 2013 at 01:14:05AM +, Luke-Jr wrote:
On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
that you are using merge-mining is a red-flag because without majority,
or at least near-majority, hashing power
On Monday, December 30, 2013 11:22:25 PM Peter Todd wrote:
that you are using merge-mining is a red-flag because without majority, or
at least near-majority, hashing power an attacker can 51% attack your
altcoin at negligible cost by re-using existing hashing power.
I strongly disagree on this
On Tuesday, December 17, 2013 10:41:30 PM Troy Benjegerdes wrote:
I want to get some feedback.. I've used distributed version control
systems for a long time, and the most useful feature is to be able
to merge two different forks.
So what's the equivalent of this for Bitcoin or other
On Sunday, December 08, 2013 8:51:07 PM Drak wrote:
Otherwise, who has admin rights to the code projects
(github/sourceforge/this mailing list)? Those people have proven they can
be trusted so far.
Can someone explain how Sirius has proven the least bit untrustworthy?
Luke
On Sunday, December 08, 2013 9:16:09 PM Saïvann Carignan wrote:
1) Who pays for it? Most obvious answer: Foundation. However there's
currently a fairly clear line between the foundation website and the
bitcoin.org http://bitcoin.org website. I personally am fine with the
bitcoin foundation
On Thursday, December 05, 2013 1:37:10 PM Wladimir wrote:
Hello all,
A while ago after discussion on the mailing list a repository was set up to
store the BIP documents, as this is deemed a more secure solution than
having them on the wiki:
https://github.com/bitcoin/bips
To prevent
On Saturday, November 16, 2013 12:41:56 AM Drak wrote:
So a payment clears after one confirmation, but you might want to wait
until the payment has been confirmed n times.
Then at least you are not using the same word for two different meanings
and you're using stuff more familiar in popular
On Thursday, November 14, 2013 11:45:51 AM Melvin Carvalho wrote:
Would now be a good time to start thinking about changing the default
display in the software. Perhaps initially it could be a dropdown display
option, then at some point mbtc becomes the default?
There's already a dropdown
On Thursday, November 14, 2013 10:07:58 PM Allen Piscitello wrote:
Obviously the answer is to just display all fees and trading rates as BTC
or MBTC (.005 MBTC fee? how cheap!). On a more serious note, the
transition should definitely be thought out well as it could be very
damaging to
On Thursday, November 14, 2013 10:53:16 PM Alan Reiner wrote:
I really like the XBT idea. It makes a lot of sense to match the ISO
currency symbol (though the ISO guys will have to adjust the way they've
defined the XBT). And I do agree that going right to uBTC and
skipping mBTC makes sense,
On Saturday, November 09, 2013 8:16:07 PM Chris Evans wrote:
maybe add an optional note field to transaction so the receiver knows who
sent the btc
This mailing list is for development discussion, NOT bug reports nor feature
requests.
Bitcoin does not currently support any built-in mechanism
On Sunday, November 03, 2013 1:19:51 AM Allen Piscitello wrote:
I actually had a use case in my case where it was possible, and that was
the check I used to get around it, just configured it so that I always
generated a new key when I needed to set up a 2 of 2 Multisig Refund Tx.
It was
On Saturday, November 02, 2013 5:01:43 AM bitcoingr...@gmx.com wrote:
In celebration of the 5 year anniversary of the Bitcoin whitepaper, we are
delighted to introduce the Message Signing based authentication method. In
brief, the authentication work as follows:
Server provides a token for the
On Sunday, October 27, 2013 2:32:57 PM Mike Hearn wrote:
Currently bitcoinj gets a small but steady stream of bug reports of the form
my transaction did not propagate. It's flaky because the library picks one
peer to send the transaction to, and then watches it propagate across the
network.
On Sunday, October 27, 2013 10:52:25 PM Gavin Andresen wrote:
If anybody has strong feelings about what the reject categories should be,
then please take the time to write a specific list, I can't read your
mind
It might make sense to use the rejection reasons from BIP 22 where applicable.
On Saturday, October 26, 2013 3:31:05 AM Gregory Maxwell wrote:
One limitation of the payment protocol as speced is that there is no
way for a hidden service site to make use of its full authentication
capability because they are unable to get SSL certificates issued to
them.
A tor hidden
On Thursday, October 24, 2013 5:29:18 PM thoma...@gmx.de wrote:
I would like to propose a new BIP, that replaces BIP0039.
BIP 39 is still a draft. Just suggest revisions to the author(s)...
--
October Webinars: Code for
On Monday, October 21, 2013 7:38:37 PM Jean-Paul Kogelman wrote:
1) Should the protocol specification page also be codified into BIP(s)?
Probably wouldn't hurt, but it'd likely need a rewrite in a more modular and
formal form.
2) Should the current wiki pages be taken down / forwarded to the
On Saturday, October 19, 2013 9:16:24 PM Jean-Paul Kogelman wrote:
I have a question regarding this part. I wrote a BIP for base 58 encoding /
encryption of BIP 32 root keys. The BIP page states that we shouldn't add
to this list ourselves, but should contact you for a BIP number. I have
Faré,
Let me start out by noting that there are plenty of good ideas which could be
implemented, but haven't been yet, and might take a long time to get to. There
are only a couple handfuls of Bitcoin developers, and even fewer of us who are
able to work full-time on Bitcoin development.
pushed three branches to https://github.com/luke-jr/leveldb :
bitcoin-1.5 Our old/unreleased LevelDB 1.5 fork, for reference
bitcoin Our LevelDB 1.7 fork, included in 0.8.x
bitcoin-upOur LevelDB 1.7 fork, merged with upstream LevelDB 1.12
A diff from current master (Ripple LevelDB
Chris,
First, an important point: addresses are not wallet ids. They are single-use
destinations for a single transaction. It isn't intended that anyone should
remember them, just that they should send them electronically (or with eg, QR-
Codes). Bitcoin does not (yet?) have a person/wallet
On Sunday, July 28, 2013 7:39:08 PM John Dillon wrote:
What are your thoughts on creating a whitelist for specific opcodes that
would apply to scripts serialized using P2SH, retaining the existing
standard whitelist for scriptPubKeys? (I would still recommend dropping
pay-to-pubkey and
On Tuesday, July 23, 2013 10:02:28 PM Scott Howard wrote:
1) It appears that the consensus of upstream developers is that any
distributed binary should only be linked against libraries that the
bitcoin developers have tested and audited since any compatibility bug
is a risk to both the user
On Wednesday, July 24, 2013 3:54:25 AM Wendell wrote:
Is there a substantial barrier to endian independence in the Bitcoin
codebase?
I got the obvious stuff ('endian' branch in my repo), but it still didn't work
when I moved on. I haven't had time to try to figure out why not yet.
Luke
On Sunday, July 14, 2013 7:22:10 PM John Dillon wrote:
Merged mining is not mining the coin for free. The total reward (ie
btc + frc + nmc + dvc) should tend to equal the mining costs. But the
value comes from demand, not costs. So if people demand it more it
price will rise no matter how
On Sunday, July 14, 2013 7:42:06 PM Pieter Wuille wrote:
On Sun, Jul 14, 2013 at 07:33:06PM +, Luke-Jr wrote:
The issue is that unless there is a cost to mining a *invalid* block
the merge mined coin has little protection from miners who mine invalid
blocks, either maliciously
On Monday, July 15, 2013 12:12:23 AM Peter Todd wrote:
On Sun, Jul 14, 2013 at 08:16:41PM +, Luke-Jr wrote:
P.S. How about a Zerocoin with no-reward/PoSacrifice merged mining as
well as (rewarded) Prime POW; maybe with no subsidy halving, to try a
new economic idea as well ;)
Your
On Thursday, June 27, 2013 5:30:21 PM Jeff Garzik wrote:
* Very real possibility of an overall net reduction of full nodes on P2P
network
Even a reduction of *nodes at all*, as I've never seen a listening bitcoinj or
MultiBit node. :/
Jim, will MultiBit be adding p2p listening support?
I'm
On Friday, June 14, 2013 8:06:54 PM Peter Todd wrote:
On Mon, Jun 10, 2013 at 09:23:14PM +, Luke-Jr wrote:
Might as well just use higher difficulty shares (each one audited) for
the same effect. Block proposals allow the miner to tell the pool its
transaction set once (per txset change
Note that the earn a mixture of BTC and TBC, but not both in full volume
only works for TBC because the price is by definition fixed with BTC.
I'm not sure how you could implement something like this for an altcoin where
the price is floating independently of Bitcoin.. that is, how you would
On Tuesday, June 11, 2013 1:11:33 PM Melvin Carvalho wrote:
For the sake of argument let's say that opaque means that you can tell
nothing about the address by examining the characters.
This is true or false based on CONTEXT.
Obviously, an implementation of transaction handling (eg, wallets)
On Monday, June 10, 2013 9:09:13 PM Peter Todd wrote:
# Protocol Work
This is basically done.
Basic idea is the miner makes two connections, their pool, and a local
bitcoind.
They always (usually?) work on the subset of transactions common to both
the pool's getblocktemplate and their
above.
I could be totally misreading this thread, too, so please allow me some
slack if I have!
On Thu, Jun 6, 2013 at 12:14 PM, Luke-Jr l...@dashjr.org wrote:
On Saturday, June 01, 2013 7:30:36 PM Peter Todd wrote:
scriptPubKey: data OP_TRUE
...
Along with that change anyone
On Thursday, June 06, 2013 8:16:40 PM Andreas M. Antonopoulos wrote:
This doesn't work like you might think: first of all, the fees today are
greatly subsidized - the actual cost to store data in the blockchain is
much higher than most storage solutions. Secondly, only the miner receives
On Thursday, May 30, 2013 2:54:00 AM grarpamp wrote:
Should there not be a 0.8.2 branch laid down at 09e437b (v0.8.2)
in which the like of release build stoppers or critfixes such as d315eb0
are included... for those tracking that level of defect without
wishing to track all the growing post
On Thursday, May 16, 2013 10:02:05 AM bitcoingr...@gmx.com wrote:
One of the main goals will be to separate the wallet from the node, as we
have already done with mining.
How is this different from what Electrum has already done?
Luke
On Thursday, May 16, 2013 10:55:44 AM Addy Yeow wrote:
Is the number representing the count for the client nodes?
I was curious of the count myself earlier this week and started to
traverse down the network using getaddr message starting from seed
nodes and found upward to 57k nodes running
On Saturday, May 25, 2013 8:25:35 AM Melvin Carvalho wrote:
It might be an idea to have 'rule change' fixes and 'bug fix' releases go
out separately
Bitcoin is a consensus system. You can't run clients with different rules on
the same blockchain/network - it just won't work! Maybe we're now
On Saturday, May 25, 2013 3:36:46 AM Robert Backhaus wrote:
Here is the link to the FreeBSD build system 'port' that I am planning to
get committed when 0.8.2 is released. Any comments appreciated.
The Makefile mostly just applies the users request for GIU/QR/UPNP. The
major change is using
On Wednesday, May 22, 2013 2:20:22 PM Jeff Garzik wrote:
On Wed, May 22, 2013 at 10:12 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
On 22 May 2013 16:07, Jeff Garzik jgar...@exmulti.com wrote:
On Wed, May 22, 2013 at 6:27 AM, Melvin Carvalho
melvincarva...@gmail.com wrote:
On Sunday, April 14, 2013 5:09:58 AM Peter Todd wrote:
Currently signmessage/verifymessage only supports messages signed by a
single key. We should extend that to messages signed by n-of-m keys, or
from the users point of view, P2SH multisig addresses.
I think it would be wise to figure out HD
On Saturday, March 23, 2013 10:42:26 AM Randy Willis wrote:
Introducing super-nodes with thousands of connected peers can greatly help
here.
UDP is connectionless.
I would hope any UDP bitcoin protocol doesn't try to emulate a connection. :/
Luke
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote:
I don't think anyone is mining using bitcoind 0.7 or later?
slush, BTC Guild, ozcoin too I think, several others.
Not for producing coinbases (where BIP 34
On Saturday, March 23, 2013 5:47:46 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:43 PM, Luke-Jr l...@dashjr.org wrote:
On Saturday, March 23, 2013 5:28:55 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:09 PM, Luke-Jr l...@dashjr.org wrote:
I don't think anyone is mining using bitcoind
On Saturday, March 23, 2013 6:21:32 PM Jeff Garzik wrote:
On Sat, Mar 23, 2013 at 1:51 PM, Luke-Jr l...@dashjr.org wrote:
bitcoind is nowhere in the implementation of the miner end of BIP 34.
Again, not strictly true.
bitcoind's 'getblocktemplate' RPC call used by some supplies the block
On Friday, March 15, 2013 5:06:20 PM Benjamin Lindner wrote:
On Mar 13, 2013, at 8:18 PM, Cameron Garnham da2...@gmail.com wrote:
For me, everyone signed up to bitcoin thinking that there was a 1MB /
block limit. The lock limits were unexpected, and could be considered
extremely
controversial changes.
I figured 2 MB in 2-3 years was fairly uncontroversial.
If not, let's scrap that idea for now.
Luke-jr, any chance in getting you to revise your proposal to narrow
the scope to things that don't need serious debate?
It was a one-time start the conversation proposal.
I expect what
clients *is by definition* a
hard fork.
Proposal:
1) Patch the pre-0.8 branches to support an increased lock count, whatever
number is required to make sure that this problem never shows up again at
the current block size (I defer to Luke-Jr and gmaxwell's numbers on this).
This is a hard fork
On Wednesday, March 13, 2013 6:01:02 PM Michael Gronager wrote:
Please note that it was not 0.8 that had issues, but 0.7(and downwards).
While 0.7 and earlier do have issues, they also define the Bitcoin protocol.
0.8's failure to comply with the protocol is an issue.
On Wednesday, March 13, 2013 6:27:13 PM Mark Friedenbach wrote:
Luke-Jr is suggesting that we add-to/modify the bitcoin protocol rules
which all verifying implementations must adhere to. I'm suggesting that we
instead change the old codebase to do what we expected it to do all along
(what 0.8
On Tuesday, March 12, 2013 7:03:54 AM Alan Reiner wrote:
I'm sure it won't be long before Slashdot and a variety of sources start
reporting on this event. Bitcoin has been in the media a lot lately, so
this story is likely to get some attention. The blowback of this event
is mostly
On Monday, March 11, 2013 7:27:51 PM Rune K. Svendsen wrote:
From: Rune K. Svendsen runesv...@gmail.com
On the Main tab in the Options dialog, it previously said a minimum
fee of 0.01 is recommended. This amounts to about $0.50 at today's
price. Change this to 0.001 to be more sensible. We
On Monday, March 11, 2013 9:17:25 PM Rune Kjær Svendsen wrote:
On Mon, Mar 11, 2013 at 9:46 PM, Luke-Jr l...@dashjr.org wrote:
On Monday, March 11, 2013 8:34:52 PM Rune Kjær Svendsen wrote:
Ok. I'll fork on Github. Looking at the source, and some Qt
documentation,
it should
On Saturday, February 09, 2013 2:33:25 PM Timo Hanke wrote:
Why don't you use namecoin or another alt-chain for this?
Because namcoin tries to solve a different problem, DNS, whereas I want
to establish an identity for a payment protocol.
What is the technical difference here? Namecoin ties
On Friday, February 08, 2013 11:49:09 PM Gavin Andresen wrote:
Windows builds are varying with every compile, and I think I finally
figured out why: we are not passing the -frandom-seed flag down into
the leveldb build (I used objdump to dump two different binaries, and
they differed only in
On Monday, November 26, 2012 11:32:46 PM Gregory Maxwell wrote:
Obviously the state of the world with browsers is not that good... but
in our own UAs we can do better and get closer to that.
This effectively centralizes Bitcoin (at least in the eyes of many) and even
if each competing client
On Tuesday, November 06, 2012 6:47:34 PM Gavin Andresen wrote:
Thursdays at 18:00 UTC (6PM Europe/1PM east US/10AM west US) seem to
be a good time for the core dev team to meet on the #bitcoin-dev
freenode IRC channel to chat.
I'd like to talk about:
o Can we put together a TODO list to
On Tuesday, November 06, 2012 7:56:23 PM slush wrote:
On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote:
But more important to the success of BIP today, I think, is encouraging
wider community participation.
It's not about BIP process, it's possibly about content of particular
On Sunday, October 14, 2012 8:52:33 PM Kyle Henderson wrote:
Given that sourceforge has shown to restrict access to a number of
countries at the request of the USA
This needs some clarification. If the USA has requested it, then presumably
there's some legality involved, and our US developers
On Monday, September 10, 2012 3:07:52 PM Matthew Mitchell wrote:
Here is a BIP draft for improving the block relaying and validation so that
it can be done in parallel and so that redundancy can be removed. This
becomes more beneficial the larger the block sizes are.
to enabled)
luke-jr https://github.com/bitcoin/bitcoin/pull/1431
11) MAYBE: getblocktemplate ('getmemorypool', post IRC debate)
luke-jr https://github.com/bitcoin/bitcoin/pull/936
+
+ m) getmemorypool: longpolling support
+ luke-jr https://github.com/bitcoin/bitcoin/pull/1355
+
+ m) Refactor
On Monday, July 30, 2012 8:26:12 PM Amir Taaki wrote:
https://en.bitcoin.it/wiki/BIP_0022
Note that the Pooled Mining parts have already been moved to:
https://en.bitcoin.it/wiki/BIP_GMPPM
It just needs a number assigned (as the last part).
On Sunday, July 29, 2012 10:17:51 AM Mike Hearn wrote:
I guess Gavin would be the final signer.
Considering that Gavin is not interested in participating in any way in the
stable versions, I would prefer to see someone else responsible for OS-vendor
signing.
On Friday, July 27, 2012 5:59:20 AM grarpamp wrote:
I now have an 1.8 ghz p3 celeron (128k cache) which should be
substantially slower than your machine, running vintage 2.6.20 linux.
Unfortunately I forgot to turn on timestamp logging so I don't know
how long it took to sync the chain,
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
FWIW, all this argumenting is why my original suggestion for a Clients list
focussed on objective information in alphabetical order.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways
On Sunday, June 17, 2012 11:04:42 PM grarpamp wrote:
https://github.com/bitcoin/bitcoin
https://git.gitorious.org/bitcoin/bitcoind-stable
The latter is Luke's backports of security and stability fixes to
otherwise unmaintained old versions.
Ah ok, coming from cvs/svn, it's a bit
On Saturday, June 16, 2012 11:39:00 PM Gregory Maxwell wrote:
On Sat, Jun 16, 2012 at 5:41 PM, Gavin Andresen gavinandre...@gmail.com
wrote:
RE: 0x06/0x07 'hybrid' public keys:
Any opinions? Forbidding it certainly makes alternative implementation
slightly easier in the future, but I'm not
Block 177618 was rejected by BIP16-enabled backports (0.4.x and 0.5.x) due to
containing a P2SH redemption with over 200 bytes in. Since the BIP16 code uses
IsPushOnly to check the scriptSig for compliance, and IsPushOnly in these
versions also enforced the 200-byte is standard rule, they were
On Monday, June 04, 2012 1:43:42 AM Peter Vessenes wrote:
Does it have asymmetric payoff for an attacker, that is, over time does it
pay them more to spend their hashes attacking than just mining?
That depends on the pool's reward scheme. Some complicated forms are capable
of getting bonus
1 - 100 of 164 matches
Mail list logo
