On Mon, Nov 4, 2013 at 3:26 PM, Peter Todd p...@petertodd.org wrote:
The attacker now only needs to connect to every identified miner
with especially fast nodes. With judicious use of DoS attacks and low
latency .
So you're back to a complicated sybil attack. I don't follow your thought
I like the UUID-as-path idea. That resolves the problem of how to share the
alt-chain merkle tree quite nicely.
On Mon, Nov 4, 2013 at 7:16 PM, Peter Todd p...@petertodd.org wrote:
No sense in compromising - you need a whole merkle path to prove the
extra data is valid so you might as well
Yes, sure. I was talking about the case of transiently relayed data, like
IP addresses.
On Mon, Nov 4, 2013 at 8:53 PM, Mark Friedenbach m...@monetize.io wrote:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 11/4/13 11:38 AM, Mike Hearn wrote:
The Merkle branch doesn't get stored
Very cool, thanks Matt.
I was actually thinking this morning, maybe we should require all nodes to
go through the inv/getdata dance. Otherwise it's possible to improve your
chances at racing a block by mining a block, waiting to see a block inv
from another node, then blasting out your block
I think trying to help miners figure out the propagation/fees tradeoff at
the moment is a non-starter until we understand it better ourselves. A
server that tracks and records block propagation times, how many fees per
passed up per block, orphan stats per size bucket etc would be tremendously
Once the ASIC race calms down because everyone has one, has more or less
optimal power supplies, process improvements aren't easily reachable
anymore etc then I'd expect people to dissipate from the large pools
because eliminating their fees will become the next lowest hanging fruit to
squeeze out
I took a brief look at the code - it's looking very reasonable. You can
replace any construct like
try {
Thread.sleep(1000);
} catch (InterruptedException e) {
throw new RuntimeException(e);
}
which is quite verbose, just with
Uninterruptibles.sleepUninterruptably(1000,
I don't use testnet much anymore, partly because it sometimes kind of
breaks like this. It's a public resource and people sometimes abuse it.
You can create your own local network with -regtest and that lets you mint
new blocks instantly. It's a much simpler way to do testing and app
development.
thing?
On Thu, Nov 21, 2013 at 2:55 PM, Addy Yeow ayeo...@gmail.com wrote:
Try https://bitcointalk.org/index.php?action=profile;u=19897?
On Fri, Nov 22, 2013 at 12:48 AM, Mike Hearn m...@plan99.net wrote:
I added some additional logging to my node and ran it for a few days.
There's a pull
I added some additional logging to my node and ran it for a few days.
There's a pull req open for my extra logging, it is quite trivial. Here's
what it looks like:
2013-11-21 13:41:04 AcceptToMemoryPool:
5.9.24.81:7834/Satoshi:0.8.99/Gangnam Style:2.1/ : accepted
This is great, thanks for doing it. Tip sent your way.
Graphs of how propagation data change over time would also be helpful (as
well as raw data so we can calculate overhead per kilobyte and so on). I
know there are only two days worth of data, but for future, it'd be good.
I think the next
Hey Christian,
Could you sort the snapshots by date? At the moment they're kind of in a
random order.
Sometimes I wish we had real-time stats too but this is a great start.
On Mon, Nov 25, 2013 at 8:27 PM, Christian Decker
decker.christ...@gmail.com wrote:
Thanks Mike for the Tip :-)
I
Lately I was pondering how to make floating fees and SPV wallets work well
together.
I propose the following plan:
1) 0.9 ships with something dead simple, like a command to query what a
node estimates and then clients just take the average, or cross-check a
centralised estimate against the P2P
Both can be combined into adapting the current generic messages (This
payment should become spendable shortly for incoming and This payment
has not been transmitted yet for outgoing transactions).
What would the new messages say?
We need to get away from the notion of senders attaching fees
This payment did not become spendable since xxx minutes. Check with the
sender if s/he paid the Bitcoin network fee. Check if your internet
connection is working properly. (incoming)
That seems reasonable.
The other message should be implementable today, I think? If numBroadcastPeers
0
Bitcoin is and always will be limited in capacity - transactions may not
confirm in a reasonable about of time because of high-demand and/or DoS
attacks.
I agree in the general case, but I was talking about the mobile wallet case
specifically (i.e. people who are sending money between
On Tue, Dec 3, 2013 at 2:40 AM, Gavin Andresen gavinandre...@gmail.comwrote:
optional uint64 allowfeetag number=1000
Let's just use a normal/low tag number. The extensions mechanism is great
for people who want to extend the protocol outside the core development
process. It'd be weird
On Tue, Dec 3, 2013 at 11:36 AM, Drak d...@zikula.org wrote:
I dont like the idea of putting the min fee in the hands of the receiver.
Seems like that will work against the best interests of senders in the long
run.
Senders have no interest in ever attaching any kind of fee, which is one
On Tue, Dec 3, 2013 at 12:41 PM, Gavin Andresen gavinandre...@gmail.comwrote:
If users want to pay with a huge transaction then it seems to me the user
should cover that cost. Allowing users to pay merchants with 100K
transactions full of dust and expecting them to eat the cost seems like a
On Tue, Dec 3, 2013 at 12:57 PM, Taylor Gerring taylor.gerr...@gmail.comwrote:
Why should there be two classes of transactions? Where does paying a local
business at a farmer’s stand lie in that realm? Transactions should work
the same regardless of who is on the receiving end.
Lots and lots
On Wed, Dec 4, 2013 at 2:06 PM, Peter Todd p...@petertodd.org wrote:
replace-by-fee is no less speculative than your original proposals;
you're also trying to convince people that things should work
differently re: fees
The original proposal I started this thread with hasn't even received
I wrote an article intended for a broad/non-developer audience on a few
Bitcoin privacy topics:
- P2P connection encryption
- Address re-use/payment protocol
- CoinJoin and merge avoidance
I don't think there's anything much new here for people who were involved
with the BIP70 design
is widely deployed.
On Thu, Dec 12, 2013 at 11:03 AM, Mike Hearn m...@plan99.net wrote:
I wrote an article intended for a broad/non-developer audience on a few
Bitcoin privacy topics:
- P2P connection encryption
- Address re-use/payment protocol
- CoinJoin and merge avoidance
I don't think
Why would there be an iteration count? The payer would handle that,
wouldn't they?
I'm thinking about a use case I hope will become common next year -
pastebin style hosting sites for payment requests. Like, if I as a regular
end user wish to use the payment protocol, I could just upload a
Or alternatively, the user-signed payment request without iteration
count is enclosed within a payr.com-signed envelope that contains the
iteration count.
But how does that show up in the user interface? I don't know how you would
explain what the signature means or implies, or what you do
On Mon, Dec 16, 2013 at 12:31 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
Will that also mean no longer reusing (change) addresses?
Jim seems to be planning some parallel development to what I'm doing, but
HD wallets and stopping address re-use is the current feature I'm working
on for
On Mon, Dec 16, 2013 at 11:13 AM, Drak d...@zikula.org wrote:
It just occurs to me this kind of sad story could be averted if wallets
implemented a confirmation box if the fee amount seems crazy - for example,
if it's 10x what the default fee should be, or if it's greater than x% of
the
It is irrelevant.
--
Rapidly troubleshoot problems before they affect your business. Most IT
organizations don't have a clear picture of how application performance
affects their revenue. With AppDynamics, you get 100%
Thanks Warren! That's great. It's also a prerequisite for chain pruning, so
it's not only about decentralisation but also scalability.
Looking forward to reviewing and merging that.
On Tue, Dec 24, 2013 at 6:11 PM, Warren Togami Jr. wtog...@gmail.comwrote:
I was concerned about this issue so
For a long time the only block explorer for testnet has been the original
blockexplorer.com, which is unfortunately often broken / behind / slow and
not really maintained any more.
There is now a new one, here:
https://www.biteasy.com/testnet/blocks
There's also a REST/JSON API for it.
Please
I was reading there are some commands to access a peer's mempool state.
The purpose being to allow miners to recover faster after a reboot, I
think?
The mempool command allows nodes to request the contents of a peers
memory pool, yes.
It is currently used by SPV clients to find transactions
(nb: Gavin is on vacation at the moment, I post this now just to give food
for thought over the holidays).
I patched my bitcoind to use a modified version of Gavin's fee estimation
framework. Here is what it's currently estimating. This shows number of
samples taken for fee-paying transactions
Given that hardly anyone checks the signatures, it's fair to say downloads
aren't protected by anything at the moment. SSL for downloads can only
raise the bar, never lower it, and if the NSA want to kick off the process
of revoking some of the big CA's then I'm game (assuming anyone detects it
of
to a BitTorrent magnet link, but I
also understand objections to adding an entire BitTorrent stack into a
wallet.
On Tue, 31 Dec 2013 06:23:55 -0800, Mike Hearn m...@plan99.net wrote:
The site was actually moved onto a dedicated server temporarily and it
melted down under the load. I wouldn't call
Oh, it did? When was that? I must have missed this excitement :)
I would be very interested to learn more about this. It seems the steady
state load on the site is not very high:
https://github.com/bitcoin/bitcoin.org/pull/287
(Saivann ran Google Analytics on the site for a little while to
You can always just extend the payment protocol with the new fields as
well, vs making very long addresses. If this technique can be made to work
well, it would have applicability in both fixed textual address context,
and for a fixed/upload-once payment protocol file. That has the advantage
of
Cool!
On Mon, Jan 13, 2014 at 10:18 AM, Jeremy Spilman jer...@taplink.co wrote:
I spent 1BTC on TestNet to a stealth address...
TxID: df092896c1347b303da299bc84c92bef1946f455dbdc80ffdb01a18ea4ed8b4c
... but can you redeem it?
Code which generated this transaction is here:
On further reflection, I'm not sure I understand this use case of the
payment protocol. Since a PaymentRequest currently contains the
Outputs that specify the addresses to send to, reusing a
PaymentRequest like this without using stealth addresses implies
address reuse.
Yes indeed ..
Do any people who aren't computer programmers or physicists ever use the
term static?
I liked routing address.
On Wed, Jan 15, 2014 at 9:44 PM, Jeff Garzik jgar...@bitpay.com wrote:
static address seems like a reasonable attempt at describing intended
use/direction.
On Wed, Jan 15, 2014
May need to modify the network address format to include the ability to
differentiate IPv6 clearnet vs. Tor addresses
sipa already implemented some clever hack where the 80-bit Tor keys are
mapped to a subregion of reserved IPv6 space, giving magical IPv6 hidden
service addresses. So addr
I think we have a winner in reusable address. Yes an existing address can
be reused and will superficially appear to work, it just won't work well.
Calling them reusable addresses helps reinforce the idea in peoples mind
that the other kind shouldn't be reused.
On Thu, Jan 16, 2014 at 11:14 AM,
Yes correct, using hidden services just as a kind of more complicated, out
of process/sandboxable SSL.
would the overall transactions/second the Bitcoin network could handle go
down?
If all nodes talked to each other all the time over Tor, probably yes
because Bitcoin is quite sensitive to
We have an implementation of the latest spec in bitcoinj, with the wordlist
provided by slush+stick. As far as I can see it's all working fine so LGTM
from us.
On Mon, Jan 20, 2014 at 5:42 PM, slush sl...@centrum.cz wrote:
Hi all,
during recent months we've reconsidered all comments which we
We should just perform Unicode canonicalization before any text hits the
crypto code. There are algorithms that automatically resolve such issues.
Although with an English wordlist it would seem to make no difference
anyway.
On Tue, Jan 21, 2014 at 10:01 AM, Gary Rowe g.r...@froot.co.uk wrote:
brittleness. The real world experience is that users, or to be exact
wallet authors, turn down SPV privacy parameters until bloom filters
have almost no privacy in exchange for little bandwidth usage.
That's not fundamental though, it just reflects that the only
implementation of this is
, so we can skip the
delimiter for these mediums.
On 01/26/2014 10:24 PM, Mike Hearn wrote:
Which medium is this an issue for? As you note, for files and HTTP
responses it's not a problem in practice. i'd guess nor for NFC tags nor
QR codes.
On Sun, Jan 26, 2014 at 10:11 PM, Andreas
. The embedded messages don't need length prefixes.
On 01/26/2014 11:00 PM, Mike Hearn wrote:
I think for binding the payment protocol to those transports we should
indeed use protobuf varint length prefixes. But it's unnecessary for all
cases. Unless Gavin feels it'd be better
Thanks Andreas, that's really interesting work. Comments below.
On Mon, Jan 27, 2014 at 12:59 PM, Andreas Schildbach
andr...@schildbach.dewrote:
Because I could not find any standard for Bluetooth URLs, I made
up my own: bt:112233445566 means MAC address 11:22:33:44:55:66.
I would like to
At the moment there's no way to distinguish between a failed / rejected
submission and a successful one beyond the freeform memo field, right? It'd
be good if we had an error code field as well, perhaps for a future version.
On Mon, Jan 27, 2014 at 7:18 PM, Andreas Schildbach
andr...@schildbach.dewrote:
I'm not saying I'm against signed payment requests, but unfortunately
they are just too big for QR-codes. Then again, QR-codes *can* take up
to 2 KB. How big would a very basic trust chain plus signature be?
As I
All insist on handling the link with their download manager, which would
involve an additional click.
That's the expected behaviour, right? That's why I said download and
open. The Bitcoin URI with r= is better because it lets you remove that
second click, but in some contexts the file
I think the right approach for this is to actually implement it and
*then* propose
a BIP. There are so many possible features we could add to the payment
protocol, any other approach would rapidly turn into lots of people
deciding to do the fun bits and often leaving others doing the hard work
Yeah, that's the interpretation I think we should go with for now. There
was a reason why this isn't specified and I forgot what it was - some
inability to come to agreement on when to broadcast vs when to submit via
HTTP, I think.
On Mon, Jan 27, 2014 at 11:39 PM, Kevin Greene
And even if you don't care about CoinJoin, not broadcasting the
transaction as soon as the inputs are signed adds implementation complexity
(should you retry if payment_url is unavailable? how many times?
I guess a lot of wallets just won't broadcast at all and try to submit via
the URL. If
Todd p...@petertodd.org wrote:
On Tue, Jan 28, 2014 at 07:53:14AM -0500, Gavin Andresen wrote:
On Tue, Jan 28, 2014 at 6:42 AM, Mike Hearn m...@plan99.net wrote:
Yeah, that's the interpretation I think we should go with for now.
There
was a reason why this isn't specified and I forgot
Hi Chuck,
Both Bitcoin Core and bitcoinj are about to ship with the protocol as-is,
so any changes from this point on have to be backwards compatible.
On Thu, Jan 30, 2014 at 6:47 AM, Chuck chuck+bitcoin...@borboggle.comwrote:
I presume the receipt R=(PaymentRequest,[transactions]) would
Although it should be noted that these binaries don't yet do URI support so
you can't scan a bitcoin URI with r= in it and see the verified merchant
name, etc. I think Andreas plans to do the UI for that in the next update.
On Thu, Jan 30, 2014 at 11:46 AM, Andreas Schildbach
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.comwrote:
In arbitration the merchant could argue the transactions seen on the
network were insufficient.
The arbitrator would presumably have some rules about what is or isn't an
acceptable form of payment.
HTTP has response
straightforward and how I'd expect things to work as a user.
On Thu, Jan 30, 2014 at 12:46 PM, Pieter Wuille pieter.wui...@gmail.comwrote:
On Thu, Jan 30, 2014 at 12:15 PM, Chuck chuck+bitcoin...@borboggle.com
wrote:
Hi Mike. Thanks for replying.
On 1/30/2014 5:49 PM, Mike Hearn wrote:
Both
If you sent the Payment message and the server goes silent after receiving
it, you retry to delivery. However, the merchant can broadcast the
transactions and force them into your wallet anyway. You could, quite
likely, pay and never get an ACK.
No retries. If there's a timeout the wallet
Is this truly the intent? That the merchant/processor takes full
responsibility for getting the TX confirmed?
As per Gavin at the top of the thread, the intent is to give the customer
reassurance that their payment will be processed. The merchant trying to
get the tx confirmed is presumably
That looks OK at a very high level. Things you probably want to think about:
- How to trigger it off the existing payment protocol (no new top level
messages or mime types or uri extensions please)
- Data structures to define the payment schedule
- Do you allow pre-submission of time
Hello,
I'm pleased to announce the release of bitcoinj 0.11, a library for writing
Bitcoin applications that run on the JVM. BitcoinJ is widely used across the
Bitcoin community; some users include Bitcoin Wallet for Android, MultiBit,
Hive, blockchain.info, the biteasy.com block explorer
Here’s a new release announcement with full ID’s this time:
The v0.11 tag is signed by Andreas Schildbach’s GPG key (fingerprint E944 AE66
7CF9 60B1 004B C32F CA66 2BE1 8B87 7A60). The commit hash is
410d4547a7dd20745f637313ed54d04d08d28687.
Key: 16vSNFP5Acsa6RBbjEA7QYCCRDRGXRFH4m
Signature:
but the wallet
receives a callback to verify the payment matches the contract and should
go through.
Please give us some feedback whenever you have the chance. In the meantime
we will start implementing the merchant side and test the code.
Cheers!
On Jan 31, 2014, at 10:13 AM, Mike Hearn m...@plan99
Thanks for the feedback guys!
I would also like to understand the problems you've been having with
certificates in node.js. FYI the CA cert is *not* supposed to be included,
this matches what the code in Bitcoin Core and bitcoinj expects. It may be
that Bitcoin Core accepts a redundant CA cert
We've done forking changes before much faster than a year and that was with
less experience. If we want, we can get this done within months.
On 20 Feb 2014 16:30, Michael Gronager grona...@mac.com wrote:
As I see the BIP it is basically stressing that ver 1 transactions are
malleable.
It then
:
On Thu, Feb 20, 2014 at 6:08 AM, Mike Hearn m...@plan99.net wrote:
We've done forking changes before much faster than a year and that was
with
less experience. If we want, we can get this done within months.
You mean P2SH... which your implementation has only picked up support
Bear in mind a separate process doesn't buy you anything without a sandbox,
and those are expensive (in terms of complexity).
On 21 Feb 2014 11:40, Jeff Garzik jgar...@bitpay.com wrote:
[Meta: Bitcoin Core is the newfangled branding of bitcoind /
Bitcoin-Qt reference implementation, in case you
One more thing. The new bitcoin URI in BIP 72 is extremely long and
makes for very dense QR codes.
BIP 73 seems OK except that existing wallets that can scan QR codes will
choke. One reason the new URIs are long is for backwards compatibility.
One thing that makes the URI smaller is not
Hey there,
So the essence of this protocol is as follows:
enum PaymentFrequencyType {
WEEKLY = 1;
MONTHLY = 2;
QUARTERLY = 3;
ANNUAL = 4;
}
message RecurringPaymentDetails {
// Namespace for the merchant such as org.foo.bar
required string
There are two possibilities.
One is that the value of transactions with the new lower fee is outweighed
by increased orphan costs and miners refuse to include them en-masse.
Wallet authors lose the staring match and go back to setting higher fees
until such a time as block propagation is
Thanks for the explanation. I agree that makes sense, and you did actually
explain this before, I just didn't connect the dots :)
The accompanying BIP should explain all this, so the rationale for the
design and how you use it is made clear to developers.
I've CCd Jeff and Stephen on this
Now we're starting to see the first companies deploy BIP70, we're
encountering a need for identity delegation. This need was long foreseen by
the way: it's not in BIP70 because, well, we had to draw the line for v1
somewhere, and this is an issue that mostly affects payment processors. But
I
SHA-1 support is there for PHP developers. Apparently it can't do SHA-2.
On 2 Mar 2014 08:53, Jeremy Spilman jer...@taplink.co wrote:
From BIP70:
If pki_type is x509+sha256, then the Payment message is hashed using
the
SHA256 algorithm to produce the message digest that is signed. If
I'm hoping I can convince Saivann to do a bit of graphics work for this at
some point :-)
Something like a green stamp that appears (like a watermark) in the
background, might be good.
On Sat, Mar 1, 2014 at 8:50 AM, Jeremy Spilman jer...@taplink.co wrote:
On Fri, 28 Feb 2014 23:26:57 -0800,
http://php.net/manual/en/mhash.constants.php
http://php.net/manual/en/function.hash-algos.php#refsect1-function.hash-algos-examples
On 2 Mar 2014 08:44, Mike Hearn m...@plan99.net wrote:
SHA-1 support is there for PHP developers. Apparently it can't do SHA-2.
On 2 Mar 2014 08:53, Jeremy Spilman
Perhaps the UI just isn't expressive enough currently to expose this
situation in any way, let alone reliably alert the user to the issue,
because there's no way for the payment processor to get authenticated
fields other than memo into the UI.
I think for now as long as payment processors
On Sat, Mar 1, 2014 at 9:07 PM, Dev Random c1.devran...@niftybox.netwrote:
I'm wondering about the small business case. A small business or an
individual might not have the technical expertise to perform the
delegation signature.
If they take delivery of an SSL cert from the CA themselves,
On Sun, Mar 2, 2014 at 4:20 PM, Andreas Schildbach andr...@schildbach.dewrote:
I somehow think that it is too early for this heavy kind of extension,
given that the first version of BIP70 isn't even deployed widely let
alone *used*.
Definitely agree - like I said, I publish this only because
Hey Tom,
Thanks for getting involved! It's great to see someone who would like to
focus on docs.
One project I've been thinking about recently is a Bitcoin Developer
Network subsection of our website. Right now bitcoin.org is entirely
consumer focused. And as you noted, the wiki is undergoing
On an unrelated note, X.509 is a terrible standard that should be
abandoned as quickly as possible. BitPay is working on a new standard
based on bitcoin-like addresses for authentication. It would be great if
we could work with the community to establish a complete, decentralized
A new practical technique has been published that can recover secp256k1
private keys after observing OpenSSL calculate as little as 200 signatures:
http://eprint.iacr.org/2014/161.pdf
This attack is based on the FLUSH+RELOAD technique published last year. It
works by observing L3 CPU cache
I'm wondering about whether (don't laugh) moving signing into the kernel
and then using the MTRRs to disable caching entirely for a small scratch
region of memory would also work. You could then disable pre-emption and
prevent anything on the same core from interrupting or timing the signing
I just did my first contactless nfc payment with a MasterCard. It worked
very well and was quite delightful - definitely want to be doing more of
these in future. I think people will come to expect this kind of
no-friction payment experience and Bitcoin will need to match it, so here
are some
On Thu, Mar 6, 2014 at 12:26 PM, Andreas Schildbach
andr...@schildbach.dewrote:
I'm not sure if iso-dep is the way to go here. Afaik as soon as you pick
up the phone the connection breaks.
If the phone isn't willing to immediately authorise then it'd have to fall
back to HTTPS or Bluetooth as
I wonder about the receipt step -- are you generating a PDF on device
and sending it via NFC? This is something that could be supported by the
BIP70 payment protocol. We should try to avoid the second tap, its not
intuitive.
Together, the signed PaymentRequest and the transactions in the
I think maybe the way you do it is to have a NDEF tag that triggers the
app, and then that starts an IsoDep protocol once opened. I *think*.
On Thu, Mar 6, 2014 at 5:55 PM, Andreas Schildbach andr...@schildbach.dewrote:
On 03/06/2014 03:51 PM, Andreas Schildbach wrote:
I'm not sure if
Thanks Alex!
About the video - I'm curious how your device is better than just a regular
tablet. Could you give us the elevator pitch? :)
On Thu, Mar 6, 2014 at 3:39 PM, Alex Kotenko alexy...@gmail.com wrote:
I mean - if with Bitcoin v0.9 transaction fees will become really
floating, and it
if some sort of Stealth address or HD wallet root was the identity gaining
the reputation, then address re-use wouldn't have to be mandatory.
The identity would be the X.520 name in the signing cert that signed the
payment request. It doesn't have to be a difficult to obtain cert. It could
If there was a way for a Bitcoin user to provide feedback on a payment
(ECDSA signature from one of the addresses involved in the payment, signing
an identifier of the payment and a feedback score)
Well now you're getting into the area that I said rapidly got very
complicated.
Define
it's the responsibility of the individual members to maintain their own
good/bad user lists. Would you think that's a good thing or a bad thing to
give the individual players that level of control/responsibility?
If it's explicit, I think it's a non starter and nobody will bother with
it,
Yes please, pull req would be great! I also noticed that escaping doesn't
seem to be necessary, and the resultant de-escaped QRcodes are certainly
much nicer! Thanks!
--
Subversion Kills Productivity. Get off Subversion
No, this doesn't make any sense. Multisig outputs are a tool you use to
build helpful features, not a feature in and of themselves.
By all means create a nice protocol, implementation and BIP for something
like:
- Creation of multi-user money pools for managing an organisations funds
- Dispute
You can follow HDW progress in bitcoinj on this branch:
https://github.com/bitcoinj/bitcoinj/commits/keychain
I've been working on it for a couple of months now. Electrum (Thomas V) is
also making good progress, and Trezor already uses HD wallets. I think most
popular end user wallets except
Can this be calculated in advance knowing the initial transaction size and
the number of signatures required?
Sure of course. You assume each signature to be placed in the tx is 73
bytes. Not very hard, but if the tx you get back from the API doesn't
contain such a 73-byte sentinel value then
The standard has become mBTC and that's what was adopted. It's too late to
try and sway this on a mailing list thread now.
On Thu, Mar 13, 2014 at 2:29 PM, Gary Rowe g.r...@froot.co.uk wrote:
The MultiBit HD view is that this is a locale-sensitive presentation
issue. As a result we offer a
BitPay should use mBTC as well. Unless you can point to any major wallets,
exchanges or price watching sites that use uBTC by default?
I think it is highly optimistic to assume we'll need another 1000x shift
any time soon. By now Bitcoin isn't obscure anymore. Lots of people have
heard about it.
Even if a cup of coffee costs 3.12345 mBTC, that's a lot more annoying
than 3123.45 uBTC.
This is subjective though. To me the first price looks like the price of a
cup of coffee (or I just mentally double it). The second looks like the
price of an expensive holiday.
If users really find
Well it looks like the consensus is to do it, instead of talking about
it. I'm going to make sure we get uBTC into the next Armory release.
Hmm - be careful with the word consensus here. A bunch of people on a
mailing list does not make consensus ;)
If you survey other wallets, you'll find
201 - 300 of 642 matches
Mail list logo
