Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner
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

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner
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

Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner
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

Re: [Bitcoin-development] Block Size Increase

2015-05-07 Thread Alan Reiner
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

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

2015-02-12 Thread Alan Reiner
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

2015-01-23 Thread Alan Reiner
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

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Alan Reiner
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

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Alan Reiner
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

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Alan Reiner
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

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread Alan Reiner
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

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

2015-01-19 Thread Alan Reiner
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

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

2015-01-16 Thread Alan Reiner
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

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

2014-11-16 Thread Alan Reiner
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

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

2014-10-08 Thread Alan Reiner
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

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

2014-10-01 Thread Alan Reiner
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')

2014-09-28 Thread Alan Reiner
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

2014-09-25 Thread Alan Reiner
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

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

2014-09-23 Thread Alan Reiner
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

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

2014-09-23 Thread Alan Reiner
-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

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

2014-09-23 Thread Alan Reiner
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

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

2014-07-30 Thread Alan Reiner
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

Re: [Bitcoin-development] ASIC-proof mining

2014-07-04 Thread Alan Reiner
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] ASIC-proof mining

2014-07-04 Thread Alan Reiner
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

Re: [Bitcoin-development] Bloom bait

2014-06-07 Thread Alan Reiner
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

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

2014-05-24 Thread Alan Reiner
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

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

2014-05-24 Thread Alan Reiner
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

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

2014-04-26 Thread Alan Reiner
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

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

2014-04-25 Thread Alan Reiner
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

Re: [Bitcoin-development] Economics of information propagation

2014-04-21 Thread Alan Reiner
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

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

2014-04-20 Thread Alan Reiner
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

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

2014-03-29 Thread Alan Reiner
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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

2014-03-29 Thread Alan Reiner
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

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

2014-03-29 Thread Alan Reiner
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

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

2014-03-29 Thread Alan Reiner
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

Re: [Bitcoin-development] New BIP32 structure

2014-03-26 Thread 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

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

2014-03-25 Thread Alan Reiner
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

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

2014-03-13 Thread Alan Reiner
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

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

2014-03-13 Thread Alan Reiner
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

Re: [Bitcoin-development] Multisign payment protocol?

2014-03-11 Thread Alan Reiner
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

Re: [Bitcoin-development] Multisign payment protocol?

2014-03-10 Thread Alan Reiner
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

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

2014-03-08 Thread Alan Reiner
, 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

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

2014-03-08 Thread Alan Reiner
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

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

2014-02-12 Thread Alan Reiner
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] [RFC] [BIP proposal] Dealing with malleability

2014-02-12 Thread Alan Reiner
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

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

2014-02-12 Thread Alan Reiner
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

Re: [Bitcoin-development] Stealth Addresses

2014-01-13 Thread Alan Reiner
-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

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

2013-11-14 Thread Alan Reiner
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

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

2013-11-14 Thread Alan Reiner
people on this list would consider bitcoin overvalued in the long term perspective. Better to go through a confusing renumbering only once. Mark On 11/14/13 12:01 PM, Alan Reiner wrote: ... I'm also of the opinion that it's freakin' hard to change the base unit in such an established

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

2013-11-14 Thread Alan Reiner
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] Auto-generated miner backbone

2013-11-04 Thread Alan Reiner
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?

2013-10-14 Thread Alan Reiner
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

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

2013-08-09 Thread Alan Reiner
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

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

2013-08-07 Thread Alan Reiner
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

Re: [Bitcoin-development] Safe auto-updating

2013-08-05 Thread Alan Reiner
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

Re: [Bitcoin-development] Preparing for the Cryptopocalypse

2013-08-04 Thread Alan Reiner
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

Re: [Bitcoin-development] Preparing for the Cryptopocalypse

2013-08-04 Thread Alan Reiner
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

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

2013-06-19 Thread Alan Reiner
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

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

2013-06-19 Thread Alan Reiner
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

2013-06-19 Thread Alan Reiner
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

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

2013-06-19 Thread Alan Reiner
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

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

2013-06-19 Thread Alan Reiner
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

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

2013-06-17 Thread Alan Reiner
_*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

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

2013-06-10 Thread Alan Reiner
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?

2013-06-05 Thread Alan Reiner
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] 2BTC reward for making probabalistic double-spending via conflicting transactions easy

2013-05-15 Thread Alan Reiner
-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

Re: [Bitcoin-development] Cold Signing Payment Requests

2013-04-24 Thread Alan Reiner
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

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

2013-04-17 Thread Alan Reiner
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

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

2013-04-13 Thread Alan Reiner
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

[Bitcoin-development] New webpage: Offline Backups

2013-03-21 Thread Alan Reiner
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

Re: [Bitcoin-development] 0.8.1 plan

2013-03-16 Thread Alan Reiner
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

[Bitcoin-development] Some PR preparation

2013-03-12 Thread Alan Reiner
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

Re: [Bitcoin-development] Some PR preparation

2013-03-12 Thread Alan Reiner
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,

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

2012-12-06 Thread Alan Reiner
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

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

2012-12-04 Thread Alan Reiner
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

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

2012-12-04 Thread Alan Reiner
. 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

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

2012-12-03 Thread Alan Reiner
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

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

2012-12-03 Thread Alan Reiner
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

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

2012-08-16 Thread Alan Reiner
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

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

2012-07-09 Thread Alan Reiner
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

2012-06-19 Thread Alan Reiner
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

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

2012-06-19 Thread Alan Reiner
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

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

2012-06-17 Thread Alan Reiner
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

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

2012-06-17 Thread Alan Reiner
...@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

[Bitcoin-development] A tangent about BIP 10

2012-06-14 Thread Alan Reiner
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

[Bitcoin-development] Full Clients in the future - Blockchain management

2012-06-02 Thread Alan Reiner
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] Fwd: Re: Full Clients in the future - Blockchain management

2012-06-02 Thread Alan Reiner
: [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

Re: [Bitcoin-development] Punishing empty blocks?

2012-05-25 Thread Alan Reiner
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,

Re: [Bitcoin-development] URI Handling in Bitcoin-Qt

2012-05-03 Thread Alan Reiner
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Alan Reiner
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Alan Reiner
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Alan Reiner
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-05-02 Thread Alan Reiner
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-04-30 Thread Alan Reiner
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

Re: [Bitcoin-development] new bitcoin.org clients page

2012-04-30 Thread Alan Reiner
. 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

Re: [Bitcoin-development] Trusted identities

2012-04-26 Thread Alan Reiner
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

Re: [Bitcoin-development] Bitcoin TX fill-or-kill deterministic behavior

2012-04-12 Thread Alan Reiner
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

Re: [Bitcoin-development] Signature Blocks and URI Sign Requests

2012-04-03 Thread Alan Reiner
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

Re: [Bitcoin-development] Signature Blocks and URI Sign Requests

2012-04-03 Thread Alan Reiner
once collected by SOME client? Would we expect the standard client do so? Sorry if this has been discussed before - I'm trying to understand the proposal. On Tue, Apr 3, 2012 at 2:12 PM, Alan Reiner etothe...@gmail.com mailto:etothe...@gmail.com wrote: Just to clarify, I'm

[Bitcoin-development] Signature Blocks and URI Sign Requests

2012-04-02 Thread Alan Reiner
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

Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

2012-01-16 Thread Alan Reiner
You guys are representing both extremes of the issue. In response to Jeff and Luke-Jr, I don't see how this is /just any other poltical issue/. It strikes at the heart of everything Bitcoin is about. Barring Bitcoin-specific legislation, I don't see how any legislation could be more

  1   2   >