Re: [Bitcoin-development] Block Size Increase

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" wrote: > > > On Fri, May 8, 2015 at 2:59 PM, Alan Reiner wrote: > >> >> This isn't

Re: [Bitcoin-development] Block Size Increase

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

Re: [Bitcoin-development] Block Size Increase

he network to scale to be a useful global payments system On 05/07/2015 03:54 PM, Jeff Garzik wrote: > On Thu, May 7, 2015 at 3:31 PM, Alan Reiner <mailto:etothe...@gmail.com>> wrote: > > > (2) Leveraging fee pressure at 1MB to solve the problem is > actually rea

Re: [Bitcoin-development] Block Size Increase

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 reliabilit

Re: [Bitcoin-development] replace-by-fee v0.10.0rc4

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

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

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 > secur

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

On 01/23/2015 11:05 AM, Gregory Maxwell wrote: > On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner 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 variatio

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

On 01/23/2015 11:05 AM, Gregory Maxwell wrote: > On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner 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 variatio

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

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 relevant,

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

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 t

Re: [Bitcoin-development] BIP70: why Google Protocol Buffers for encoding?

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 bunch

Re: [Bitcoin-development] convention/standard for sorting public keys for p2sh multisig transactions

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 lo

Re: [Bitcoin-development] Increasing the OP_RETURN maximum payload size

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

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

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 ID-associa

Re: [Bitcoin-development] [BIP draft] CHECKLOCKTIMEVERIFY - Prevent a txout from being spent until an expiration time

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

Re: [Bitcoin-development] New opcodes and transaction version numbers (was 'relax the IsStandard rules for P2SH transactions')

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.

Re: [Bitcoin-development] BIP43 Purpose code for voting pool HD wallets

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 prop

Re: [Bitcoin-development] Bitcoin-development Digest, Vol 40, Issue 9

" >> >> >> 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) >>

Re: [Bitcoin-development] Proposal: "No-Collision" mode for Multisig BIP32 Wallets

-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 b

[Bitcoin-development] Proposal: "No-Collision" mode for Multisig BIP32 Wallets

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 documentatio

[Bitcoin-development] [ANN] Armory 0.92 with Decentralized Multi-sig and Simulfunding

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

Re: [Bitcoin-development] ASIC-proof mining

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 an

Re: [Bitcoin-development] ASIC-proof mining

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

Re: [Bitcoin-development] Bloom bait

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 differe

Re: [Bitcoin-development] Cut-through propagation of blocks

On 05/24/2014 08:14 PM, Gregory Maxwell wrote: > On Sat, May 24, 2014 at 5:04 PM, Alan Reiner 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 con

Re: [Bitcoin-development] Cut-through propagation of blocks

