I think MSG_TX is fine. Simply sending an inv to the other node at startup
would work, but it's better to request it explicitly as it will let the
connecting peer configure a bloom filter before requesting mempool
contents. It's already too heavy for mobile clients to download the entire
mempool
I think it's pretty reasonable, although people will want to use node
flags to get into the addr broadcasts anyway.
That said, I suspect (based on previous discussions) that there would
be quite some pushback against putting extra functionality into the
core Bitcoin network. Most likely people
MacOS X 10.8 makes application signing borderline mandatory, in that
you cannot run unsigned apps unless you tweak your settings via the
control panel. You must sign with a certificate issued by Apple via
their identified developer program.
Windows allows but does not require signing. However,
OP_CODESEPARATOR 14
OP_DEPTH 182
I'm interested to see what scripts were using OP_DEPTH and
OP_CODESEPARATOR, as the latter appears to be useless to my eyes.
Could you give some tx ids which use unusual opcodes?
--
That'd be 7 bytes of nonce in the block header, which is
72,057,594,037,927,936 ~ 72 petahashes = 72,000 terahashes
So: the changes for version 2 blocks would be has height in the
coinbase, and has a 1-byte version number with a 3-byte extranonce.
I don't understand why more nonce bits
My point is that stuffing nonces into whatever spaces we can find to
eke out a bit more scalability in pools seems like a very short term
fix with potentially very long term consequences.
Although it may sound harsh, if your pool is struggling to keep up
with calculating merkle roots (which is
The Satoshi client uses a pure reentrant mutexes model
As you presumably already know, the reference client doesn't attempt
to parallelise most operations at all. Chain download is entirely
single threaded.
--
Live
Hi bitcoin-development,
blockchain.info generates non-BIP-compliant URIs in its QRcodes, as
does its iPhone app. They are of the form bitcoin://address not
bitcoin:address.
I asked Ben to fix this (social networks don't parse QRcodes after
all), but after explaining that social networks don't
I strongly agree, but this is *why* I suggested moving it to the wiki. I
recently had to choose an XMPP client and I looked on xmpp.org - after a
frustrating experience with their listing [1]
Probably because their listing is even more useless than any of the
proposals that were presented
Link?
It was a private conversation for some reason.
I also proposed this on this list (see the response in the tree
datastructures thread) along with more elaboration on IRC.
Ah OK. I wasn't paying much attention to those threads.
on this again until next week.
On Wed, Jun 20, 2012 at 2:41 PM, Mike Hearn m...@plan99.net wrote:
Two days ago on #bitcoin-dev:
21:01:19 sipa what was CTxDB::ReadOwnerTxes ever used for?
21:01:31 sipa maybe it predates the wallet logic
(read: it's not used anywhere in the code, and apparently wasn't
I've been having a discussion with d'aniel from the forums about how
to handle the possibility of a majority-miner conspiracy to raise
inflation, if most economic actors use SPV clients.
Because of how blocks are formatted you cannot check the coinbase of a
transaction without knowing the fees in
+list
On Mon, Jun 18, 2012 at 9:07 PM, Gregory Maxwell gmaxw...@gmail.com wrote:
In addition to the ECDSA caching, ECDSA can can easily be run on
multiple cores for basically a linear speedup.. so even with the
checking in place once ECDSA was using multiple threads we'd be back
to the DB
I switched the transaction database to use the Google LevelDB library,
which is a refactored out part of BigTable.
Here are my results. All tests are done on this hard disk:
* 0x04 [32-byte X coord] [32-byte Y coord]: uncompressed format
* 0x06 [32-byte X coord] [32-byte Y coord]: hybrid format for even Y coords
* 0x07 [32-byte X coord] [32-byte Y coord]: hybrid format for odd Y coords
So what's the actual difference in format? Is there any at all, or
it's just
-
From: Mike Hearn m...@plan99.net
To: Jeff Garzik jgar...@exmulti.com
Cc: Bitcoin Development bitcoin-development@lists.sourceforge.net
Sent: Friday, June 15, 2012 3:43 PM
Subject: Re: [Bitcoin-development] New P2P commands for diagnostics, SPV
clients
Yes, the format is something
I had to hit the sack last night as it was 2am CET, but I'd like to
sum up the discussion we had on IRC about scalability and SatoshiDice
in particular.
I think we all agreed on the following:
- Having senders/buyers pay no fees is psychologically desirable even
though we all understand that
Need to specify the format of how these arrive. It means that when a
new block is found instead of inv-getdata-block we'd see something
like inv-getdata-merkleblock where a merkleblock structure is a
header + list of transactions + list of merkle branches linking them
to the root.
Thinking
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
Actual BDB files are absolutely not deterministic. Nor is the raw
blockchain itself currently, because blocks aren't always added in the
same order (plus they get orphans in them)
That's true. Though if you prune up to the last checkpoint, orphans
before that point can be safely thrown away.
I'm pleased to announce the release of BitCoinJ 0.5, the library that
powers Android Wallet, SatoshiDice, Bitcoin Status, the server side part of
BCCAPI and much more.
This release focusses on bug fixes, making the build more standard and
completing the transition to the protobuf wallet format.
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
We're debating the descriptions on the thread. I provided rewritten
descriptions that try and keep with the theme per client goal, whilst
being less technical.
I think it's unclear how best to run this page. It's clear we need one
though. If everyone can just submit whatever they like then we'll
What computer is the initial start time 24-hours+ now? On normal
systems initial sync-up now takes a couple hours.
OK, I haven't tried a full block chain sync for a while. If it's only a
couple of hours that's great. Let's change that.
Bitcoin-qt is translated into a pretty broad set of languages (now— I
cant tell you how many of them are _good_). Listing language just
under multibit makes it sound like a distinguishing characteristic.
Fair enough then, let's take that out.
It sounds OK as long as you exclude nLockTimed transactions.
That said, if you broadcast a transaction that does not meet the fee
rules, you should be able to notice that it wasn't accepted by your
peers immediately. Today it's painful because the protocol isn't very
chatty - in bitcoinj I plan
Jeff asked for a BIP for the pong message, so here it is:
https://en.bitcoin.it/wiki/BIP_0031
--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second
TCP keep-alives aren't reliably implemented.
I've got reports that sometimes we struggle to keep connection to the
network on mobile, eg, because we roam into an area with poor
connectivity but not poor enough for the network stack to drop access
entirely. Being able to quickly check if the
I'm pleased to announce the release of BitCoinJ 0.4, the leading Java
implementation of the Bitcoin protocol. BitCoinJ implements simplified
payment verification, a lightweight mode in which no central server or
authority is needed but the resource requirements are still low enough to
be usable on
Why does anyone care what an address looks like?
If the user is seeing an address, that's a usability fail right there. It's
common today because AFAIK nobody finished off the URL handling support in
the main client for browser integration. It'd be a much better use of time
to finish off that
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.
Fixed addresses like that are a temporary thing during Bitcoins maturation
period. They lead to merchants
Base58 was chosen not for human readability but to make it easy to
copy/paste.
It was also chosen for hand-writeability, weirdly enough. That's why it
excludes some confusible characters. But Satoshi didn't really understand
how people would end up using Bitcoin, he originally imagined most
Perhaps a bit off-topic for this list, maybe there should be a
software/services announcements list? Anyway ...
I'm happy to announce version 0.3 of the leading Java implementation of the
Bitcoin protocol. BitCoinJ is a widely used library that forms the
foundation of projects as diverse as the
BIPs are either standards track (affects everyone, represents consensus),
informational (ie basically just summarizing the authors viewpoints on
things) or process.
My point is you can't have a credible standards track BIP until something
has been implemented end to end. I don't think it's a good
Sure, of course, as long as it's clearly labelled as just your thoughts, no
issues.
For dispute mediation the way I'd start is playing around with some UI
design stuff and a toy protocol underneath. Once the process is smooth from
the users POV (no seeing binary blobs disguised as text) then it
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 zgen...@yahoo.com wrote:
Hi,
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___
Interesting suggestion! So if I understand correctly, greensig would be
the signature generated from signing the transaction with the key of a
green address?
Sure. Or just a key. It wouldn't have to be an actual key used in
the block chain.
Sounds good - I guess I never thought in this
scriptPubKeys that use OP_EVAL contain a hash of a script. If I
understand correctly, that means to detect a transaction in a block
that is relevant to your wallet, that means you need to pre-calculate
every possible hash that might appear.
For the case of a single payment, that's not a problem.
I imagine a lot of the things on the contracts page will be implemented by
specialized software that interacts with the Bitcoin network directly.
Transactions would then be moved around, for example, by having clients do
HTTP POSTs of protocol buffers to servers that are listening and know how to
If I think you're trying to DoS me, why would I be nice to you?
The issue is, what if I'm not trying to DoS you, but something went wrong?
think response messages would just give an attacker another potential
attack vector, and it is clear from the debug.log what triggers a ban.
Only clear
Actually Steve, take a look at the bitcoinj mailing list today. Somebody has
already built this and has it running. It's accumulating data at the moment,
they'll announce it more widely soon. But I think there's no need to
duplicate work.
601 - 642 of 642 matches
Mail list logo
