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.
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
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
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.
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___
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,
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
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
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
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
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
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
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.
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
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.
Yeah, for actually storing transactions the approach Satoshi uses of
relying on a database engine makes sense and is what the code already does,
so I'm not sure why this is a problem.
The real problem with Satoshis code for scaling down to smaller devices
(and one day desktops too) is the need to
Apologies if this has been discussed elsewhere. I don't recall us ever
reaching a solid conclusion on it.
A node that has pruned its block chain cannot serve the chain to new
nodes. So there are three options for bootstrapping a newly installed
node:
1) Have some kind of special archival nodes
If we wanted to go the route of shipping pruned chains I'd prefer to
have a deterministic process to produce archival chains
Yeah, that sounds reasonable. I mean, I can't see why pruning would
not be deterministic. So if you download a binary that contains a
pre-indexed and pruned chain up to
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 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
-
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
* 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
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:
+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'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
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 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
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
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
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?
--
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,
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
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
Why Signing the input scripts as well would obviously make it
impossible to construct a transaction?
As it states in the source code, signatures cannot sign themselves. If
scriptSigs were included in the data that is being signed, the act of
inserting the newly calculated signature for one
Sounds good— my only concern is that nodes will repeat their own
transactions but not the unconfirmed parents.
Nodes repeat wallet transactions and any previous transactions that
are not yet included in the chain (see
CWalletTx::RelayWalletTransaction). So I don't think it's an issue.
(ok,
I'm pleased to announce the release of version 0.6 of bitcoinj, the leading
Java implementation of Bitcoin. You can download the source from Google
Code, or use the release-0.6 branch from git. Our Nexus repository will be
updated soon.
This release focuses on improved compliance with the
I've been thinking about the requirements for a payment protocol
lately. It seems we have consensus that we need one of these. Pieter
has a gist on the topic here: https://gist.github.com/1237788
IMHO we'll want to move away from send X BTC to address Y and more
towards upload to me transactions
I think it's worth pondering the different things we may want in
future, even if that future is quite far out, just to ensure we have a
robust design that won't box us in later. Brainstorming feature ideas
now doesn't commit anyone to implementing them, but it may help
improve the final v1 design.
+gary
Electrum also has a daemon for merchants.
Well, I suggest taking it up with Thomas directly. A thread here won't do much.
Considering the dislike of
Java that exist reflexively in much of the non-java community and the
greater ease of deployment and the integration of type-2 split key
No objections.
On Sun, Oct 21, 2012 at 7:05 PM, Gavin Andresen gavinandre...@gmail.com wrote:
Any objections from other transaction-validating implementations?
I strongly support more precisely defining the transaction validity
rules by changing the reference implementation.
--
--
Gavin
I've written a draft BIP describing the bloom filtering protocol
extension developed by myself and Matt.
https://en.bitcoin.it/wiki/BIP_0037
(yes I know there's some kind of process around getting allocated a
number - it seems overkill for this).
Please read it and let me know if there are any
Some questions:
* why limit the number of matching transactions to 255?
Copy/paste error in the does :(
* what does each hash and key in the output script mean exactly? what
about the output script in its entirety?
It's an informal way to say data elements. If you insert a key then it
What is the worst-case for an attacker interested in trying to get you
to saturate your upstream bandwidth or use lots of memory? Set a
bloom filter that matches everything, and then start requesting old
blocks in the chain?
It would be slightly worse than shipping a full block but not
Presumably these components will just get implemented a few times in
some carefully constructed library code, so I don't see an
implementation complexity argument here— except the fact that it isn't
what Matt has implemented so far.
Well, yes, that is basically the implementation complexity
Because I can potentially waste bandwidth of all nodes forever (well as long
as users are still scanning blocks with my transactions in them) with O(1)
work.
And this gets you what?
Users who have active wallets will have their bandwidth wasted for as
long as you keep up the attack. Once you
I won't be able to make it this time. My feeling is IRC is a good place to
bounce ideas around when time and people happen to be available, but having
meetings there will inevitably lead to decision making that's better done
in a slower manner via email.
Comments:
BIP process: are we happy
there's no re-org handling at all.
If Electrum does end up doing all SPV work correctly, how is it different
to MultiBit? Just the deterministic wallet seeding?
On Fri, Nov 16, 2012 at 4:59 PM, Mike Hearn m...@plan99.net wrote:
Great to hear
On Tue, Nov 27, 2012 at 9:43 AM, Michael Gronager grona...@ceptacle.com wrote:
* What if the SignedReceipt is not received AND the transactions IS posted on
the p2p.
I think this is a problem with confusing terminology rather then the
spec itself.
The original formulation had a receipt being
That hash would then be reported via some secure channel outside of bitcoin's
domain.
OK, I see. I guess that could be a reasonable fallback for the case
where you have a secure channel.
I don't understand what the relevance of multi-factor is to invoices?
Yes, exactly. It's about paying who
Cool, will check it out soon.
libccoin should work on Windows. picocoin will work on Windows,
but be a bit less secure than other platforms due to lack of fork.
FYI, Windows has quite good sandboxing support. You could implement
the same thing later with Win32 if you want.
I'd still like to understand the rationale for having the merchant
broadcast the transaction
There are several reasons for this:
1) P2P network sockets are a limited resource and bringing up
connections to the network, whilst somewhat fast today, is not
guaranteed to be fast in future. Passing
I found that the problem is the version of the Qt SDK I used didn't
like the new MacOS version. Re-installing Qt fixed it.
On Mon, Nov 26, 2012 at 4:05 PM, Mike Hearn m...@plan99.net wrote:
It appears that something about Boost doesn't play nicely with the default
build instructions (possibly
The main source for these 1 Satoshi payouts is Sahtoshi Dice.
Because people are making 1 satoshi bets, or is this part of their
messaging system?
Pieter is right, getting consensus behind your proposal is too hard
and it's not likely to ever happen (I wouldn't support it, for one).
Outputs
It's part of their messaging system. Every losing play results in a
new 1e-8 output being created.
Every losing play? That's ... not excellent.
Well, this why the payment protocol spec has a way for merchants to
reply to customers with text instead of outputs.
Perhaps it could be improved by cleaning up dust from any address by default
(not just ones already included in the tx), with the option for the user to
disable that behavior. After all, anonymity was never a core feature of the
network
It's cool that Armory already does this. I never had
So, if a bitcoin client is getting Invoice messages via email or from
a web server, the version will be specified as part of the MIME type;
for example:
Content-Type: application/x-bitcoin-invoice; version=1
The version= syntax is part of the MIME standard.
I think that's OK. However, you
It sounds to me that you're insisting that you're asking people who
oppose degrading our recommendations to commit to a costly rushed
development timeline. I think this is a false choice.
Hardly. I don't have any particular timeline in mind. But I disagree
we have forever. New ideas have a
I was under the impression that connectedness was the real metric of
concern
I think the real thing we need full nodes for is sockets where by
socket I mean resources needed to serve another node.
Last year we actually ran out of sockets and it took forever for new
nodes to connect because so
Escrow/multisig is complicated enough to wait for another day. But
certainly having a payment protocol is an important step towards it
On 6 Dec 2012 07:32, Andreas Petersson andr...@petersson.at wrote:
During/before the Payment Request there should be a method to exchange
the public keys to be
Re: the newest spec. Rather than make the signature over the
concatenation of, why not just make it a signature over the
serialized protobuf minus the signature field (as I did in my demo
code). Otherwise it seems like we'd need more code than really
necessary. We can state explicitly tags must be
OK. I want to keep the signature field required, though, so how about:
signature: digital signature over a protocol buffer serialized variation of
the SignedPaymentRequest message where signature is a zero-byte array and
fields are serialized in numerical order (all current protocol buffer
mitigations into something like this, for the
same reason HTML doesn't impose a maximum page size. It's in the
message builders interest to ensure it gets read by all users.
Crashing their clients doesn't achieve anything as long as the crash
isn't exploitable.
On Fri, Dec 7, 2012 at 11:45 AM, Mike
yeah... I had similar thoughts on what to do if some Outputs specify an
amount and others don't. I'm still waffling on whether or not I like
allowing repeated Outputs; a single Output would make the spec a fair bit
simpler
Yes, but at the cost of privacy. Generators of payment requests always
Thanks for the thoughts. For those who don't know, Stephen works for BitPay.
My first observation is that the proposal is too heavily oriented around a
merchant/customer interaction.
The term merchant is just being used to mean the entity requesting
the payment. I'm hopeful that in future
++, which perhaps ends up making
gcc stricter than it's supposed to be.
On Thu, Nov 29, 2012 at 8:34 PM, Mike Hearn m...@plan99.net wrote:
I found that the problem is the version of the Qt SDK I used didn't
like the new MacOS version. Re-installing Qt fixed it.
On Mon, Nov 26, 2012 at 4:05 PM
Here's a quick update on where we're up to.
Thanks to Matts excellent work, I was able to test his bitcoinj and
bitcoin-qt work together today. There are a few minor tweaks needed,
but I feel like we're maybe a week away from having all the code in a
mergeable state. Here is the remaining work:
Oh, one last stat - syncing the entire chain with a wallet containing
two keys and a 0.0001 FP rate (one or two FPs every 5 blocks or so)
resulted in a download of about 46mb of data.
On Fri, Jan 11, 2013 at 3:11 PM, Mike Hearn m...@plan99.net wrote:
I did some very rough initial performance
Matts latest code has been tested by Andreas and seems to work
correctly. He had to extend the client a bit to refresh the filter
every 25k blocks because even with the extra flag, eventually the
filter degrades into uselessness, but it did still improve the
situation quite a bit.
Because it's
algorithmic change I would like to
make to the way the hash function is computed really quick before it
gets merged, I'll have that finished up by the end of today.
Matt
On Wed, 2013-01-16 at 11:43 +0100, Mike Hearn wrote:
Matts latest code has been tested by Andreas and seems to work
, as otherwise there's a
risk that 0.7 snapshot nodes will get overloaded.
On Wed, Jan 30, 2013 at 12:09 PM, Mike Hearn m...@plan99.net wrote:
Andreas has uploaded Android builds that use the new bloom filtering and
peer selection code (also, dependency analysis of transactions).
The performance gain
Can somebody please unlock the BIP wiki page? I don't know why it was
locked but it's stale.
On Wed, Jan 30, 2013 at 12:13 PM, Mike Hearn m...@plan99.net wrote:
Sorry, to clarify, these are test builds available here:
https://code.google.com/p/bitcoin-wallet/downloads/detail?name=bitcoin
So what exactly was the OP_RETURN bug anyway? I know it has something to
do with not executing the scriptSig and scriptPubKey separately
(https://bitcointalk.org/index.php?topic=58579.msg691432#msg691432) but
commit 7f7f07 that you reference isn't in the tree, nor is 0.3.5 tagged.
It was
I'm pleased to announce the release of version 0.7 of the bitcoinj Java
library for working with Bitcoin. Bitcoinj forms the foundation of
MultiBit, Bitcoin Wallet for Android, SatoshiDice and more.
To get bitcoinj 0.7, check out our source from git and then run *git reset
--hard a9bd8631b904*.
:
On Wed, Feb 6, 2013 at 8:33 AM, Mike Hearn m...@plan99.net wrote:
Can somebody please unlock the BIP wiki page? I don't know why it was
locked
but it's stale.
I asked for permissions to unlock it but haven't heard back— will prod
To summarize your post - it's another go at arguing for strongly
limited block sizes, this time on the grounds that large blocks make
it easier for $AUTHORITY to censor transactions? Is that right?
--
Symantec Endpoint
As an aside, there's a paper coming out in perhaps a few months that
describes a new way to provide Chaum-style privacy integrated with
Bitcoin, but without the use of blinding and without any need for
banks. It's quite smart, I was reviewing the paper this week.
Unfortunately the technique is too
Why does demurrage even still come up? The base rules of Bitcoin will
not be changing in such a fundamental way.
With regards to trying to minimize the size of the UTXO set, this
again feels like a solution in search of a problem. Even with SD
abusing micropayments as messages, it's only a few
This would be bloating UTXO data at a speed of 52 GB/year. That's a very
big memory leak. And this is just the unspendable outputs.
Firstly, the UTXO set is a LevelDB, it's not stored in memory. Outputs
that never get spent are not in the working set by definition, after a
while they just end
Just so we're all on the same page, can someone confirm my
understanding - are any of the following statements untrue?
BDB ran out of locks.
However, only on some 0.7 nodes. Others, perhaps nodes using different
flags, managed it.
We have processed 1mb sized blocks on the testnet.
Therefore it
However, most nodes are not running in such a loop today. Probably
almost no nodes are.
I suppose you could consider mass node death to be more benign than a
hard fork, but both are pretty damn serious and warrant immediate
action. Otherwise we're going to see the number of nodes drop sharply
We just saw a hard-fork happen because we ran into previously unknown
scaling issues with the current codebase.
Technically, it with the previous codebase ;)
--
Symantec Endpoint Protection 12 positioned as A LEADER in
I'm not even sure I'd say the upgrade went wrong. The problem if
anything is the upgrade didn't happen fast enough. If we had run out
of block space a few months from now, or if miners/merchants/exchanges
had upgraded faster, it'd have made more sense to just roll forward
and tolerate the loss of
My general hope/vague plan for bitcoinj based wallets is to get them all on
to automatic updates with threshold signatures. Combined with regular
audits of the initial downloads for new users, that should give a pretty
safe result that is immune to a developer going rogue.
On Wed, Apr 3, 2013 at
By the way, I have a download of the Bitcoin-Qt client and signature
verification running in a cron job.
On Thu, Apr 4, 2013 at 10:11 AM, Mike Hearn m...@plan99.net wrote:
My general hope/vague plan for bitcoinj based wallets is to get them all
on to automatic updates with threshold
51% isn't a magic number - it's possible to do double spends against
confirmed transactions before that. If Michael wanted to do so, with the
current setup he could, and that's obviously rather different to how
Satoshi envisioned mining working.
However, you're somewhat right in the sense that
In bitcoinj we desperately need integration tests to exercise the wallet
code, and I think if it was done well the tests would be applicable to
bitcoind as well. There have been a series of bugs in bitcoinj that boiled
down to the unit tests were not realistic enough, either because they
stopped
It'd help to know how the signatures are invalid.
On Sun, Apr 7, 2013 at 5:34 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
(cross-post from bitcointalk.org)
Hello all,
as some may know, Bitcoin uses DER-encoded signatures in its transactions.
However, OpenSSL (which is used to verify
OK, as the start of that conversation is now on the list, I might as well
post the other thoughts we had. Or at least that I had :)
It's tempting to see this kind of abuse through the lens of fees, because
we only have a few hammers and so everything looks like a kind of nail. The
problem is the
1 - 100 of 646 matches
Mail list logo
