Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner

This isn't about everyone's coffee.  This is about an absolute minimum
amount of participation by people who wish to use the network.   If our
goal is really for bitcoin to really be a global, open transaction
network that makes money fluid, then 7tps is already a failure.  If even
5% of the world (350M people) was using the network for 1 tx per month
(perhaps to open payment channels, or shift money between side chains),
we'll be above 100 tps.  And that doesn't include all the
non-individuals (organizations) that want to use it.

The goals of a global transaction network and everyone must be able
to run a full node with their $200 dell laptop are not compatible.  We
need to accept that a global transaction system cannot be
fully/constantly audited by everyone and their mother.  The important
feature of the network is that it is open and anyone *can* get the
history and verify it.  But not everyone is required to.   Trying to
promote a system where the history can be forever handled by a low-end
PC is already falling out of reach, even with our miniscule 7 tps. 
Clinging to that goal needlessly limits the capability for the 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 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, and relying on fee pressure at 1 MB severely
 impacts attractiveness and adoption potential of Bitcoin (due to
 high fees and unreliability).  But more importantly, it ignores
 the fact that for a 7 tps is pathetic for a global transaction
 system.  It is a couple orders of magnitude too low for any
 meaningful commercial activity to occur.  If we continue with a
 cap of 7 tps forever, Bitcoin *will* fail.  Or at best, it will
 fail to be useful for the vast majority of the world (which
 probably leads to failure).  We shouldn't be talking about fee
 pressure until we hit 700 tps, which is probably still too low. 

  [...]

 1) Agree that 7 tps is too low

 2) Where do you want to go?  Should bitcoin scale up to handle all the
 world's coffees? 

 This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day --
 just for a single feed.  If you include relaying to multiple nodes,
 plus serving 500 million SPV clients en grosse, who has the capacity
 to run such a node?  By the time we get to fee pressure, in your
 scenario, our network node count is tiny and highly centralized.

 3) In RE fee pressure -- Do you see the moral hazard to a
 software-run system?  It is an intentional, human decision to flood
 the market with supply, thereby altering the economics, forcing fees
 to remain low in the hopes of achieving adoption.  I'm pro-bitcoin and
 obviously want to see bitcoin adoption - but I don't want to sacrifice
 every decentralized principle and become a central banker in order to
 get there.


--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 right now.  I was
simply suggesting that if Bitcoin is to *ultimately* achieve the goal of
being a globally useful payment rails, 7tps is embarrassingly small. 
Even with off-chain transactions.  It should be a no-brainer that block
size has to go up.

My goal was to bring some long-term perspective into the discussion.  I
don't know if 100 MB blocks will *actually* be necessary for Bitcoin in
20 years, but it's feasible that it will be.  It's an open, global
payments system.  Therefore, we shouldn't be arguing about whether 1 MB
blocks is sufficient--it's very clearly not.  And admitting this as a
valid point is also an admission that not everyone in the world will be
able to run a full node in 20 years.

I don't think there's a solution that can accommodate all future
scenarios, nor that we can even find a solution right now that avoids
more hard forks in the future.   But the goal of everyone should be
able to download and verify the world's global transactions on a
smartphone is a non-starter and should not drive decisions. 

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Block Size Increase

2015-05-08 Thread Alan Reiner
Actually I believe that side chains and off-main-chain transactions will be
a critical part for the overall scalability of the network.  I was actually
trying to make the point that (insert some huge block size here) will be
needed to even accommodate the reduced traffic.

I believe 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 everyone's coffee.  This is about an absolute minimum
 amount of participation by people who wish to use the network.   If our
 goal is really for bitcoin to really be a global, open transaction network
 that makes money fluid, then 7tps is already a failure.  If even 5% of the
 world (350M people) was using the network for 1 tx per month (perhaps to
 open payment channels, or shift money between side chains), we'll be above
 100 tps.  And that doesn't include all the non-individuals (organizations)
 that want to use it.


 The goals of a global transaction network and everyone must be able to
 run a full node with their $200 dell laptop are not compatible.  We need
 to accept that a global transaction system cannot be fully/constantly
 audited by everyone and their mother.  The important feature of the network
 is that it is open and anyone *can* get the history and verify it.  But not
 everyone is required to.   Trying to promote a system wher000e the history
 can be forever handled by a low-end PC is already falling out of reach,
 even with our miniscule 7 tps.  Clinging to that goal needlessly limits the
 capability for the network to scale to be a useful global payments system


 These are good points and got me thinking (but I think you're wrong). If
 we really want each of the 10 billion people soon using bitcoin once per
 month, that will require 500MB blocks. That's about 2 TB per month. And if
 you relay it to 4 peers, it's 10 TB per month. Which I suppose is doable
 for a home desktop, so you can just run a pruned full node with all
 transactions from the past month. But how do you sync all those
 transactions if you've never done this before or it's been a while since
 you did? I think it currently takes at least 3 hours to fully sync 30 GB of
 transactions. So 2 TB will take 8 days, then you take a bit more time to
 sync the days that passed while you were syncing. So that's doable, but at
 a certain point, like 10 TB per month (still only 5 transactions per month
 per person), you will need 41 days to sync that month, so you will never
 catch up. So I think in order to keep the very important property of anyone
 being able to start clean and verify the thing, then we need to think of
 bitcoin as a system that does transactions for a large number of users at
 once in one transaction, and not a system where each person will make a
 ~monthly transaction on. We need to therefore rely on sidechains,
 treechains, lightning channels, etc...

 I'm not a bitcoin wizard and this is just my second post on this mailing
 list, so I may be missing something. So please someone, correct me if I'm
 wrong.




 On 05/07/2015 03:54 PM, Jeff Garzik wrote:

  On Thu, May 7, 2015 at 3:31 PM, Alan Reiner 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, and
 relying on fee pressure at 1 MB severely impacts attractiveness and
 adoption potential of Bitcoin (due to high fees and unreliability).  But
 more importantly, it ignores the fact that for a 7 tps is pathetic for a
 global transaction system.  It is a couple orders of magnitude too low for
 any meaningful commercial activity to occur.  If we continue with a cap of
 7 tps forever, Bitcoin *will* fail.  Or at best, it will fail to be
 useful for the vast majority of the world (which probably leads to
 failure).  We shouldn't be talking about fee pressure until we hit 700 tps,
 which is probably still too low.

  [...]

  1) Agree that 7 tps is too low

  2) Where do you want to go?  Should bitcoin scale up to handle all the
 world's coffees?

  This is hugely unrealistic.  700 tps is 100MB blocks, 14.4 GB/day --
 just for a single feed.  If you include relaying to multiple nodes, plus
 serving 500 million SPV clients en grosse, who has the capacity to run such
 a node?  By the time we get to fee pressure, in your scenario, our network
 node count is tiny and highly centralized.

  3) In RE fee pressure -- Do you see the moral hazard to a software-run
 system?  It is an intentional, human decision to flood the market with
 supply, thereby altering the economics, forcing fees to remain low in the
 hopes of achieving adoption.  I'm pro-bitcoin and obviously want to see
 bitcoin adoption - but I don't want to sacrifice every decentralized
 principle and become a central

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 of the network (from the average user perspective)
is about to be impacted in a very negative way (I believe it was due to
the inconsistent time between blocks).  I think Gavin said that his
simulations showed 400 kB - 600 kB worth of transactions per 10 min
(approx 3-4 tps) is where things start to behave poorly for certain
classes of transactions.  In other words, we're very close to the
effective limit in terms of maintaining the current standard of
living, and with a year needed to raise the block time this actually is
urgent.

(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, and
relying on fee pressure at 1 MB severely impacts attractiveness and
adoption potential of Bitcoin (due to high fees and unreliability).  But
more importantly, it ignores the fact that for a 7 tps is pathetic for a
global transaction system.  It is a couple orders of magnitude too low
for any meaningful commercial activity to occur.  If we continue with a
cap of 7 tps forever, Bitcoin *will* fail.  Or at best, it will fail to
be useful for the vast majority of the world (which probably leads to
failure).  We shouldn't be talking about fee pressure until we hit 700
tps, which is probably still too low. 

You can argue that side chains and payment channels could alleviate
this.  But how far off are they?  We're going to hit effective 1MB
limits long before we can leverage those in a meaningful way.  Even if
everyone used them, getting a billion people onto the system just can't
happen even at 1 transaction per year per person to get into a payment
channel or move money between side chains.

We get asked all the time by corporate clients about scalability.  A
limit of 7 tps makes them uncomfortable that they are going to invest
all this time into a system that has no chance of handling the economic
activity that they expect it handle.  We always assure them that 7 tps
is not the final answer. 

Satoshi didn't believe 1 MB blocks were the correct answer.  I
personally think this is critical to Bitcoin's long term future.   And
I'm not sure what else Gavin could've done to push this along in a
meaninful way.

-Alan


On 05/07/2015 02:06 PM, Mike Hearn wrote:

 I think you are rubbing against your own presupposition that
 people must find and alternative right now. Quite a lot here do
 not believe there is any urgency, nor that there is an immanent
 problem that has to be solved before the sky falls in.


 I have explained why I believe there is some urgency, whereby some
 urgency I mean, assuming it takes months to implement, merge, test,
 release and for people to upgrade.

 But if it makes you happy, imagine that this discussion happens all
 over again next year and I ask the same question.



 --
 One dashboard for servers and applications across Physical-Virtual-Cloud 
 Widest out-of-the-box monitoring support with 50+ applications
 Performance metrics, stats and reports that give you Actionable Insights
 Deep dive visibility with transaction tracing using APM Insight.
 http://ad.doubleclick.net/ddm/clk/290420510;117567292;y


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
One dashboard for servers and applications across Physical-Virtual-Cloud 
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 tx are safe solely because it has always
appeared safe.  You can argue about rational miner behaviors all day,
but in a decentralized system you have no idea what miners consider
rational, or speculate about their incentives. 

If there's one thing I learned playing poker (many years ago), was that
always assuming your opponent is rational can lose you a lot of money. 
You made play that, in hindsight, was terrible given what he actually
had.  But you assumed no sane or rational person in his position would
make such a play so you discounted it in your decision-making process. 
You're right that his actions were terrible and irrational, but he
still won your money because you discounted his ability to make such a
bad play.  Here, you are speculating that an opponent uses the same
values/motivations/rationality as yourself, and then building systems
that depend on that being true.  Even if it should be true doesn't
mean that it is true and will remain that way.  And you will get burned
by it eventually.

The Bitcoin network achieves something that we didnt' think was possible
10 years ago:  a totally trustless, decentralized ledger.  The cost?  It
takes time for the decentralized network to reach consensus that
transactions happened.  That is quite literally the trade-off that we
make: you can centralize things by putting a bank in the middle and
getting instant confirmation, or you decentralize and let the network
reach consensus over time without the central authority.   If you want
instant confirmations, you're going to need to add centralization
because Bitcoin never offered it.  I support efforts to dispel any such
myths as soon as possible and encourage building robust solutions
(payment channels, insured zero-conf services, etc.).

-Alan


On 02/12/2015 07:37 PM, Allen Piscitello wrote:
 You cannot close Pandora's box.  Whether or not this type of patch should 
 exist is irrelevant.  It
does, and there are incentives to use it by miners.  These are the
bounds we have to deal with and the world we must adapt to.

 On Thu, Feb 12, 2015 at 12:11 PM, Justus Ranvier
justusranv...@riseup.net mailto:justusranv...@riseup.net wrote:

 On 02/12/2015 05:24 PM, Oleg Andreev wrote:

  I think that is a misdirection on your part. The point of
  replace-by-fee is to make 0-confirms reliably unreliable.
  Currently people can get away with 0-confirms but it's only
  because most people arent actively double spending, and when they
  do it is for higher value targets. Double spend attacks are
  happening a lot more frequently than is being admitted here,
  according to Peter from work with various clients.
 
  Like single address reuse, people have gotten used to something
  which is bad. Generally accepting 0-conf is also a bad idea(tm)
  and instant confirmation solutions should be sought elsewhere.
  There are already interesting solutions and concepts:
  greenaddress for example, and CHECKLOCKTIMEVERIFY micropayment
  channels for example. Rather than supporting and promoting risky
  0-confirms, we need to spend time on better alternative solutions
  that will work for everyone and not during the honeymoon phase
  where attackers are fewer.

  Here's value-free assessment of the issue here:

  1. Zero-conf txs are unsafe. 2. We'd all want to have a safer
  instant payments solution if possible. 3. As a social artifact,
  today zeroconf txs happen to work for some people in some
  situations. 4. Replace-by-fee will break #3 and probably hasten
  development of #2.

  The discussion boils down to whether we should make #2 happen
  sooner by breaking remnants of #3 sooner.

  I personally would rather not break anything, but work as fast as
  possible on #2 so no matter when and how #3 becomes utterly broken,
  we have a better solution. This implies that I also don't want to
  waste time debating with Peter Todd and others. I want to be ready
  with a working tool when zeroconf completely fails (with that patch
  or for some other reasons).

  TL;DR: those who are against the patch are better off building a
  decentralized clearing network rather than wasting time on debates.
  When we have such network, we might all want this patch to be used
  for all the reasons Peter has already outlined.

 You've left out of the discussion that many (or all) proposed
 solutions for 2 either reduce privacy, or security, or both.

 That fact should not be ignored or swept under the rug.

 There's also no mention of the degree to which child-pays-for-parent
 achieves the stated aims of the original proposal (clearing mempool of
 stuck transactions, increasing payee assurance of conformation)
 without introducing incentives to double 

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 contained by the wallet).

 
Self-correction ... I didn't mean it's the only way, I mean it's by
far the easiest, simplest, least-intrusive way that achieves the
properties we need for this to be useful.

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 relevant, and if the attacker can DoS you for 24 hours, it
doesn't take a ton of mining power to make the attack extremely likely
to succeed.




On 01/23/2015 10:31 AM, Tamas Blummer wrote:
 Not a fix, but would reduce the financial risk, if nodes were not
 relaying excessive fee transactions.

 Tamas Blummer



--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 their signers.   The proposal simply provides
a way to optionally sign the input values with the TxOut scripts.  In
other words a signature right now says I sign this transaction using
these inputs, whatever value they are.  With this SIGHASH type, the
signature says I sign this transaction assuming that input 0 is X BTC,
input 1 is Y BTC,.  If the online computer providing the data to be
signed lies about the value of any input, the resulting signature will
be invalid.

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 of it required the coins being spent to have been
originated in a special way.  In other words, it would only work if the
coins had entered the wallet with some special, modified TxOut script. 
So it wouldn't work with existing coins, and would require senders to
update their software to reshape the way they send transactions to be
compatible with our goals.

I *strongly* encourage this to be considered for inclusion at some
point.  Not only does it simplify HW as Marek suggested, it increases
the options for online-offline communication channels, which is also a
win for security.  Right now, QR codes don't work because of the
possibility of having to transfer megabytes over the channel, and no way
to for the signer to control that size.  With this change, it's possible
for the signer to control the size of each chunk of data to guarantee it
fits in, say, a QR code (even if it means breaking it up into a couple
smaller transactions).

-Alan



On 01/23/2015 09:51 AM, slush wrote:
 Hi,

 is any progress or even discussion in this area? 

 https://bitcointalk.org/index.php?topic=181734.0

 I don't insist on any specific solution, but this is becoming a real
 issue as hardware wallets are more widespread. I'm sitting next to
 TREZOR for 40 minutes already, because it streams and validate some
 complex transaction. By using proposed solution, such signature would
 be a matter of few seconds.

 That's also not just about time/resource/hw cost optimization. I'm
 talking about possibility of huge simplification of the firmware
 (=security FTW), because 50% of actual codebase is solving this
 particular downside of Bitcoin protocol.

 So, there's real world problem. On which solution can we as a
 community find a wide agreement?

 Best,
 Marek


 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 of it required the coins being spent to have been
 originated in a special way.  In other words, it would only work if the
 coins had entered the wallet with some special, modified TxOut script.  So
 it wouldn't work with existing coins, and would require senders to update
 their software to reshape the way they send transactions to be compatible
 with our goals.
 I think this is unreasonable. There is a straight-forward soft-fork
 approach which is safe (e.g. no risk of invalidating existing
 transactions). Yes, it means that you need to use newly created
 addresses to get coins that use the new signature type... but thats
 only the case for people who want the new capability. This is
 massively preferable to expecting _every_ _other_ user of the system
 (including miners, full nodes, etc.) to replace their software with an
 incompatible new version just to accommodate your transactions, for
 which they may care nothing about and which would otherwise not have
 any urgent need to change.




As far as I'm concerned, anything that requires the coins to originate
in the wallet with some special form is a non-starter.  The new SIGHASH
type allows you to sign transactions with any coins already in your
wallet, and imposes no requirements on anyone paying your cold wallet. 
Any such proposals that require origination structure means that 100% of
people paying you need to be nice and use this new script type, or
else you *have* to

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 of it required the coins being spent to have been
 originated in a special way.  In other words, it would only work if the
 coins had entered the wallet with some special, modified TxOut script.  So
 it wouldn't work with existing coins, and would require senders to update
 their software to reshape the way they send transactions to be compatible
 with our goals.
 I think this is unreasonable. There is a straight-forward soft-fork
 approach which is safe (e.g. no risk of invalidating existing
 transactions). Yes, it means that you need to use newly created
 addresses to get coins that use the new signature type... but thats
 only the case for people who want the new capability. This is
 massively preferable to expecting _every_ _other_ user of the system
 (including miners, full nodes, etc.) to replace their software with an
 incompatible new version just to accommodate your transactions, for
 which they may care nothing about and which would otherwise not have
 any urgent need to change.




As far as I'm concerned, anything that requires the coins to originate
in the wallet with some special form is a non-starter.  The new SIGHASH
type allows you to sign transactions with *any* coins already in your
wallet, and imposes no requirements on anyone paying your cold wallet to
be compatible with your signer. 

Any proposals that require coin origination features means that 100% of
people paying you need to be nice and send you coins with this special
structure.  You can't spend old coins that were sent before this
proposal was implemented, and if anyone sends you coins without
respecting the new structure, then your signing devices need the
full-complexity routines to accommodate, which defeats the entire purpose.

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 contained by the wallet).


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 bunch of named fields between systems.  I thought there
was no guarantee that two identical protobuf structures will get
serialized identically...?




On 01/19/2015 02:57 PM, Richard Brady wrote:
 Thanks guys, great answers. 

 The design choice certainly makes a lot more sense now regardless of
 whether one agrees with it or not.

 Regards,
 Richard



 --
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 looking for all combinations of compressed  uncompressed.

On 01/16/2015 11:34 AM, Thomas Kerin wrote:


 It seems there is scope for further narrowing down how a multisig
 scripthash address should be determined - what do people think of
 anticipating only compressed keys for scripts?

 It's possible to cause confusion if one put forward a compressed key
 at some time, and an uncompressed key at another. A different script
 hash would be produced even though there is no difference to the keys
 involved. The client will not search for this.


 Having spoken with Jean-Pierre and Ruben about this for quite some
 time now, there is 100% the need for a BIP outlining this. Everyone
 has had the idea at some point, and some of us already using it, but
 people shouldn't have to go digging in BIP45 for the two lines which
 mention it. All we need is a place to put the docs.

 I am building up a list of implementations which currently support
 sorting, and briefly describing a motivation for such a BIP.


 On 16/01/15 10:16, Ruben de Vries wrote:
  Since we only need the sorting for creating the scriptPubKey,
  wouldn't it make the most sense to sort it by the way it represented
 in that context?


  On Thu, Jan 15, 2015 at 2:03 PM, Wladimir laa...@gmail.com
 mailto:laa...@gmail.com wrote:

  On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock
 b...@mattwhitlock.name mailto:b...@mattwhitlock.name wrote:
   On Wednesday, 14 January 2015, at 3:53 pm, Eric Lombrozo wrote:
   Internally, pubkeys are DER-encoded integers.
  
   I thought pubkeys were represented as raw integers (i.e.,
 they're embedded in Script as a push operation whose payload is the
 raw bytes of the big-endian representation of the integer). As far as
 I know, DER encoding is only used for signatures. Am I mistaken?

  OP_CHECKSIG (and OP_CHECKSIGVERIFY) takes a DER-encoded pubkey and a
  DER-encoded signature on the stack.

  Possibly you're confused with OP_HASH160 hash160 OP_EQUALVERIFY as
  used in outputs, which compares the 160-bit hash of the pubkey
 against
  the given hash (usually taken from a bitcoin address).

  It doesn't help understanding to consider either as integers.
 They are
  binary blob objects with either a fixed format (DER) or a fixed size
  (hashes).

  Wladimir




  --
  BlockTrail B.V.
  Barbara Strozzilaan 201
  1083HN Amsterdam
  The Netherlands

  Phone:+31 (0)612227277
  E-mail:ru...@blocktrail.com mailto:ru...@blocktrail.com
  Web:www.blocktrail.com
  http://www.blocktrail.com/
  Github:www.github.com/rubensayshi http://www.github.com/rubensayshi

  BlockTrail B.V. Is registered with the Dutch Chamber of Commerce in
 Amsterdam with registration No.:60262060 and VAT No.:NL853833035B01


 
 --
  New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
  GigeNET is offering a free month of service with a new server in
 Ashburn.
  Choose from 2 high performing configs, both with 100TB of bandwidth.
  Higher redundancy.Lower latency.Increased capacity.Completely compliant.
  http://p.sf.net/sfu/gigenet


  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development





--
 New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
 GigeNET is offering a free month of service with a new server in Ashburn.
 Choose from 2 high performing configs, both with 100TB of bandwidth.
 Higher redundancy.Lower latency.Increased capacity.Completely compliant.
 http://p.sf.net/sfu/gigenet


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
New Year. New Location. New Benefits. New Data Center in Ashburn, VA.
GigeNET is offering a free month of service with a new server in Ashburn.
Choose from 2 high performing configs, both with 100TB of bandwidth.
Higher redundancy.Lower latency.Increased capacity.Completely compliant.
http://p.sf.net/sfu/gigenet___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 had been reduced to 40 bytes, because I had an application where I
wanted to put ECDSA in signatures in the OP_RETURN, and you're going to
need at least 64 bytes for that.   Unfortunately I can't remember now
what that application was, so it's difficult for me to argue for it. 
But I don't think that's an unreasonable use case:  sending a payment
with a signature, essentially all timestamped in the blockchain.



--
Download BIRT iHub F-Type - The Free Enterprise-Grade BIRT Server
from Actuate! Instantly Supercharge Your Business Reports and Dashboards
with Interactivity, Sharing, Native Excel Exports, App Integration  more
Get technology previously reserved for billion-dollar corporations, FREE
http://pubads.g.doubleclick.net/gampad/clk?id=157005751iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 ID-association_:
You want to make N recurring payments of 1 BTC each month to a service. 
Sign N transactions each of them use a CHECKLOCKTIMEVERIFY block number
approximately X months in the future (one for each month).   The script
allows the customer to move the coins at any time, but after the
locktime the merchant/service has signing access.  The merchant software
will continually watch for and sweep all coins that become available via
this mechanism and credit the appropriate customer account.  The
customer maintains control of the funds until payment time, the merchant
can automatically collect it each month without requiring user
interaction, and the customer can cancel it just by spending it
elsewhere before the locktime. 

This scheme has an added benefit:  both the merchant's address and the
user's address is in the script.  Given an appropriate scheme for
linking addresses to accounts (perhaps sending the service a watch-only
BIP32 branch), the service can use the other address in the script to
recognize and link that payment to the user's account.  This allows you
to continue paying and extending your subscription without having to
explicitly link each payment to the account.  The wallet will simply
make sure to use a return address that is in a BIP32 branch that was
provided to the service during signup, and the service will
automatically extend your subscription every month based on that info
when it sweeps payments.

Along with everything else that was mentioned by Peter in his original
proposal, I see OP_CHECKLOCKTIMEVERIFY as an enabling feature, not just
a simple improvement.
 
-Alan


On 10/08/2014 06:26 AM, Wladimir wrote:
 On Tue, Oct 7, 2014 at 6:08 PM, Mike Hearn m...@plan99.net wrote:
 That is easy to change; I'll submit a pull request.

 That's certainly a useful improvement. It won't help the existing userbase
 though - assuming CHECKLOCKTIMEVERIFY is to go in to the next major release.
 The next minor release (0.9.4) could have Gavin's change already.

 I don't think CHECKLOCKTIMEVERIFY will make it into the next major
 release though. Once headers-first and pruning is merged (which is
 expected to be a matter of weeks). I'd like to split off the 0.10
 branch and give it some time to stabilize with a feature freeze, then
 do a release before the end of the year.

 So 0.11, in say 6 months, would be soonest.

 Wladimir

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 proof-of-burn scheme, wouldn't using P2SH
defeat the purpose of it?

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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.

Can't this be solved with a single update to the address format,
allowing a tx version number to be part of the address serialization? 
Then the sending software will apply that version to the payment tx.   
Of course, I'm not sure if allowing nodes to create transactions with
version numbers outside of their programming is safe.  It seems like it
should be since we're talking about soft forks anyway, but there's
probably some subtleties I'm overlooking.


--
Slashdot TV.  Videos for Nerds.  Stuff that Matters.
http://pubads.g.doubleclick.net/gampad/clk?id=160591471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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
proposal for a No-collision mode for multisig BIP32 trees
http://sourceforge.net/p/bitcoin/mailman/message/32860512/ is another
variant that might get some traction but not everyone will use it. 
These things could be supported by simply changing the BIP43 Purpose
index and wallet software could be designed to recognize and react to
the Purpose node for any number of different tree structures, and ignore
any trees that it doesn't recognize (or maybe be able to view the
balance across all the leaves of the tree but not expand it)

We have clients with special use-cases (complex multi-layer trees) that
are unlikely to be recycled across users.  In such cases we might just
use a random Purpose that is recognized by their system, and know that
other software won't mess with it.  Though it would be better if that
field was encoded in the root seed, instead.

Nonetheless, putting that extra layer between the root and the
important tree nodes provides flexibility to BIP32 as a whole.
-Alan


On 09/25/2014 09:53 PM, Gregory Maxwell wrote:
 On Tue, Aug 19, 2014 at 10:11 AM, Justus Ranvier jus...@monetas.net wrote:
 Two draft information BIPs are attached.
 I've pinged some people privately but also pinging the list… no
 commentary on this proposal?

 --
 Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
 Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
 Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
 Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
 http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 documentation).  It's in presentation form:

