On 05/07/2015 03:54 PM, Jeff Garzik wrote:
On Thu, May 7, 2015 at 3:31 PM, Alan Reiner etothe...@gmail.com
mailto:etothe...@gmail.com wrote:
(2) Leveraging fee pressure at 1MB to solve the problem is
actually really a bad idea. It's really bad while Bitcoin is
still growing
On 05/08/2015 01:13 AM, Tom Harding wrote:
On 5/7/2015 7:09 PM, Jeff Garzik wrote:
G proposed 20MB blocks, AFAIK - 140 tps
A proposed 100MB blocks - 700 tps
For ref,
Paypal is around 115 tps
VISA is around 2000 tps (perhaps 4000 tps peak)
For reference, I'm not proposing 100 MB blocks
that it is definitely over 20MB. If it was determined to be 100
MB ten years from now, that wouldn't surprise me.
Sent from my overpriced smartphone
On May 8, 2015 1:17 PM, Andrew onelinepr...@gmail.com wrote:
On Fri, May 8, 2015 at 2:59 PM, Alan Reiner etothe...@gmail.com wrote:
This isn't about
This *is* urgent and needs to be handled right now, and I believe Gavin
has the best approach to this. I have heard Gavin's talks on increasing
the block size, and the two most persuasive points to me were:
(1) Blocks are essentially nearing full now. And by full he means
that the reliability
I'll add fuel to the fire here, and express that I believe that
replace-by-fee is good in the long-term. Peter is not breaking the
zero-conf, it was already broken, and not admitting it creates a false
sense of security. I don't want to see systems that are built on the
assumption that zero-conf
On 01/23/2015 11:27 AM, Alan Reiner wrote:
I am happy to entertain other ideas that achieve our goals here, but I'm
fairly confident that the new SIGHASH type is the only way that would
allow devices like Trezor to truly simplify their design (and still work
securely on 100% of funds
Unfortunately, one major attack vector is someone isolating your node,
getting you to sign away your whole wallet to fee, and then selling it
to a mining pool to mine it before you can figure why your transactions
aren't making it to the network. In such an attack, the relay rules
aren't
The SIGHASH_WITHINPUTVALUE proposal is a hardfork, but otherwise
non-intrusive, doesn't change any TxOut scripts, doesn't change any
tx/block parsing (besides verification), it works with all existing
coins in the network, and existing software doesn't have to use it if
they don't want to upgrade
On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner etothe...@gmail.com wrote:
Unfortunately, it seems that there was no soft-fork way to achieve this
benefit, at least not one that had favorable properties. Most of the
soft-fork variations
On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner etothe...@gmail.com wrote:
Unfortunately, it seems that there was no soft-fork way to achieve this
benefit, at least not one that had favorable properties. Most of the
soft-fork variations
I'm a bit confused. It's been a long time since I looked at protobuf
(and will have to dig into it soon), but I seem to recall it doesn't
have any of the determinism properties you guys just said. It is
intended to allow you to skip details of the on-the-wire representations
and just send a
I see no reason to restrict compressed/uncompressed. Strings don't have
to be the same length to sort them lexicographically. If a multi-sig
participant provides an uncompressed key, they are declaring that the
key that they use and it will only be used uncompressed. Clients don't
have to go
On 11/16/2014 02:04 PM, Jorge Timón wrote:
I remember people asking in #bitcoin-dev Does anyone know any use
case for greater sizes OP_RETURNs? and me answering I do not know of
any use cases that require bigger sizes.
For reference, there was a brief time where I was irritated that the
size
By the way, I really like this proposal. I haven't spent much time
thinking about the deeper subtleties and risks associated with it, but I
see a lot of opportunities. One just came to mind that I didn't see
mentioned in his original proposal:
_Non-Interactive Recurring payments__with
On 10/01/2014 04:58 PM, Gavin Andresen wrote:
If the first transaction is P2SH, then the miner won't know there is
an advantage to holding it until it is too late (the scriptPubKey is
an opaque hash until the second transaction is final and
relayed/broadcast).
If you're doing some kind of
On 09/28/2014 10:35 PM, Peter Todd wrote:
This can be solved by upgrading the address format at
the same time to let senders know they must send the funds in a
transaction with an increased version number, but obviously needing new
addresses for every new opcode defeats the purpose of P2SH.
I'm in favor of BIP43.
Adding a Purpose node can be used as an identifier for what kind of
tree is in the wallet file we're reading. I can envision a few
different, common tree structures. Perhaps using a non-hardened
first-layer derivation (we have clients who want this). Similarly, my
This topic has been touched on briefly here before, but I wanted to
solidify it and propose it as a BIP if there is wider support for it.
Also, the topic is difficult to discuss without lots of pictures -- so
that's what I've done (mainly to describe it to my team, but also as
general
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 09/23/2014 12:37 PM, Justus Ranvier wrote:
Would be nice if you'd at least mention our work, since we did share
it with you back in January and have been publicly documenting it ever
since.
Or does the fact that we're implementing it in
edit your Subject line so it is more specific
than Re: Contents of Bitcoin-development digest...
Today's Topics:
1. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets
(Justus Ranvier)
2. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets
(Alan Reiner)
3
Hi Everyone,
The Armory team is pleased to announce the official release of our
decentralized multi-signature interface, called Lockboxes. It is a
true multi-signature transaction interface:
* Decentralized multi-sig (no third-party servers or signers needed)
* Any multi-sig from 1-of-2 up
Just a thought on this -- I'm not saying this is a good idea or a bad
idea, because I have spent about zero time thinking about it, but
something did come to mind as I read this. Reading 20 GB of data for
every hash might be a bit excessive. And as the blockchain grows, it
will become infeasible
On 07/04/2014 07:15 AM, Andy Parkins wrote:
On Friday 04 July 2014 06:53:47 Alan Reiner wrote:
ROMix works by taking N sequential hashes and storing the results into a
single N*32 byte lookup table. So if N is 1,000,000, you are going to
compute 1,000,000 and store the results
On 06/07/2014 07:22 AM, Mike Hearn wrote:
You can send different bloom filters to different peers too, so I'm
not sure why you're listing subsetting as a unique advantage of prefix
filters.
Please let me know if we've gone down this path before, but it would
seem that the more different
On 05/24/2014 07:41 PM, Ashley Holman wrote:
On Sun, May 25, 2014 at 8:29 AM, Bernd
Jendrissek bitc...@bpj-code.co.za
mailto:bitc...@bpj-code.co.za wrote:
The difference is that with cut-through forwarding of blocks, a
sufficiently motivated attacker (being willing to blow 25BTC's
On 05/24/2014 08:14 PM, Gregory Maxwell wrote:
On Sat, May 24, 2014 at 5:04 PM, Alan Reiner etothe...@gmail.com wrote:
I think the most important change is modifying the way Bitcoin Core
prioritizes blocks. Right now it uses the first full block verified.
Instead, it should consider the first
On 04/26/2014 04:33 PM, Mike Hearn wrote:
Let's assume we use one shared branch for everyone. Then two
cosigners could need a new receiving address at the same time, and
get the next unused address on that branch.
This is the part I struggle to understand. There is no shared
I will just chime in that I've been working on a similar spec for Armory
to implement P2SH multisig and I came up with basically an identical
scheme. I think you covered most of what is needed. The one thing I
did differently was try to match the BIP 32 structure, by keeping the
original 3
On 04/21/2014 11:40 AM, Ashley Holman wrote:
On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd p...@petertodd.org
mailto:p...@petertodd.org wrote:
That is mistaken: you can't mine on top of just a block header,
leaving small miners disadvantaged as they are earning no profit
while they
is an earlier reference to bits:
https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04248.html
https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04248.html
I forgot that Alan Reiner was also supporting a unit equals to bits :
https://www.mail
Armory has had Fragmented Backups for over a year, now. Advanced
users love it. Though, I would say it's kind of difficult to
standardize the way I did it since I was able to implement all the
finite field math with recursion, list comprehensions and python
arbitrary-big-integers in about 100
On 03/29/2014 01:19 PM, Matt Whitlock wrote:
I intentionally omitted the parameter M (minimum subset size) from the shares
because including it would give an adversary a vital piece of information.
Likewise, including any kind of information that would allow a determination
of whether the
On 03/29/2014 02:00 PM, Matt Whitlock wrote:
On Saturday, 29 March 2014, at 1:52 pm, Alan Reiner wrote:
On 03/29/2014 01:19 PM, Matt Whitlock wrote:
I intentionally omitted the parameter M (minimum subset size) from the
shares because including it would give an adversary a vital piece
leak no useful information,
The length of such fingerpring (say 4 bytes) and the degree (1 byte)
does not seem a big overhead for me.
Remember that the biggest obstacle of Bitcoin is usability not security.
Regards,
Tamas Blummer
http://bitsofproof.com
On 29.03.2014, at 18:52, Alan Reiner
This might be tangential, but the comment about refund chains reminded
me. Armory will be implementing multi-sig/linked wallets where a each
device has a parallel HDW branch and produces P2SH addresses. For those
types of wallets, I plan to allocate two chains /per signing
authority/. If you
I would echo the need for some kind of moderation.
I believe Peter Todd is an extremely intelligent individual, who has a
lot to offer the Bitcoin community. He has a firm grasp of a lot of
really deep Bitcoin concepts and his *technical* insight is generally
positive. Technically. But the
On 03/13/2014 10:32 AM, Jeff Garzik wrote:
On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn m...@plan99.net wrote:
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
On 03/13/2014 01:51 PM, Mike Hearn wrote:
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
I might as well throw in a word about Armory. After our next release in
a couple weeks, we will be going full-speed at new wallets and BIP32
integration. Just like Jean-Pierre mentioned, we'll be using parallel
trees to generate P2SH addresses after sorting the keys
lexicographically. We plan
it. Probably should do it soon before someone implements it in PB or XML.
Alan Reiner wrote:
Then of course I tried to do this with BIP 10
https://github.com/bitcoin/bips/blob/master/bip-0010.mediawiki when
Armory implemented offline-transactions two years ago. I got some
positive feedback, but no one
, Alan Reiner etothe...@gmail.com
mailto:etothe...@gmail.com wrote:
I create a new keypair, c_pub with c_priv which I know (it can
be any arbitrary key pair). But I don't give you c_pub, I give
you b_pub = c_pub minus a_pub (which I can do because I've
seen a_pub before doing
public key, they can be sure that
the public key is not chosen based on the public key they themselves
presented.
Although, I have to wonder, why not just use multisig?
- Joel
On 08.03.2014 10:51, Edmund Edgar wrote:
On 8 March 2014 17:10, Alan Reiner etothe...@gmail.com
mailto:etothe
I think the solution is simply to encourage Bitcoin software developers to
design their software to use this static ID, instead of the full
transaction hash.If MtGox had talked those IDs instead of the TX ID,
their software would've correctly identified the mutated transactions and
there would
accounting is
insufficient.
-Allen
On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner etothe...@gmail.com wrote:
I think the solution is simply to encourage Bitcoin software developers
to design their software to use this static ID, instead of the full
transaction hash.If MtGox had talked those IDs
some buggy behavior it
doesn't actually fix the problem. Fortunately the non-fixed parts
aren't too critical today.
On Wed, Feb 12, 2014 at 8:22 AM, Alan Reiner etothe...@gmail.com wrote:
I think the solution is simply to encourage Bitcoin software developers to
design their software to use
-addresesd use case:
With stealth addresses the user experience can be as simple as you
telling me on the phone hey! send me that 0.234 BTC you owe me!,
me clicking on Send to Alan Reiner (verified by PGP) (perhaps
again on my off-line second factor device for a multi-sig wallet)
and tellling
I highly recommend that if we make any move towards this, that the
software show verification in both/all units.
For instance, there should be 3 input fields, one for BTC, one for
mBTC one for uBTC. As the user enters a value in one of the fields,
it would automatically update the other fields
I disagree. There's a real perception and usability issue with the
current interface combined with the current price. People are
intimidated by the current system, even though the price really reflects
Bitcoin starting to spread its wings (maybe prematurely, bubble-style,
but the price will have
Sorry guys, I'm a little late to the party here. I skimmed over the
paper, and appreciated Peter Todd's recap of it. My first thought was
that this seems profit-neutral at best, when you take into account all
the races you lose by trying to beat the propagation of other miners'
blocks.
So given
fork by defining the root hash in coinbase blocks
as v3 and once we cross the limit all blocks are v3.
I will have a closer look at you bitcoin talk post to see how well my
approach and ideas fit to yours.
Michael
On 20/5/13 08:34 , Alan Reiner wrote:
This is exactly what I was planning to do
and
non-disruptive enough that it could be supported easily for no other
reason than to support that use case (which I intend to implement in
Armory to help verify high-volume services).
-Alan
On 06/26/2013 11:29 AM, Alan Reiner wrote:
Although I'd still prefer my original request, I get much
On 08/07/2013 05:10 PM, Gavin Andresen wrote:
I'd like to hear from other wallet implementors. Do you have a notion
of 'locked inputs' ? The tricky bit in constructing a transaction but
not broadcasting it right away is the inputs must be locked, so
they're not accidentally double-spent.
I
Indeed. You can hardcode a distributor public key in the software,
and client software will only trust signed data from that key. Of
course, the private key for that data is not kept on the server
distributing the signed checksums. Ideally it would be kept offline,
and the couple-times-per-year
That is a great presentation, thanks for sharing that!
Though I question the validity of the claim that ECC is so much more
secure than RSA (with appropriate keysizes). My experience from
studying quantum computing is that Factoring and DLP are intimately
related, such that a break of one is
Whoops, I didn't mean to run us down the Quantum Computing debate path.
I was simply using my experience with QCs as a basis for questioning the
conclusion that ECDLP is so much more robust than RSA/factoring
problems. It's possible we would simply be jumping from one burning
bridge to another
On 06/19/2013 08:19 AM, Melvin Carvalho wrote:
Generally in favour of hierarchical deterministic wallets.
Will this new style of address make it into the block chain? I'd be
less keen on that.
I'm finding BIP0032 quite hard to read right now, but perhaps that's
because I'm less familiar
On 06/19/2013 10:25 AM, Timo Hanke wrote:
Since you mention to use this in conjunction with the payment protocol,
note the following subtlety. Suppose the payer has to paid this address
called destination:
Standard Address ~ Base58(0x00 || hash160(PubKeyParent * Multiplier[i]) ||
On 06/19/2013 02:36 PM, Adam Back wrote:
This maybe simpler and trivially compatible with existing type2 public
keys
(ones that are multiples of a parent public key): send an ECDSA
signature of
the multiplier, and as we know you can compute (recover) the parent
public
key from an the ECDSA
On 06/19/2013 03:29 PM, Jeremy Spilman wrote:
If you have two parties who want to form a persistent relationship, by
exchanging and verifying public keys beforehand, then I think the
canonical way to do this with BIP32 is for the parties to exchange
PubKey and *ChainCode*.
I don't
On 06/19/2013 05:58 PM, Jeremy Spilman wrote:
Hi Alan,
“BIP 32 does not prescribe a way to use multiple chains like you described
with the convenient type-2 derivation (though we could create a variant
that does)”
What do you think is missing from BIP32 for this? A wallet creates a
_*Goal*_: An alternative address format made possible by BIP 32, which
allows one to specify a Wallet ID and One-time payment code, instead
of the standard one-use Base58-Hash160 addresses. This allows parties
with a persistent relationship to be able to prove that payment
addresses they
One major problem I see with this, no matter how well-thought-out it is,
it's unlikely that those with money will participate. Those with the
most stake, likely have their private keys behind super-secure
accessibility barriers, and are not likely to go through the effort just
to sign votes. Not
The two most basic ways would be simply:
(1) You create your transactions having a locktime of X days and has
sequence numbers such that it can be replaced exactly once. The
replacement, can be executed within 30 days.
(2) You simply send money to 1-of-2 transactions: me-or-you. If the
person
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
You can do this right now, with Armory. If you switch Armory to Expert
usermode, you can combine coin-control with unsigned transactions to do
exactly this. It's because Armory doesn't lock coins used in previous
unsigned transactions, until
There's some good discussion about that here:
https://bitcointalk.org/index.php?topic=130749.msg1398972#msg1398972
thanke came up with this first, and then I reinvented it, and now you
have. But the thread has some good discussion about how to move
forward. I'm a big fan of putting the
One of the big topics of recent past on IRC is malleability of
transactions: to what extent can someone /else /change your signed
transaction without affecting its validity? In the past I used to
consider this just annoying, but not so malicious. But in terms of HFT,
it sounds like malicious
If we're going to extend/expand message signing, can we please add a
proper ASCII-armored format for it? Really, anything that encodes the
signed message next to the signature, so that there's no ambiguities
about what was signed. You can keep the bare signatures as an option
for backwards
I noticed the new webpage is up on bitcoin.org. I still have mixed
feelings about it, but I noticed there is a You need to know! section
that suggests offline backups.
As long as you are featuring Armory and Electrum on the wallets page,
you should be including them in that blurb as options for
On 03/16/2013 09:13 PM, Gavin Andresen wrote:
I chose May 15 arbitrarily; two months seems like a reasonable 'quick'
amount of time to give people to upgrade/workaround.
Maybe you should wait until after the Bitcoin Conference -- if something
goes wacky on May 15th but then everyone is getting
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 psychological, so I think it would be exceptionally wise to
start
On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr l...@dashjr.org wrote:
I think we should be careful not to downplay the reality either.
For a number of hours, transactions could have received up to N
confirmations
and then still been reversed. While we could contact the bigger payment
processors,
On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen gavinandre...@gmail.comwrote:
When I say pass around I'm not thinking of users copying and pasting,
that would be a terrible user experience; all of that communication needs
to happen automatically behind the scenes. Lets tackle that after we've
. After they understand the value of the system and want
to use it, they are much more likely to become educated and willing to
support the network with full node.
-Alan
On 12/04/2012 07:27 PM, Gregory Maxwell wrote:
On Tue, Dec 4, 2012 at 5:44 PM, Alan Reiner etothe...@gmail.com wrote:
Greg's
On 12/03/2012 10:02 AM, Gregory Maxwell wrote:
(1) Make client software aggressive about sweeping up dust inputs:
Any time a transaction is created that has change keep adding in
extra inputs— smallest to largest— until an additional one would
increase the cost of the transaction by 0.0001 BTC
These are all valid points. I hadn't really thought much about this point
until you all just brought it up. The reason I so quickly spout off that
phrase, is that I endlessly get requests from Armory users to implement
more anonymity-based features. When I say there are bigger priorities,
they
On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik jgar...@exmulti.com wrote:
On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille pieter.wui...@gmail.com
wrote:
I suppose it is interesting in general for nodes to
get a memory pool refill at startup anyway.
Yes.
An inv message is always
I generally agree with Greg. I don't see anything he's said or done as
anti-alt-client.
As an alt-client developer, I'm happy to see my client on the main page,
but I'm also happy if that clients page is simply an acknowledgement that
there's more to the Bitcoin world than just the Bitcoin-Qt
I hope that someone else here would chime in on the issue raised in the
thread, about using a tree-structure that has multiple valid
configurations for the same set of unspent-TxOuts. If you use any
binary tree, you must replay the entire history of insertions and
deletions in the correct
On 06/19/2012 01:59 PM, Gregory Maxwell wrote:
On Tue, Jun 19, 2012 at 1:33 PM, Alan Reineretothe...@gmail.com wrote:
One app developer updates their
RB tree code which updated the RB-tree optimizations/rebalancing, and
now a significant portion of the network can't agree on the correct
All,
With the flurry of discussion about blockchain compression, I thought it
was time to put forward my final, most-advanced idea, into a single,
well-thought-out, *illustrated*, forum post. Please check it out:
https://bitcointalk.org/index.php?topic=88208.0
This is a huge
...@petertodd.org:
On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote:
All,
With the flurry of discussion about blockchain compression, I
thought it was time to put forward my final, most-advanced idea,
into a single, well-thought-out, *illustrated*, forum post.
Please check it out: https
On Thu, Jun 14, 2012 at 9:22 AM, Gavin Andresen gavinandre...@gmail.comwrote:
I've been asked a couple of times: why doesn't signrawtx handle the
BIP 0010 (https://en.bitcoin.it/wiki/BIP_0010) transaction format?
I considered parsing/writing BIP 10 format for raw transactions, but
decided
Devs,
I have decided to upgrade Armory's blockchain utilities, partly out of
necessity due to a poor code decision I made before I even decided I was
making a client. In an effort to avoid such mistakes again, I want to
do it right this time around, and realize that this is a good
: [Bitcoin-development] Full Clients in the future -
Blockchain management
Date: Sat, 2 Jun 2012 12:07:44 -0500
From: Douglas Huff m...@jrbobdobbs.org
To: Alan Reiner etothe...@gmail.com
I think you're trying to solve something a little out of scope, really.
Most of the issues aren't really
I like the concept except that it only works if every node connected to the
miner enforces the rule (if it works). Once any one of the nodes forwards
the block, other nodes see it coming from a node that can pass the
challenge.
I don't think any solution based on node queries will succeed,
On 05/03/2012 01:46 AM, Wladimir wrote:
Label is a label for the destination address, message is a freeform
message describing the transaction.
I don't think the message is currently stored in the Satoshi client.
That feature is somewhere on our way-too-long issue and todo list.
But I
Btw, I sent updated text to Genjix Armory. I hope that gets included or
reviewed.
And I agree about the $4k donations thing. That's complete immaterial for
this page. Though the rest of the description there is reasonable, and
might even be better than what I sent Genjix.
-Alan
On Wed, May
Oh, like I did 3 hours ago? Gah! I replied directly to grarpamp by
accident. Sorry if this seems out of place now...
I'm all for sorting the clients by ease of use. We want the smoothest
first experience greeting users new to Bitcoin. I have grand plans of
defaulting Armory to a standard
I'm not sure what designed for occasional use means. Many users of
other clients use them exclusively without touching other clients. Armory
is designed to be your only wallet (if bitcoind[d/-qt] is running in bkgd).
I'm sure the other clients are the same.
Instead, I think that line would be
I think it's perfectly reasonable to debate ordering. I personally don't
think Armory should be up front, because it's not intended for beginners.
How's that for honesty? I don't think anyone is trying to game the system
right now, I think we're trying to come up with a reasonable mechanism for
Hey, looks good! I'm glad to see them sorted alphabetically :)
A couple comments: I don't think the entries for wallet security and
backups accurately describe Armory. Wallet Security should say
Encrypt/Offline or something to to that effect -- after all, offline
wallets are the holy grail
. For each client I was
trying to empaphise a 'theme'. Bitcoin-Qt is stability. Armory is advanced.
Electrum is convenient. MultiBit is ease of use.
From: Alan Reiner etothe...@gmail.com
To: Amir Taaki zgen...@yahoo.com
Cc: bitcoin-development@lists.sourceforge.net
On 04/26/2012 01:30 PM, Peter Todd wrote:
More difficulty shortens the safe time we can transact large volumes in,
which is good for the network.
I'm not sure of the current implementation of replacement transactions, can
anyone on the core team speak to this? Can I replace transactions, or
My one big concern about this that users find a way to exploit this
behavior for themselves. If it's too easy for users to create tx they know
will get stuck and expire, it's no different than letting them cancel their
zero-conf transactions. i.e. I pay 0.5 BTC in a store for a candy bar, so
I
On 04/03/2012 02:46 PM, Gavin Andresen wrote:
RE: signature blocks and BIP 10:
We should avoid reinventing the wheel, if we can. I think we should
extend existing standards whenever possible.
So: could we encode signature blocks or BIP-10 transactions using
S/MIME ? Or is there a more
I would like to propose two things that are closely related. I will
start making BIPS if there's positive feedback. Sorry it's so long, but
I felt both should be in the same email...
_*(1) Signature Blocks* -- A more-robust, versatile, message-signing
exchange_
Satoshi client 0.6.0
I haven't been much a part of these brainstorming discussions, and so I'm
really looking at this from a bird's eye view, without any bias towards any
particular idea.
I do see what appears to be relevant concerns, brought up just before new,
powerful functionality is injected into 50%+ of the
The whole point of having headers built at a constant size and
generation rate is to minimize the amount of data needed to understand
of the blockchain while simultaneously maximizing integrity/security in
the presence of untrusted nodes. Barring the 50%-attack, you only need
a couple honest
I can substantiate Gavin's point quite powerfully: a couple months ago I
did a search for the hardest block in the network and found a *very
**impressive* one:
https://bitcointalk.org/index.php?topic=29675.0
That block has a difficulty of **36 billion** when the network had a
difficulty of
is discarded, *all* out-of-band solutions are going to
require encoding this exact information somehow. I think offering this
solution before developers start asking the question of how to do it is
exactly what's needed.
-Alan
Cheers,
Michael
On 10/11/2011, at 04:00, Alan Reiner wrote
1 - 100 of 105 matches
Mail list logo