On 05/24/2014 07:41 PM, Ashley Holman wrote: > On Sun, May 25, 2014 at 8:29 AM, Bernd > Jendrissek > wrote: > > The difference is that with cut-through forwarding of blocks, a > sufficiently motivated attacker (being willing to blow 25BTC's worth > of ele

Re: [Bitcoin-development] moving the default display to mbtc

I've been a strong supporter of the 1e-6 unit switch since the beginning and ready to do whatever I can with Armory to help ease that transition. I'm happy to prioritize a release that updates the Armory interface to make "bits" the default unit, when the time is right. I think it makes sense to

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

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 share

Re: [Bitcoin-development] New BIP32 structure for P2SH multisig wallets

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 level

Re: [Bitcoin-development] Economics of information propagation

On 04/21/2014 11:40 AM, Ashley Holman wrote: > On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd > 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 wait for th

Re: [Bitcoin-development] "bits": Unit of account

et some commitments from some > other wallet developers, so we can make a unified push for it. I'm > happy to lead that and make it default as long as I'm not the only one > in the world doing it. > > -Alan > > > > On 04/20/2014 11:05 AM, Tamas Blummer wrote:

Re: [Bitcoin-development] "bits": Unit of account

doing it. -Alan On 04/20/2014 11:05 AM, Tamas Blummer wrote: > Here 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

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

not security. > > Regards, > > Tamas Blummer > http://bitsofproof.com > > On 29.03.2014, at 18:52, Alan Reiner <mailto:etothe...@gmail.com>> wrote: > >> On 03/29/2014 01:19 PM, Matt Whitlock wrote: >>> I intentionally omitted the parameter M (minimum subset

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

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 woul

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

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 th

Re: [Bitcoin-development] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

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

Re: [Bitcoin-development] New BIP32 structure

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 h

Re: [Bitcoin-development] Tree-chains preliminary summary

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 way

Re: [Bitcoin-development] moving the default display to mbtc

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 d

Re: [Bitcoin-development] moving the default display to mbtc

On 03/13/2014 01:24 PM, Mike Hearn wrote: > > Using milli- and micro- notation for currency units is also not very > well supported. Last time this thread was active, I believe there > was a > suggestion to use 1 XBT == 1 uBTC. > > > Unfortunately I think some people already starte

Re: [Bitcoin-development] moving the default display to mbtc

On 03/13/2014 10:32 AM, Jeff Garzik wrote: > On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn 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 need an

Re: [Bitcoin-development] Multisign payment protocol?

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 to

Re: [Bitcoin-development] Multisign payment protocol?

dust off my notes and see where I left > 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 >> A

Re: [Bitcoin-development] Multisign payment protocol?

Then of course I tried to do this with BIP 10 when Armory implemented offline-transactions two years ago. I got some positive feedback, but no one wanted to help improve it, etc. I guess nobody else was doing it and/or cared at the

Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

y before they'll show their own 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: >>

Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

; On 8 March 2014 17:10, Alan Reiner <mailto:etothe...@gmail.com>> wrote: > > > I create a new keypair, with which I know (it can > be any arbitrary key pair). But I don't give you , I give > you = minus (which I can do because I've >

Re: [Bitcoin-development] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

On 03/08/2014 01:55 AM, Edmund Edgar wrote: > On 4 March 2014 14:07, Odinn Cyberguerrilla > > wrote: > > Nothing is safe. > > > This is true. To rephrase, imagine I gave you an ECC public key > , you gave me back a public key of your own > devising, the

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

canonical ID can be used to prevent 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 wrote: > I think the solution is simply to encourage Bitcoin software developers to > de

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

etely remove malleability. There are other important use > cases where having a unique identifier just for internal accounting is > insufficient. > > -Allen > > > On Wed, Feb 12, 2014 at 10:22 AM, Alan Reiner wrote: > >> I think the solution is simply to encourage Bitcoi

Re: [Bitcoin-development] [RFC] [BIP proposal] Dealing with malleability

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

Re: [Bitcoin-development] Stealth Addresses

*Avoiding ECDH calcs on every blockchain transaction (and avoiding the prefix thing):* Can we skip the whole ECDSA/ECDH thing, and use the second key pair for encryption instead? Then we don't need any ephemeral keys. We use the much simpler scheme like I mentioned before (just root keys and mul

Re: [Bitcoin-development] Stealth Addresses

that Peter Todd mentions is actually *the* > most important currently under-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 t

Re: [Bitcoin-development] Stealth Addresses

On 01/13/2014 03:14 PM, Peter Todd wrote: > On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote: >> How is this different from the proposal I have made? >> >> You distribute the root public key (but not chaincode!) of a BIP32 >> branch. You can put your root ke

Re: [Bitcoin-development] Stealth Addresses

How is this different from the proposal I have made? You distribute the root public key (but not chaincode!) of a BIP32 branch. You can put your root key on a business card if you want. Then when someone wants to pay you, you simply give them the multiplier and root key (they already have the ro

Re: [Bitcoin-development] moving the default display to mbtc

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

Re: [Bitcoin-development] moving the default display to mbtc

I really like the XBT idea. It makes a lot of sense to match the ISO currency symbol (though the ISO guys will have to adjust the way they've defined the "XBT"). And I do agree that going right to uBTC and skipping mBTC makes sense, too. I'd prefer them not be called "micro bitcoins." I really

Re: [Bitcoin-development] moving the default display to mbtc

e wouldn't be too far from human scale > everyday numbers: 25.00uBTC ~= $0.01 currently. And I don't think very > many people on this list would consider bitcoin overvalued in the long > term perspective. > > Better to go through a confusing renumbering only once. > > Ma

Re: [Bitcoin-development] moving the default display to mbtc

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 fie

Re: [Bitcoin-development] Auto-generated miner backbone

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

mining, easily (part of libcoind) > 3. to utilize the soft 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. > > Micha

Re: [Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

-to-address uses more bytes in the > chain and there isn't any typeability benefit. > > The multiplication trick for deterministic keys is a nice one and > worth doing, but it has to be a v2 feature by this point. It's more > important to get v1 widely implemented and deploye

[Bitcoin-development] Optional "wallet-linkable" address format (Re-request)

#x27;s other use cases, but it seems simple enough 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: > Alth

Re: [Bitcoin-development] Payment Protocol: BIP 70, 71, 72

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. >

Re: [Bitcoin-development] Safe auto-updating

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-yea

Re: [Bitcoin-development] Preparing for the Cryptopocalypse

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 bu

Re: [Bitcoin-development] Preparing for the Cryptopocalypse

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 like

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

Although I'd still prefer my original request, I get much of what I want from your guys' recommendation. It complicates the wallet design, because it requires tracking and associating a matrix of addresses for each wallet, instead of a single linear list. But if this is what it's going to take th

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

On 06/20/2013 05:10 AM, Jeremy Spilman wrote: >> which could involve proving something to a third party that has not seen >> the communication between payer and payee. > OK - I think I follow now. So a third-party who does not see any of the > communication between the payer and payee only know

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

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

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

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 und

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

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 th

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

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]) || >>

Re: [Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

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 fam

[Bitcoin-development] Optional "wallet-linkable" address format - Payment Protocol

_*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 pro

Re: [Bitcoin-development] Proposal: Vote on the blocksize limit with proof-of-stake voting

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

Re: [Bitcoin-development] Revocability with known trusted escrow services?

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

Re: [Bitcoin-development] is there a way to do bitcoin-staging?

This is exactly what I was planning to do with the inappropriately-named "Ultimate Blockchain Compression ". I wanted to reorganize the blockchain data into an authenticated tree, indexed by TxOut script (address), instead of tx-hash. Much like

Re: [Bitcoin-development] 2BTC reward for making probabalistic double-spending via conflicting transactions easy

-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 they

Re: [Bitcoin-development] Cold Signing Payment Requests

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 lower-ca

Re: [Bitcoin-development] Anti DoS for tx replacement

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 b

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 04/14/2013 02:25 AM, Peter Todd wrote: > On Sun, Apr 14, 2013 at 01:21:21AM -0400, Alan Reiner wrote: >> If we're going to extend/expand message signing, can we please add a >> proper ASCII-armored format for it? Really, anyth

Re: [Bitcoin-development] RFC: extend signmessage/verifymessage to P2SH multisig

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 comp

[Bitcoin-development] New webpage: Offline Backups

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

Re: [Bitcoin-development] 0.8.1 plan

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 getti

Re: [Bitcoin-development] Some PR preparation

On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr 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, I saw pe

[Bitcoin-development] Some PR preparation

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 prepa

Re: [Bitcoin-development] Payment Protocol Proposal: Invoices/Payments/Receipts

On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen wrote: > 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 got > the simpler c

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

gning up for anything or paying any fees. 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

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

This discussion sounds to be veering slightly off track. I think we should be focusing on how we will ease the transition for new users to get on the network and use it. Talking about the necessity and costs of running full nodes in the future is important, but irrelevant here: unless we don't w

Re: [Bitcoin-development] Roadmap to getting users onto SPV clients

My personal opinion is that the ideal first client has three features: (1) Starts up and is usable within a couple minutes (even 10 min the first time would be okay, to sync block headers) (2) Supports Windows, Linux and OSX (3) Uses deterministic wallets that can produce a permanent backup (prefe

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

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 s

Re: [Bitcoin-development] Chain dust mitigation: Demurrage based Chain Vacuuming

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

Re: [Bitcoin-development] BIP 35: add mempool message

On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik wrote: > On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille > 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 returned, even if empty. > > > > I'm

Re: [Bitcoin-development] Random order for clients page

On 07/09/2012 10:36 PM, Stefan Thomas wrote: It looks like that because feature matrices aren't especially helpful for newbies to make a decision, especially when the "features" in question were often things like how they handled the block chain or which protocol standards they support, ie, thing

Re: [Bitcoin-development] Random order for clients page

I was originaly for the idea of randomization. Because it is the most "fair", but "fair" is a relative term. It's fair for client developers who argue over whose client should be first, and whose is better for various purposes. But it's not fair for users, to have an inconsistent page, that som

Re: [Bitcoin-development] Random order for clients page

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

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

On 06/19/2012 02:18 PM, Mark Friedenbach wrote: On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner <mailto:etothe...@gmail.com>> wrote: If we were to use a raw trie structure, then we'd have all the above issues solved: a trie has the same configuration no matter how el

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

On 06/19/2012 01:59 PM, Gregory Maxwell wrote: On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner 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 root. Not only

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite node

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 ord

Re: [Bitcoin-development] Ultimate Blockchain Compression w/ trust-free lite nodes

I've sent you the message privately by mistake. > Also, I don't quite understand your concern of "unbalancing" the tree. > > 2012/6/17 Peter Todd: >> On Sun, Jun 17, 2012 at 02:39:28PM -0400, Alan Reiner wrote: >>> All, >>> >>> With the flu

  1   2   >