https://s3.amazonaws.com/bitcoinarmory-media/MultisigWalletNoCollide.pdf

The proposal is that for an M-of-N multisig wallet based on BIP32, there
should be N internal chains and N external chains.  Each party is
assigned a chain based on the lexicographic ordering of their wallet's
root public key in the multisig.   This guarantees that no parties are
generating and distributing the same addresses, and also provides a
certain level of built-in book-keeping.  Coins being received on chain
2*x were created by participant x (receiving), and coins received on
2*x+1 are change outputs created by participant x (outgoing).  Thus,
it's easy from simply looking at the wallet structure who was
responsible for which transactions.

Alternatively, we could change it to suggest that each device is
assigned a pair of chains.  For a 2-of-3 there may 3 participants plus a
CFO with a watch-only version of the multisig wallet.  Then you might
use four pairs of chains.  I'm just not sure how they would be assigned.

If this has been proposed before, then consider this my contribution to
documentation. 
-Alan

P.S. -- No-Collision Mode is not a great name.  Happy to take
suggestions for changing it.


--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 btcwallet mean what
 we're working on is unmentionable here?


Please don't assume poor intentions or sneaky motives.  I get a lot of
emails from a lot of people about a lot of things.  Nine months ago was
an eternity in this world, and it can't be ruled out that I simply forgot.

I have no problem giving credit where it is due, and I mentioned in my
first email that I wasn't sure if my stuff was original.  Please
recap/link it here so that it can be part of this discussion.

- -Alan
-BEGIN PGP SIGNATURE-
Version: GnuPG v1

iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X
pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS+QH1lCz97nr5AoVYV5SAaRzv0z
L9Bz0PiHJFHd4IRbfuFqlPZB8mw2TMD7QWJx/1U+WmpnYYOGsUeJn25psIVZSRTU
FTCsmYrA4cGZ4bZoUKI/eiXrHao8rm/zQ7QHKOMSFWZT57sNea67vlxPXKu+AkmK
nEYa4hD0kD7/R/TrNcmRmOlmbqCnyjICd/yp8Lj26CdHPv3PAvaxUwSX3VhWPbdc
UOiGeo+lXqRnBVpwMd+k7oFddwrc2k9ISRdUVsU86z3JdAXKl/dLS5UoOtfC1JA9
m90TuRtq4QuuzjLF3brI9FthuHNowA//qaVfjo/AYgsKy15td9UBtFbt4E9w263M
NiFEmFkXfbE1JmIvmPG3AQEEdQ1/nmWiN5UcLrBfauEHMDQ1fGd89A8IBpus7bWM
kYXboW3E9RBN4lB6OdyYU4AuH0YQhZodmry4iElMPox/tclmNiaeqDR8UYhD5BMd
eQN9zAALyR1IY1167Ki/abVfWVf5jF7b0Eeu/wAfwcble3sCFrvWWAwzHjNi3GjY
gNfy1eDTbwLj2M63QbtB+YqzQBZx3+SY4euGKYQ1s1CVV9ibAFI52oxeMhwzVOWF
ofeDK5BPL8H+5L3tk+1o
=tX2n
-END PGP SIGNATURE-



--
Meet PCI DSS 3.0 Compliance Requirements with EventLog Analyzer
Achieve PCI DSS 3.0 Compliant Status with Out-of-the-box PCI DSS Reports
Are you Audit-Ready for PCI DSS 3.0 Compliance? Download White paper
Comply to PCI DSS 3.0 Requirement 10 and 11.5 with EventLog Analyzer
http://pubads.g.doubleclick.net/gampad/clk?id=154622311iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-09-23 Thread Alan Reiner
Yes, we sort the keys at each address as well.  But this isn't about key
sorting, it's about assigning each device a different branch of the BIP 32
tree to avoid accidental address re use and to make it self evident which
devices were used for each transaction in the overall wallet history.  I
only suggested sorting the root public keys as a way to assign which
internal/external pair of chains the device should use.

@Justus... Looking at the links you sent I'm not clear how it is related.
And naming it key voting pools seems unrelated to why we are proposing
this scheme.  I'll need more than naked links to understand (I'm not saying
it isn't related, I'm just not seeing the connection)

-Alan

Sent from my overpriced smartphone
On Sep 23, 2014 2:25 PM, Vitalik Buterin v...@buterin.com wrote:

 Have you looked at how Coinvault does it? They have a similar setup, but
 sort the pubkeys at each address.

 On Tue, Sep 23, 2014 at 1:09 PM, 
 bitcoin-development-requ...@lists.sourceforge.net wrote:

 Send Bitcoin-development mailing list submissions to
 bitcoin-development@lists.sourceforge.net

 To subscribe or unsubscribe via the World Wide Web, visit
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 or, via email, send a message with subject or body 'help' to
 bitcoin-development-requ...@lists.sourceforge.net

 You can reach the person managing the list at
 bitcoin-development-ow...@lists.sourceforge.net

 When replying, please 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. Re: Proposal: No-Collision mode for Multisig BIP32 Wallets
   (Justus Ranvier)


 --

 Message: 1
 Date: Tue, 23 Sep 2014 16:37:20 +
 From: Justus Ranvier jus...@monetas.net
 Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for
 Multisig BIP32 Wallets
 To: bitcoin-development@lists.sourceforge.net
 Message-ID: 5421a1c0.6080...@monetas.net
 Content-Type: text/plain; charset=utf-8

 -BEGIN PGP SIGNED MESSAGE-
 Hash: SHA256

 On 09/23/2014 04:16 PM, Alan Reiner wrote:
  P.S. -- No-Collision Mode is not a great name.  Happy to take
  suggestions for changing it.

 I'd call it a voting pool wallet, since that was the original
 application for this arrangement.

 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 btcwallet mean what
 we're working on is unmentionable here?

 - --
 Justus Ranvier   | Monetas http://monetas.net/
 mailto:jus...@monetas.net  | Public key ID : C3F7BB2638450DB5
  | BM-2cTepVtZ6AyJAs2Y8LpcvZB8KbdaWLwKqc
 -BEGIN PGP SIGNATURE-

 iQEcBAEBCAAGBQJUIaHAAAoJEMP3uyY4RQ21nwoH/3MYi9JibblZYmSOvCT1vJrN
 Ih+Q2WNumIAI+Y9bh4bBgLuhnG5lXyHedhYEUW+mfuwGiX+92Uc47nwaWED2/Lte
 4Zk/KZnwLifdWCgKLdGpW6mzksRiOaVyU4vV5JchVOrGZZ2zYNIq+NcChtCph7Y5
 L202ReAG+1dfSpp4rFckuv7pTVjNcrq89UN1tJFDNQdxzIRd7bwoeCuvyFurZagB
 88bNiOl0BI3e090WC+CWmbC6BfqJiicn/d0gp/agW01wy7CVbLypPPTKmYqt3+54
 msLUgaRHcbjuyKqu8HMHpYtgYVSNFg2q+U4SgmEepzPAkQ97khbduqA6i1B0ULM=
 =t/xp
 -END PGP SIGNATURE-
 -- next part --
 A non-text attachment was scrubbed...
 Name: 0x38450DB5.asc
 Type: application/pgp-keys
 Size: 14046 bytes
 Desc: not available

 --

 Message: 2
 Date: Tue, 23 Sep 2014 12:48:34 -0400
 From: Alan Reiner etothe...@gmail.com
 Subject: Re: [Bitcoin-development] Proposal: No-Collision mode for
 Multisig BIP32 Wallets
 To: bitcoin-development@lists.sourceforge.net
 Message-ID: 5421a462.6030...@gmail.com
 Content-Type: text/plain; charset=ISO-8859-1


 -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 btcwallet mean what
  we're working on is unmentionable here?
 

 Please don't assume poor intentions or sneaky motives.  I get a lot of
 emails from a lot of people about a lot of things.  Nine months ago was
 an eternity in this world, and it can't be ruled out that I simply forgot.

 I have no problem giving credit where it is due, and I mentioned in my
 first email that I wasn't sure if my stuff was original.  Please
 recap/link it here so that it can be part of this discussion.

 - -Alan
 -BEGIN PGP SIGNATURE-
 Version: GnuPG v1

 iQIcBAEBAgAGBQJUIaRiAAoJEBHe6b77WWmFcBgP/2IiQWda5diBIrd8MjbtYz/X
 pF+B1zOipClil151pKN5h9f4CI75qwSBSG6pUS

[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 to 7-of-7
  * Any or all of the signing devices can be *offline*
  * All private keys can be generated and managed independently
  * Works with existing Armory wallets
  * Simultaneous funding (simulfunding) features for escrow and
contracts (basically CoinJoin)
  * All wrapped up in a nice graphical user interface!

Armory 0.92 includes a GUI for creating, funding and spending from
multi-signature lockboxes, anything from 1-of-2 up to 7-of-7.  All
private keys can be generated independently and never have to be
co-located.Most importantly, any number of the signing keys can be
created and managed on offline computers!  Also, all transaction and
signature data is communicated directly between parties/devices using
ASCII-armored blocks of text, so no third-party servers/services are
needed (though, in the future, we hope to provide an optional service to
help synchronize the data between parties).

The release also includes the ability to do simultaneous funding
(simulfunding) which is basically CoinJoin through a GUI, but intended
to be used for contracts and escrow.  Each party creates a promissory
note (which is basically just a list of UTXOs and a change address),
and those can be merged into a single transaction to be signed by all
funders.  Either all contributions are made simutaneously, or none of
them are.   There is no other outcome.  This means that no trust is
required between the simulfunders.  It is a basic contract enforced by
the bitcoin network itself.

Simulfunding would normally be used in conjuction with multi-signature
lockboxes -- two parties that don't trust each other together create a
lockbox, and then simultaneously fund it (and subsequently spend it)
according to some agreement.  However, it can actually be used to
simulfund any address.  To promote this feature, Armory Technologies Inc
is offering to match up to 20 BTC in donations to the EFF, FSF, College
Crypto Network, Chamber of Digital Commerce, and the Bitcoin Foundation
(and hopefully wikipedia, as a late addition to the list).We posted
a list of ATI promissory notes for matching donations on our
website:   https://bitcoinarmory.com/donation-match-list/

We're very excited about this release, which has been in testing for
over three months, and we've been using for management of company funds
between officers for the last two months.  We have not seen anything
else that comes close to matching the flexibility and security afforded
by it (and without being exceptionally inconvenient!).   See our
tutorials, and especially the FAQ at the end: 

https://bitcoinarmory.com/about/using-lockboxes
https://bitcoinarmory.com/about/using-lockboxes/#faq
 
We hope that people will try it out and provide feedback.  Maybe even
match some donations!  We've already matched 3 BTC so far and it was
announced less than 24 hours ago. 

Cheers,
-Alan


--
Press Release: 
http://finance.yahoo.com/news/armory-releases-first-decentralized-multi-233500704.html
--
Changelog:

*VERSION 0.92**
**Released July 29, 2014**
*

- *Multi-Signature Lockboxes!*
  Full-featured interface for creating multi-signature addresses,
  putting money into them, and collecting signatures to spend them.
  See our tutorials at:
https://bitcoinarmory.com/about/using-lockboxes/

- *Simulfunding for Addresses and Lockboxes*
  Use the Multi-Sig menu to do prepare simulfunding to any
  arbitrary address.  Or click on the Simul checkbox in the
  lockbox manager if you are simulfunding a lockbox.  As a promotion
  for this feature we are matching up to 20 BTC worth donations
  to organizations that support Bitcoin, digital security, online
  freedoms, and open-source software.  See our donation list (with
  instructions): https://bitcoinarmory.com/about/donation-match-list

- *Improved Mac/OSX Stability*
  We merged a couple Qt4 patches that dramatically improved
  compatibility on OSX 10.7 and newer.  Should work with the
  upcoming release of OSX 10.10.

- *Armory Daemon/API Upgrades (Beta)*
  The Armory API has been upgraded substantially since version 0.91.
  This version has tons of new functionality matching bitcoind,
  as well as unique functionality including lockbox operations.
  Plan to have complete functionality implemented and tested by
  version 0.93.

- *Upgraded Transaction History Export to CSV*
  Added running balance reporting for individual and all wallets.
  Also fixed a bug where internal transfers within wallets were
  not being reported properly.

- 

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 to continue.  However, what comes to mind is the
ROMix algorithm defined by Colin Percival, which was the pre-cursor to
scrypt.  Which is actually what Armory uses for key stretching because
it's far simpler than scrypt itself while maintaining the memory-hard
properties (the downside is that it's much less flexible in allowing the
user to trade-off compute time vs memory usage).

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 into 32,000,000 sequential bytes
of RAM.  Then you are going to do 1,000,000 lookup operations on that
table, using the hash of the previous lookup result, to determine the
location of next lookup (within that 32,000,000 bytes).  Assuming a
strong hash function, this means its impossible to know in advance what
needs to be available in RAM to lookup, and it's easiest if you simply
hold all 32,000,000 bytes in RAM.

Something similar could be applied to your idea.  We use the hash of a
prevBlockHash||nonce as the starting point for 1,000,000 lookup
operations.  The output of the previous lookup is used to determine
which block and tx (perhaps which chunk of 32 bytes within that tx) is
used for the next lookup operation.   This means that in order to do the
hashing, you need the entire blockchain available to you, even though
you'll only be using a small fraction of it for each hash.  This might
achieve what you're describing without actually requiring the full 20 GB
of reading on ever hash.

-Alan



On 07/04/2014 06:27 AM, Andy Parkins wrote:
 Hello,

 I had a thought after reading Mike Hearn's blog about it being impossible to 
 have an ASIC-proof proof of work algorithm.

 Perhaps I'm being dim, but I thought I'd mention my thought anyway.

 It strikes me that he's right that it's impossible for any algorithm to exist 
 that can't be implemented in an ASIC.  However, that's only because it's 
 trying to pick an algorithm that is CPU bound.  You could protect against 
 ASCI 
 mining (or rather, make it irrelevant that it was being used) by making the 
 algorithm IO-bound rather than CPU-bound.

 For example, what if the proof-of-work hash for a block were no longer just 
 hash of block, which contains the hash of the parent block, but instead 
 were 
 hash of 

[NEW_BLOCK] [ALL_PREVIOUS_BLOCKS] [NEW_BLOCK]

 [ALL_PREVIOUS_BLOCKS] is now 20GB (from memory) and growing.  By prefixing 
 and 
 suffixing the new block, you have to feed every byte of the blockchain 
 through 
 the hashing engine (the prefix prevents you caching the intermediate result). 
  
 Whatever bus you're using to feed your high speed hashing engine, it will 
 always be faster than the bus -- hence you're now IO-bound, not CPU-bound, 
 and 
 any hashing engine will, effectively, be the same.

 I'm making the assumption that SHA-256 is not cacheable from the middle 
 outwards, so the whole block-chain _has_ to be transferred for every hash.

 Apologies in advance if this is a stupid idea.



 Andy


--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 into 32,000,000 sequential bytes
 of RAM.  Then you are going to do 1,000,000 lookup operations on that
 table, using the hash of the previous lookup result, to determine the
 location of next lookup (within that 32,000,000 bytes).  Assuming a
 strong hash function, this means its impossible to know in advance what
 needs to be available in RAM to lookup, and it's easiest if you simply
 hold all 32,000,000 bytes in RAM.
 My idea wasn't to make hashing memory hungry; it was to make it IO-hungry.  
 It 
 wouldn't be too hard to make an ASIC with 32MB of RAM.  Especially if it 
 gained you a 1000x advantage over the other miners.  It seems that sort of 
 solution is exactly the one that Mike Hearn was warning against in his blog.

I think you misundersood  using ROMix-like algorithm, each hash
requires a different 32 MB of the blockchain.  Uniformly distributed
throughout the blockchain, and no way to predict which 32 MB until you
have actually executed it.   If the difficulty is high enough, your
miner is likely to end up going through the entire X GB blockchain while
searching for a good hash, but other nodes will only need to do 32 MB
worth of disk accesses to verify your answer (and it will be unknown
which 32 MB until they do the 1,000,000 hash+lookup operations on their
X GB blockchain).

I think that strikes a good compromise of needing access to 100% of the
blockchain, without requiring reading 20 GB to verify a block.

(Replace N=1,000,000, 32 MB and 20 GB with the appropriately calibrated
numbers in the future)

--
Open source business process management suite built on Java and Eclipse
Turn processes into business applications with Bonita BPM Community Edition
Quickly connect people, data, and systems into organized workflows
Winner of BOSSIE, CODIE, OW2 and Gartner awards
http://p.sf.net/sfu/Bonitasoft
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 bloom filters you create, the more
information you give away.  It would be most useful to create a single
bloom filter that captures every address you ever intend to use (say a
look ahead of 1000 addresses), and then only ever communicate that. 
Once people see multiple filters that you produce, they can start
looking at the intersection of them to reduce the identity space.  I
would expect that after enough bloom variants, they could figure out a
perfect subset of blockchain addresses in your wallet.  (I suppose you
could intentionally select an extra 20% addresses to include in every
bloom filter, but it's a hack).

Similarly, if you keep updating your bloom filter to include more
addresses, the difference in what passes through the previous one and
the new one gives away information about new addresses you created.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their 
applications. Written by three acclaimed leaders in the field, 
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 worth
 of electricity on the effort) can subjugate the entire Bitcoin network
 to its DoS attack, rather than having to connect to every node
 individually and then still have those individual nodes reject that
 invalid block without relaying any knowledge of its existence.


 That is true, but they could also apply the same hash power to mine
 valid blocks and would achieve the same outcome (their blocks would go
 to everyone), except they would get paid for it.  I wonder if it
 should even be called DoS, due to the extreme and costly rate-limiting
 thats implied.

  

 An attack could also take the form of a block body that never arrives
 - a sort of teergrube attack, where the goal is to get the network
 mining empty block upon empty block on top of that valid-PoW header
 whose body never arrives. It doesn't have to be with an explicitly
 invalid block.


 Thank you for raising this, as I share this concern.  There is another
 similar attack: if I send you a new block very slowly, I occupy all
 your upstream peer slots indefinitely until the block is complete,
 because there is no out-of-band messaging capability or ability to
 cancel a message.

 There is also sub-optimal logic in choosing to download a block only
 from the first person to offer it.  It means you are fetching it from
 the lowest latency path, but what really matters is who can give it to
 you fastest.  If there are multiple people who can send you a block at
 once, and you have some idea of your spare upstream bandwidth
 capacity, why not let two or more peers compete to send you the block
 fastest?

 So to implement this type of thing,  the p2p protocol should allow for
 multiplexing of messages.  Something like HTTP chunked encoding.  It
 could be in the form of:

 msgidchunksizerawbytes, msgidchunksizerawbytes,  etc etc

 You only send a chunk once you've got the whole chunk in your buffer,
 so it's not possible to get hung up on a single slow message.   One
 block can overtake another along the same hop path if it is being
 streamed faster.

 On Sun, May 25, 2014 at 8:46 AM, Gregory Maxwell gmaxw...@gmail.com
 mailto:gmaxw...@gmail.com wrote: 

 If you want to go full out crazy in optimizing in this space, there
 are fancier things that can be done to further reduce latency and
 increase efficiency:
 https://en.bitcoin.it/wiki/User:Gmaxwell/block_network_coding  ... but
 some of this stuff really should be done as a seperate protocol. There
 is no need to have Bitcoin transport all using a single protocol, and
 we can get better robustness and feature velocity if there are a
 couple protocols in use (you could just run a block-transport-protocol
 daemon that connects to your local node via the classic protocol).


 What about a separate project which is a mesh router specifically
 designed for low-latency transmission of blocks?  It could support
 things like a more sophisticated/configurable routing table, and have
 some kind of discovery where it tries to optimise its topology.  There
 could even be some way for nodes to prove their hash power, so pools
 can find each other and directly peer / prioritise sends.


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 valid header received as highest
priority, but only mine on it once it has done full verification of the
block.  In other words, nodes will mine on whatever full/verified block
they have with the earliest header-received time.  If another header
comes in and the tx list is received before the first tx list is done,
then the node will mine the second block *until* it receives and
verifies the first block, then it will switch to mining that first
block.  Most of the time there's no race, it will simply mine the block
N-1 for an extra 1-3 seconds until it receives and verifies the full
block for the new header.

This at least solves part of the problem:  nodes are still only mining
on full blocks, but priority is given to *headers* that come first which
is independent of block size.   As long as a block isn't found within
the 1-3 seconds, then each miner will switch when they finish receiving
and verifying it.  If miners are concerned about that 1-3 second gap,
they should perhaps focus on making sure the tx they are mining are
well-propagated already, so that most of the network has most of the
transactions already in their memory pool by the time their block is mined.
--
Accelerate Dev Cycles with Automated 

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 valid header received as highest
 priority, but only mine on it once it has done full verification of the
 This directly opens an attack where as soon as you find a block you
 announce the header to the world and then you delay announcing the
 block content.  You can continue to mine on the block but no one else
 can (or alternatively they break their rule and risk extending an
 invalid block— bad news for SPV wallets)— then when you find a
 successor block or someone else finds a competing block you
 immediately announce the content.

 It basically means that you can always delay announcing a block and be
 sure that doing so doesn't deprive you of your winning position.



Would this not be solved by putting a expiration on application of this
logic?  For instance, if you haven't received the full new block within
5-10 seconds (perhaps adjusted based on local bandwidth), then the
header-received time is ignored.  Or is this too hacky?   I suppose this
is exactly what Ashley is trying to solve, she's just already made a few
more leaps forward in the design process than I have.  I'll stop
derailing it.

--
Accelerate Dev Cycles with Automated Cross-Browser Testing - For FREE
Instantly run your Selenium tests across 300+ browser/OS combos.
Get unparalleled scalability from the best Selenium testing platform available
Simple to use. Nothing to install. Get started now for free.
http://p.sf.net/sfu/SauceLabs
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 branch
 because each user/cosigner has their own unique seed and thus unique
 key hierarchy, right? What you described above could be an issue if
 all co-signers shared the same seed but then the scheme wouldn't work.

Consider two people with phones, using 2-of-2,  using private seeds k1
and k2.  Every address generated by either party is:

2-of-2(K1/a'/b/c, K2/a'/b/c) 

So for any a, b and c you end up with a 2-of-2 address.  The
seeds/branches will not be used for single-sig receiving... it's always
a multisig 2-of-2.  In fact it behaves much like a regular wallet, you
give an a, b, and c value, and you get an address -- it's just that this
wallet always gives you a P2SH multisig address.

The problem is that if you follow BIP32 in the the most obvious way,
both devices will generate receiving addresses along the last index, 
i.e.   K/a'/b/0, K/a'/b/1, K/a'/b/2,...  If I am at one store and my
wife at another, we might both give out 2-of-2(K1/a'/b/382, K2/a'/b/382)
at the same time not realizing the other one has distributed that
address.  There's not a good way to coordinate the devices well enough
to avoid it.  But we don't have to.

The solution is to use two separate branches -- both phones will
follow/watch both branches, but each only only distributes payment
addresses from one such branch.

The original proposal here suggested adding a level to the tree using
the cosigner index as a branch point for doing this...  I recommended
simply having 2*N values for b, so that each participant has a
receiving line and change line, that won't conflict with other devices. 
However, all devices will still watch all 2*N branches to know the total
balance of the wallet, and will use UTXOs from those branches when
constructing spending transactions/proposals.
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 levels (wallet, chain, addresses), and use 2*N chains to
handle the N different parties generating receiving and change
addresses.  It's not necessary, but it follows more closely the
three-level scheme that BIP 32 originally envisioned.  I also concluded
that the chain indices are ordered by lexicographical sorting of root
public keys, but resorting each individual address.  There are use cases
where it will be necessary for parties to know how to combine public
keys into a multi-sig address without knowing the root keys.

Also, for the purposes of one-off types of escrow multi-sig, we have
included a wallet locator field in the transaction that must be passed
around.  This wallet locator is stored with each key (perhaps at the
time public keys are collected and merged), and passed around with
transactions to be signed.  This allows lightweight devices like
hardware wallets, to recognize their own keys.  It would encoded in a
VAR_STR, and doesn't have to be meaningful to the other participants --
each device would look at all signing slots in a transaction (either
singlesig or each key in a multisig) and would generate a public key
along each path, and see if the result matches.  If so, it can sign it. 
If not, it must be someone else's.

I bring this up, because this multisig wallet structure you're talking
about has a very simple wallet locator scheme -- all parties will use
the same locator for a given receiving address.  But that field should
remain part of the data structure for each key, to accommodate all types
of multisig, not just linked/parallel tree schemes. 

-Alan




On 04/25/2014 06:27 PM, Manuel Araoz wrote:
 Hi, I'm part of the team building copay
 https://github.com/bitpay/copay, a multisignature P2SH HD
 wallet. We've been following the discussion regarding standardizing
 the structure for branches both on this list and on github (1
 https://github.com/bitcoin/bips/blob/master/bip-0032.mediawiki, 2
 https://github.com/bitcoin/bips/blob/master/bip-0039.mediawiki, 3
 https://github.com/bitcoin/bips/blob/master/bip-0043.mediawiki, 4
 https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki, 5
 https://github.com/bitcoin/bips/pull/52). Soon, we realized the
 assumptions in the discussions were not true for a multisig hd wallet,
 so we wanted to share our current approach to that, to get feedback
 and see if we can arrive to a new standard (and possibly a new BIP)

 These are our assumptions: 
  - N parties want to share an m-of-n wallet.
  - Each party must generate their master private keys independently.
  - Use multisig P2SH for all addresses.
  - Use BIP32 to derive public keys, then create a multisig script, and
 use the P2SH address for that.
  - The address generation process should not require communicating
 with other parties. (Thus, all parties must be able to generate all
 public keys)
  - Transaction creation + signing requires communication between
 parties, of course.

 -

 Following BIP43, we're be using:
 m / purpose' / *
 where /purpose/ is the hardened derivation scheme based on the new BIP
 number.
 We then define the following levels:
 m / purpose' / cosigner_index / change / address_index
 Each level has a special meaning detailed below:

 /cosigner_index/ http://en.wikipedia.org/wiki/Co-signing: the index
 of the party creating this address. The indices can be determined
 independently by lexicographically sorting the master public keys of
 each cosigner.

 /change/: 0 for change, 1 for receive address.

 /address_index/: Addresses are numbered from index 0 in sequentially
 increasing manner. We're currently syncing the max used index for each
 branch between all parties when they connect, but we're open to
 considering removing the index sync and doing the more elegant
 used-address discovery via a gap limit, as discussed in BIP44
 https://github.com/bitcoin/bips/blob/master/bip-0044.mediawiki#address-gap-limit.
 We feel 20 might be too low though. 

 *Wallet high-level description:*
 Each party generates their own extended master keypair and shares the
 extended purpose' public key with the others, which is stored
 encrypted. Each party can generate any of the other's derived public
 keys, but only his own private keys. 

 *General address generation procedure:*
 When generating an address, each party can independently generate the
 N needed public keys. They do this by deriving the public key in each
 of the different trees, but using the same path. They can then
 generate the multisig script and the corresponding p2sh address. In
 this way, each path corresponds to an address, but the public keys for
 that address come 

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 wait for the information to validate the block and
 update their UTXO sets. This results in the same problem as
 before, as the large pools who mine most blocks can validate
 either instantly - the self-mine case - or more quickly than the
 smaller miners.

  
 Under the headers first scenario, wouldn't the full block still reach
 everyone in the same time as it would under the current rules?  So the
 small miner loses nothing in terms of updating their UTXO set, but
 gains an early heads up alert that a new block is coming.  This
 allows them spend the propagation time working more productively on an
 empty block in the new chain rather than wasting time on an orphan.
  It's true that it doesn't solve the problem of larger pools vs
 smaller pools, but if it doesn't make it any worse then headers-first
 propagation would be a net benefit to the network since it removes the
 incentive to make small blocks.


I think the most important part is that nodes can reliably decide on
first received, regardless of how they subsequently act on it.  I
believe it would be fine for a node to receive a header and continue
mining the old block, or a subsequently-verified competing block, until
it has the necessary pieces to fully verify the first header received. 
If that block data doesn't come, then it will be naturally ignored.  But
if multiple blocks come at once, even if a competing block verifies
first, the node would still switch to considering the first header
received as the best block when it later receives proof it is valid
(which may only be a couple seconds).

In other words, the node will always consider the header-received time
as the primary ordering criteria, but will not mine on anything until it
has full proof of validity, even if /that/ is out of order.  This means
that new blocks effectively propagate at the speed of 80 bytes, which
limits certain kinds of block-injection/racing attacks. 


--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source Intranet - Social, Extensible, Cloud Ready
Get Started Now And Turn Your Intranet Into A Collaboration Platform
http://p.sf.net/sfu/ExoPlatform___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-04-20 Thread Alan Reiner
I've been a staunch supporter of microbitcoin and would like to do
anything I can to make sure that we jump directly to it if we're going
to promote changing the default units.  And I'm happy to integrate it
into Armory as a default (with appropriate explanations and
settings/options).  I'm not so convinced about the bits name though --
I do like it, but I do also think that word is too overloaded.  Though,
I think we could get away with it. 

(Sadly, I still use microbes occasionally (as in *microb*itcoin) when
I'm talking to coworkers, because it slips off the tongue and is
actually a good combination of brevity and self-explanatory -- it just
doesn't instill the right visuals...)

We started integrating alternative units into Armory.  But, of course,
there were a few more loose ends than I expected, which will require
some work.   We want to put it in but not necessarily change the default
right away.  I'd /prefer/ we get 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:
 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.html

 I forgot that Alan Reiner was also supporting a unit equals to bits :

 https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04264.html
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04264.html

 and here the earlier going back to March 2013 and a poll at that time
 pushing for XBT being 1 bit

 https://www.mail-archive.com/bitcoin-development%40lists.sourceforge.net/msg04256.html
 https://www.mail-archive.com/bitcoin-development@lists.sourceforge.net/msg04256.html

 Regards,

 Tamas Blummer
 http://bitsofproof.com

 On 20.04.2014, at 16:53, Pieter Wuille pieter.wui...@gmail.com
 mailto:pieter.wui...@gmail.com wrote:

 I told him specifically to bring it here (on a pull request for
 Bitcoin Core), as there is no point in making such convention changes
 to just one client.

 I wasn't aware of any discussion about the bits proposal here before.

 On Sun, Apr 20, 2014 at 4:28 PM, Tamas Blummer ta...@bitsofproof.com
 mailto:ta...@bitsofproof.com wrote:
 People on this list are mostly engineers who have no problem dealing
 with
 magnitudes and have rather limited empathy for people who have a problem
 with them.
 They also tend to think, that because they invented money 2.0 they
 would not
 need to care of finance's or people's current customs.

 The importance of their decisions in these questions will fade as people
 already use wallets other than the core.

 Bring this particular discussion elsewhere, to the wallet developer.

 BTW the topic was discussed here several times, you have my support
 and Jeff
 Garzik's.

 Regards,

 Tamas Blummer
 http://bitsofproof.com

 On 20.04.2014, at 15:15, Rob Golding rob.gold...@astutium.com wrote:

 The average person is not going to be confident that the prefix they
 are using is the correct one,


 The use of any 'prefix' is one of choice and entirely unnecessary,
 and there
 are already established 'divisions' in u/mBTC for those that feel
 they need
 to use such things.

 people WILL send 1000x more or less than
 intended if we go down this road,


 Exceptionally unlikely - I deal every day with currencies with 0, 2
 and 3
 dp's in amount ranging from 'under 1 whole unit' to tens of
 thousands - Not
 once in 20 years has anyone ever 'sent' more or less than intended - oh,
 they've 'intended' to underpay just fine, but never *unintended*.

 I propose that users are offered a preference to denominate the
 Bitcoin currency in a unit called a bit. Where one bitcoin (BTC)
 equals one million bits (bits) and one bit equals 100 satoshis.


 I propose that for people unable to understand what a bitcoin is,
 they can
 just use satoshi's and drop this entire proposal.

 Rob


 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and
 their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and
 their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free

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 lines.  I'm not sure how portable
it is to other languages.  There's obviously better ways to do it, but I
didn't need a better way, because I don't need to support fragmentation
above M=8 and this was 100% sufficient for it.  And I was the only one
doing it, so there was no one to be compatible with.

I won't lie, there's a lot of work that goes into making an interface
that makes this feature usable.  The user needs clear ways to identify
which fragments are associated with which wallet, and which fragments
are compatible with each other.  They need a way to save some fragments
to file, print them, or simply write them down.  They need a way to
re-enter fragment, reject duplicates, identify errors, etc.  Without it,
the math fails silently, and you end up restoring a different wallet.   
And they need a way to test that it all works.   Armory did all this,
but it was no trivial task.  Including an interface that will test up to
50 subsets of make sure the math produces the same values every time
(which still is not sufficient for some users, who won't be satisified
til they see they're wallet actually restored from fragments.

Also I put the secret in the highest-order coefficient of the
polynomial, and made sure that the other coefficients were
deterministic.  This meant that if print out an M-of-N wallet, I can
later print out an M-of-(N+1) wallet and the first N fragments will be
the same.  I'm not sure how many users would trust this, but we felt it
was important in case a user needs to export some fragments, even if
they don't increase N.

You might consider loading Armory in offline mode, create a wallet, and
then do a fragmented backup to see how we did it.  I am extremely
satisfied with the interface, but it's most definitely an advanced
tool.  But so is Armory ... which made it a good fit.  But it might not
be for everyone.

-Alan



On 03/29/2014 11:44 AM, Matt Whitlock wrote:
 On Saturday, 29 March 2014, at 11:08 am, Watson Ladd wrote:
 https://freedom-to-tinker.com/blog/stevenag/new-research-better-wallet-security-for-bitcoin/
 Thanks. This is great, although it makes some critical references to an ACM 
 paper for which no URL is provided, and thus I cannot implement it.

 A distributed ECDSA notwithstanding, we still need a way to decompose a BIP32 
 master seed into shares. I am envisioning a scenario in which I might meet my 
 sudden and untimely demise, and I wish to allow my beneficiaries to 
 reconstruct my wallet's master seed after my death. I would like to 
 distribute seed shares to each of my beneficiaries and some close friends, 
 such that some subset of the shares must be joined together to reconstitute 
 my master seed. Shamir's Secret Sharing Scheme is perfect for this use case. 
 I am presently working on extending my draft BIP so that it also applies to 
 BIP32 master seeds of various sizes.

 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 secret has been correctly reconstituted would give an 
 adversary too much information. Failing silently when given incorrect shares 
 or an insufficient number of shares is intentional.

I do not believe this is a good tradeoff.  It's basically obfuscation of
something that is already considered secure at the expense of
usability.  It's much more important to me that the user understands
what is in their hands (or their family members after they get hit by a
bus), than to obfuscate the parameters of the secret sharing to provide
a tiny disadvantage to an adversary who gets ahold of one. 

The fact that it fails silently is really all downside, not a benefit. 
If I have enough fragments, I can reconstruct the seed and see that it
produces addresses with money.  If not, I know I need more fragments. 
I'm much more concerned about my family having all the info they need to
recover the money, than an attacker knowing that he needs two more
fragments instead of which are well-secured anyway.



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 of 
 information. Likewise, including any kind of information that would allow a 
 determination of whether the secret has been correctly reconstituted would 
 give an adversary too much information. Failing silently when given 
 incorrect shares or an insufficient number of shares is intentional.
 I do not believe this is a good tradeoff.  It's basically obfuscation of
 something that is already considered secure at the expense of
 usability.  It's much more important to me that the user understands
 what is in their hands (or their family members after they get hit by a
 bus), than to obfuscate the parameters of the secret sharing to provide
 a tiny disadvantage to an adversary who gets ahold of one. 

 The fact that it fails silently is really all downside, not a benefit. 
 If I have enough fragments, I can reconstruct the seed and see that it
 produces addresses with money.  If not, I know I need more fragments. 
 I'm much more concerned about my family having all the info they need to
 recover the money, than an attacker knowing that he needs two more
 fragments instead of which are well-secured anyway.
 For what it's worth,  also omits from the shares any information about 
 the threshold. It will happily return a garbage secret if too few shares are 
 combined. (And actually, it will happily return a garbage secret if too 
 *many* shares are combined, too. My implementation does not have that 
 problem.)

Regardless of how  does it, I believe that obfuscating that
information is bad news from a usability perspective.  Undoubtedly,
users will make lots of backups of lots of wallets and think they
remember the M-parameter but don't.  They will accidentally mix in some
3-of-5 fragments with their 2-of-4 not realizing they are incompatible,
or not able to distinguish them.   Or they'll distribute too many
thinking the threshold is higher and end up insecure, or possibly not
have enough fragments to restore their wallet thinking the M-value was
lower than it actually was.   

I just don't see the value in adding such complexity for the benefit of
obfuscating information an attacker might be able to figure out anyway
(most backups will be 2-of-N or 3-of-N) and can't act on anyway (because
he doesn't know where the other frags are and they are actually in
safe-deposit boxes)




--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-03-29 Thread Alan Reiner
Armory does exactly this: it defines the Fragment ID as the first few
bytes of the hash of the root pubKey + M-parameter, converted to
base58.  Then it explains to the user All fragments with the same
fragment ID are compatible (which only works if you use deterministic
coefficients).  Each fragment is then labeled with [FragID]-#1,
[FragID]-#2, etc.  It became quite useful for organizing the fragments
and documenting how I was distributing them, especially if I had printed
or saved the same fragment twice by accident.



On 03/29/2014 02:16 PM, Tamas Blummer wrote:
 I also think that we can add usability features if the underlying
 secret remains well protected.
 I do not think there is any reason to assume that the knowledge of the
 degree of the polynomial, would aid an attacker.

 Similarly a fingerprint of the secret if it is unrelated to the hash
 used in the polinomyal should 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 etothe...@gmail.com
 mailto:etothe...@gmail.com 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 of information. Likewise, including any kind of information
 that would allow a determination of whether the secret has been
 correctly reconstituted would give an adversary too much
 information. Failing silently when given incorrect shares or an
 insufficient number of shares is intentional.

 I do not believe this is a good tradeoff.  It's basically obfuscation of
 something that is already considered secure at the expense of
 usability.  It's much more important to me that the user understands
 what is in their hands (or their family members after they get hit by a
 bus), than to obfuscate the parameters of the secret sharing to provide
 a tiny disadvantage to an adversary who gets ahold of one.

 The fact that it fails silently is really all downside, not a benefit.
 If I have enough fragments, I can reconstruct the seed and see that it
 produces addresses with money.  If not, I know I need more fragments.
 I'm much more concerned about my family having all the info they need to
 recover the money, than an attacker knowing that he needs two more
 fragments instead of which are well-secured anyway.



 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 have a shared 2-of-2 wallet split between your phone
and your spouse's phone, your phone would distribute addresses on P2SH
chain 0 and generate change addresses on P2SH chain 1.  Your spouse's
phone would use chains 2 and 3.

So if you and your spouse switch to a new app that supports M-of-N
linked wallets, it should search for coin history along the first 2*N
chains.
-Alan



On 03/26/2014 07:37 PM, Andreas Schildbach wrote:
 Thanks for starting the discussion on finding a better structure.

 For me, the most important thing is either we're 100% interoperable or
 0%. There should not be anything inbetween, as users will delete seeds
 without knowing there is still money in them on another implementation.
 I heard from multiple sources that using this standard some wallets will
 only see a subset of the addresses/keys of some other wallets.
 Implementation differences can always happen (and should addresses as
 bugs), but I think its unacceptable that this source of issues is by design.

 I suggest we agree on an even simpler least common denominator and
 wallets that want to implement some feature on top of that can do but
 are encouraged to pick a totally different cointype. I guess that
 would mean removing reserved and account.

 I'm still thinking it might be a good idea to have a separate chain for
 refunds. Refunds will be rarely used and thus need a much slower
 moving window than receiving addresses or change.


 On 03/26/2014 09:49 PM, Mike Hearn wrote:
 Myself, Thomas V (Electrum) and Marek (Trezor) got together to make sure
 our BIP32 wallet structures would be compatible - and I discovered that
 only I was planning to use the default structure.

 Because I'm hopeful that we can get a lot of interoperability between
 wallets with regards to importing 12-words paper wallets, we
 brainstormed to find a structure acceptable to everyone and ended up with:

   /m/cointype/reserved'/account'/change/n

 The extra levels require some explanation:

   * cointype:  This is zero for Bitcoin. This is here to support two
 things, one is supporting alt coins based off the same root seed.
 Right now nobody seemed very bothered about alt coins but sometimes
 feature requests do come in for this. Arguably there is no need and
 alt coins could just use the same keys as Bitcoin, but it may help
 avoid confusion if they don't.

 More usefully, cointype can distinguish between keys intended for
 things like multisig outputs, e.g. for watchdog services. This means
 if your wallet does not know about the extra protocol layers
 involved in this, it can still import the raw money and it will
 just ignore/not see the keys used in more complex transactions.

   * reserved is for other stuff. I actually don't recall why we ended
 up with this. It may have been intended to split out multisig
 outputs etc from cointype. Marek, Thomas?

   * account is for keeping essentially wallets-within-a-wallet to avoid
 mixing of coins. If you want that.

   * change is 0 for receiving addresses, 1 for change addresses.

   * n is the actual key index

 For bitcoinj we're targeting a deliberately limited feature set for hdw
 v1 so I would just set the first three values all to zero and that is a
 perfectly fine way to be compatible.

 The goal here is that the same seed can be written down once, and meet
 all the users needs, whilst still allowing some drift between what
 wallets support.

 Pieter made the I think valid point that you can't really encode how
 keys are meant to be used into just an HDW hierarchy and normally you'd
 need some metadata as well. However, I feel interop between wallets is
 more important than arriving at the most perfect possible arrangement,
 which feels a little like bikeshedding, so I'm happy to just go with the
 flow on this one.



 --



 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 way he communicates on this list is
*extremely* corrosive and breeds hostility.  It makes it a scary place
to discuss things, with frequent, public ridicule of everything posted. 

I agree that I would rather have a friendly environment to discuss
technicals, even if it means losing additional technical insight. 
People who would explicitly insult other contributors intelligence and
character on a public list should be subject to some kind of negative
reinforcement.   Maybe there's solutions other than outright banning.

-Alan



On 03/25/2014 01:37 PM, Jeff Garzik wrote:
 On Tue, Mar 25, 2014 at 9:49 AM, Peter Todd p...@petertodd.org wrote:
 For someone with 'Chief Scientist' as their job title, I'm surprised you
 think so little of hard evidence and so much of idol worshipping.
 Peter, take this unprofessional, personal crap off-list.

 Mike's anecdote of hostility is not an isolated one.  Just today, a
 bitcore developer commented on Peter Todd's ..apocalyptic vision
 and... negative view on bitcoin which turned off some other
 developers from participating more interactively.

 As I commented on IRC, open source projects are no strangers to people
 who simultaneously (a) make useful contributions and (b) turn
 potential contributors away with an abrasive or hostile attitude
 toward others.  It's an unsolved problem in OSS, that I saw for 15+
 years in the Linux kernel community.

 For this list, as Mike suggested on IRC, introducing an openly stated
 moderation policy may be the one route.



--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 need another 1000x shift any
 time soon. By now Bitcoin isn't obscure anymore. Lots of people have heard
 Such hand-wavy, data-free logic is precisely why community
 coordination is preferred to random apps making random decisions in
 this manner.

 mBTC is problematic because you do not need 1000x shift in value to
 produce annoyances for major accounting packages that are hard-limited
 to two decimal places.  Further, spreadsheets hide information if
 formatting is configured naively -- that is, if formatting is
 configured for bitcoin the way it is configured for other currencies.

 Fundamentally, more than two decimal places tends to violate the
 Principle Of Least Astonishment with many humans, and as a result,
 popular software systems have been written with that assumption.


I whole-heartedly agree with Jeff.  micro-BTC was the way to go to end
user confusion and make things easier for software systems which are
designed to handle money (i.e. two decimal places).  I also echo the
sentiment about people being able to handle large numbers well. 

We've been working with Marty Zigman who's creating a Bitcoin plugin for
NetSuite accounting platform, and he was already forced to switch
micro-BTC long ago for exactly the reasons described above.  I think the
system will track up to 3 decimal places without causing all sorts of
heartache and automatic rounding.

Of course, as Mike said, this ship may have already sailed, but if
there's any way to revisit this, I'm there.  We're just about to do
another Armory release and could support this very easily.

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 make consensus ;)

 If you survey other wallets, you'll find most already switched to
 mBTC, that it took some effort to do so (look at the size of the
 patches for instance) and that probably, nobody is super-keen to
 change again so soon. So uBTC would make you different to most of the
 other wallets and services in wide usage. 

 If Armory wants to do that, that's no problem, maybe it will be a
 competitive advantage - just saying, don't quote this thread as
 indicating some kind of community consensus.

 Wallets and services that are using mBTC (that I know of)

 blockchain.info http://blockchain.info
 MultiBit
 Bitcoin Wallet (Android)
 Hive
 Bitcoinity
 KnC Wallet (defaults to BTC but can be switched to mBTC in settings,
 uBTC not an option)
 Mullvad
 btcstore.eu http://btcstore.eu

 Doing a google search for [bitcoin mBTC] and [bitcoin uBTC], the
 former has a bunch of sites and services with prices in mBTC. The
 latter only has faucets, as far as I can tell, which sort of makes sense.

I actually was not aware that so many had already switched to mBTC.   I
guess it shows how much I use other wallets. 

You misunderstood my consensus comment.   I was simply stating the
consensus of debating on the mailing list endlessly is not as
effective as doing it.  Thus I was just going to do it and see who
follows.  But that also assumed there was not a critical mass who'd
already switched -- I must admit I'm not so confident anymore...

I am/so strongly opposed //to mBTC /compared to uBTC, I was ready to
take a small leap of faith (with associated risks), to help push the
consensus.  Of course it would still remain configurable, but the
default will make a big difference.

-Alan
--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 to introduce the concept of a wallet
bundle (that name is far from concrete... I'd love a better word). 
All wallets in a bundle are protected by the same backup, and stored in
the same file.  The default behavior will be use new branches in the
same BIP32 tree when a user creates a new wallet, though we will allow
multiple bundles in advanced and expert usermode (which is needed to
have watching-only wallets from a different seed created from an offline
computer).

However, we do plan to allow separate parties to create
multisig-intended wallets with public parts that can be exported and
combined with other users.  We feel this is critical, as it allows for
linked wallets in which there was never a single-point of failure from
key-generation to signing.  This is especially important for contexts
where employees may be handling a company's Bitcoins wallets.

On this topic, I have gotten a lot of inquiries into BIP 38 and 39.  I
was not clear whether those BIPs were worth prioritizing ... i.e. is
there a general consensus from a variety of wallet developers that they
should be supported?  Rather, I'm happy to start prioritizing them if
others do too, but I haven't spent much time trying to understand them
to even know if they're mature, yet.

-Alan


On 03/11/2014 08:29 PM, Jean-Pierre Rupp wrote:
 Hello people,

 We are working on some of this stuff. We had some very early draft on
 how we envisioned multisig happening. It is all implemented in Haskoin
 available as multiple repositories in Github. I am happy to see this
 gathering momentum.

 Our multisig system uses BIP-0032 HD wallets, and there will soon be
 BIP-0039 support for keys compatibility.

 Our wallet uses synced trees rooted at the extended pubkeys of the
 participants. Currently we are sorting public keys in the scripts to
 avoid ambiguity.

 Download haskoin-wallet:

 cabal install haskoin-wallet

 Check out the hw command (installed in ~/.cabal/bin/hw). Use importtx to
 bring transactions into the wallet. You must initialize first with a
 seed and create an account. It supports both regular and multisig accounts.

 Perhaps this can lead to interesting discussions on key exchange, and
 the appropriate handling of wallet metadata. I?d love to work on a
 proper standard that could lead us to compatible implementations.

 This document explains how we do it now:

 http://haskoin.com/~xeno/hd-multisig-wallet.html

 Cheers!



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Learn Graph Databases - Download FREE O'Reilly Book
Graph Databases is the definitive new guide to graph databases and their
applications. Written by three acclaimed leaders in the field,
this first edition is now available. Download your free book today!
http://p.sf.net/sfu/13534_NeoTech___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Multisign payment protocol?

2014-03-10 Thread Alan Reiner
As far as I'm concerned, the way forward is to scrap BIP 10 and build up
something new that is flexible and extensible.  Also, my understanding
is that there may be room in the payment protocol for this stuff though
I'm not sure if it is really adapted well to all the steps: exchanging
public keys, creating multi-sig/P2SH addresses, proposing multi-sig
spends, bundling meta-data needed for lite/offline nodes, aggregating
signatures, and any other details.

When I start multisig integration into Armory (very soon!) I'll write a
list of requirements for the new format/process and post it here for a
wider discussion.  Certainly, if the payment protocol can already handle
all this, that would be awesome.

-Alan


On 03/10/2014 08:04 PM, kjj wrote:
 I was trying to use bip10 for multisig and coinjoin, but there was a
 problem with it.  I'll have to look back at my notes, but I thought I
 sent you a message about it.  And then real life swallowed my bitcoin
 time...

 I think the bottom line was that it would be useful in the generic
 case with just one minor change.  If there is interest, and it sounds
 like there just may be, I can 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
 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 time.  So I
 continue to use BIP 10 even though it's pretty crappy.  I wanted it
 to be useful for multisig, too, but it has some deficiencies there
 (it was done when Armory was extremely young and OP_EVAL was still on
 the table).

 However, with all this activity, we should start thinking about that
 and discussing it.  Otherwise, I'll just do my own thing again and
 probably end up with something that fits my own needs, but not anyone
 else's.  Really though, multisig shouldn't require all the same app
 to work.

 -Alan


 On 03/10/2014 01:49 PM, Gavin Andresen wrote:
 In my experience, best process for standardizing something is:

 1) Somebody has a great idea
 2) They implement it
 3) Everybody agrees, Great idea! and they copy it.
 4) Idea gets refined by the people copying it.
 5) It gets standardized.

 Mutisig wallets are at step 2 right now. BIP is step 5, in my humble
 opinion...




 On Mon, Mar 10, 2014 at 1:39 PM, Drak d...@zikula.org
 mailto:d...@zikula.org wrote:

 I was wondering if there would be merit in a kind of BIP for a
 payment protocol using multisig?

 Currently, setting up a multisig is quite a feat. Users have to
 exchange public keys, work out how to get the public keys from
 their addresses. If one of the parties are not savvy enough, an
 malicious party could easily be setup that was 2 of 3 instead of
 2 of 2 where the malicious party generates the multisig
 address+script and thus be able to run off with funds anyway.

 It's also terribly complex to generate and keep track of.
 There's been a nice attempt at creating an browser interface at
 coinb.in/multisig http://coinb.in/multisig but it still lacks
 the kind of ease with created by the payment protocol. If there
 was a BIP then it would go a long way to aiding future usability
 of multisig wallet implementations.

 What are your thoughts?

 Drak

 
 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases
 and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 -- 
 --
 Gavin Andresen


 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases and their
 applications. Written by three acclaimed leaders in the field,
 this first edition is now available. Download your free book today!
 http://p.sf.net/sfu/13534_NeoTech


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Learn Graph Databases - Download FREE O'Reilly Book
 Graph Databases is the definitive new guide to graph databases

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

2014-03-08 Thread Alan Reiner
Note that one of the reasons why this is insecure is because EC point
addition is invertible.  EC-scalar multiplication is not, thus why EC
Diffie-Hellman is secure even when this timing asymmetry exists.

A good cryptosystem doesn't have strange restrictions, like your public
key can only be public sometimes, but needs to protected like your
private key other times.  If you have to worry about things like that,
you're doing it wrong :)  And why we always recommend sticking to
well-known, well-studied operations.

-Alan


On 03/08/2014 03:51 AM, Edmund Edgar wrote:
 On 8 March 2014 17:10, 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 this). 

 Sure, I don't know the private key for b_pub, but it doesn't
 matter... because what

 b_pub + a_pub = c_pub (mine)

 You have no way to detect this condition, because you don't know
 what c_pub/c_priv I created, so you can only detect this after
 it's too late (after I abuse the private key)


 Thanks Alan and Forrest, that makes sense. So to salvage the situation
 in the original case, we have to make sure the parties exchange their
 public keys first, before they're allowed to see the public keys
 they'll be combining them with. 

 -- 
 -- 
 Edmund Edgar
 Founder, Social Minds Inc (KK)
 Twitter: @edmundedgar
 Linked In: edmundedgar
 Skype: edmundedgar
 http://www.socialminds.jp

 Reality Keys
 @realitykeys
 e...@realitykeys.com mailto:e...@realitykeys.com
 https://www.realitykeys.com


 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works. 
 Faster operations. Version large binaries.  Built-in WAN optimization and the
 freedom to use Git, Perforce or both. Make the move to Perforce.
 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-03-08 Thread Alan Reiner
Note that one of the reasons why this is insecure is because EC point
addition is invertible.  EC-scalar multiplication is not, thus why EC
Diffie-Hellman is secure even when this asymmetry exists.

A good cryptosystem doesn't have strange restrictions, like your public
key can only be public sometimes, but needs to protected like your
private key other times.  If you have to worry about things like that,
you're doing it wrong :)

-Alan


On 03/08/2014 05:37 AM, Joel Kaartinen wrote:
 If both parties insist on seeing a hash of the other party's public
 key 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:
 On 8 March 2014 17:10, 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 this). 

 Sure, I don't know the private key for b_pub, but it doesn't
 matter... because what

 b_pub + a_pub = c_pub (mine)

 You have no way to detect this condition, because you don't know
 what c_pub/c_priv I created, so you can only detect this after
 it's too late (after I abuse the private key)


 Thanks Alan and Forrest, that makes sense. So to salvage the
 situation in the original case, we have to make sure the parties
 exchange their public keys first, before they're allowed to see the
 public keys they'll be combining them with. 

 -- 
 -- 
 Edmund Edgar
 Founder, Social Minds Inc (KK)
 Twitter: @edmundedgar
 Linked In: edmundedgar
 Skype: edmundedgar
 http://www.socialminds.jp

 Reality Keys
 @realitykeys
 e...@realitykeys.com mailto:e...@realitykeys.com
 https://www.realitykeys.com


 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to 
 Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works. 
 Faster operations. Version large binaries.  Built-in WAN optimization and the
 freedom to use Git, Perforce or both. Make the move to Perforce.
 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
 With Perforce, you get hassle-free workflows. Merge that actually works. 
 Faster operations. Version large binaries.  Built-in WAN optimization and the
 freedom to use Git, Perforce or both. Make the move to Perforce.
 http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Subversion Kills Productivity. Get off Subversion  Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 be  no problem.

Armory is slightly different, since it doesn't deal with the same stuff as
exchanges do.  But it didn't have any problems with malleability because it
doesn't track anything by ID, it only pays attention to whether inputs and
outputs are related to your wallets.  It's not necessarily hard to do it
this way, people just have to be aware of it.

-Alan

Sent from my overpriced smartphone
On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com wrote:

 Instead of trying to remove the possibility of transaction
 malleability, would it make sense to define a new, canonical
 transaction hash/ID (cTxID), which would be a hash of the part of the
 transaction data which we know is not malleable, and have clients use
 this cTxID internally, thus making the traditional transaction hash
 irrelevant for a client to function correctly?

 We already have a non-malleable transaction hash: the hash that is
 signed, ie. the transaction with each scriptSig replaced by the
 scriptPubKey it redeems. This could be the cTxID.

 Or is this simply a too fundamental change to the way bitcoin-qt (and
 all other clients) work in order to be feasible?

 As far as I can see, it completely solves the issue of not having a
 canonical ID for a transaction, but it also increases the
 computational requirements for a node. For one, as far as I can see,
 it requires the node to index all transactions, because in order to
 calculate a cTxID, it would be necessary to fetch all transactions
 referred to by the transaction in question, in order to pull in the
 scriptPubKeys that are redeemed.


 On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote:
  On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
  Hello all,
 
  it was something I planned to do since a long time, but with the
  recent related issues popping up, I finally got around to writing a
  BIP about how we can get rid of transaction malleability over time.
 
  The proposed document is here: https://gist.github.com/sipa/8907691
 
  I expect most rules to not be controversial. Maybe rules 1 and 3, as
  they require modifications to wallet software (Bitcoin Core 0.9 and
  BitcoinJ already implement it, though) and potentially invalidate some
  script functionality. However, these new rules remain optional and
  controlled by an nVersion increase.
 
  Comments please!
 
  You should probably add making CHECKMULTISIG require the dummy value to
  be exactly equal to OP_FALSE; verifying that in the transaction itself is
  laborious. A more subtle example is we may want both CHECKSIG and
  CHECKMULTISIG to fail the transaction if the signature is invalid but
  not exactly equal to OP_FALSE; some transaction forms are significantly
  more compact if you can have failed signatures, but that's a source of
  malleability. (are there counter examples people can think of?)
 
 
  But as I said on IRC, I'm a bit hesitant to bake in assumptions about
  malleability when we have no solid idea if ECC signatures are or are not
  malleable on a fundemental level; if whack-a-mole anti-malleability is
  all we've got it could be ugly if a break is found. Similarly, we may
  find we missed something, or some needed change makes the malleability
  rules difficult to work with for some new script type that is required.
 
  I'd rather see a new CHECKSIG mode for the case where malleability
  absolutely must be eliminated - certain multi-party protocols - and fix
  wallet software instead. (the malleability problems people see are
  closely related to inability to handle double-spends and reorgs) But I
  can easily see that being an impossible goal engineering wise...
 
  --
  'peter'[:-1]@petertodd.org
  0001465bc2730ffed7493d166d18d288f6cf15e8cdb5d4a3c7b1
 
 
 --
  Managing the Performance of Cloud-Based Applications
  Take advantage of what the Cloud has to offer - Avoid Common Pitfalls.
  Read the Whitepaper.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=121051231iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


 --
 Android apps run on BlackBerry 10
 Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
 Now with support for Jelly Bean, Bluetooth, Mapview and more.
 Get your Android app in front of a whole new audience.  Start now.

 http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
 

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

2014-02-12 Thread Alan Reiner
Agreed.  I'm not suggesting that malleability shouldn't be fixed or isn't a
problem.  I would love to be able to leverage chained TX for Bitcoin
contracts.  But that in its current state it doesn't have to be complicated
to deal with  it.

Changing the protocol to use these static IDs is a pretty fundamental
change that would never happen in Bitcoin.   But they can still be useful
at the application level to mitigate these issues.

Sent from my overpriced smartphone
On Feb 12, 2014 11:38 AM, Allen Piscitello allen.piscite...@gmail.com
wrote:

 While that solution does work for many use cases, it does make it much
 harder to do anything needing chained transactions.  Granted, this is the
 short term solution for current implementations, but having a transaction
 identifier that does not change does open up other use cases.

 For example, Alice wants to send coins to a multisignature address with
 Bob, such that both parties are required to spend the coins.  Alice also
 requires for Bob to send coins to this address as well before they will
 proceed.  Alice cannot guarantee that Bob will cooperate (and vice versa),
 so before she broadcasts the transaction to send to A+B, she sends Bob a
 transaction that spends her incoming transaction back to herself, but has a
 time lock of far into the future.  Bob signs this, returns it to Alice, and
 she broadcasts her funding transaction.  At this point, Bob disappears,
 loses his key, or just decides to spite Alice and her coins are locked.
  Since she has a refund transaction, she can broadcast it in a month and
 get her coins back.  Except her funding transaction has been modified such
 that the txhash is different, so her refund is now invalid.  She would need
 Bob to issue a new refund as soon as her funding transaction hits the
 blockchain if it is modified, which defeats the point of the trustless
 refund transaction.

 Longer term it would be more ideal have a canonical identifier for the
 transaction before it even gets to the chain to support these use cases,
 even if wallets are able to properly identify the status of it's
 transactions.  Obviously this is a difficult problem to solve and cannot be
 implemented without breaking changes, but it would be a nice goal to be
 able to completely 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 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 instead of the TX ID,
 their software would've correctly identified the mutated transactions and
 there would be  no problem.

 Armory is slightly different, since it doesn't deal with the same stuff
 as exchanges do.  But it didn't have any problems with malleability because
 it doesn't track anything by ID, it only pays attention to whether inputs
 and outputs are related to your wallets.  It's not necessarily hard to do
 it this way, people just have to be aware of it.

 -Alan

 Sent from my overpriced smartphone
 On Feb 12, 2014 10:15 AM, Rune Kjær Svendsen runesv...@gmail.com
 wrote:

 Instead of trying to remove the possibility of transaction
 malleability, would it make sense to define a new, canonical
 transaction hash/ID (cTxID), which would be a hash of the part of the
 transaction data which we know is not malleable, and have clients use
 this cTxID internally, thus making the traditional transaction hash
 irrelevant for a client to function correctly?

 We already have a non-malleable transaction hash: the hash that is
 signed, ie. the transaction with each scriptSig replaced by the
 scriptPubKey it redeems. This could be the cTxID.

 Or is this simply a too fundamental change to the way bitcoin-qt (and
 all other clients) work in order to be feasible?

 As far as I can see, it completely solves the issue of not having a
 canonical ID for a transaction, but it also increases the
 computational requirements for a node. For one, as far as I can see,
 it requires the node to index all transactions, because in order to
 calculate a cTxID, it would be necessary to fetch all transactions
 referred to by the transaction in question, in order to pull in the
 scriptPubKeys that are redeemed.


 On Mon, Feb 10, 2014 at 4:00 AM, Peter Todd p...@petertodd.org wrote:
  On Mon, Feb 10, 2014 at 12:33:02AM +0100, Pieter Wuille wrote:
  Hello all,
 
  it was something I planned to do since a long time, but with the
  recent related issues popping up, I finally got around to writing a
  BIP about how we can get rid of transaction malleability over time.
 
  The proposed document is here: https://gist.github.com/sipa/8907691
 
  I expect most rules to not be controversial. Maybe rules 1 and 3, as
  they require modifications to wallet software (Bitcoin Core 0.9

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

2014-02-12 Thread Alan Reiner
We're talking about two slightly different things.  If their system had
tracked by inputs and outputs (or some kind of static ID) , their system
wouldn't have been issuing refunds/replacements/cancellations in the first
place.

I agree with you that the reissuing code should also guarantee that both TX
can't be valid... But really their system should do both.   Without the I/O
based tracking their bookkeeping will be off, regardless of the reissuing
code,  because they can't properly associate outgoing transactions with
customer accounts/actions.

Sent from my overpriced smartphone
On Feb 12, 2014 1:06 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen runesv...@gmail.com
wrote:
 Instead of trying to remove the possibility of transaction
 malleability, would it make sense to define a new, canonical
 transaction hash/ID (cTxID), which would be a hash of the part of the
 transaction data which we know is not malleable, and have clients use
 this cTxID internally, thus making the traditional transaction hash
 irrelevant for a client to function correctly?

This is fine and good. But it only scratches the surface of the
problems created by malleability, especially for fancier transaction
protocols.

Mutation allows you to invalidate a chain of unconfirmed transaction
by mutating the parent. This breaks any protocol which depends on
creating a precomputed nlocked time refund transaction.

So a 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 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 instead of the TX ID, their
software
 would've correctly identified the mutated transactions and there would be
 no problem.

This is incorrect.  MtGox was automatically issuing replacement
transactions resulting in double payments.

When you attempt to replace/reissue/cancel a transaction you __MUST__
double-spend the original transaction. If the original transaction has
not been conflicted then it is possible someone will pull the original
transaction out of a hat and both your replacement and the original
will be confirmed.  It is not safe at any time to look to see if the
original has been confirmed yet, and if not reissue-- not because
mutation may mean you're looking in the wrong place-- but because the
state of the world could change nano-seconds after you looked.

If you do double-spend the original then there is no chance that both
will go through, you'll have atomic exclusion and only one transaction
or the other will be confirmed.

--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development
--
Android apps run on BlackBerry 10
Introducing the new BlackBerry 10.2.1 Runtime for Android apps.
Now with support for Jelly Bean, Bluetooth, Mapview and more.
Get your Android app in front of a whole new audience.  Start now.
http://pubads.g.doubleclick.net/gampad/clk?id=124407151iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Stealth Addresses

2014-01-13 Thread Alan Reiner
On 01/13/2014 04:02 PM, Roy Badami wrote:
 It's not public.  When I say please pay me I also say use this
 multiplier.
 Sending a please pay me message is really great for business
 transactions.

 But I think the use case 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 to Alan Reiner (verified by PGP) (perhaps
 again on my off-line second factor device for a multi-sig wallet)
 and tellling you OK, sent.
 Lots of work is being done on handling consumer-to-merchant
 transactions.  BIP 70 does a good job of tackling the online purchase
 case, and the work that Andreas Schildbach is doing with Bluetooth and
 NFC will improve the options for a payer in a physical PoS transaction
 who might not have Internet connectivity on their smartphone.

 But relatively little work (that I know of) is being done on
 non-transactional personal payments - that is, being able to pay money
 to friends and other people that you have a face-to-face relationship
 with.

 What I want... no need... is to be able to open my wallet, select a
 friend from my address book, and transfer the $10 I owe them from the
 bar last night.

 I don't care - within reason - what process is involved in getting my
 friend set up in my address book.  That may well requires two way
 communication (e.g. over NFC).  But once it's set up, I should be able
 to just select the payee from the address book and send them some
 funds.  Anything else is just too complciated.

 I don't know if stealth addresses are the best solution to address
 this use case, but AFAIK the only current solution to this use case is
 to store a long-lived Bitcoin address in the addresss book.

 roy


Fair enough.  I haven't spent much time thinking about that use case. 
Though, I question the feasibility of anything that requires O(N) EC
multiply operations/sec, where N is the total volume of transactions
moving over the network.  But I guess if the prefix is big enough, the
scanning operations will remain feasible forever.

--
CenturyLink Cloud: The Leader in Enterprise Cloud Services.
Learn Why More Businesses Are Choosing CenturyLink Cloud For
Critical Workloads, Development Environments  Everything In Between.
Get a Quote or Start a Free Trial Today. 
http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 with the converted value
as they type.  This makes it really difficult to get it wrong... if
you're typing 10 into the BTC field, thinking it's mBTC, you'll see
10,000 mBTC showing up in the other box as you type.  Similarly, it
should display all units on all verification windows.  Users may also
use it for sanity checking conversion between units.

Personally, I'm of the opinion that this change is important in the long
run:  the current price makes Bitcoin *intimidating* to new users.  But
I'm also of the opinion that it's freakin' hard to change the base unit
in such an established system.  There is no easy way to do this that
doesn't cause more heartache than it's worth.  But it's possible if you
make it idiot-proof enough, and roll it out in the least inconvenient way.

-Alan


On 11/14/2013 06:45 AM, Melvin Carvalho wrote:
 Rationale
 ===

 Given the recent rise in value there seems to be anecdotal evidence
 that 1 bitcoin being so high is putting off a lot of normal buyers,
 because they feel that putting down $400+ and only getting 1 coin,
 or having to buy in multiples of 1 whole coin, is too much.. only
 after it being explained that they can buy fractional amounts to they
 regain interest, apparently happening increasingly.


 Straw Poll
 

 6 months ago there was a straw poll on this

 https://bitcointalk.org/index.php?topic=220322.0

 Roughly 2/3 of respondents favoured switching

 A further 20% said to switch after it hits 1000

 Satoshi's comments:
 

 Eventually at most only 21 million coins for 6.8 billion people in the
 world if it really gets huge.

 But don't worry, there are another 6 decimal places that aren't shown,
 for a total of 8 decimal places internally.  It shows 1.00 but
 internally it's 1..  If there's massive deflation in the
 future, the software could show more decimal places.

 If it gets tiresome working with small numbers, we could change where
 the display shows the decimal point.  Same amount of money, just
 different convention for where the ,'s and .'s go.  e.g. moving
 the decimal place 3 places would mean if you had 1.0 before, now
 it shows it as 1,000.00.

 https://bitcointalk.org/index.php?topic=44.msg267#msg267


 Would now be a good time to start thinking about changing the default
 display in the software.  Perhaps initially it could be a dropdown
 display option, then at some point mbtc becomes the default?



 --
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2013-11-14 Thread Alan Reiner
Just keep in mind it will be a little awkward that 54.3 uBTC is the
smallest unit that can be transferred [easily] and the standard fees are
500 uBTC.It's not a deal breaker, it's just something that needs to
be taken into consideration when it comes to user perception (which is
one of the reasons we would make such a change in the first place). 

Holy crap these fees are huge!  I thought Bitcoin didn't have fees!


On 11/14/2013 04:55 PM, Allen Piscitello wrote:
 I also would prefer to go straight to uBTC as the standard wallet unit.
 It works out
perfectly with Satoshi's being the decimal units.  Something that costs
$10USD would be 25000uBTC.  This isn't a problem for a place like South
Korea, where 10USD is about 10,000 Won, so we aren't even off on a scale
of usable currencies in major economies.

 The downsides are obviously confusion (causing mistakes resulting in
lost coins), and possibly from a psychological perspective on price
(uBTC are worthless!).  On the other hand, it also might help people
feel like they are getting in on the ground floor still (I own 100,000
uBTC!), and reduce the perception the Bitcoins are not divisible (I have
heard several people worry that 21 million is not enough units).

 Alan's ideas for compatibility with multiple fields will also be
helpful to solving the confusion issue.



 On Thu, Nov 14, 2013 at 3:15 PM, Mark Friedenbach m...@monetize.io
mailto:m...@monetize.io wrote:

 For this reason I'm in favor of skipping mBTC and moving straight to
 uBTC. Having eight, or even five decimal places is not intuitive to
 the average user. Two decimal places is becoming standard for new
 national currencies, and we 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.

 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 system.  There is no easy way to
  do this that doesn't cause more heartache than it's worth...


--
 DreamFactory - Open Source REST  JSON Services for HTML5  Native
Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP
server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and
Native!

http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
mailto:Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development





--
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!

http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 to get to this point eventually if Bitcoin will
thrive at the target scale). 

Bitcoin's learning curve is hard enough already.   As silly as it
sounds, feeling insecure because you only 0.00032 BTC, and then using
too many zeroes when paying for your smoothie are problems that can
really turn people off.  You say Let the market sort it out. 
Sometimes the market needs direction and consistency.  Without us doing
anything, we just end up with fragmentation and confusion. 

I'd much prefer we reach a consensus on a path forward and push that
path hard.  Because there's always resistance to change, and confusion
along the way.  The easier and more consistent we can make it, the
smoother it will be.  We want to avoid:

Hey, I'll sell it to you for 382 microbes. 
What is a microbe?  Is that the same as a XBT?
I don't know, my wallet uses NBC.
Well how much BTC is it? Okay, just send me 0.00038200 BTC
Four zeros after the decimal?
Yeah... oh wait you just sent me 10x
...

Again it sounds silly, but this is a real usability issue.

On 11/14/2013 07:37 PM, Daniel F wrote:
 This is a decentralized currency, and we should avoid centralizing
 decisions.  This is something that impacts the community at large, and
 deserves input and discussion at every level.

 I would suggest posting on all possible forums proposal: switch to
 uBTC, labelled as ISO prefers (XBT?) and see what sort of discussion
 is generated.  If the support is broad, it will be plain from the
 responses if there is a consensus.  Perhaps everyone will agree it is
 the best course, and we can make an easy change.

 But we need less core dev fiat not more :)

 this seems like such a paint-the-bikeshed problem that it's sure to
 generate vast volumes of discussion, waste a lot of people's time, and
 all for only a dubious (imo) gain. (case in point - here i am
 contributing to it :) ).

 i agree that we should avoid centralizing this. i'll go a step further
 and note that the client already has a dropdown allowing individuals to
 choose units. merchants are free to choose to price in different units.
 exchanges are free to denominate trade in different units.

 i suggest we just let the market do its thing and not get into trying to
 'make a decision' of any sort.

 --
 DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
 OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
 Free app hosting. Or install the open source package on any LAMP server.
 Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
 http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
DreamFactory - Open Source REST  JSON Services for HTML5  Native Apps
OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access
Free app hosting. Or install the open source package on any LAMP server.
Sign up and see examples for AngularJS, jQuery, Sencha Touch and Native!
http://pubads.g.doubleclick.net/gampad/clk?id=63469471iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 the assumption that Alice is well-connected as Peter
mentioned, it seems like this is a concern.  But is this a realistic
assumption?  All miners have an incentive to be thoroughly connected to
one another, to make sure they minimize the amount of time they spend
mining on forks and that their blocks win with minimal chance of being
orphaned.  Is it realistic that one miner can somehow monopolize the
good connections when the big miners are already trying to do the same
thing for honest reasons?  If you have a network full of honest miners
and this one selfish-miner, it seems that all the honest miners need to
do is try to establish those connections to each other as well as Alice
does, and Alice will end up orphaning all her profit away.

Furthermore, you can de-incentivize it by simply randomizing the order
of broadcasts.  Although you are maintaining multiple concurrent
connections, the data still exits your network card as a serial stream
of packets, and it seems that if you randomize who gets your new-block
broadcasts first, then it further reduces the Alice's advantage if she's
not guaranteed to be first.   Sure, she can do it sometimes, but it
would seem that even a couple failures to beat the rest of the network
is going to erase most/all of what she gained on the blocks/chains that
she wins.

I liked the statement by Chris WIllmer on the reddit thread:  practice
 theory.  The more we can theorize our way to believing the
conclusions that this is a problem, the more incentive there is for
someone intelligent to actually try it.  It's very possible that the
conditions needed to execute this attack just cannot be attained in
practice. 

-Alan




On 11/04/2013 04:04 PM, Peter Todd wrote:
 On Mon, Nov 04, 2013 at 02:12:44PM -0500, Ittay wrote:
 On Mon, Nov 4, 2013 at 10:25 AM, Ittay ittay.e...@cornell.edu wrote:

 As for the rational motivation of the individual miners - that's a good
 point!
 Here is a solution we did not put in the paper due to space constraints
 that should alleviate your concern:
 Instead of locally choosing a block at random, have a deterministic
 pseudo-random mechanism for choosing between competing chains. E.g., take
 the one whose last block hash is smaller. This way all miners choose the
 same chain, and the guarantees of our solution hold.

 I take that back.
 Speaking of, I'm going to take back my solution as well; I misunderstood
 your paper.

 So here's your argument in a ELI5 nutshell:

 Alice is a miner with some amount of hashing power. She has the ability
 to detect new blocks on the network extremely effectively for whatever
 reason; in short she has unusually good knowledge of the state of the
 network. She is also very good at publishing her blocks and getting them
 to the majority of hashing power in very little time; she has unusually
 good connectivity to all miners. (low-latency and high bandwidth)

 She's so good at this that when she finds a new block, she keeps it a
 secret! She can get away with this because she knows that the moment Bob
 finds a block, she can immediately broadcast it to the rest of the
 network before the other block propagates. Instead of building on Bob's
 blocks, almost everyone builds on Alice's block, depriving Bob of the
 revenue. Gradually Alice gets more and more miners because Bob, and
 other pools, don't pay out as much.

 You propose a rule where essentially miners extend Bob's block 50% of
 the time, and show in your paper how that leads to a scenario where
 Alice needs to have at leastr 1/4 of the total hashing power to
 succesfully pull this attack off anyway.


 What I did succesfully show is that for a short-term rational miner
 they're still better off mining to extend the block they hear about
 first rather than using your pick-one-at-random rule, because when you
 hear about a block is important information about whether or not the
 majority is mining on it. This is true even if others are using the
 pick-one-at-random rule. (they're better defecting than doing what's
 right for the whole network) Even worse is that miners have a rational
 incentive to broadcast such near-target headers to try to encourage
 other miners to work on the same fork that they are working on. The
 near-target idea came about for a totally different reason, so it's
 something that might wind up being implemented anyway.

 Mike Hearn's idea of making it easy to identify nodes associated with
 hashing power is still wrong. Although again, it's something that miners
 themselves have rational incentives to do. (you always want to encourage
 others to send you their blocks, and you also want to be able to send
 your blocks to the majority of hashing 

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

2013-10-14 Thread Alan Reiner
Michael,

Very interesting that you have tackled that off the radar.  I didn't
know anyone else was working on anything similar.  I'm sure you saw the
recent Armory-funding announcement, so understandably I have other
priorities in recent past and near future, but I think you should
connect with Mark Friedenbach about this topic.  He solicited donations
for working on my idea, and has been doing proof-of-concept for for the
last few months.  In fact, he was just looking for funding for another 3
months, and Armory Technologies, Inc, just offered up 50 BTC for him to
continue (@Mark, whoops, I haven't actually paid you yet; contact me to
work out details).

For now, my ability to participate directly is limited, but I am still
very interested to see the ideas developed further, as well as provide a
first test of this whole staging-area idea.  I devised it originally for
the UBC/Reiner-tree concept, but there's no reason it couldn't be used
for any other type of sweeping change to the protocol. 

-Alan


On 10/14/2013 02:43 PM, Michael Gronager wrote:
 Hi Alan,

 What you describe in the ultimate blockchain compression I have already
 coded the authenticated datastructure part of in libcoin
 (https://github.com/libcoin/libcoin) - next step is to include a p2pool
 style mining, where a parallel chain serves several purposes:
 1. to validate the root hash at a higher frequency than the 10 min
 2. to enable distributed 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.

 Michael

 On 20/5/13 08:34 , Alan Reiner wrote:
 This is exactly what I was planning to do with the inappropriately-named
 Ultimate Blockchain Compression
 https://bitcointalk.org/index.php?topic=88208.0.  I wanted to
 reorganize the blockchain data into an authenticated tree, indexed by
 TxOut script (address), instead of tx-hash.  Much like a regular merkle
 tree, you can store the root in the block header, and communicate
 branches of that tree to nodes, to prove inclusion (and exclusion!) of
 TxOuts for any given script/address.  Additionally, you can include at
 each node, the sum of BTC in all nodes below it, which offers some other
 nice benefits.

 I think this idea is has epic upside-potential for bitcoin if it works
 -- even SPV nodes could query their unspent TxOut list for their
 wallet from any untrusted peer and compare the result directly to the
 blockheaders/POW.  Given nothing but the headers, you can verify the
 balance of 100 addresses with 250 kB.  But also epic failure-potential
 in terms of feasibility and cost-to-benefit for miners.  For it to
 really work, it's gotta be part of the mainnet validation rules, but no
 way it can be evaluated realistically without some kind of staging. 
 Therefore, I had proposed that this be merge-mined on a meta-chain
 first...get a bunch of miners on board to agree to merge mine and see it
 in action.  It seemed like a perfectly non-disruptive way to prove out a
 particular idea before we actually consider making a protocol change
 that significant.  Even if it stayed on its own meta chain, as long as
 there is some significant amount of hashpower working on it, it can
 still be a useful tool. 

 Unfortunately, my experience with merged mining is minimal, so I'm still
 not clear how feasible/reliable it is as an alternative to direct
 blockchain integration.  That's a discussion I'd like to have.

 -Alan


 On 5/19/2013 11:08 AM, Peter Vessenes wrote:
 I think this is a very interesting idea. As Bitcoiners, we often stuff
 things into the 'alt chain' bucket in our heads; I wonder if this idea
 works better as a curing period, essentially an extended version of
 the current 100 block wait for mined coins.

 An alternate setup comes to mind; I can imagine this working as a sort
 of gift economy; people pay real BTC for merge-mined beta BTC as a
 way to support development. There is no doubt a more elegant and
 practical solution that might have different economic and crypto
 characteristics.



 On Sun, May 19, 2013 at 6:23 AM, Adam Back a...@cypherspace.org
 mailto:a...@cypherspace.org wrote:

 Is there a way to experiment with new features - eg committed
 coins - that
 doesnt involve an altcoin in the conventional sense, and also
 doesnt impose
 a big testing burden on bitcoin main which is a security and
 testing risk?

 eg lets say some form of merged mine where an alt-coin lets call it
 bitcoin-staging?  where the coins are the same coins as on
 bitcoin, the
 mining power goes to bitcoin main, so some aspect of merged
 mining, but no
 native mining.  and ability to use bitcoins by locking them on
 bitcoin to
 move them to bitcoin-staging and vice versa (ie exchange them 1:1
 cryptographically, no exchange

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

2013-08-09 Thread Alan Reiner
Guys,

I'd like to reiterate my previous request to support this alternate
address serialization in the payment protocol.  We got caught up in the
specifics of one use case, but didn't acknowledge that it's still a
valid address representation that will provide value to those who wish
to use it and can be safely ignored by others.

Current address format:   binary_to_base58( idbyte + hash160(pubkey) +
checksum)
Alternate format: binary_to_base58( idbyte + parentpubkey +
multiplier + checksum)

The receiving party will multiply the pubkey by the multiplier, and then
hash it to get the 20-byte address to send to.  The idea is that you use
your BIP 32 parent public key, and then you generate whatever child you
want, and only send them the multiplier used (not the chaincode).  This
preserves privacy, but if the recipient has your parent public key
already, they can identify that address being linked to you, but cannot
determine any other addresses in your wallet.

This form has no drawbacks to the existing address format except for
being longer and requiring an extra EC multiplication by the person
sending to that address.  But the advantage is that it optionally allows
the sender to provide more information than currently contained in the
25-byte hash160 form.  The discussion about this got side-tracked with
the use case I presented, but I believe there are plenty of other uses
for this.

The particular use case I had in mind was that certain services could be
setup (pre-arranged), say between wallet software and a
business/exchange.  The exchange would like to be able to reliably send
addresses to the user for deposit, without risk of MITM, or even if
their own public server is compromised.  The author of wallet software
pre-verifies the public key portion of the service, and either hardcodes
it into the software, or hardcodes their own public key into the
software and makes the service's signed public key available through
query server (allowing the software author to offline-sign replacement
keys, or add keys for new service providers, as needed). 

When the user's software receives a payment address, the software can
verify it belongs to that service.  You can't use dedicated chain
technique, because it would either have to be exchanged with the user on
first transaction which half defeats the purpose, or they give them the
full public key and chaincode which allows the user to see /all
/addresses ever used by the service.  Neither one is a reasonable solution.

This use case doesn't necessarily scale, but it doesn't have to.  It
simply allows service providers to skip the SSL and go right to public
key exchange/verification for a few of the important services they
provide access to, and will provide better security than relying on
SSL/PKI.  This would simply be one, coexisting option for providing
payment details in the absence (or in addition to) SSL/PKI infrastructure.

I'm sure there'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:
 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 then I will go along. 

 Right now BIP 32 defines, m/i'/j/k, where j=0 is the external chain
 used for distributing addresses, and j=1 is the internal chain for
 sending change.  The CONOPs (concept of operations) for the extended
 wallet would be like Jeremy described:

 - Chains with j=2 would be independent address chains carved out for
 individuals relationships
 - Add wallet code to individually associate each j-value with a
 particular identity
 - Update the wallet code to pool all the addresses in all j-chains
 when calculating the balance of the wallet and/or creating transactions
 - When choosing to generically Receive Bitcoins, will pick the next
 address from the j=0 chain
 - Will have to add extra function to Receive Bitcoins button to
 allow creation of new contacts/identities.
 - Change will always go to the next address in j=1, no matter which
 chains are used to provide inputs.
 - Add code to figure out lookaheads for each alternate chain.  Not
 just each chain, but looking ahead a couple chains, too.  Luckily, the
 lookahead doesn't have to be very big for chains j=1 
 - Add an interface to display and choose the different chains in your
 wallet, and export the pubkeychaincode in some
 soon-to-be-standardized format. 
 - Add code and interface to receive and track alternate j-chains from
 other clients/users, and maintain those.  Should we try associating
 incoming and outgoing chains?  What happens if they do

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 have avoided any notion of locking inputs in Armory for offline
wallets.  The underlying concept of why a seemingly-random amount of
funds are inaccessible at a given time is so non-intuitive and difficult
to explain to a non-expert, that I haven't even tried to deal with it.
   Luckily, most users do one operation at a time, so it's not a real a
problem.  But as more businesses have started to use Armory, it /will/
become a problem that will need to be addressed /somehow/.

I have considered at least marking inputs to indicate to the user that
the transaction they are creating may not be valid unless all previous
transactions have been broadcast.  The user will not necessarily
understand why, but they might easily comprehend the solution (and
perhaps a button that says Forget all previously created transactions
that haven't been broadcast.  Press this button if there are no
transactions waiting to be broadcast). 

Even if the user somewhat understands the concepts behind locking, you
easily end up with a mess of some coins being locked and rejecting
transaction creation somewhat randomly, especially when they create
transactions that they later decide not to execute.  And you have to
give the user a way to manually unlock the outputs which they wouldn't
know to use because it's so non-intuitive.  I'd much rather say either
do one transaction at a time, or bundle payments into a single
multi-output transaction.  Or risk invalid transactions that have to be
re-created and signed.

-Alan


--
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with 2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 that you actually execute an upgrade, you
sign the new checksums offline and upload the signed checksum to the
distribution server.  Then even if the server is compromised, the
client-side software will not accept a bogus checksum because it won't
bear the right signature.

If you do this, it would be good to also have some kind of revocation
process that can be used in the event of the offline key being
compromised.  You won't be able to switch keys, as that would defeat
the purpose (the attacker who compromises the offline key could just
issue a replacement with his own).  Instead, it would be an irreversible
broadcast that would force clients to start rejecting updates from that
key.  If the key is compromised (and find out), you broadcast the
revocation and the users will stop auto-updating, and be given a warning
that they should manually upgrade the software through trusted
channels.  It's not failproof, but it's a decent way to minimize damage
if you discover compromise early enough.

-Alan






On 08/05/2013 11:54 AM, Daniel F wrote:
 If you want package authentication, you should at least throw in some
 digital signing, not just a checksum. With a compromised host, both the
 checksum and binaries can be changed undetectably, but if there's a
 signature made by a key that is not kept on the host, there's no way to
 fake a valid binary.

 There may be other issues people would want to bring up, but surely just
 a checksum is not sufficient.

 on 08/05/2013 10:39 AM Wendell said the following:
 For usability purposes, we at Hive would like to have an
 auto-updater
 in our wallet app.
 What is a safe way to do this? I understand that Bitcoin-QT lacks
 such
 an updater for security reasons... Has been thought out in more detail
 since that decision was made?
 We have been toying around with the idea of placing one server
 behind
 a Tor hidden service, whose only function is to output a checksum of the
 update package. The theory is that if it is well-secured, it will at
 least be immune to tampering at the physical hosting level.
 Any thoughts or advice about any of this?
 -wendell

 grabhive.com | twitter.com/grabhive | gpg: 6C0C9411



 --
 Get your SQL database under version control now!
 Version control is standard for application code, but databases havent 
 caught up. So what steps can you take to put your SQL databases under 
 version control? Why should you start doing it? Read more to find out.
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk



 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


 --
 Get your SQL database under version control now!
 Version control is standard for application code, but databases havent 
 caught up. So what steps can you take to put your SQL databases under 
 version control? Why should you start doing it? Read more to find out.
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 likely to break the other.  In
fact, I seem to remember that QCs use an efficient DLP-solving circuit
to shortcut the factoring problem.  But it's been a long time since I
looked at it, so I don't remember for sure.   Also, it's not clear
whether that relationship exists outside the scope of QCs.

It's still a good presentation, but they're pushing ECC pretty hard as
the answer to the cryptopocalypse, and I'm not convinced that's a real
answer.

-Alan



On 08/04/2013 01:13 PM, Melvin Carvalho wrote:
 A great presentation on advances in crypto

 http://www.slideshare.net/astamos/bh-slides


 --
 Get your SQL database under version control now!
 Version control is standard for application code, but databases havent 
 caught up. So what steps can you take to put your SQL databases under 
 version control? Why should you start doing it? Read more to find out.
 http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 burning bridge by rushing to convert everything to ECC
in the event of a factoring breakthrough.

From the perspective of quantum computers, it seems those two problems
are essentially the same.  As I said, I remember that one of the
problems is solved by using the solution/circuit for the other.  But I
don't know if this relationship holds outside the realm of QCs.   The
guy who did this presentation said he's not a mathematician and/or
cryptographer, yet he still strongly asserts the superiority of ECDLP. 
I'm not convinced.


On 08/05/2013 01:29 AM, John Dillon wrote:
 On Mon, Aug 5, 2013 at 3:30 AM, Peter Vessenes pe...@coinlab.com wrote:
  I studied with Jeffrey Hoffstein at Brown, one of the creators of
NTRU. He
  told me recently NTRU, which is lattice based, is one of the few (only?)
  NIST-recommended QC-resistant algorithms.

  We talked over layering on NTRU to Bitcoin last year when I was out that
  way; I think such a thing could be done relatively easily from a crypto
  standpoint. Of course, there are many, many more questions beyond
just the
  crypto.

 Is NTRU still an option? My understanding is that NTRUsign, the
algorithm to
 produce signatures as opposed to encryption, was broken last year:

http://www.di.ens.fr/~ducas/NTRUSign_Cryptanalysis/DucasNguyen_Learning.pdf

 Having said that my understanding is also that the break requires a few
 thousand signatures, so perhaps for Bitcoin it would still be
acceptable given
 that we can, and should, never create more than one signature for any
given key
 anyway. You would be betting that improving the attack from a few thousand
 signatures to one is not possible however.

 In any case, worst comes to worst there are always lamport signatures.
If they
 are broken hash functions are broken and Bitcoin is fundementally broken
 anyway, though it would be nice to have alternatives that are similar
is pubkey
 and signature size to ECC.


--
Get your SQL database under version control now!
Version control is standard for application code, but databases havent 
caught up. So what steps can you take to put your SQL databases under 
version control? Why should you start doing it? Read more to find out.
http://pubads.g.doubleclick.net/gampad/clk?id=49501711iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 with the material than some.  However,
 there's little things like it never actually defines a deterministic
 wallet in the Abstract.  But, I'll keep trying to understand and see
 if I can use the test vectors.
  



This has nothing to do with the blockchain.  This is simply an alternate
way to encode an address, in the event that you want to prove that this
address is linked to another address.  The same thing ends up in the
blockchain, either way.

Either:
(1) I give you a Hash160 address which shows up in the blockchain
or
(2) I give you {PubKey, Mult}, then you compute PubKey*Mult then hash it
to get the same Hash160 I would've given you in (1)

I can always give you version #1, and that's what everyone does right
now.  Version #2 is essentially the same, but used if you want to give
the other party extra information (such as the root public key, so that
the next time you send a version#2 address they can see they are from
the same root public key). 
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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]) ||
 checksum)
 Also suppose the payee has spent the output, i.e. the pubkey
 corresponding to destination, which is PubKeyParent * Multiplier[i],
 is publicly known. Then anybody can (in retrospect) create arbitrary
 many pairs {PublicKeyParent, Multiplier} (in particular different
 PublicKeyParent) that lead to the same destination.

 Depending on what you have in mind that the transaction should prove
 regarding its actual receiver or regarding the receiver's PubKeyParent,
 this could be an unwanted feature (or it could be just fine). If it is
 unwanted then I suggest replacing
 PubKeyParent * Multiplier[i] by 
 PubKeyParent * HMAC(Multiplier[i],PubKeyParent)
 which eliminates from the destination all ambiguity about PubKeyParent.

 This modification would not be directly compatible with BIP32 anymore
 (unfortunately), but seems to be better suited for use in conjunction
 with a payment protocol. 

 Timo

It's an interesting observation, but it looks like the most-obvious
attack vector is discrete log problem:  spoofing a relationship between
a target public key and one that you control.   For instance, if you see
{PubA, Mult} produces PubB and you have PubC already in your control
that you want to prove [maliciously] is related to PubB, then you have
to find the multiplier, M that solves:  M*PubC = PubB.  That's a
discrete logarithm problem.

I'm not as familiar as you are, with the available operations on
elliptic curves, but it sounds like you can produce essentially-random
pairs of {PubX, Mult} pairs that give the same PubB, but you won't have
the private key associated with those public keys.  It's an interesting
point, and there may be a reason to be concerned about it.  Though, I
don't see it yet.

-Alan

--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 signature made using it.

 Adam

 On Wed, Jun 19, 2013 at 05:28:15PM +0200, Adam Back wrote:
 [q-th root with unknown no discrete log artefact]

 If it was a concern I guess you could require a proof of knowledge of
 discrete log.  ie as well as public key parent, multiplier the
 address must
 include ECDSA sig or Schnorr proof of knowledge (which both demonstrate
 knowledge of the discrete log of Q to base G.)

It's a cool trick but requiring a signature on each multiplier defeats
one of the purposes of a deterministic wallet.  I don't want to have to
explicitly export a whole bunch of signatures from my offline system
just to exercise this address option.  The observer wallet should be
able to do anything it needs to on its own, without help from the
offline wallet. 

Unless you mean that there is a one-time signature from the offline
computer that works for all addresses, that can be exported with the
observer wallet...?  If all you want to do is prove that /someone/ owns
that private key, you could send {Sign(MagicString), Multiplier}.   So
it becomes one signature operation *per wallet*, but creating new
wallets would require going back to the offline computer for that
one-time signature.  That's better than the alternative, but it's still
extra bloat for the wallet apps.

Either way, I'm not convinced that these are a problem for the specified
use cases I outlined.   In cases where you have a persistent business
relationship, they need to verify the parent public key exchange
anyway.  After that, the software doesn't technically require the
transmission of the PubKey, it only needs the Name/ID of the party and
the multiplier and it will fetch the PubKey from its data store.  Or it
is transmitted and the payer verifies it's correct.  Computing an
alternate {PubKey', Mult'} that produces the same address and then using
it in a MitM attack doesn't work here if the two parties pre-verified
the public keys. 

In the case that a business is checking whether the cashout address of a
customer is the same as the last time:  if the first payout was not
replaced by an attacker, then the business already has the correct
public key in their DB and a replacement of further payout requests will
fail validation.  If the first payout was replaced... well that could've
been done anyway (with or without this alternate form), and the customer
wouldn't have received their money and the whole process would be
flagged and terminated before further transactions.

-Alan


--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 understand the use case for handing out individual
 multipliers, if what you desire is a persistent relationship. If each
 party dedicates a child-wallet for receiving coins, and saves a
 PubKey/ChainCode for sending coins, the two parties can transaction
 securely forever without ever exchanging any more information, and
 without any address reuse.
  
 I think ideally, the default behavior is that wallets always dedicate
 a new child node {PubKey, ChainCode} to each party they transact with.
 At the presentation layer, you have a contact and each contact has a
 transaction history. You can send coins to a contact at any time, and
 internally the wallet picks the next address in their sequence. Any
 funds received on pubkeys from contact's sequence are attributed to
 that contact. The wallet can organize the contacts, and roll-up the
 transaction history into 'ledgers' and 'balances' however they want --
 it could be based on the underlying BIP32 hierarchy or perhaps not.
 The cost of watching large a number of pubkeys, even if you 'look
 ahead' 100 pubkeys for each contact, is relatively small versus the
 benefits.
  


What you just described is complimentary to what I am proposing.  There
is nothing stopping you from doing it that way, except that it may be
inconvenient in some circumstances.  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).  And all
separate chains with their 100-address look-aheads may be fine for your
desktop or mobile device, but maybe not a HW signing device with 128 kB
of memory. 

So, some use cases might prefer having a different parent public key
[and chaincode] per contact, some may prefer to synchronize across many
contacts.  For instance, maybe there's a benefit to using the same
parent pubkey across multiple services, as a form of identity.   If I
don't want that, I use your method.  If I do want that, I use my
method.  Given its simplicity, I don't know why both can't be options.

Actually, it doesn't have to be specific to the payment protocol, it can
just be alternative address encoding that some apps would use if they
have a need for it.

-Alan
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 
 child-node using the public / type-2 CDF, hands out the PubKey/ChainCode, 
 and then generally expects transactions to come in starting at /0 and 
 incrementing monotonically.



You are suggesting that creating new wallet chains are the only
operation needed to achieve the functionality I'm requesting.  I
disagree.  I am okay with using different wallets for different parties
*/if the user wants to/*.  But there are orthogonal use-cases to having
a single wallet serve as a single identity that can be used across
multiple transactions or services.  And doing so is much simpler
conceptually for the user, and simpler in implementation for the app
developer.

BIP 32 already specifies how to use the first three tree levels: 
M/i/j/k, i~wallet, j~Internal/External, k~address.  The first level is
actually type-1 derived, and thus we cannot create an arbitrary number
of them without pre-computing them from the offline wallet.  So it's not
free to create new wallets unless we redefine how the levels work. 
Even if we assume the simplest case where the first level is actually
type-2 derived and it costs nothing to create separate wallets for each
contact/party:
 
-- Do these extra wallet chains behave as different wallets, or
sub-wallets? 
-- Should their balances be bundled into a single wallet or displayed
separately?
-- When a user tries to spend, does he have to specify which wallet(s)
he's spending from?
-- Should the app developer be required to implement a multiple-wallet
interface, and handle cross-wallet spending just to achieve this simple
mechanism?  Sure, they could instead implement a tiered wallet hierarchy
with primary wallets and sub-wallets... wait this just got complicated.

All that complexity just to support this identity mechanism that can be
included purely as an alternative address encoding with a single
wallet.  With my request, the user can't have one wallet and distribute
most of his addresses the normal/anonymous way, but certain apps would
choose to use the alternate encoding as a form of identity.  If the user
feels the need to create a separate wallet for certain operations to
separate his identities, that is his option if the software supports
multiple wallets.  But it's not the only way.

To achieve what I'm suggesting is useful and trivial to implement even
in the simplest wallet applications. 

-Alan
--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 provide each other are linked to a particular wallet,
reducing exposure to MitM attacks without the need for SSL or a web of
trust, and without compromising the privacy of either party.For
instance, this could be used between businesses that frequently do
business, by exchanging and verifying public keys beforehand, or could
be used by an exchange to identify if a customer withdrawal address is
related to their last deposit address, and if not enforce extra
authentication measures.

_*Background*__:_
I haven't been following the payment protocol discussions/development
much, so I apologize if this has already been addressed.   I'm calling
it wallet-linkable addresses, which would be an optional second form
for sending someone your address.   With BIP 32, the address is computed
by the payee (the person sending the address to receive money):

   Standard Address ~ Base58(0x00 || hash160(PubKeyParent *
Multiplier[i]) || checksum)

What I'd like to do is have the option, when specifying an address
through the payment protocol, to send *just* the {PublicKeyParent,
Multiplier[i]} and let the receiver of that address compute the address
on their own.  This is no significant burden on the receiver, but it
does provide the useful property that they can recognize when addresses
specified in this way come from the same wallet -- because the
PubKeyParent will be the same.  Remember, this is _optional_ for the
person providing the address.

One nice, accidental feature of BIP 32 is that the Multiplier[i] used
above does not actually reveal the chaincode (I think Pieter started
calling it the tweak).   It is derived from the chaincode but doesn't
reveal it.  Therefore, the payer sees the parent public key, but that's
not useful to derive any of the other addresses unless they also have
the chaincode.  But they can verify that the PublicKeyParent is
identical between transactions, and thus is accessible only to that
wallet.  It allows them validate a specific address provided by the
payee, but not generate or identify any other addresses.

*_Use Cases:_*
(1)  So, just like with PGP/GPG, when two parties decide they will start
a relationship, they can start by exchanging the public keys of their
wallet and verify them in a reliable manner.  After that, when one party
requests a payment address from the other, they can optionally send
{PubKey, Multiplier}, and the payer's software will identify the owner
of that address, or let you select who you think the address belongs to
and it will verify it.  If the payee's system is compromised and address
is replaced, the address received by the payer won't validate.  This
doesn't help if the side sending the money is compromised.

(2)  When a customer first provides a deposit to an exchange, it will
send money from an address in their wallet and the software will provide
the exchange the {PubKey,Mult}.  When the customer later provides a
withdrawal address, the site can automatically trust the address as long
it is provided in the alternate form and the public keys match.  If they
don't, it might be the same customer just requesting a withdrawal to a
different wallet, which is fine, but they'll have to go through an extra
verification step to do so. 


_*Downsides:*_ 
Multi-sig/P2SH  - The only way this works with P2SH, violates one of the
goals of P2SH slightly, but may not matter much if it's all done under
the hood by the software.  Instead of providing a 20-byte hash of a
script, you provide all the public keys and multipliers for the
individual addresses.  The payer's software automatically verifies all
addresses and creates the P2SH script itself (after a divine decree that
public keys will always be sorted lexicographically in the multi-sig
script).  The blockchain still benefits from the compression of moving
the bulky scripts to the TxIn, but it does require revealing more
information than is necessary for the payer to pay the payee.  But it
may not /really/ be a problem, given the benefits.  It might just be
slightly longer strings to exchange during initialization and for each
transaction.

I have various reasons I'd like to use this, and it'd be nice to have
some community backing, so I don't have to twist anyone's arm to trust
me that it's legit.

-Alan




--
This SF.net email is sponsored by Windows:

Build for Windows Store.

http://p.sf.net/sfu/windows-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 only that, but it would require them to reveal their
public key, which while isn't technically so terrible, large amounts of
money intended to be kept in storage for 10+ years will prefer to avoid
any exposure at all, in the oft-chance that QCs come around a lot
earlier than we expected.  Sure, the actual risk should be pretty much
non-existent, but some of the most paranoid folks are probably the same
ones who have a lot of funds and want 100.00% of the security that is
possible.   They will see this as wildly inconvenient.

I think this a great thought experiment, and I'd like to see where this
idea goes, in terms of designing ways for a decentralized community to
find consensus for important decisions, but I don't think that any idea
that requires users to dig up their private keys is going to be feasible
(or possibly reconstruct them from pieces and/or get multiple
signatures).  Especially if the system requires some kind of persistent
voting.

-Alan


On 06/10/2013 12:46 PM, Mark Friedenbach wrote:

 John,

 What you are recommending is a drastic change that the conservative
 bitcoin developers probably wouldn't get behind (but let's see).
 However proof-of-stake voting on protocol soft-forks has vast
 implications even beyond the block size limit. Within Freicoin, we
 have looked at is as a possibility for determining how to distribute
 the demurrage, a proposal we are calling 'Republicoin' due to the fact
 that with proxy voting we expect a system to emerge similar to the
 government budgeting in parliamentary republics. Distributed,
 non-coersive government by protocol, if you will.

 So anyway, even if you get shot down, please continue to pursue this
 proposal. It very likely has uses that you haven't thought of yet.

 Cheers,
 Mark

 On 6/9/13 9:09 PM, John Dillon wrote:
  It has been suggested that we leave the decision of what the
 blocksize to be
  entirely up to miners. However this leaves a parameter that affects
 every
  Bitcoin participant in the control of a small minority. Of course we
 can not
  force miners to increase the blocksize if they choose to decrease
 it, because
  the contents of the blocks they make are their decision and their
 decision
  only. However proposals to leave the maximum size unlimited to allow
 miners to
  force us to accept arbitrarily large blocks even if the will of the
 majority of
  Bitcoin participants is that they wish to remain able to validate the
  blockchain.

  What we need is a way to balance this asymetrical power relationship.

  Proof-of-stake voting gives us a way of achieving that balance.
 Essentially for
  a miner to prove that the majority will of the poeple is to accept a
 larger
  blocksize they must prove that the majority has in fact voted for that
  increase. The upper limit on the blocksize is then determined by the
 median of
  all votes, where each txout in the UTXO set is one vote, weighted by
 txout
  value. A txout without a corresponding vote is considered to be a
 vote for the
  status quo. To allow the voting process to continue even if coins
 are lost
  votes, including default votes, are weighted inversely according to
 their age
  in years after 1 year. IE a vote with weight 1BTC that is 1.5 years
 old will be
  recorded the same as a 1 year old vote weighted as 0.67BTC, and a 1
 day old
  and 6 months old UTXO are treated equivalently. The 1 year minimum
 is simply to
  make voting required no more than once per year. (of course, a real
  implementation should do all of these figures by block height, IE
 after 52,560
  blocks instead of after 1 year)

  A vote will consist of a txout with a scriptPubKey of the following
 form:

  OP_RETURN magic vote_id txid vout vote scriptSig

  Where scriptSig is a valid signature for a transaction with nLockTime
  500,000,000-1 spending txid:vout to scriptPubKey:

  OP_HASH160 H(OP_RETURN magic vote_id txid vout vote) OP_EQUAL

  vote_id is the ID of the specific vote being made, and magic is
 included to
  allow UTXO proof implementations a as yet unspecified way of
 identifying votes
  and including the weighted median as part of the UTXO tree sums. (it
 also
  allows SPV clients to verify the vote if the UTXO set is a Patricia
 tree of
  scriptPubKeys) vote is just the numerical vote itself. The vote must
 compute
  the median, rather than the mean, so as to not allow someone to skew
 the vote
  by simply setting their value extremely high. Someone who still
 remembers their
  statistics classes should chime in on the right way to compute a
 median in a
  merkle-sum-tree.

  The slightly unusual construction of votes makes implementation by
 wallet
  software as simple as 

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 who is receiving it wants it, they have to sign for it by sending
it to one of their own single-sig addresses.  Otherwise, you can return
it to yourself at some point in the future.

I don't totally understand the goal, and how/if these solutions actually
achieve such goal.  But it does add a way for transactions to exist a
non-final state for some amount of time.  But in both cases,
accessibility is still binary:  you have complete access to it, until
you don't.   Which might be seen as the point of irrevocable transfer.

-Alan



On 06/05/2013 08:19 PM, Peter Vessenes wrote:
 So, this
 http://www.americanbanker.com/bankthink/the-last-straw-for-bitcoin-1059608-1.html?pg=1
  article got posted today, noting that FinCEN thinks irrevocable
 payments are money laundering tools. 

 I will hold my thoughts about the net social good of rent-seeking
 large corporations taking money from consumers over fraudulent
 reversals. Actually, I won't, I just said it.

 At any rate, it got me thinking, can we layer on revocability somehow
 without any protocol change, as an opt-in?

 My initial scheme is a trusted (hah) escrow service that issues time
 promises for signing. If it doesn't receive a cancel message, it will
 sign at the end of the time. 

 The addresses would be listed by the escrow service, or in an open
 registry, so you could see if you were going to have a delay period
 when you saw a transaction go out.

 This seems sort of poor to me, it imagines that mythical thing, a
 trusted escrow service, and is vulnerable to griefing, but I thought
 I'd see if some of the brighter minds than me can come up with a
 layer-on approach here.

 When I think about it, I can imagine that I would put a good number of
 my coins in a one day reversible system, because I would have warning
 if someone wanted to try and spend them, and could do something about
 it. I'm not sure if it gets me anything over a standard escrow
 arrangement, though.

 Peter

 -- 

 

 CoinLab LogoPETER VESSENES 
 CEO

 *pe...@coinlab.com mailto:pe...@coinlab.com * /  206.486.6856
  / SKYPE: vessenes 
 71 COLUMBIA ST / SUITE 300  /  SEATTLE, WA 98104



 --
 How ServiceNow helps IT people transform IT departments:
 1. A cloud service to automate IT design, transition and operations
 2. Dashboards that offer high-level views of enterprise services
 3. A single system of record for all IT processes
 http://p.sf.net/sfu/servicenow-d2d-j


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 they're actually broadcast and confirmed to
be out in the wild.  This was done for simplicity to avoid people
getting arbitrarily-locked coins, even though it means you end up
accidentally double-spending if you try to create two different unsigned
transactions from the same wallet without signbroadcasting the first one.

So here's what you do:
(1) Switch to Expert usermode in Armory
(2) Open any wallet (you don't need a watch-only wallet, full wallet is
fine)
(3) In the Send Bitcoins window, click coin-control
(4) Create a transaction using one sufficiently large input
(5) Click Create Unsigned Transaction and save it
(6) Repeat 3-5 with the same coin, but sending to yourself, specify a
larger fee
(7) Go into Offline Transactions and Sign and Broadcast Transactions
(8) Load tx1, sign  broadcast
(9) Load tx2, sign  broadcast

This only works if your Bitcoin-Qt/bitcoind client has the
replace-by-fee patch, since Armory uses Bitcoin-Qt/bitcoind as a gateway
to the network. Otherwise, the second tx will be DOA.  But you don't
have to mess with Armory other than switching it to Expert mode to get
to the coin-control feature.

- -Alan

P.S. -- If you try this, Armory is likely to not show the second tx as
having ever happened (Bitcoin-Qt will send it back to us and we ignore
it because we already have a tx).  But if your Bitcoin node has the
modification, it /will/ reach the network


On 05/15/2013 08:19 AM, Peter Todd wrote:
 On Wed, May 15, 2013 at 07:38:27AM -0400, Peter Todd wrote:
 So I'm offering 2BTC for anyone who comes up with a nice and easy to use
 command line tool that lets you automagically create one version of the
 transaction sending the coins to the desired recipient, and another
 version sending all the coins back to you, both with the same
 transaction inputs. In addition to creating the two versions, you need
 to find a way to broadcast them both simultaneously to different nodes
 on the network. One clever approach might be to use blockchain.info's
 raw transaction POST API, and your local Bitcoin node.

 Oh, and while we're at it, a good starting point for your work would be
 Gavin's spendfrom utility in the contrib/spendfrom directory in the
 Bitcoin-QT respository.

 Also please do keep in mind that it's much better for the community if
 an attack is demonstrated first, followed by releasing the code some
 time later.




--
 AlienVault Unified Security Management (USM) platform delivers complete
 security visibility with the essential security capabilities. Easily and
 efficiently configure, manage, and operate all of your security controls
 from a single console and one unified framework. Download a free trial.
 http://p.sf.net/sfu/alienvault_d2d


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/

iQIcBAEBAgAGBQJRk441AAoJEBHe6b77WWmFZNQP/02t6cQkhih/CcA1oSCM72np
KMRW0Z+piHShORxLyhMX3cIpi3ICJ2lJ/Pm6GfDn74oSHq8wipIFoV88xhy810bL
MnJtbPH900v8PHh/ji2nWMig9NibeUa1zV9/tp31rYjUT3mmMoC4yQlyxKII8GWK
iignkAHV/UL5kQGmhmr1RKN127cthSMeIzAYWXfIWVObPNm85pvizVZdgqzSK73h
vwdfeFOelNbVn8ZCNT19OsxWfAKZSaBMywAX95wQBs0BtY2ZgDRmeXa6MdQKpXGW
KP3O2zjjJC2CKc4+L6elMfsoL1doEsk35w/GuI4HZK4MLAI8BChi6ZPnAYjdRvir
eHeszyxkKDCEaJ9JPLA/AszqkYHIB+56wTtrpVb1duyTwuqgVT5dcpMPIH8bDqjq
k3I8C9zCSeQ6JgyvOd8grKJchRtq0SOWYt2bB3ytePzwOs+W+6mRenb/WtMt2dQg
ntDTEIG7pCsWHenipeTBzvJNqeSsAAoIXnkGY20iDxCB+uFkTzisoCQqpOIglArm
vD+Cl2nv3OKU3NTVTUt2VinoFskezI7xvsxHD8xs2V/hrlpPbPRAo+l7ER6aTazj
wrONfmllHSE2XCM7wb/bX3gBNmsM3zUIgSBmNSH/SQeTy8PvwvlkZ/RRYmtVSmHL
rUTp7x4U63JiIDO1jj+T
=JiPo
-END PGP SIGNATURE-

--
AlienVault Unified Security Management (USM) platform delivers complete
security visibility with the essential security capabilities. Easily and
efficiently configure, manage, and operate all of your security controls
from a single console and one unified framework. Download a free trial.
http://p.sf.net/sfu/alienvault_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 lower-case root hash160 in your
subdomain and getting and SSL cert for that.  Feel free to contribute to
that thread if you find it compelling.

-Alan


On 04/24/2013 07:01 PM, Jeremy Spilman wrote:
 Payment Protocol uses x509 certs to sign a Payment Request. This allows 
 wallets to display meta-data from the cert to the payer instead of the 
 address, which should make it easier to verify where money is being sent, and 
 make it harder for an attacker to change the address displayed to a user so 
 that coins are not sent to the wrong place.

 The difficulty is that Payment Requests must be generated live, and therefore 
 the key used to sign those requests must also be live, exposing the key to 
 theft similar to a hot wallet. Steal the key, forge payment requests, and the 
 payer sees a 'green box' but the coins go to the attacker. The question... is 
 there a way to sign something once, with a key kept offline, which verifies 
 the address in the Payment Request belongs to the payee?

 1) Given a 'parent' cert which is kept offline, and a child certificate of 
 'parent' which is kept hot on the payment server.

 2) Given a public key and chain code { pubKey, code } under BIP32 we generate 
 child keys as I = HMAC(code, Kpar || i), Ki = I[0:32] * Kpar.

 3) If we sign Kpar with the parent cert's key offline, we can sign the 
 remaining less critical data (address, I[0:32], amount, description, etc.) 
 with the child cert's key.

 4) The payer verifies Kpar, and verifies the address by calculating 
 Hash160(Kpar * I[0:32])

 In fact, there's no requirement to use BIP32 to calculate I[0:32], it could 
 also just be randomly generated.

 Any I[0:32] included in the Payment Request, even if it is tampered with, 
 will correspond to an address for which the payee can calculate the 
 corresponding private key.
 So the idea is your 'most trusted' cert would be used offline only to sign a 
 Kpar once, and a 'less trusted' cert would be used to sign the other stuff, 
 like 'amount', 'description', 'merchant-data', and the 'I[0:32]' as well.
 I'm not an expert on x509, but I imagine the trouble is, how does the payer 
 know which cert is which? I was originally thinking the parent cert would be 
 an intermediate CA cert used to sign the child cert, but I guess good look 
 getting one of those, even with a name constraint, from a Root CA. I'm not 
 sure if you can do better than just a 'convention' such as one is an EV cert 
 and one is not. Perhaps the less trusted cert is actually self-signed using 
 the EV cert, but that requires special validation, since its no longer a 
 standard certificate chain. I would love to hear a better idea.

 Any comments if this is something worth pursuing? I think there are 
 definitely benefits if merchants can keep the key signing the address offline.
 Thanks,
 --Jeremy


 --
 Try New Relic Now  We'll Send You this Cool Shirt
 New Relic is the only SaaS-based application performance monitoring service 
 that delivers powerful full stack analytics. Optimize and monitor your
 browser, app,  servers with just a few lines of code. Try New Relic
 and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Try New Relic Now  We'll Send You this Cool Shirt
New Relic is the only SaaS-based application performance monitoring service 
that delivers powerful full stack analytics. Optimize and monitor your
browser, app,  servers with just a few lines of code. Try New Relic
and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 behavior is possible:

To recap the procedure:

(1)  Alice creates a transaction, Tx1, for 10 BTC to a 2-of-2-{Alice,
Bob} address.  It has a locktime of 30 days in the future.
(2)  Before signing the transaction, she gets Bob to sign a transaction,
Tx2, from 2-of-2-{Alice, Bob} back to herself.   That transaction
references the Tx1 by hash.
(3)  Any time in the next 30 days, Alice can sign an alternate Tx2
transactions reducing the amount returned to self and increasing amount
to Bob, as a method of paying Bob more.  Bob doesn't need to broadcast
anything except for the last one, 29 days later.

It was originally conceived that Bob couldn't do anything malicious,
because Alice gets Bob to sign Tx2-spending-Tx1 before she gives him
Tx1.  The problem is that Bob can follow her process, then
broadcast/mine Tx1' (Tx1-prime), which has a different number of 0x00
pad bytes in the signatures, or flips the sign of one of the s-values
in the signature, thus changing the hash of Tx1.

By doing this, Bob has now created a transaction, Tx1', that Tx2 no
longer returns to Alice.  It's not flat-out theft, because Tx1 still
sends to a 2-of-2 address requiring both of their signatures.  But Bob
didn't risk anything to do this, besides his reputation/trust.  He now
has Alice's money locked and can hold it for ransom, since she needs his
signature to do move it.  He could offer his signature for half of it.

Of course, these types of HFT contracts will usually be between parties
that have some mutual respect/history.  Thus, they are not usually
zero-trust.   But we should find a way to try to close that, if
possible.  For instance, if the malleability was reduced to one bit, you
could just have Bob sign two different transactions before Alice
broadcasts Tx1.  The two tx would be from either variant.  But I know
there's too many bits of malleability in the transaction serialization
for that to work.  Is there any way to avoid this?

-Alan



On 04/17/2013 05:48 AM, Mike Hearn wrote:
 When this system was first being discussed, Gavin was concerned that
 miner incentives were to ignore replacements because it meant extra
 work and the replacement might have equal or lower fees than before
 (or indeed, no fees). He proposed two solutions: one is to
 progressively raise the fee on each replacement. The other is to
 specify lock time in terms of blocks and then step it backwards once
 for each replacement, thus ensuring that by replacing the transaction
 you get to claim any attached fee earlier.

 It should be apparent that both solutions can be implemented by
 whichever application is running the contract - the core Bitcoin
 network and software is agnostic either way.

 Now, Gavin and I disagreed on whether this would actually be
 necessary. As I already pointed out, both solutions seriously reduce
 the utility of HFT because they limit how often you can update the
 contract. Instead of an online game billing you per second, maybe it
 can only do it per minute or per 10 minutes with the lock time
 solution because otherwise you run out of blocks, and with
 ever-increasing fees perhaps the contract becomes too expensive to
 justify after a while.

 So it'd be nice if this ended up not being necessary. Experience
 indicates that rational miners typically don't pursue a short-termist
 profit-at-any-cost agenda - free transactions have always been
 included in blocks, miners include transactions even though you could
 avoid a lot of complexity by just not including any at all, etc. Some
 miners like BTC Guild have actually sacrificed significant amounts of
 money for the good of the system. You can see this in terms of
 rational self interest - miners earn Bitcoins thus it's in their
 interest for Bitcoins to be as useful as possible, as that is what
 gives them value. Or you can see it in terms of ideologically-driven
 altruism. Or both.

 If I were to implement an application that used tx replacement, I
 would probably start with replacements that don't change the fees and
 don't count down the lock time field. We can then observe whether
 miners bother changing their software to behave differently, or
 whether the inherent utility of the application is enough to convince
 them to play by the default rules. Ideally at least one application
 made possible by this feature is a killer app - something so useful
 / unique / compelling that people want to obtain Bitcoin just to use
 it. If someone can find such an app, then rational miners should want
 tx replacement to work as reliably as possible because it boosts the
 value of their earnings.

 There are some other misc details - reactivation requires that we bump
 the protocol version and 

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 compatiblity, but offer this as the primary one.

What we really want is to have the user copy an ASCII-armored block of
text into the client (or we could have a URI-extension for this), and
the app pops up with a window that says The following message has a
valid signature from address 1XKjf32kJbf...:   message.  

I know people argue they'd like to get away from raw addresses and
copy-and-paste.  But it'll be a while before that happens, and there's a
lot of demand for Armory to become compatible with Bitcoin-Qt signing. 
People are obviously using it.

-Alan





On 04/14/2013 01:09 AM, Peter Todd wrote:
 Currently signmessage/verifymessage only supports messages signed by a
 single key. We should extend that to messages signed by n-of-m keys, or
 from the users point of view, P2SH multisig addresses.

 rpc.cpp:signmessage() returns the output of SignCompact(). That in turn
 starts with a header byte marking the signs of the various keys to allow
 for key recovery. The header byte can be one of 0x1B, 0x1C, 0x1D or 0x1E


 For multisig signmessage signatures this is extended:

 01 varint n varint m sig or key {sig or key, ...}

 Each signature or key can be one of the following forms:

 sig: 1B/1C/1D/1E 32 byte r 32 byte s
 compress key: 02/03 32 byte x
 uncompressed key: 04 32 byte x 32 byte y

 Note that we have to provide all pubkeys, even if they aren't used for a
 given signature, to allow the P2SH address to be reconstructed.

 Decoding/encoding is a bit code-intensive due to the all the cases, but
 on the other hand this format keeps the size down to an absolute
 minimum. Alternatively I could use length bytes.

 The format is backwards compatible in the sense that older versions will
 fail safely on new signatures, even ones that have been truncated.
 Similarly new signatures are easily distinguished from old, and going
 forward if we for some reason need yet another signature format the
 leading byte can be incremented.

 Signing incomplete signatures on messages can be handled by converting
 pubkeys to signatures. Similarly the RPC signmessage command can be
 extended with an optional existing signature option.



 --
 Precog is a next-generation analytics platform capable of advanced
 analytics on semi-structured data. The platform includes APIs for building
 apps and a phenomenal toolset for data science. Developers can use
 our toolset for easy data analysis  visualization. Get a free account!
 http://www2.precog.com/precogplatform/slashdotnewsletter


 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Precog is a next-generation analytics platform capable of advanced
analytics on semi-structured data. The platform includes APIs for building
apps and a phenomenal toolset for data science. Developers can use
our toolset for easy data analysis  visualization. Get a free account!
http://www2.precog.com/precogplatform/slashdotnewsletter___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 offline
storage.  It's kind of silly to say /You must do this!  But we have no
recommendations for how.  At all.  Good luck/!  At least have a
dedicated page or (not-ideally, forum post) describing the various
options and leads for them to follow for actually doing it. 

-Alan
--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 on a plane to go to
San Jose two days later, it may create unnecessary stress.  It's
probably not a big deal, but if the date is arbitrary anyway, why not
just push back one more week?

-Alan

--
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 preparing PR comments that can be posted on articles immediately
after they go public.  This event is likely draw much more negative
attention than it deserves, and getting some positiveinformed comments
posted up front will potentially make a difference in the way the story
is received. 

Undoubtedly, many articles (and especially commenters) will shape this
into the end of Bitcoin.   I would describe it as there was a short
and mostly-harmless lapse in the ability of the network to reach a
consensus, causing transactions to get delayed by a few hours.   It
*really* needs to be emphasized that coins are safe, and nothing anyone
has/could do will change that.  And that it would've been extremely
difficult to exploit for gain.  Transactions got delayed while a bug was
fixed.  End of story.

Hell, someone here should submit their own slashdot article about it! 
100% chance this hits slashdot -- it might as well be written by someone
who understands it.  Similarly, we could be sending sources information
to pre-empt misinformation being spread about it.  Unfortunately, I have
to go to bed, so I can't really do much.  I just wanted folks to be on
the lookout and be ready to respond to the crazy stuff that's going to
hit the media in the next 12 hours.

-Alan

--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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, I saw people still trying to buy/sell on OTC, whom could have
 been
 scammed even by taking standard precautions.


I don't want to misrepresent what happened, but how much of that was really
a risk?  The block was rejected, but the transactions were not.  Any valid
transactions to hit the network would get added to everyone's memory pool
and mined in both chains.  Thus all nodes would still reject double-spend
attempts.  As far as I understood it, you would've had to have majority
mining power on one of the chains (and both had non-negligible computing
power on them), so double-spending still required an exceptional amount of
resources -- just not the normal 50% that is normally needed.  Perhaps...
10%?   But how many people can even have 10%?  In addition to that, a
victim needs to be found that hasn't seen the alert, is willing to execute
a large transaction, and is on the wrong side of the chain.

Is this incorrect?  Yes, there was less resources needed to execute an
attack -- but it still required a very powerful attacker, way outside the
scope of regular users.
--
Symantec Endpoint Protection 12 positioned as A LEADER in The Forrester  
Wave(TM): Endpoint Security, Q1 2013 and remains a good choice in the  
endpoint security space. For insight on selecting the right partner to 
tackle endpoint security challenges, access the full report. 
http://p.sf.net/sfu/symantec-dev2dev___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 got
 the simpler customer-pays-merchant flow working nicely
 (funded-escrow-pays-merchant is a subset of that, anyway).



I think that the pass around method needs to happen in addition to the
methods of transparent protocols that occur behind the scenes.  For one,
there's a lot of CONOPs that need to be worked out by getting knowledgeable
people using it, and providing feedback about how it could/should/will be
used and how it could be improved.  The pass-around method is simpler to
implement and still usable by the types of users that will be using it in
the beginning -- experts.  Also, I see that for very large, important
multi-sig tx/contracts/escrow, the manual method might be preferred --
much the same way many people prefer manual-transmission cars even though
automatics are easier -- some people/organizations will want the control.


I'm all for protocols that enable higher-level access to this
functionality, I'm just saying there should be lower-level access, too.
--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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
want users who aren't willing to run full nodes, we need to accommodate
users who want to simply use the network, not necessarily support it.  *I'm
making an assumption here that we want new users whether they use a full
node or not*.  Greg's point looks like it's veering towards we don't want
to grow the network unless we're going to get more full nodes out of it.
  I'm of the opinion, like Mike Hearn, that the number of full nodes needed
for a healthy network is *not* O(N) in the number of users of the network.
 I expect it to be something more like O(sqrt(N))... or perhaps there's
even an upper limit above which the network gets no benefit, even if all 7
billion humans were using it.  (the bottleneck would be size of blocks and
CPU processing power at that point, not a shortage of full nodes).  Would
we rather have a system that is full-node-or-nothing and drive away users
that won't support the network, or accommodate those users with various
gradations of participation?

I believe my proposal for an address-based meta-chain (or something like
it) is *exactly* what is needed in the long run.  It could almost obsolete
this entire discussion.  However, as Greg pointed out there is a long,
treacherous path between the theory I presented, and a workingrobust
implementation that can serve as the backbone for future SPV nodes.  I have
every intention to help pioneer that when Armory has other major features
completed (such as multi-sig), but it's not something that we can even
consider in the near- or medium-term as a solution to rely on.  I'd be
surprised if any such solution existed in the next 6-12 months.

I think it is very much in everyone's interest here to encourage new users
to start using Bitcoin, even if they don't support it.  As long as
there is a convenient channel for interested users to get more information
about the system, the benefits of spending the effort to run a full node,
and the features available in more-advanced clients that they might benefit
from, then I'm not personally concerned about a shortage of full nodes, and
we should carry forward with the idea of promoting SPV nodes for the
really-new users.

-Alan




On Tue, Dec 4, 2012 at 4:41 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn m...@plan99.net wrote:
  It sounds to me that you're insisting that you're asking people who
  oppose degrading our recommendations to commit to a costly rushed
  development timeline. I think this is a false choice.
 
  Hardly. I don't have any particular timeline in mind. But I disagree
  we have forever. New ideas have a certain time window to take off
  and become credible.

 Marketing initiatives have limited windows.  This matters, perhaps,
 when you're some VC pumping cash into a startup with the hopes of
 being the next stockmarket pump and dump darling.  Outside of that
 people use whatever they use because it works for them.

 And by the numbers Linux desktops are more common than they've ever
 been— and certainly Linux kernel _systems_ half the people I know have
 one in their pocket and its hard to go more than a few hours without
 touching one.  To some extent the Year of the Linux desktop is a bit
 like the Year of being able to turn lead into gold ... we can turn
 lead into gold now, but the particle accelerators, atomic power, and
 atomic weapons enabled by the same technology are far more interesting
 due to the particle realities of this. So we didn't get the ubiquitous
 Linux desktop: We got the ubiquitious Linux server, the ubiquitous
 Linux-kernel smart phone, the ubiquitous Linux television, media
 player, HVAC controller, etc. instead.

 Desktops— well, that didn't meet people's hopes though I think not for
 the lack of marketing on the part of Linux, but because Apple stepped
 up and produced middle ground products that attracted a larger
 audience. Especially as MSFT dropped the ball. They did some things
 better, had a running start, and had a non open source software
 business model which made reaping rewards easier.

 But I don't see how any of this has anything to do with Bitcoin...
 Except for the point that if Bitcoin doesn't become the money system
 everyone uses and instead becomes the money system infrastructure all
 the systems people use depend on— just as Linux has with the desktop,
 where it might not be on the desktop but its in router firmware, cloud
 servers, and just about everything else— I wouldn't consider that much
 of a loss.

  time window, eventually people just give up and move on. Does anyone
  take desktop Linux seriously anymore? No. The year of desktop Linux
  is a joke. People took it seriously in 2001 but 

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

2012-12-04 Thread Alan Reiner
Our divergence is on two points (personal opinions):

(1) I don't think there is any real risk to the centralization of the
network by promoting a SPV (purely-consuming) node to brand-new users. 
In my opinion (but I'm not as familiar with the networking as you), as
long as all full nodes are full-validation, the bottleneck will be
computation and bandwidth, long before a constant 10k nodes would be
insufficient to support propagating data through the network.  In fact,
I was under the impression that connectedness was the real metric of
concern (and resilience of that connectedness to large percentage of
users disappearing suddenly).  If that's true, above a certain number of
nodes, the connectedness isn't really going to get any better (I know
it's not really that simple, but I feel like it is up to 10x the current
network size).

(2) I think the current experience *is* really poor.  You seem to
suggest that the question for these new users is whether they will use
full-node-or-lite-node, but I believe it will be a decision between
lite-node-or-nothing-at-all (losing interest altogether).  Waiting a day
for the full node to synchronize, and then run into issues like
blkindex.dat corruption when their system crashes for some unrelated
reason and they have to resync for another day... they'll be gone in a
heartbeat.

Users need to experience, as quickly and easily as possible, that they
can move money across the world, without signing 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, Alan Reiner etothe...@gmail.com wrote:
 Greg's point looks like it's veering towards we don't want to grow
 the network unless we're going to get more full nodes out of it.
 No…

 There is no fundamental completion between taking what actions we can
 to maximize the decentralization of the network and making the
 software maximally friendly and painless to get started with and use.
 It's possible— not even deep rocket science— to create software that
 accommodates both.

 And because of this, I don't think it's acceptable to promote
 solutions which may endanger the decentralization that makes the
 system worthwhile in the first place.  If the current experience is so
 poor that you'd even consider talking about promoting directions which
 reduce its robustness then thats evidence that it would be worth
 finding more resources to make the experience better without doing
 anything the that reduces the model, even if you've got an argument
 that maybe we can get away with it.  If there isn't interest in
 putting in more resources to make these improvements then maybe the
 issue isn't as bad as we think it is?

 I think it is very much in everyone's interest here to encourage new users 
 to start using Bitcoin, even if they don't support it.
 Absolutely— and yet that has nothing to do with promoting software to
 users which only consumes without directly contributing and which
 doesn't even have the capability to do so even if the user wants to
 (or much less, is indifferent).


--
LogMeIn Rescue: Anywhere, Anytime Remote support for IT. Free Trial
Remotely access PCs and mobile devices and provide instant support
Improve your efficiency, and focus on delivering more value-add services
Discover what IT Professionals Know. Rescue delivers
http://p.sf.net/sfu/logmein_12329d2d
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 or more — the only
 major complication is doing this without concurrently harming privacy
 which is why it's not done yet in the reference client.


FYI, Armory uses exactly this logic to try to clean up dust outputs in
the user's transactions.  However, there's enough conditions on it, that
I don't know how often it triggers.  Recommendations are welcome for how
to improve it.

Right now, if the transaction has less than 5 inputs, there exists dust
UTXOs from addresses already included in the transaction, and those
UTXOs are sufficiently small in priority, then the Armory will add them
to the input side and increase the change accordingly.  Looking it just
made me realize I lost the last condition of making sure the tx already
has a change output -- don't want to turn a free tx into a fee-needed tx
just to do this.  (reorganized the code
https://github.com/etotheipi/BitcoinArmory/blob/master/armoryengine.py#L5279
recently, and must have fell through the cracks).

Perhaps it could be improved by cleaning up dust from *any* address by
default (not just ones already included in the tx), with the option for
the user to disable that behavior.  After all, anonymity was never a
core feature of the network -- I think it makes sense that the logic
would reduce anonymity by default in exchange for a cleaner network,
with a clear option to opt-out of that logic if user cares.  I think
most users don't actually care...

-Alan
--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 suggest that anonymity is a core benefit of Bitcoin and I should be
supporting it.  I'm not against anonymity, and I most certainly favor
privacy, but my goal was to produce a versatile client, not one focused on
any one aspect -- there are plenty of people who use it for other reasons
than anonymity.

However, I do like Greg's comment about attacks against a
blind-dust-inclusion algorithm, and suggestion to maintain a clustering of
already-linked addresses.  That's not terribly difficult to do with the
transaction history in hand, and it could increase how often the logic
triggers.  I suppose these hardcore SD players probably have a lot of
one-satoshi outputs that could use vacuuming...




On Mon, Dec 3, 2012 at 11:18 AM, Stephen Pair step...@bitpay.com wrote:

 On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn m...@plan99.net wrote:

 Second thing, it's best to carefully separate anonymity from
 privacy. Privacy is supposed to be a feature of the system (it says
 so in Satoshis paper) because people demand it. If I loan a tenner to
 my friend and he is able to find out what I earned last month, then
 that trade was neither anonymous nor private. In this case I want
 privacy but anonymity isn't useful. Mixing up anonymity with privacy
 is not only a public relations problem, but can lead to confusion from
 users when they, eg, try and buy Bitcoins from an exchange and are
 asked to provide ID proofs.


 I would like to second this point...privacy is essential because the
 market demands it.  If Bitcoin doesn't do it well (and I would argue that
 it doesn't today), then eventually a competitor to Bitcoin will do it
 better and that would be the beginning of the end for Bitcoin.  Debates
 about whether it was or wasn't a core feature are pointless.

--
Keep yourself connected to Go Parallel: 
BUILD Helping you discover the best ways to construct your parallel projects.
http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 returned, even if empty.
 
  I'm not sure about this last. What is it good for? inv packets can
 always be
  sent, even not in response to others, so it is not that this gives you an
  acknowledgement the mempool is updated?

 A simple guarantee of 1:1 correspondence between request and response.
  The bitcoin protocol sometimes simply elides a response when the
 response would be empty, and this makes it difficult to know whether a
 request is timing out or already processed.

 Sending a ping(nonce) after each P2P command is another way of achieving
 same :)



Is there a problem with sending unrecognized messages to nodes?   If we
create a new message type specifically asking for memory pool transactions,
and we broadcast it to all nodes that we are connected to, and none of them
respond, then either there are no tx in their memory pools, or they don't
recognize the message and ignore it.  Either way, you're not going to get
any extra information out of them.  If you really care, a simple ping can
identify whether they're still connected and should've responded (as Jeff
said).

As long as the older node won't cut you off for sending one unrecognized
request, it seems that you can get by fine without requiring that bit.  I
guess it depends on the utility of definitively identifying whether a node
supports the functionality.  I personally don't feel like it's critical,
especially considering that this is most useful only during the transient
period when it's not normal for nodes to support it yet.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 client, and a
link of where to find more information (i.e. the wiki).  I would still *
prefer* to have the page the way it is, because I think alt clients should
be more accessible and word will spread better where it is now -- but I
also recognize the inherent difficulty of gaining any kind of consensus of
how it should be organized, what goes on the list, etc, and no matter how
you do it, someone will complain about it being unfair or not right.

We either have to have a czar who is trusted to make responsible
decisions, and complaints of being unfair or recommendations for
improvements can go through that person, but ultimately it is that person
who makes the call.  Or we just move it to another page that is less
strictly controlled and where these things matter less.  Trying to gain
consensus among an amalgamation of developers all with competing priorities
and products is a terrible way to try to agree on stuff.

-Alan




On Mon, Jul 9, 2012 at 1:46 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki zgen...@yahoo.com wrote:
  JS randomisation is bad. People shouldn't need JS to view a webpage.

 JS randomization doesn't imply needing JS to view the page. It implies
 needing JS to see it in random order.  You could also combine it with
 the server-side randomization if you care about non-js being non
 random, though I don't think it matters.

 As others have pointed out I don't generally think the randomization
 is good in principle, but if its done it should at least achieve its
 goals.

  Only you have a problem with this page. I don't see why Bitcoin-Qt needs
 to be first either when it dominates the front page. It is perfectly fine
 as it is.

 I'll let other people speak for themselves, but I did consult others
 before reverting your last batch of changes.

 More generally, we have pull requests in order to get some peer review
 of changes.  Everyone should use them except for changes which are
 urgent or trivially safe.  (Presumably everyone with access knows how
 to tell if their changes are likely to be risky or controversial)

  You are not a developer of any alternative clients, and this is a
 webpage for Bitcoin clients. I have made a change to remove a source of
 disputes, and make the process more fair and equal. Your suggestion to
 remove the clients page is your bias towards thinking that there should be
 only one Bitcoin client that everyone uses (the one which you contribute
 towards).

 I'm strongly supportive diversity in the Bitcoin network, and some alt
 client developers can speak to the positive prodding I've given them
 towards becoming more complete software. If I've said anything that
 suggests otherwise I'd love to be pointed to it in order to clarify my
 position.

 Unfortunately none of the primary alternatives are yet complete, the
 network would be non-function if it consisted entirely of multibit or
 electrum nodes (and as you've noted armory uses a local reference
 client as its 'server').  The distinction between multiple kinds of
 clients in terms of security and network health are subtle and can be
 difficult to explain even to technical users and so until something
 changes there the reference client needs to be the option we lead
 with. People should us it unless their use-case doesn't match. When it
 does they'll know it and they'll be looking. We don't need to make one
 of those recommendations a primary option.

 I like the proposals of moving this stuff to the Wiki as the wiki
 already contains tons of questionable (and sometimes contradictory)
 advice and so there is less expectation that placement there implies
 any vetting.


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. 

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 order to get the tree structure and correct 
root.  Along those lines, using something like a red-black tree, while 
theoretically well-known, could be subject to implementation errors.  
One implementation of a red-black tree may do the rebalancing 
differently, and still work for it's intended purpose in the majority of 
applications where it doesn't matter.  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 would that be disruptive, it would be a disaster to 
track down.

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 elements 
are inserted or deleted, and accesses to elements in the tree are 
constant time -- O(1).  There is no such thing as an unbalanced trie.  
But overall space-efficiency is an issue.

A PATRICIA tree/trie would be ideal, in my mind, as it also has a 
completely deterministic structure, and is an order-of-magnitude more 
space-efficient.  Insert, delete and query times are still O(1).
However, it is not a trivial implementation.  I have occasionally looked 
for implementations, but not found any that were satisfactory.

So, I don't have a good all-around solution, within my own stated 
constraints. But perhaps I'm being too demanding of this solution.

-Alan



On 06/19/2012 12:46 PM, Andrew Miller wrote:
 Peter Todd wrote:
 My solution was to simply state that vertexes that happened to cause the
 tree to be unbalanced would be discarded, and set the depth of inbalance
 such that this would be extremely unlikely to happen by accident. I'd
 rather see someone come up with something better though.
 Here is a simpler solution. (most of this message repeats the content
 of my reply to the forum)

 Suppose we were talking about a binary search tree, rather than a
 Merkle tree. It's important to balance a binary search tree, so that
 the worst-case maximum length from the root to a leaf is bounded by
 O(log N). AVL trees were the original algorithm to do this, Red-Black
 trees are also popular, and there are many similar methods. All
 involve storing some form of 'balancing metadata' at each node. In a
 RedBlack tree, this is a single bit (red or black). Every operation on
 these trees, including search, inserting, deleting, and rebalancing,
 requires a worst-case effort of O(log N).

 Any (acyclic) recursive data structure can be Merkle-ized, simply by
 adding a hash of the child node alongside each link/pointer. This way,
 you can verify the data for each node very naturally, as you traverse
 the structure.

 In fact, as long as a lite-client knows the O(1) root hash, the rest
 of the storage burden can be delegated to an untrusted helper server.
 Suppose a lite-client wants to insert and rebalance its tree. This
 requires accessing at most O(log N) nodes. The client can request only
 the data relevant to these nodes, and it knows the hash for each chunk
 of data in advance of accessing it. After computing the updated root
 hash, the client can even discard the data it processed.

 This technique has been well discussed in the academic literature,
 e.g. [1,2], although since I am not aware of any existing
 implementation, I made my own, intended as an explanatory aid:
 https://github.com/amiller/redblackmerkle/blob/master/redblack.py


 [1] Certificate Revocation and Update
  Naor and Nissim. 1998
  
 http://static.usenix.org/publications/library/proceedings/sec98/full_papers/nissim/nissim.pdf

 [2] A General Model for Authenticated Data Structures
  Martel, Nuckolls, Devanbu, Michael Gertz, Kwong, Stubblebine. 2004
  http://truthsayer.cs.ucdavis.edu/algorithmica.pdf

 --
 Andrew Miller

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, 

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
root.  Not only would that be disruptive, it would be a disaster to
track down.

This is why good comprehensive tests and a well specified algorithim
are important. The tree update algorithm would be normative in that
scheme. Worrying that implementers might get it wrong would be like
worrying that they'd get SHA256 wrong.


The point is not that they get it *wrong*, it's that the implement it 
*differently*.  Given a set of 100 TxOuts, there's a seemingly-infinite 
number of ways to construct a binary tree.  Put them in in a different 
order, and you get a different tree. *They're all correct and legal* in 
terms of satisfying expectations of insert, delete and query runtime -- 
but they will produce different root hashes.   And the differences in 
underlying structure are completely transparent to the calling code.


I'm extremely uncomfortable with the idea the you can have all the nodes 
in the tree, but have to replay X years of blockchain history just to 
get the same tree configuration as someone else.  However, a trie 
configuration is history-independent -- given an unspent-TxOut list, 
there's only one way to construct that tree.  That's an important 
property to me.


I can't tell if you're joking about Judy structures: I've never heard of 
them.  But I'll look into it anyway...


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 undertaking, but it has some pretty huge benefits.  And 
it's actually feasible because it can be implemented without disrupting 
the main network.  I'm sure there's lots of issues with it, but I'm 
putting it out there to see how it might be improved and actually executed.



*Summary:

*/Use a special tree data structure to organize all unspent-TxOuts on 
the network, and use the root of this tree to communicate its 
signature between nodes.  The leaves of this tree actually correspond 
to addresses/scripts, and the data at the leaf is actually a root of the 
unspent-TxOut list for that address/script.  To maintain security of the 
tree signatures, it will be included in the header of an alternate 
blockchain, which will be secured by merged mining.


This provides the same compression as the simpler unspent-TxOut merkle 
tree, but also gives nodes a way to download just the unspent-TxOut list 
for each address in their wallet, and verify that list directly against 
the blockheaders.  Therefore, even lightweight nodes can get full 
address information, from any untrusted peer, and with only a tiny 
amount of downloaded data (a few kB). /*

*

Alright, tear it up!
-Alan

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-06-17 Thread Alan Reiner
Hi Alberto,

Your thread was part of the inspiration for the idea that I proposed.  
But as I read it more, I see that I originally misunderstood it 
(mistaking it for a simpler unspent-TxOut tree idea).  Even after 
reading it, I'm not entirely clear how your proposal would work, but I 
see that you proposed something very similar.  I just want to clarify 
that there are two, major orthogonal pieces to both proposals:

(1) The method for creating unspent-TxOut-tree roots/fingerprints for 
verification
(2) Using an alternate blockchain to maintain and distribute those 
fingerprints

There are multiple ways to do both of those.  You proposed a different 
tree structure (which I haven't entirely figured out, yet), and putting 
those fingerprints in the main chain header.

In my proposal, (2) is to avoid inducing a blockchain fork, or even 
changing the protocol at all.  By using a separate blockchain, it can be 
done non-disruptively, and could even be thrown out and re-worked if we 
were to find an issue with it later.  The availability of merged mining 
makes it possible to get [almost] the same security as changing the 
protocol, but without the disruption of hard-forking.  (I expect that if 
there's not too much computational overhead and the software is already 
written, most miners would sign on)

I'll read into your page a little more.  I don't want to take credit 
away from you, since you clearly had a comparable idea developed long 
before me :)

-Alan


On 06/17/2012 06:46 PM, Alberto Torres wrote:
 Hi,

 I did describe a very similar thing back in January (also illustrated,
 and, if I'm not mistaken, more simple and efficient to recalculate),
 and I wanted to do a prototype, but I have been very busy with other
 projects since then.

 https://en.bitcoin.it/wiki/User:DiThi/MTUT

 I just saw Gavin left a comment in the talk page, I'm sorry I haven't
 seen it earlier.

 I think armory is the perfect client to implement such an idea. I sort
 of waited it to be able to run in my laptop with 2 GB of RAM before
 being sucked into other projects. I even lost track of its
 development.

 I hope this gets developed. I will be able to help after summer if
 this is still not done.

 DiThi

 P.S: Sorry Peter, 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 Toddp...@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://bitcointalk.org/index.php?topic=88208.0

 This is a huge undertaking, but it has some pretty huge benefits.
 And it's actually feasible because it can be implemented without
 disrupting the main network.  I'm sure there's lots of issues with
 it, but I'm putting it out there to see how it might be improved and
 actually executed.

 
 *Summary:

 */Use a special tree data structure to organize all unspent-TxOuts
 on the network, and use the root of this tree to communicate its
 signature between nodes.  The leaves of this tree actually
 correspond to addresses/scripts, and the data at the leaf is
 actually a root of the unspent-TxOut list for that address/script.
 To maintain security of the tree signatures, it will be included in
 the header of an alternate blockchain, which will be secured by
 merged mining.

 This provides the same compression as the simpler unspent-TxOut
 merkle tree, but also gives nodes a way to download just the
 unspent-TxOut list for each address in their wallet, and verify that
 list directly against the blockheaders.  Therefore, even lightweight
 nodes can get full address information, from any untrusted peer, and
 with only a tiny amount of downloaded data (a few kB). /*
 How are you going to prevent people from delibrately unbalancing the
 tree with addresses with chosen hashes?

 One idea that comes to mind, which unfortunately would make for a
 pseudo-network rule, is to simply say that any *new* address whose hash
 happens to be deeper in the tree than, say, 10*log(n), indicating it was
 probably chosen to be unbalanced, gets discarded. The new address part
 of the rule would be required, or else you could use the rule to get
 other people's addresses discarded.

 Having said that, such a rule just means that anyone playing games will
 find they can't spend *their* money, and only with pruning clients.
 Unrelated people will not be effected. The coins can also always be
 spent with a non-pruning client to an acceptable address, which can
 later re-spend on a pruning client.


 It also comes to mind is that with the popularity of firstbits it may be
 a good idea to use a comparison function that works last bit first...


 It's merkles all the way down...

 --
 'peter'[:-1]@petertodd.org

[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 that reading/writing BIP 10 format should happen at a higher
 level and not in the low-level RPC calls. So 'raw transactions' are
 simply hex-encoded into JSON strings, and encoding/decoding them is
 just a couple of lines of already-written-and-debugged code.


BIP 10 https://en.bitcoin.it/wiki/BIP_0010 could use some improvement.  I
created it for offline and multi-sig tx but there was no reception to it
because no one was using offline or multi-sig tx at the time except for
Armory (which only currently implements offline tx).  So I made something
that fit my needs, and it has served its purpose well for me. But I also
think it could be expanded and improved before there is wider adoption of
it.  It's a little clunky and not very rigorous.

Elements of it that I'd really like to keep:

(1) Some aspects of human-readability -- even if regular users will never
look at it, it should be possible for advanced users to manually copypaste
the data around and see what's going on in the transaction and what
signatures are present.  I'm thinking of super-high-security situations
where manual handling of such data may even be the norm.
(2) Should be compact -- I took the concept of ASCII-armoring from PGP/GPG,
because, for the reason above, it's much easier and cleaner to view/select
when copied inline.  If a random user accidentally runs across it, it will
partially self-identify itself
(3) Includes all previous transactions so the device can verify transaction
inputs without the blockchain.


Things that could be added:

-- It needs a BIP16 script entry (this was created for vanilla multi-sig
before BIP 16 was created)
-- Comment lines
-- Version number
-- Use base58/64 encoding
-- Rigorous formatting spec
-- Binary representation
-- A better name than Tx Distribution Proposal

I'll be releasing the Beta version of Armory soon, and after that, I'll
probably be thinking about a multi-signature support interface.  That would
be a good time for me to tie in a better version of BIP 10 -- one that is
compatible with other clients implementing the same thing.
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 
discussion for all the devs that will have to deal with this eventually...


The part I'm having difficulty with, is the idea that in a few years 
from now, it just may not be feasible to hold transactions 
file-/pointers/ in RAM, because even that would overwhelm standard RAM 
sizes.  Without any degree of blockchain compression, I see that the 
most general, scalable solution is probably a complicated one.


On the other hand, where this fails may be where we have already 
predicted that the network will have to split into super-nodes and 
lite nodes.  In which case, this discussion is still a good one, but 
just directed more towards the super-nodes.  But, there may still be a 
point at which super-nodes don't have enough RAM to hold this data...


(1)  As for how small you can get the data:  my original idea was that 
the entire blockchain is stored on disk as blk.dat files.  I store 
all transactions as 10-byte file-references.  10 bytes would be


-- X in blkX.dat (2 bytes)
-- Tx start byte (4 bytes)
-- Tx size bytes (4 bytes)

The file-refs would be stored in a multimap indexed by the first 6 bytes 
of the tx-hash.  In this way, when I search the multimap, I potentially 
get a list of file-refs, and I might have to retrieve a couple of tx 
from disk before finding the right one, but it would be a good trade-off 
compared to storing all 32 bytes (that's assuming that multimap nodes 
don't have too much overhead).


But even with this, if there are 1,000,000,000 transactions in the 
blockchain, each node is probably 48 bytes  (16 bytes + map/container 
overhead), then you're talking about 48 GB to track all the data in 
RAM.  mmap() may help here, but I'm not sure it's the right solution


(2) What other ways are there, besides some kind of blockchain 
compression, to maintain a multi-terabyte blockchain, assuming that 
storing references to each tx would overwhelm available RAM?   Maybe 
that assumption isn't necessary, but I think it prepares for the worst.


Or maybe I'm too narrow in my focus.  How do other people envision this 
will be handled in the future.  I've heard so many vague notions of 
well we could do /this/ or /that/, or it wouldn't be hard to do /that/ 
but I haven't heard any serious proposals for it.  And while I believe 
that blockchain compression will become ubiquitous in the future, not 
everyone believes that, and there will undoubtedly be users/devs that 
/want/ to maintain everything under all circumstances.


-Alan
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-06-02 Thread Alan Reiner

(response from Doug forwarded below)

It's a very good point.  I have no experience with database engines.  I 
had assumed that in most cases, data could always be indexed in RAM, and 
wanted to know where to go when that's not the case.  I will look into 
that solution, further.


I am very interested to solve the blockchain compression problem, and 
think I've got a great way that will not just compress the blockchain, 
but improve the network for lightweight clients.  But the idea is not 
fully formed yet, so I was holding off...




 Original Message 
Subject: 	Re: [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 issues for other clients using 
established storage mechanisms (bdb,SQLite,etc) and they're using them 
precisely because this is a problem that people have been working on for 
decades and a poor candidate for reinvention.


If you really look at what you're proposing it's fundamentally how bdb 
operates except your indexing format is usage domain specific and you're 
in charge of all the resource management semantics. While at the same 
time you'll be missing many of the newer features that make working 
with/recovering/diagnosing issues in the storage layer easier.


If you're really wanting to talk about pruning methods to prevent the 
massive amount of duplicated; but no longer pertinent, data that's a 
different story and please continue. :)


--
Douglas Huff

On Jun 2, 2012, at 10:40, Alan Reiner etothe...@gmail.com 
mailto:etothe...@gmail.com wrote:



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 discussion for all the devs that will have to deal with this 
eventually...


The part I'm having difficulty with, is the idea that in a few years 
from now, it just may not be feasible to hold transactions 
file-/pointers/ in RAM, because even that would overwhelm standard RAM 
sizes.  Without any degree of blockchain compression, I see that the 
most general, scalable solution is probably a complicated one.


On the other hand, where this fails may be where we have already 
predicted that the network will have to split into super-nodes and 
lite nodes.  In which case, this discussion is still a good one, but 
just directed more towards the super-nodes.  But, there may still be a 
point at which super-nodes don't have enough RAM to hold this data...


(1)  As for how small you can get the data:  my original idea was that 
the entire blockchain is stored on disk as blk.dat files.  I store 
all transactions as 10-byte file-references.  10 bytes would be


-- X in blkX.dat (2 bytes)
-- Tx start byte (4 bytes)
-- Tx size bytes (4 bytes)

The file-refs would be stored in a multimap indexed by the first 6 
bytes of the tx-hash.  In this way, when I search the multimap, I 
potentially get a list of file-refs, and I might have to retrieve a 
couple of tx from disk before finding the right one, but it would be a 
good trade-off compared to storing all 32 bytes (that's assuming that 
multimap nodes don't have too much overhead).


But even with this, if there are 1,000,000,000 transactions in the 
blockchain, each node is probably 48 bytes  (16 bytes + map/container 
overhead), then you're talking about 48 GB to track all the data in 
RAM.  mmap() may help here, but I'm not sure it's the right solution


(2) What other ways are there, besides some kind of blockchain 
compression, to maintain a multi-terabyte blockchain, assuming that 
storing references to each tx would overwhelm available RAM?   Maybe 
that assumption isn't necessary, but I think it prepares for the worst.


Or maybe I'm too narrow in my focus.  How do other people envision 
this will be handled in the future.  I've heard so many vague notions 
of well we could do /this/ or /that/, or it wouldn't be hard to do 
/that/ but I haven't heard any serious proposals for it.  And while I 
believe that blockchain compression will become ubiquitous in the 
future, not everyone believes that, and there will undoubtedly be 
users/devs that /want/ to maintain everything under all circumstances.


-Alan
--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263

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,  especially
if it requires spontaneous super-majority-of-nodes acceptance.  I think
it's gotta be based on the block itself and each nodes' own info.

If you could spontaneously get all miners to agree not to build off of
anti-social blocks (however that is defined) ,  it would have a chance of
making a difference,  but individual miners would have an advantage
building off the antisocial block because they only need to produce one to
create the longest chain (and collect reward) while the miners following
the rules need two blocks.

--Sent from my overpriced smartphone
On May 25, 2012 3:48 AM, Christian Decker decker.christ...@gmail.com
wrote:

 How about a simple proof of work test? This one though does not ask for
 CPU work but asks the miner for a random old transaction. If the miner
 really stores the entire blockchain he will not have any problem answering
 to that getdata request, whereas a botnet would have to ask someone else
 for it, which could be detected if the response time deviates too much from
 what has been previously measured (compare it against getdata for the block
 they advertise). It's not perfect but it allows an estimate of whether it
 is a chainless miner.

 Regards,
 Chris
 --
 Christian Decker



 On Fri, May 25, 2012 at 3:17 AM, Jeff Garzik jgar...@exmulti.com wrote:

 On Thu, May 24, 2012 at 8:57 PM, Luke-Jr l...@dashjr.org wrote:
  Block times are not accurate enough for that.

 The times in your log are very accurate, assuming your system clock is
 remotely accurate.

 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 understand that you want to add transaction meta-data fields 
such as contact information, bought items, item prices?





I don't want to add fields to the URI-spec, I just want to add them /to 
the client/.  To me, it is ideal to have separate strings for labeling 
/addresses/ vs labeling /transactions/ -- i.e. different strings would 
show up in the address book (owner info) than what shows up in the 
transaction history (purchase info).   I say it's ideal because that 
concept seems to fit perfectly with availability of label= and 
message= fields in BIP 21, but it won't actually work if Bitcoin-Qt 
won't/can't do it that way.


For now, it seems that I should count on all important information being 
in the /label/ field, since users creating URLs would have to assume 
anything in the /message/ field will not be saved.  Though I imagine the 
message data will be /displayed/ after the URI is clicked, just not saved.


To expand the concept slightly further, it might make sense in the 
future for users to populate the /message/ and /label /fields with lots 
of data, using newlines.  The first line would be used as a summary and 
displayed in the address book and ledger.  The extra lines would all be 
displayed when the user opens up a details window.  All of it would be 
automatically generated by the merchant, and the purchaser would end up 
with detailed documentation on every purchase they've made for zero effort.


-Alan

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 2, 2012 at 9:42 AM, Mike Hearn m...@plan99.net wrote:

 Bitcoin-qt is translated into a pretty broad set of languages (now— I
 cant tell you how many of them are _good_). Listing language just
 under multibit makes it sound like a distinguishing characteristic.


 Fair enough then, let's take that out.

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 user mode that is standalone, easy to use,
etc.  But until then, Armory will remain an a power-users thing, and I'd
prefer not to have Bitcoin n00bs emailing me for support before they know
what Bitcoin-Qt is, or, more likely, installing Armory alone and then
walking away when nothing works.

As someone else mentioned previously, the advanced stuff will generally be
found by advanced users.  I think it should still receive exposure through
these means, but not on the top/first row.

I personally think the page should say something like New to Bitcoin?
Start experiencing Bitcoin with My Phone menu of phone options, or My
Desktop menu of desktop options  Put the top 3 on each and either a
button for More Options, or a short list of other options without
screenshots, and just descriptions with links.  Ideally, it would be sorted
by popularity, because that's probably the most important metric that ties
together all features into a single number, but we don't have good stats on
that.  For now, we settle this by putting Bitcoin-Qt up front, and sort
everything else by how easy it is for users to get started and perceived
popularity and disagreements can be settled by semi-regular rotation.

For now, I don't think ordering is super important.  No one here is
threatening lawsuits for improper placement, and the rotation will be good
to keep the main Bitcoin page looking less stagnant, and slowly exposing
repeat visitors to the variety of options available.

--Alan




On Wed, May 2, 2012 at 3:25 PM, Amir Taaki zgen...@yahoo.com wrote:

 This is like the most annoying thing about email. Often with group emails,
 we'll be having a conversation then someone will click reply instead of
 group reply and the convo will go on for a while. Eventually I'll realise
 the persons are missing and add them back in.

 On Yahoo mail (which I use for spam/mailing lists), to do reply all
 involves clicking a tab, scrolling down and clicking Reply All. Normally I
 instead go through the steps of reply, delete To, re-enter bitco... select
 drop down, click send.

 Anyone know how to make reply all the default in mutt? And how can I
 exclude it from re-including my own email when I do a group reply so I
 don't get the same email again.



 - Original Message -
 From: Jeff Garzik jgar...@exmulti.com
 To: grarpamp grarp...@gmail.com
 Cc: bitcoin-development@lists.sourceforge.net
 Sent: Wednesday, May 2, 2012 7:29 PM
 Subject: Re: [Bitcoin-development] new bitcoin.org clients page

 On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote:
  Try Reply to All
 
  That puts the sender in 'to' and list in 'cc',
  which dupes to the sender and eventually
  blows out the to and cc lines as everyone
  chimes in and doesn't trim. 'reply to' solves
  most of that. assuming the list sw can do it.

 Reply-To Munging Considered Harmful
 http://www.unicom.com/pw/reply-to-harmful.html



 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net

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 replaced by a blurb about the target
audience.  Designed for Advanced Users.  Designed for Quick Setup and
Instant usability.

Btw, Armory now has full installers for both Windows and Linux
(Ubuntu/Debian), with uninstallers and automatic URI registration



On Wed, May 2, 2012 at 3:34 PM, Gary Rowe g.r...@froot.co.uk wrote:

 How about keeping it simple?

 Bitcoin-Qt
 * Requires the entire blockchain
 * Standalone client
 * Designed for continuous operation
 * Available for Windows, Mac, Linux with installer
 * Developed in C
 * Website: https://bitcoin.org

 MultiBit
 * Requires a reduced blockchain
 * Standalone client
 * Designed for occasional use
 * Available for Windows, Mac, Linux with installer
 * Developed in Java
 * Website: http://multibit.org

 Armory
 * Requires the entire blockchain
 * Dependent client of Bitcoin-Qt
 * Designed for occasional use
 * Available for Windows (64-bit only), Mac, Linux (self-build)
 * Developed in Python
 * Website: http://bitcoinarmory.com/

 Electrum
 * Requires no blockchain
 * Dependent client of Bitcoin-Qt (on server)
 * Designed for occasional use
 * Available for Windows, Linux (self-build)
 * Developed in Python
 * Website: http://ecdsa.org/electrum/

 Bitcoin Wallet (Android client)
 * Requires a reduced blockchain
 * Standalone client
 * Designed for occasional use on mobile
 * Available for Android only
 * Developed in Java
 * Website:
 https://play.google.com/store/apps/details?id=de.schildbach.wallethl=en


 On 2 May 2012 20:25, Amir Taaki zgen...@yahoo.com wrote:

 This is like the most annoying thing about email. Often with group
 emails, we'll be having a conversation then someone will click reply
 instead of group reply and the convo will go on for a while. Eventually
 I'll realise the persons are missing and add them back in.

 On Yahoo mail (which I use for spam/mailing lists), to do reply all
 involves clicking a tab, scrolling down and clicking Reply All. Normally I
 instead go through the steps of reply, delete To, re-enter bitco... select
 drop down, click send.

 Anyone know how to make reply all the default in mutt? And how can I
 exclude it from re-including my own email when I do a group reply so I
 don't get the same email again.



 - Original Message -
 From: Jeff Garzik jgar...@exmulti.com
 To: grarpamp grarp...@gmail.com
 Cc: bitcoin-development@lists.sourceforge.net
 Sent: Wednesday, May 2, 2012 7:29 PM
 Subject: Re: [Bitcoin-development] new bitcoin.org clients page

 On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote:
  Try Reply to All
 
  That puts the sender in 'to' and list in 'cc',
  which dupes to the sender and eventually
  blows out the to and cc lines as everyone
  chimes in and doesn't trim. 'reply to' solves
  most of that. assuming the list sw can do it.

 Reply-To Munging Considered Harmful
 http://www.unicom.com/pw/reply-to-harmful.html



 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development




 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 

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
appealing to new users and get the community more connected.   And make
sure everyone understands the system.

On the other hand, perhaps it's better to take the acceptable 80% solution,
and revise it over time...

Amir, I don't have access to the page.  I've never been able to view it.
 Changing my hosts file doesn't seem to do anything.  Can you just forward
me the text?  I'll send you an approval email.




On Wed, May 2, 2012 at 3:43 PM, Amir Taaki zgen...@yahoo.com wrote:

 This discussion about ordering is absolutely retarded. Once the list fills
 up, then it won't matter. For now I'm deciding the ordering with Bitcoin-Qt
 first and the others ordered however. That was nobody can try to game the
 system (it remains unexploitable).

 If there are no objections, then I am going to merge this branch. The
 forum thread is divulging into a mess all over the place, and this
 conversation can go on forever discussing the silly fine details:

 http://hackerspaces.org/wiki/The_Bikeshed_Anti-PatternProblem:
 You suggest creating something new for your hackerspace, like a
 bikeshed.  But now all anyone will discuss is its colour. No bikeshed
 will be built.

 Armory  MultiBit, are you OK with that description? I will check with
 ThomasV about Electrum.


 
 From: Gary Rowe g.r...@froot.co.uk
 To: bitcoin-development@lists.sourceforge.net 
 bitcoin-development@lists.sourceforge.net
 Sent: Wednesday, May 2, 2012 8:34 PM
 Subject: Re: [Bitcoin-development] new bitcoin.org clients page


 How about keeping it simple?

 Bitcoin-Qt
 * Requires the entire blockchain
 * Standalone client
 * Designed for continuous operation
 * Available for Windows, Mac, Linux with installer
 * Developed in C
 * Website: https://bitcoin.org

 MultiBit
 * Requires a reduced blockchain
 * Standalone client
 * Designed for occasional use
 * Available for Windows, Mac, Linux with installer
 * Developed in Java
 * Website: http://multibit.org

 Armory
 * Requires the entire blockchain
 * Dependent client of Bitcoin-Qt
 * Designed for occasional use
 * Available for Windows (64-bit only), Mac, Linux (self-build)
 * Developed in Python
 * Website: http://bitcoinarmory.com/

 Electrum
 * Requires no blockchain
 * Dependent client of Bitcoin-Qt (on server)
 * Designed for occasional use
 * Available for Windows, Linux (self-build)
 * Developed in Python
 * Website: http://ecdsa.org/electrum/

 Bitcoin Wallet (Android client)
 * Requires a reduced blockchain
 * Standalone client
 * Designed for occasional use on mobile
 * Available for Android only
 * Developed in Java
 * Website:
 https://play.google.com/store/apps/details?id=de.schildbach.wallethl=en


 On 2 May 2012 20:25, Amir Taaki zgen...@yahoo.com wrote:

 This is like the most annoying thing about email. Often with group emails,
 we'll be having a conversation then someone will click reply instead of
 group reply and the convo will go on for a while. Eventually I'll realise
 the persons are missing and add them back in.
 
 On Yahoo mail (which I use for spam/mailing lists), to do reply all
 involves clicking a tab, scrolling down and clicking Reply All. Normally I
 instead go through the steps of reply, delete To, re-enter bitco... select
 drop down, click send.
 
 Anyone know how to make reply all the default in mutt? And how can I
 exclude it from re-including my own email when I do a group reply so I
 don't get the same email again.
 
 
 
 
 - Original Message -
 From: Jeff Garzik jgar...@exmulti.com
 To: grarpamp grarp...@gmail.com
 Cc: bitcoin-development@lists.sourceforge.net
 Sent: Wednesday, May 2, 2012 7:29 PM
 Subject: Re: [Bitcoin-development] new bitcoin.org clients page
 
 
 On Wed, May 2, 2012 at 12:58 PM, grarpamp grarp...@gmail.com wrote:
  Try Reply to All
 
  That puts the sender in 'to' and list in 'cc',
  which dupes to the sender and eventually
  blows out the to and cc lines as everyone
  chimes in and doesn't trim. 'reply to' solves
  most of that. assuming the list sw can do it.
 
 Reply-To Munging Considered Harmful
 http://www.unicom.com/pw/reply-to-harmful.html
 
 
 
 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com
 

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 

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 feature of the Armory.  And backups should say
something like One-time Printable if it fits within the box.

Otherwise, I really like the layout and design.  Although despite the fact
I enjoy being first on the list, I think Bitcoin-Qt should still go first.
 It is the reference client, and I think it's relevant that it is the
de-facto client for the majority of users, and the one with the most
quality control and stability.

-Alan


On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki zgen...@yahoo.com wrote:

 Check it :) https://github.com/bitcoin/bitcoin.org/pull/34


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-04-30 Thread Alan Reiner
Actually I was looking at a screenshot someone sent me because I couldn't
seem to access it even after changing the hosts file (I assumed it was
recent, but I guess not).  It just looked like the regular Bitcoin page
(despite doing a ping on the command line and seeing the expected IP).  Was
there a specific link to click on?Am I blind?

Is there a process we should use to submit how we think our program should
be represented on the clients page?

-Alan


On Mon, Apr 30, 2012 at 2:31 PM, Amir Taaki zgen...@yahoo.com wrote:

 Are we looking at the same list? Because here is the order I added:
 Bitcoin-Qt, Armory, Electrum and MultiBit. Maybe try CTRL-F5 to force a
 refresh of your browser.

 Also about the descriptions: yeah I know. I think it's better to put this
 up first and then have everyone submit their own descriptions and
 screenshots. Otherwise it'll be a nightmare to coordinate until everything
 is perfect. I did message you on IRC today but maybe you were offline.

 I didn't copy paste the Armory description from the website because it
 really sounds too spammy like a sales pitch. Here I was trying to give an
 even handed balanced overview of all the clients. 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 
 bitcoin-development@lists.sourceforge.net
 Sent: Monday, April 30, 2012 7:23 PM
 Subject: Re: [Bitcoin-development] new bitcoin.org clients page


 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 feature of the Armory.  And backups should say
 something like One-time Printable if it fits within the box.

 Otherwise, I really like the layout and design.  Although despite the fact
 I enjoy being first on the list, I think Bitcoin-Qt should still go first.
  It is the reference client, and I think it's relevant that it is the
 de-facto client for the majority of users, and the one with the most
 quality control and stability.

 -Alan



 On Mon, Apr 30, 2012 at 1:50 PM, Amir Taaki zgen...@yahoo.com wrote:

 Check it :) https://github.com/bitcoin/bitcoin.org/pull/34
 

 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


 --
 Live Security Virtual Conference
 Exclusive live event will cover all the ways today's security and
 threat landscape has changed and how IT managers can respond. Discussions
 will include endpoint security, mobile security and the latest in malware
 threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 is
that part of the spec unimplemented or deprecated right now?

My understanding is it's completely disabled.


Went on a scavenger hunt with Gavin a couple weeks concerning tx 
replacement.  The conclusion was that if,

(1) Transaction has lock-time in the future  AND
(2) Transaction has non-maximum sequence number

Then the transaction will both propagate and be accepted into nodes' 
memory pools, but will not go into any block until locktime expires.  If 
the lock-time is in the past OR sequence number on all TxIns is 
0x, then it will be immediately valid and included in the 
blockchain.


But the actual replacement mechanism is disabled.  Therefore, the 
nodes accept the tx as if it's replaceable, but don't allow it to be 
replaced.  This means that it is effectively replaceable *once*, but 
only if you inject a final transaction into the blockchain.   You can't 
broadcast a final version of the same tx, because it will conflict with 
the non-final one sitting in all the other nodes' memory pools.  You 
need a miner to agree to remove the non-final tx from their memory pool 
and specifically include your replacement.


-Alan


--
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and 
threat landscape has changed and how IT managers can respond. Discussions 
will include endpoint security, mobile security and the latest in malware 
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 send it using a combination of inputs and fees that I know will lead to
it being stuck and expire.

On the other hand, if such conditions are deterministic enough, it could be
detected by the recipient and flagged.

It's not a huge deal, but it's something to consider.

-Alan



On Thu, Apr 12, 2012 at 2:38 PM, Jeff Garzik jgar...@exmulti.com wrote:

 Not sure whether this rises to the level of a BIP or not, as it is
 largely an implementation change.

 One of my From-Day-One complaints about bitcoin is that transactions
 behavior could be far more deterministic (predictable), from a user
 standpoint.  Transactions in the current system can easily remain in
 limbo forever.

 One big step in making transactions behave more predictably would be
 to remove transactions from the memory pool, if they have not made it
 into a block for a couple days.  i.e.

 1.  N = 1 or 2 or whatever the community prefers.  Ideally enough time
 for a third-tier miner, mining strange TXs, finds a block.
 2.  H1 = height of block chain, when a TX is received
 3.  H2 = H1 + (144 * N)
 4.  If block chain height reaches H2, and TX has not made it into a
 block, drop TX from memory pool

 Although this only impacts a small amount of TX's ultimately, what it
 does do is give us the ability -- once miners have upgraded to this
 rule -- to tell bitcoin users that their transactions expire after N
 days.

 Backwards compatibility should not be an issue; clients are free to
 retransmit their TX at any time, as usual, thereby resetting the
 clock for all peers who have forgotten the TX in question.

 Once in place, clients may then implement code that notices a TX has
 expired (read: likely to have been forgotten by the network, assuming
 they themselves have stopped retransmitting it).  Then you can start
 working on wallet/coin recovery, perhaps resending with a higher fee
 etc.

 The above change is not really fill-or-kill but it should be a big
 step, opening the door to deterministic TX behavior.

 --
 Jeff Garzik
 exMULTI, Inc.
 jgar...@exmulti.com


 --
 For Developers, A Lot Can Happen In A Second.
 Boundary is the first to Know...and Tell You.
 Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
 http://p.sf.net/sfu/Boundary-d2dvs2
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
For Developers, A Lot Can Happen In A Second.
Boundary is the first to Know...and Tell You.
Monitor Your Applications in Ultra-Fine Resolution. Try it FREE!
http://p.sf.net/sfu/Boundary-d2dvs2___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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 appropriate sign a message standard we
 could/should use?

 You're glossing over little details like what character encoding is
 used for the message, but I'd rather leverage all the work already
 done by the IETF to nail down all those little details rather then
 re-discover them and come up with our own solutions.

I'm glossing over details because I actually have no experience dealing 
with character encodings,  or the implementation specifics of existing 
solutions (PGP or S/MIME).   That's why I'm emailing this list: I want 
to figure this stuff out, and at the same time try to converge on 
something that is efficient and can be interoperable between Armory and 
the Satoshi client (wallets, signature collection, sig blocks).

I don't go into these things solely to reinvent stuff.  My primary 
motivation for both ideas I have pitched so far (BIP 0010 and the sig 
blocks) is the versatility.  I like the encoding-independent, visual 
compactness of PGP ASCII-armored text blocks, but I don't like their 
opaqueness.  PGP vs my signature blocks basically look the same to a 
casual user, but even a moderately-knowledgeable user can appreciate the 
human-readable components of it.  You can visually identify if 
signatures are missing from sig-collection packet, or see that you 
signed with the wrong address without having to load an external program.

But that isn't a critical requirement, it's just my personal 
preference.  I'm fine with existing systems if it sidesteps a lot of 
problems and there's easy interface to it.But, I don't want to have 
another BSDDB-wallet situation where we end up with 10x more capability 
than we need, and pay for it with 10x the complexity (at least in this 
case, using PGP is an existing crypto/security-sensitive technology).  I 
have made simplicity one of my goals in Armory.

Alternatively, we could change the discussion to a requirements 
discussion, to first figure out what we need in order to address 
multi-signature collection, etc.  Then evaluate competing ideas based on 
their qualities relative to the requirements.




--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.
http://p.sf.net/sfu/Boundary-dev2dev
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[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 introduced message signing, but I've been fairly 
unimpressed with the implementation.  Strictly speaking, it works, but 
it's really not intended for regular users.  There is no indication of 
what message was signed or what address signed it.  Key recovery works 
for the computers processing it, but the user has no idea what this 
chunk of random data is.  They don't even know if the message they 
thought they signed is what's in the signature (along the lines of the 
copypaste virus, the message could be switched out without the user 
noticing).


I have implemented Signature Blocks 
https://bitcointalk.org/index.php?topic=56424.msg776163#msg776163 in 
Armory (as of v0.55), which is a fully-functional expansion on the 
idea.  Along the lines of BIP 10, a signature block is a human-readable 
chunk of data that immediately identifies the address and the message 
that are being signed.  It is easily copypasted via email or text 
files, and is fairly compact for visual identification.   Click the link 
above to see an example signature block and an Armory screenshot of the 
UI (which needs improvement, but still usable).  The verification 
process will include:


-- Check that the public key (included or recovered) matches the address 
field.
-- Verify that the signature matches the included message for this 
public key
-- The message is properly formatted with a standardized character set 
and escape/replacement scheme for things like newlines or double-quotes.


gmaxwell already pointed out that key recovery makes the Public Key 
field pointless.  Okay fine -- I just don't have key recovery 
implemented yet in Armory, and when I do I can ditch that field (or 
simply make it optional).  The point is to create a versatile, 
human-readable standardized form, much like the BIP 0010 
signature-collection scheme https://en.bitcoin.it/wiki/BIP_0010.



_*(2) Sign-Message URI scheme***-- Request signed messages from users 
using URIs_


I had the idea that for certain services, the first funding address 
could be used to identify the owner of an account, and all account 
maintenance (such as cashouts) be done through signed messages with this 
address.  For instance, the user would need both a login password *and* 
a signed message in order to make a withdrawal or purchase:


(Please withdraw 12.3 BTC from acct 1828349132 to address 
1Hfr3jk2093f)_signed_by_A


This gives the service the ability to use two separate factors to 
authenticate the request (usernamepassword *and* access to unencrypted 
wallet).  This /could/ work with manual signature blocks alone... but 
it's too many steps for regular users.  However, I think it's workable 
if we expand bitcoin URIs to include Signature Requests.


The URI scheme would add a few parameters to the scheme, and would have 
to have further replacement rules to make sure that messages are handled 
properly.   The general CONOPs would be (*Con*cept of *Op*eration*s*):


-- User navigates to Withdraw funds on webpage
-- Webpage has you fill in the details:  from-account, to-address, 
withdrawal amount
-- Webpage produces a clickable URI link that loads all the 
information into your client, including addr-reqd-for-sig
-- Client asks for confirmation and passphrase (if necessary) then 
produces a signature (and sig block if necessary)
-- URI may include reply-to field that tells it where to send the 
siganture when it's ready


So the extra tags that would be needed would probably be:

*requestSig*=True:
Flag to identify that this is a signing request URI
*sigNeeded*=1Qjf3392k31h
The address that needs to sign the message

*message*=Please%20withdraw%2012.3%20BTC%20to%20addr%201Hfr3jk2093f
Some encoding of the message that can be parsed the 
same way on all systems

*replyurl*=http://requestor.com/sig_replies.asp?;
(Optional) After signing, application will submit the 
signature to the replyurl


The reply url could be simply an http URL which will use bitcoin URI 
syntax, with the fields above copied.  Therefore, to complete the above 
request, the application handling the request will simply send an HTTP 
request to:



http://requestor.com/sig_replies.asp?*sigNeeded*=1Qjf3392k31h*message*=...*signature*=1fb1893ac193...*replySig*=True


Any thoughts?  (I have no doubts that there are :) )

-Alan





--
Better than sec? Nothing is better than sec when it comes to
monitoring Big Data applications. Try Boundary one-second 
resolution app monitoring today. Free.

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 relevant to Bitcoin and the community around it.


On the other hand, Bitcoin is still a non-entity, and shouldn't get in 
the business of making statements.  A central voice for Bitcoin gives 
the impression that it is actually centralized, and one that has 
opinions.  Plus I wouldn't be surprised if some, heavily-invested 
Bitcoin users were of the opinion that SOPA/PIPA/whatever could be a 
huge profit for themselves:  once SOPA kicks in and businesses around 
the world start getting cut off for legit or illegitimate purposes, a 
lot of them could potentially switch to Bitcoin to keep their business 
going.  That could be a huge boon for Bitcoin.  You may not agree it's 
worth the tradeoff, but people are selfish and may not actually 
understand or even care about SOPA legislation itself.


I think it's /not inappropriate/ for something to be mentioned on the 
website about Bitcoin's philosophy being threatened by SOPA, but I agree 
Bitcoin should avoid making any bold political stands.  Users could be 
reminded that SOPA affects yet another thing they care about, but it 
might be better to avoid it altogether.  If any response is made, it 
should be a very light one.


-Alan


On 01/16/2012 07:30 PM, Amir Taaki wrote:

Bunk argument. This is an issue that affects bitcoin directly.

Wikipedia has far more need to remain neutral and apolitical than bitcoin ever 
does- you've read Satoshi's politically charged whitepaper or seen the genesis 
block quote.

http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action

The Wikipedia community decided on a full and global blackout. Bitcoin should 
do the same in unison with the rest of the web- sites like Reddit, 4chan and 
Wikipedia.

It's funny / almost comical how you consign this to being just another issue or 
case of moral alarm. Sad.



- Original Message -
From: Jeff Garzikjgar...@exmulti.com
To: Amir Taakizgen...@yahoo.com
Cc: 
bitcoin-development@lists.sourceforge.netbitcoin-development@lists.sourceforge.net
Sent: Sunday, January 15, 2012 10:37 PM
Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

On Sun, Jan 15, 2012 at 5:09 PM, Amir Taakizgen...@yahoo.com  wrote:

How is this not the most important world issue right now?

EVERYTHING is under threat. Go nuclear to show our nerd-rage.

Everybody blank your personal sites too. Americans, take to the streets. World, 
go scream at the US embassy.


There are always issues that raise ire and moral outrage.  I would
rather that bitcoin.org stay apolitical -- our users will appreciate
this in the long run.



--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Alternative to OP_EVAL

2011-12-29 Thread Alan Reiner
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 nodes on the network.
 I cannot tell from my position if there is/has been consistent concern for
OP_EVAL proposal, or if it's mostly a transient response to hearing about
recursion in the scripting engine, etc (like myself, originally).  I
haven't debated this topic much, so I'm not in a position to personally
comment on any proposals.  (Though, this all feels very similar to the
problem of hash-table collisions in HTTP
POSThttp://www.securityweek.com/hash-table-collision-attacks-could-trigger-ddos-massive-scale
).

However, I would like to remind everyone that we/you are messing with a
$20+ million dollar *thing*.  There's more than just a piece of software at
stake -- whatever goes in needs to be as hard as diamond.  If we open up a
hole that allows someone to satisfy arbitrary scripts, or create one-packet
DoS/crash attacks, that could be devastating for Bitcoin.  Roconner is
persuasive enough to make *me* think that not all corners of this
functional space has been explored properly.  And while my opinion doesn't
matter, I'm concerned that others may feel too invested in the current
design path to want to go backwards.  Again, I don't know one way or
another, I just want to warn against pride getting priority over security.


At the very least, you should consider consequences and recovery path of
such unanticipated problems.  If the things that could go wrong are
devastating, let's lean towards a more conservative solution (like
sandboxing the sub-scripting engine).   Remember, the network is working
just fine *without *OP_EVAL, and while OP_EVAL provides some really nice
benefits, I don't think the benefits over regular multi-sig are worth the
consequences of making a mistake in this multi-million dollar beast.

Okay, back to your regularly-scheduled debating...
-Alan

On Thu, Dec 29, 2011 at 2:08 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 On Thu, Dec 29, 2011 at 01:55:03AM -0500, rocon...@theorem.ca wrote:
  Gavin asked me to come up with an alternative to OP_EVAL, so here is my
  proposal.
 
  OP_CODEHASH Initial Proposal

 If we're again brainstorming about alternatives for OP_EVAL, I'll do my
 own.

 It is called OP_CHECKEDEVAL, and is specified as follows:
 * It looks at the two elements most recently (in code position) pushed by
 a literal,
  and not yet consumed by another OP_CHECKEDEVAL. These are S (the
 serialized script),
  and H (its hash). This implies it defines its own literal-only stack,
 where all
  literals push to, and only OP_CHECKEDEVAL pops from. This special stack
 has the
  advantage of allowing static analysis - one does not need to execute any
 operations
  to find out which data will end up on it. Note that skipped code
 (inside the
  ignored part of an IF-THEN-ELSE) can still push to the literal stack.
 * For the outer script, it does not have any effect at all, except for:
  * 2 elements popped from the literal-only stack
  * potentially causing failure
  It does not touch the main stack, alt stack or any other part of the
 execution state
  not listed above.
 * Failure is caused when either of these conditions hold:
  * No two elements remain on the literal-only stack
  * The Hash(S) != H
  * The inner script execution caused failure
 * For the execution of the inner script:
  * It is executed in a completely new and independent execution
 environnement
  * It executes the deserialized S
  * It inherits the main stack and alt stack (without the serialized script
 and the hash
themselves) from the outer execution.

 This requires OP_CHECKEDEVAL to immediately follow the push of script and
 hash,
 so the code in the pair  script OP_CHECKEDEVAL  can be parsed and
 interpreted as code,
 allowing static analysis.

 As OP_CHECKEDEVAL has absolutely no effects except for potentially causing
 failure, it
 is very similar to the OP_NOPx it would replace, and guarantees that
 interpreting
 OP_CHECKEDEVAL as OP_NOPx can never cause the script to become invalid if
 it wasn't
 already.

 A basic pay-to-script-hash scriptPubKey is very short:

  scriptHash OP_CHECKEDEVAL

 And it is redeemed using:

  script inputs script

 Furthermore, the implementation is very similar to what was already done
 for
 OP_EVAL. Modifications:
 * EvalScriptInner needs less by-ref arguments, as it cannot modify the
 parent's state.
 * A literal-only stack needs to be maintained.


 I believe this combines all advantages:
 * Easy spend-to-script-hash (shorter than OP_EVAL)
 * Backward compatible (guaranteed by construction, instead of separately
 enforced like with OP_EVAL)
 * Statically analyzable (though it requires deserializing the script data).
 * Possibility to introduce a new language inside (not 

  1   2   >