Re: [Bitcoin-development] Block Size Increase

[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"  wrote:

>
>
> On Fri, May 8, 2015 at 2:59 PM, Alan Reiner  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  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 

Re: [Bitcoin-development] Block Size Increase

[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

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

[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

[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
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 transa

Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

[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

[Alan Reiner]

On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner  wrote:
>> Unfortunately, it seems that there was no soft-fork way to achieve this
>> benefit, at least not one that had favorable properties.  Most of the
>> soft-fork 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] SIGHASH_WITHINPUTVALUE

[Alan Reiner]

On 01/23/2015 11:05 AM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 3:24 PM, Alan Reiner  wrote:
>> Unfortunately, it seems that there was no soft-fork way to achieve this
>> benefit, at least not one that had favorable properties.  Most of the
>> soft-fork 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

[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

[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] BIP70: why Google Protocol Buffers for encoding?

[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

[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  > wrote:
>
> > On Thu, Jan 15, 2015 at 1:17 AM, Matt Whitlock
> 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  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 
> > Web:www.blocktrail.com
> > 
> > Github: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

[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=157005751&iu=/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

[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  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=154622311&iu=/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=154622311&iu=/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

[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=154622311&iu=/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')

[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=160591471&iu=/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

[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
 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  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=154622311&iu=/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=154622311&iu=/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

[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"  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 
>> 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 
>> 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-
>&g

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

[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=154622311&iu=/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

[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=154622311&iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development

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

[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 proper

Re: [Bitcoin-development] ASIC-proof mining

[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] ASIC-proof mining

[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] Bloom bait

[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

[Alan Reiner]

On 05/24/2014 08:14 PM, Gregory Maxwell wrote:
> On Sat, May 24, 2014 at 5:04 PM, Alan Reiner  wrote:
>> I think the most important change is modifying the way Bitcoin Core
>> prioritizes blocks.  Right now it uses the first full block verified.
>> Instead, it should 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] Cut-through propagation of blocks

[Alan Reiner]

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

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

[Alan Reiner]

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

My plan is to have a popup on the first load of the new version that
briefly introduces the change, and mentions that they can go back to the
old way in the settings, but make them work to do it.  For the transient
period (6 months?) all input boxes will auto-update nearby labels with
the converted-to-BTC value as they type, so that they don't have to do
any math in their head.  Similarly, all displayed BTC values will show
both.  But the 1e-6 unit will always be default or first unless they
explicitly change it in the interface.




On 5/2/2014 8:54 PM, Ben Davenport wrote:
> I fully support this (it's what I suggested over a year ago), but what
> it comes down to is BitPay, Coinbase, Blockchain and Bitstamp getting
> together, agreeing what they're going to use, and doing a little joint
> customer education campaign around it. If there's community momentum
> around "bits", great.
>
> My only addition is that I think we should all stop trying to attach
> SI prefixes to the currency unit. Name me another world currency that
> uses SI prefixes. No one quotes amounts as 63 k$ or 3 M$. The accepted
> standard at least in the US is ,
> i.e. $63k or $3M. That may not be accepted form everywhere, but in any
> case it's an informal format, not a formal one. The important point is
> there should be one base unit that is not modified with SI prefixes.
> And I think the arguments are strong for that unit being = 100 satoshi.
>
> Ben
>
>
>
>
> On Fri, May 2, 2014 at 12:17 PM, Jeff Garzik  > wrote:
>
> 
>
> Related:
> 
> http://blog.bitpay.com/2014/05/02/bitpay-bitcoin-and-where-to-put-that-decimal-point.html
>
> --
> Jeff Garzik
> Bitcoin core developer and open source evangelist
> BitPay, Inc.  https://bitpay.com/
>
> 
> --
> "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
>
>
>
>
> --
> "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

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

[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

[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
> , 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
> , 2
> , 3
> , 4
> , 5
> ). 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/ : 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
> .
> 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, 

Re: [Bitcoin-development] Economics of information propagation

[Alan Reiner]

On 04/21/2014 11:40 AM, Ashley Holman wrote:
> On Mon, Apr 21, 2014 at 1:36 PM, Peter Todd  > wrote:
>
> That is mistaken: you can't mine on top of just a block header,
> leaving small miners disadvantaged as they are earning no profit
> while they wait for 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

[Alan Reiner]

Btw, I should clarify my email: I'm a staunch supporter of moving to
1e-6 BTC as the default unit for wallet applications, not necessarily
any particular name.  I would be fine with "bits" as I think this
context is sufficiently different that it won't be confused by regular
consumers.  But it wouldn't be my first choice.  I don't know what my
first choice would be.

While writing this email, I asked my wife (who's been tired of hearing
about Bitcoin for two years), what she thinks of "bits", "microbes",
"micros".  She said she is fine with any of them.  Apparently microbes
reminders her of biology, not "germs".  But she's also well-educated, so
she fine with milli, micro, kilo, etc... and apparently biology...

Whatever we call it. I'm happy to support it as long as it's 1e-6.


On 04/20/2014 12:23 PM, Erik Garrison wrote:
>
> The world is rapidly becoming a place in which a solid grasp of orders
> of magnitude could be considered a basic mathematical skill.  People
> are very likely to learn what mBTC and µBTC are simply because they
> risk their money if they do not.  This is not a bad thing and I think
> stands only to help people who learn about these monikers for orders
> of magnitude this way.
>
> Any appropriate nicknames for these denominations is sure to develop
> in due course.  Promoting an already-overloaded term that could just
> as easily be applied colloquially to refer to a small amount of value
> in any currency seems problematic.
>
> 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 > <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
>>> 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 im

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

[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  <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 > <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  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 sa

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

[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  <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] Presenting a BIP for Shamir's Secret Sharing of Bitcoin private keys

[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

[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

[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] New BIP32 structure

[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

--
___
Bitc

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

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

[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 
> 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 
>
> 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] moving the default display to mbtc

[Alan Reiner]

On 03/13/2014 01:24 PM, Mike Hearn wrote:
>
> Using milli- and micro- notation for currency units is also not very
> well supported. Last time this thread was active, I believe there
> was a
> suggestion to use 1 XBT == 1 uBTC.
>
>
> Unfortunately I think some people already started using XBT to mean
> the same as BTC (another ship that sailed: somehow Bhutan will have to
> live with it). So if some software started to redefine it to mean
> something else, that seems like a recipe for accidentally sending far
> too much or too little money by mistake.
>

There is also the benefit that if someone screws up BTC and uBTC, it's
likely to fail.  Most people don't have 1e6 times as much money in their
wallet as they attempted to send in a single transaction.  Similarly,
sending one-millionth of what you meant to is likely invalid or below
the dust limit. 

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

[Alan Reiner]

On 03/13/2014 10:32 AM, Jeff Garzik wrote:
> On Thu, Mar 13, 2014 at 9:53 AM, Mike Hearn  wrote:
>> BitPay should use mBTC as well. Unless you can point to any major wallets,
>> exchanges or price watching sites that use uBTC by default?
>>
>> I think it is highly optimistic to assume we'll need 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] Multisign payment protocol?

[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?

[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 >> <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@li

Re: [Bitcoin-development] Multisign payment protocol?

[Alan Reiner]

Then of course I tried to do this with BIP 10 
 when
Armory implemented offline-transactions two years ago.  I got some
positive feedback, but no one wanted to help improve it, etc.  I guess
nobody else was doing it and/or cared at the 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  > 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  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
> 
> 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 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] Is this a safe thing to be doing with ECC addition? (Oracle protocol)

[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 > <mailto:etothe...@gmail.com>> wrote:
>>  
>>
>> I create a new keypair,  with  which I know (it
>> can be any arbitrary key pair).  But I don't give you , I
>> give you   =  minus  (which I can do because
>> I've seen  before doing this). 
>>
>> Sure, I don't know the private key for , but it doesn't
>> matter... because what
>>
>>  +  =  (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=122218951&iu=/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=122218951&iu=/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=122218951&iu=/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)

[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  <mailto:etothe...@gmail.com>> wrote:
>  
>
> I create a new keypair,  with  which I know (it can
> be any arbitrary key pair).  But I don't give you , I give
> you   =  minus  (which I can do because I've
> seen  before doing this). 
>
> Sure, I don't know the private key for , but it doesn't
> matter... because what
>
>  +  =  (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=122218951&iu=/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=122218951&iu=/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)

[Alan Reiner]

On 03/08/2014 01:55 AM, Edmund Edgar wrote:
> On 4 March 2014 14:07, Odinn Cyberguerrilla
>  > wrote:
>
> Nothing is safe.
>
>
> This is true. To rephrase, imagine I gave you an ECC public key
> , you gave me back a public key  of your own
> devising, then I paid some money to the address resulting from
> add_pubkeys(,) [1]. Can anyone either:
>
> a) Think of a way that Odinn could make an  such that they
> could spend the resulting money without having .
> b) Opine, somewhat knowledgeably, that this probably wouldn't be an
> easy thing to do, and they wouldn't be alarmed to see people running
> software that did this kind of thing.
>
> [1] 
> https://github.com/vbuterin/pybitcointools/blob/master/pybitcointools/main.py#L173

Consider that I see your public key  before I create and send you
my public key .

I create a new keypair,  with  which I know (it can be
any arbitrary key pair).  But I don't give you , I give you 
 =  minus  (which I can do because I've seen
 before doing this). 

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

 +  =  (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)

-Alan
--
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=122218951&iu=/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

[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"  wrote:

On Wed, Feb 12, 2014 at 7:12 AM, Rune Kjær Svendsen 
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  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=124407151&iu=/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=124407151&iu=/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

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

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

[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"  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  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=121051231&iu=/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

Re: [Bitcoin-development] Stealth Addresses

[Alan Reiner]

*Avoiding ECDH calcs on every blockchain transaction (and avoiding the
prefix thing):*

Can we skip the whole ECDSA/ECDH thing, and use the second key pair for
encryption instead?  Then we don't need any ephemeral keys.  We use the
much simpler scheme like I mentioned before (just root keys and
multpliers), but instead of requesting a multiplier from the person
receiving the money, the payer can create their own multiplier and
encrypt it into an OP_RETURN msg (using the secondary public key of the
receiver).  When they do this, they append a deterministic identifier to
it, so that the receiver can immediately identify it upon decryption.

Basically, the receiver simply attempts decryption of every OP_RETURN
message, and if the identifier is there, they immediately know that the
tx is theirs, and that the other bytes of the decrypted message is the
multiplier used.

Of course, using something like ECIES and forcing the receiver to
attempt decryption of every OP_RETURN tx may not be any faster than the
ECDH we've already talked about here.  But with this, we are not tied to
any particular crypto.  Isn't there a much faster asymmetric scheme that
we can use?  I've heard people talk about ed25519, though I'm not sure
it can be used for encryption.  I'd bet money there is an asymmetric
_/encryption/_//algorithm that would be fast enough to not burden the
receiver.

Here's how I envision it:

--Alice gives out her business card that has public key X (BIP32 root),
and public key Y (fastCrypto)
--Bob generates a random 32-byte nonce, and EC-multiplies Alice's public
key by it.   He prepares a transaction sending coins to that address (Z)
--Bob also computes a deterministic identifier, perhaps hash(pubKeyX ||
addrZ)[8:].  Bob appends the those 8 bytes to the multiplier, and
encrypts all of it with Alice's fastCrypto key, Y.   He puts that
message in the OP_RETURN output.
--Alice's wallet will attempt decryption of every OP_RETURN message. 
First she computes hash(pubKeyX, addrZ)[8:], and then decrypts the
message with the fastCrypto private key.  If the tx is actually hers,
the last 8 bytes will match the identifier, and she knows to use the
other 32 bytes as a multiplier.  If it doesn't, it's irrelevant to her
and she moves on.

[**Should probably use 24-byte values for the multipliers (or hashes of
24-byte values), so that adding 8 bytes makes the whole message an even
32 bytes which is better for encryption]

Doesn't this have the exact same properties as the original proposal
(including compatibility with CoinJoin)?  But it all depends on having
fast asymmetric encryption.

-Alan



--
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=119420431&iu=/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

[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=119420431&iu=/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

[Alan Reiner]

On 01/13/2014 03:14 PM, Peter Todd wrote:
> On Mon, Jan 13, 2014 at 02:59:08PM -0500, Alan Reiner wrote:
>> How is this different from the proposal I have made?
>>
>> You distribute the root public key (but not chaincode!) of a BIP32
>> branch.  You can put your root key on a business card if you want.  Then
>> when someone wants to pay you, you simply give them the multiplier and
>> root key (they already have the root key, but should verify).  The
>> multiplier does not reveal the chaincode, thus keeping it private, but
>> it does allow them to confirm that the final address they are paying is
>> derived from that root key they know belongs to you ("Please pay address
>> X; oh btw, X=rootKey*mult").
>>
>> You can /choose/ to reveal that a given payment address is linked to
>> your root key without any compromise of privacy.  Or you can choose to
>> ignore it and just give them a bare address the old way and still
>> maintain privacy.  What advantages does "stealth addresses" have over
>> this scheme?  You could extend it using some kind of deterministic
>> sub-branching and/or ECDH to create multiple payment addresses without
>> querying the payee.
>
> Basically stealth addresses *are* your scheme, using the blockchain as a
> low or even no overhead communication channel for the payor to give the
> payee that multiplier without bidirectional communication.
>
> In the business card example I can't easily take your business card and
> just send you some money without that transaction being linked to public
> information. (your business card)

It's not public.  When I say "please pay me" I also say "use this
multiplier".  The multiplier isn't published, and it's not publicly
discoverable without my wallet (or access to my email).  The address
remains private between you and me.  As you said, it could be
discoverable if the email is discoverable, but I'm not seeing how how
critical that really is.

There's a lot of complexity around this constraint (possibly involving
new/secondary private keys, extra outputs, relying on change outputs,
and/or using 3rd parties to help look for transactions).  I'm not
convinced that what is being gained is really worth that extra complexity.

By contrast, what I proposed, that does require sending sending the
payer a multiplier once, is easy to implement in any BIP 32 wallet,
doesn't require any special address formats, and achieves 98% of the
same benefits without any special computation.   I guess I'm just not
convinced that it's really necessary for people to be able to send
others payments without contacting them (and/or hiding the evidence a
payment was made even if they communications were discovered).

-Alan



--
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=119420431&iu=/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

[Alan Reiner]

How is this different from the proposal I have made?

You distribute the root public key (but not chaincode!) of a BIP32
branch.  You can put your root key on a business card if you want.  Then
when someone wants to pay you, you simply give them the multiplier and
root key (they already have the root key, but should verify).  The
multiplier does not reveal the chaincode, thus keeping it private, but
it does allow them to confirm that the final address they are paying is
derived from that root key they know belongs to you ("Please pay address
X; oh btw, X=rootKey*mult").

You can /choose/ to reveal that a given payment address is linked to
your root key without any compromise of privacy.  Or you can choose to
ignore it and just give them a bare address the old way and still
maintain privacy.  What advantages does "stealth addresses" have over
this scheme?  You could extend it using some kind of deterministic
sub-branching and/or ECDH to create multiple payment addresses without
querying the payee. 

I had planned to implement this system and push for people to accept it
because I don't see any downsides to it.  It can easily be integrated
into a WoT (with signed root keys), or CA system piggybacking on SSL.

-Alan


On 01/13/2014 02:44 PM, Drak wrote:
> On 13 January 2014 19:40, Roy Badami  > wrote:
>
> At the moment, I can give them a business card with a Bitcoin address.
> Being able to give out a business card with a stealth address would be
> a major advance.
>
>
> My thoughts exactly.
>
> Drak 
>
>
> --
> 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=119420431&iu=/4140/ostg.clktrk
>
>
> ___
> Bitcoin-development mailing list
> Bitcoin-development@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
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=119420431&iu=/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

[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=63469471&iu=/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=63469471&iu=/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

[Alan Reiner]

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

I'd prefer them not be called "micro bitcoins."  I really want to call
them "microbes" ... but I'm not sure that has the right flavor for money
transfer :)  "Please give me 872 microbes".  Perhaps we just call them
"bits."  Or even "micros" or "microbits".  As I write this, I realize
there's probably 872 threads on the forums about this already...

But we would want to promote a consistent term, to avoid further
confusion when people use different names for the new unit.  It's not
guaranteed to be successful, but if we pick a good name, and build it
into the interface on the first release pushing the new unit, we have a
chance to make the transition even easier.





On 11/14/2013 05:31 PM, Mark Friedenbach wrote:
> Whoops, this was meant for the list:
>
> Drawing on analogues from national currencies, it's also possible to
> alleviate the confusion by switching currency symbols, e.g. to XBT or
> NBC (New Bitcoin).
>
> 1 XBC == 1 uBTC
>
> On 11/14/13 2:03 PM, Jeff Garzik wrote:
> > Go straight to uBTC. Humans and existing computer systems handle
> > numbers to the left of the decimals just fine (HK Dollars, Yen).
> > The opposite is untrue (QuickBooks really does not like 3+ decimal
> > places).
>
> > - Jeff
>
> > On Nov 14, 2013 4:40 PM, "Mark Friedenbach"  > > 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
>
>
--
> 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=63469471&iu=/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=63469471&iu=/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

[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 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=63469471&iu=/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=63469471&iu=/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=63469471&iu=/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

[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=63469471&iu=/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=63469471&iu=/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

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

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

[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 >> <mailto:a...@cypherspace.org>> wrote:
>>>
>>> Is there a way to exp

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

[Alan Reiner]

That's fine.  I just want to make sure it's considered for inclusion at
some point, because I really hope to leverage the "identity" mechanism I
just described, and it's much easier if it's part of a standard instead
of convincing others to go around the standard with us.

I have not spent much time looking at the payment protocol itself.  I
didn't feel like I'd have much to contribute (besides requesting a
feature I know isn't there).  I was planning to wait until it was
complete before fully grokking and implementing it in Armory.


On 08/09/2013 03:58 PM, Mike Hearn wrote:
> Payment protocol is locked down for v1 already. But did you read it?
> It doesn't use addresses anywhere. Payments are specified in terms of
> a list of outputs which can contain any script. Of course it could be
> a pay-to-address script, but pay-to-address uses more bytes in the
> chain and there isn't any typeability benefit.
>
> The multiplication trick for deterministic keys is a nice one and
> worth doing, but it has to be a v2 feature by this point. It's more
> important to get v1 widely implemented and deployed first.
>
>
> On Fri, Aug 9, 2013 at 7:57 PM, Alan Reiner  <mailto:etothe...@gmail.com>> wrote:
>
> 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

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

[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 pubkey&

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

[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=48897031&iu=/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

[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=49501711&iu=/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=49501711&iu=/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=49501711&iu=/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

[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  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=49501711&iu=/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

[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=49501711&iu=/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=49501711&iu=/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

[Alan Reiner]

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 pubkey&chaincode 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 it wrong?  Meh...

Just as one final swipe at this idea, you can see that I gotta do quite
a bit of work to support the multi-chain idea, and adds a little extra
burden on the user to maintain the organization of the wallet.  This
would all be totally unnecessary with a simple alternate encoding. 
Granted, I think the multi-chain idea is good, and one that I will
probably implement anyway, but it seems like overkill in terms of
developer complexity, and interface complexity to achieve something much
simpler.  Developers of much simpler/lightweight clients would probably
find this prohibitive.

On another note:  I thought we weren't encouraging automatic payments
without requesting from the other party...?  It makes me uneasy, but it
sounds like group thought has converged on that being acceptable.  I
bring it up, because there are situations where it makes sense, but it
sounds unsafe for general users.   Alice will give Bob his own chain for
sending Alice money, then a year later Bob will send money automatically
to Alice not realizing that the wallet was lost, retired or
compromised.  It's not that Bob can't ask for a new address, it's that
if the interface says "Send Money to Alice", that looks legit enough
that Bob may not feel it necessary to check with Alice first.   That's
more of an interface issue though.  We can add a warning to "check with
the recipient that they still have access to wallet 3cQ398x", etc.   But
I just know someone is going to lose money anyway...

-Alan





On 06/20/2013 03:32 AM, Mike Hearn wrote:
> Agree with Jeremy and once the payment protocol work is further along
> I'd like to see us define an extension that lets you send payment
> requests containing public keys+chain codes, so further payments can
> be made push-style with no recipient interaction (e.g. for repeated
> billing). How apps choose to arrange their chains internally seems
> like an area for experimentation. I definitely want to implement HD
> wallets in bitcoinj to allow this and if that means not using the same
> tree structure as in the BIP then so be it.
>
>
> On Thu, Jun 20, 2013 at 5:54 AM, Jeremy Spilman  > wrote:
>
> > 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.
>
> Initially I was thinking that you would share the public key and
> chain code
> from [m/i'/0] so that you can receive payments at [m/i'/0/k], for
> a unique
> value of 'i' for each receive chain.
>
> For the case of generating new receive chains from a *watch-only*
> wallet, as
> you say, the options are to either keep a cache of
> PubKey/ChainCode for
> unused [m/i'] or simply increment 'j' past 1 for an existing
> [m/i'/j] -- the
> concept of 'internal/'external' and change addresses at Depth=2
> don't make
> sense for handing out receive chains to lots of people anyway, and
> certainly
> BI

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

[Alan Reiner]

On 06/20/2013 05:10 AM, Jeremy Spilman wrote:
>> which could involve proving something to a third party that has not seen 
>> the communication between payer and payee.
> OK - I think I follow now.  So a third-party who does not see any of the 
> communication between the payer and payee only knows the HASH160.  Let's say 
> the payee denies receipt of the funds
>
> It's easy to prove what public key it was sent to (it's the preimage), but 
> you can't prove the parent of that public key. You can provide any number of 
> ParentPubKey * Multiplier that could have been used, so the 3rd party is 
> unconvinced by a "matching" ParentPubKey * Multiplier.
>
> However, if you calculated the destination using: PubKeyParent * 
> HMAC(Multiplier,PubKeyParent) as Timo said, now if you give the 3rd party a 
> PubKeyParent and Multiplier (or Addend) that produces the destination 
> address, you've proven the payment is in fact spendable by PubKeyParent, and 
> they can't deny receipt. Very cool.
>
> Sorry for "echoing" this back, it took me a little while to work it out, so 
> I thought I'd write it down. Hope I got it right...
>
> If you give {PubKey, ChainCode} you do get this feature. If you give 
> {ParentPubKey, Addend} or {ParentPubKey, Addend, ChainCode} you're back to 
> having plausible deniability.
>
> If BIP32's CKD'((Kpar, cpar), i) was actually HMAC(HMAC(cpar, i), Kpar) you 
> could give HMAC(cpar, i) instead of Addend, and then you would get this 
> feature; a way to 'skip down' a level in the wallet hierarchy, keep the 
> 'chain of custody' so to speak back to the ParentPubKey intact, without 
> having to disclose the ChainCode. Meh...
>
>

I agree, if we used Timo's suggestion, that seems to clean up the
remaining uncertainties with this recommendation.   I'm not convinced
those uncertainties matter in this situation, where there is no question
about the parent public key.  That is the part of the process that was
already verified, per my previous examples.  But certainly, for this to
be more versatile it would need that. 

If I modify my request to match Timo's recommendation, then it loses the
benefit of being a simple, non-disruptive extension of BIP 32.   I'm not
fond of deviating from BIP 32, as it kind of defeats one of the benefits
of BIP 32:  standardization.   And I'm not inclined to make an
Armory-specific wallet variant.

But I can't tell if the benefits are lost on you, or you just don't
think they are worth it (or I'm overstating them).  I'm strongly opposed
to bring extra wallets/chains into this equation /*just*/ to get a
benefit that can be had with a simple alternative encoding.  This isn't
a question of which is better, it's a matter of recognizing that both
forms have usefulness and should both be supported. 

-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

[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

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

[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

[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

[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

[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

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

[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

[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 

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

[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  * /  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] is there a way to do bitcoin-staging?

[Alan Reiner]

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

Did anyone figure anything like that out?  Seems vaguely doable and
maybe productive.  The only people with coins at risk of defects
in a new
feature, or insufficiently well tested novel feature are people
with coins
on bitcoin-staging.

Yes I know about bitcoin-test this is not it.  I mean a real live
system,
with live value, but that is intentionally wanting to avoid
forking bitcoins
parameters, nor value, nor mindshare dillution.  In this way something
potentially interesting could move forward faster, and be les
risky to the
main bitcoin network.  eg particularly defenses against

It might also be a more real world test test (after bitcoin-test)
because
some parameters are different on test, and some issues may not
manifest
without more real activity.

Then also bitcoin could cherry pick interesting patches and merge
them after
extensive real-world validation with real-money at stake (by early
adopters).

Adam


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




--
Are you coming to Bitcoin2013 

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

[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 sign&broadcasting 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

[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

[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 - reactiva

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

[Alan Reiner]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On 04/14/2013 02:25 AM, Peter Todd wrote:
> On Sun, Apr 14, 2013 at 01:21:21AM -0400, Alan Reiner wrote:
>> If we're going to extend/expand message signing, can we please add a
>> proper ASCII-armored format for it?  Really, 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...:   ". 
>
> I already looked into ASCII-armoring PGP style for a different project.
> (timestamping) Basically you'd want to follow RFC2440, section 7
> "Cleartext signature framework":
>
> -BEGIN BTC SIGNED MESSAGE-
>
> Hello world!
> -BEGIN BTC SIGNATURE-
> IKBeCbxXHvD1TJh8ZlMySo26w5z6YZQD1xqKgbhsvlhEgcFD+kvKx4LzUz1yxg/8
> IdYdBnzez77VDq3odHrVftg=
> -END BTC SIGNATURE-
>
> Pretty simple really and doesn't need to be done prior to other
> signmessage changes. There may be an issue passing \r's through the RPC
> interface; the RFC specifies CRLF line endings.
>
Perfect.  That was the spec I was looking for but too lazy to find it. 
I guess I'll lead by example and just do it in Armory.  I'll let users
pressure the other devs to follow :)

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

iEYEARECAAYFAlFq9GIACgkQYdHIW5RKKv1A2gCeMfdttPylmPqPqemo0Q2uACEt
eAcAn21a7sYy+TNIinRR3SlVgm4VbJPh
=qGlo
-END PGP SIGNATURE-


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

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

[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...:   ".  

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>{, ...}
>
> 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

[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

[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

Re: [Bitcoin-development] Some PR preparation

[Alan Reiner]

On Tue, Mar 12, 2013 at 8:10 AM, Luke-Jr  wrote:

>
>
> I think we should be careful not to downplay the reality either.
> For a number of hours, transactions could have received up to N
> confirmations
> and then still been reversed. While we could contact the bigger payment
> processors, I saw 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

[Bitcoin-development] Some PR preparation

[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 positive&informed 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] Payment Protocol Proposal: Invoices/Payments/Receipts

[Alan Reiner]

On Thu, Dec 6, 2012 at 11:56 AM, Gavin Andresen wrote:

> When I say "pass around" I'm not thinking of users copying and pasting,
> that would be a terrible user experience; all of that communication needs
> to happen automatically behind the scenes. Lets tackle that after we've got
> the simpler 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

[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  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] Roadmap to getting users onto SPV clients

[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 working&robust
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  wrote:

> On Tue, Dec 4, 2012 at 3:58 PM, Mike Hearn  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 

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

[Alan Reiner]

My personal opinion is that the ideal first client has three features:

(1) Starts up and is usable within a couple minutes (even 10 min the first
time would be okay, to sync block headers)
(2) Supports Windows, Linux and OSX
(3) Uses deterministic wallets that can produce a permanent backup
(preferably paper)

Encryption is a major upside, too, but people new enough to Bitcoin that
they need such a simple client, can survive without encryption (thye're not
going to be holding a ton of coins) -- as long as they are made aware that
they do not currently have encryption, and the associated risks (and other
options).

I think it's extremely important that users have a clear way to backup
their coins to offline media or paper, in such a way that they don't ever
need to worry about it again.  Not only does it give users protection
against hard-drive loss, it means that they may find it again in the far
future when they haven't used Bitcoin in 2 years, and it reminds them that
they still have coins (and they don't have to type in 1000 private keys to
get their coins)

For that reason, I think Multibit is an excellent choice.  I haven't spent
much time with it, but I do understand it to  satisfy (1) and (2) clearly,
and (3) may be happening in the near future (along with encryption).  But I
do wonder if it has enough staffing behind it to be the center of attention
(no offense to jim618, but if this becomes the "de-facto" client for new
users, we should make sure there's a lot of people available to support it
-- what if a major security bug is found?  how long would it take the
current team to identify, fix and test that bug?)

-Alan


On Tue, Dec 4, 2012 at 12:46 PM, Mike Hearn  wrote:

> At the moment if you visit bitcoin.org then you're recommended to
> download the full client. I think we all agree that at some point we
> need to start presenting users with something more like this:
>
>
> To get started, download wallet apps A or B.
>
> If you'd like to contribute your computing resources to the Bitcoin
> network and have a fast computer with an unfiltered internet
> connection, download:
>
>- for desktop machines, Bitcoin-Qt
>- for servers, bitcoind
>
>
>
> Obviously not that exact wording.
>
> I personally feel it's a bit early for this, but it's true that users
> are being turned away by the fact that they're pointed to Bitcoin-Qt
> by default, so having some kind of roadmap or plan for changing that
> would be good.
>
> I think MultiBit is maturing into a client that I'd feel comfortable
> recommending to end users who take the fast-start path, though it
> still has a few serious lacks (encrypted wallets aren't released yet,
> bloom filters will help performance a lot, needs to catch up with some
> newer features). But there doesn't have to be a one true client.
>
> The alternative, I guess, is to make Bitcoin-Qt have an SPV mode. I'm
> not convinced this is the best use of time, but if somebody steps up
> to do it, that could also work. MultiBit has some unique features that
> are quite useful like integrating charting and exchange rate feeds.
>
> What does everyone think on this?
>
>
> --
> 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
>
--
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

[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  wrote:

> On Mon, Dec 3, 2012 at 10:30 AM, Mike Hearn  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] Chain dust mitigation: Demurrage based Chain Vacuuming

[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

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] BIP 35: add mempool message

[Alan Reiner]

On Thu, Aug 16, 2012 at 2:04 PM, Jeff Garzik  wrote:

> On Thu, Aug 16, 2012 at 1:56 PM, Pieter Wuille 
> wrote:
> > I suppose it is interesting in general for nodes to
> > get a memory pool refill at startup anyway.
>
> Yes.
>
> >>An "inv" message is always returned, even if empty.
> >
> > I'm 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

[Alan Reiner]

On 07/09/2012 10:36 PM, Stefan Thomas wrote:

It looks like that because feature matrices aren't especially helpful
for newbies to make a decision, especially when the "features" in
question were often things like how they handled the block chain or
which protocol standards they support, ie, things only of interest to
developers.

A well-designed feature matrix can quite useful and user-friendly.

http://www.apple.com/ipod/compare-ipod-models/

Prose is better to get a sense of the philosophy and basic idea of a
client. If it was between having only a feature matrix or only prose,
I'd probably go for the prose as well.

What a feature matrix is good at though is it allows you to very quickly
find the specific feature or general criteria you're looking for without
reading through all of the text. So it might be a useful addition maybe
not on Bitcoin.org, but certainly on the wiki.

If we're keeping the clients page, I would really like to see the 
feature matrix linked from that page.  It shouldn't be on that main 
clients page (for the reasons already stated), but Stefan makes a point 
that /it is really useful for many users./  Add "Compare features of the 
various different clients here: " and users who will benefit will 
most definitely click on it.  I think that's win-win.
--
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

[Alan Reiner]

I was originaly for the idea of randomization.  Because it is the most
"fair", but "fair" is a relative term.  It's fair for client developers who
argue over whose client should be first, and whose is better for various
purposes.   But it's not fair for users, to have an inconsistent page, that
sometimes recommends less-developed solutions, or doesn't show what's best *for
the users in the community*.

I think the premise of having a page that is "fair for developers" is its
downfall.  Once we agree things have to be fair, we must agree on what fair
means, and then we must accept 30 new recently-started projects that barely
squeak by the requirements for being on the page, despite having
substantial issues/bugs.  The premise of being fair is the downfall here.

This *has* to be a subjective list.   Someone who is trusted to understand
what is good for users, and who also has familiarity with the programs,
should be the one to decide.  People can try to provide input, and make
them aware of stuff they didn't know.  But it should be *that
person's*decision, and if it's not "fair" in your world, too bad.  At
least we won't
spend the next 3 years arguing on the mailing list about how to compare
programs that are all great in many different dimensions, and failing in
the others.

If it's going to go on the main page, give someone the responsibility to
come up with "what's best for the users of Bitcoin.org", however they
decide to interpret it, and save our breath arguing over more important
things.

-Alan



On Mon, Jul 9, 2012 at 2:57 PM, Gregory Maxwell  wrote:

> On Mon, Jul 9, 2012 at 2:54 PM, Jim  wrote:
> > RE: The position randomisation - I have to admit I was secretly pleased
> > with the original layout, as MultiBit just happened to have the "eye
> > candy" position of "top and centre".  It is only fair to have them
> > switch around.
>
> This ordering wasn't accidental.
>
>
> --
> 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] Random order for clients page

[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  wrote:

> On Mon, Jul 9, 2012 at 12:09 PM, Amir Taaki  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. http://www.accelacomm.com/jaw/sfrnl04242012/114/50

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

[Alan Reiner]

On 06/19/2012 02:18 PM, Mark Friedenbach wrote:
On Tue, Jun 19, 2012 at 10:33 AM, Alan Reiner <mailto:etothe...@gmail.com>> wrote:


If we were to use a raw trie structure, then we'd have all the above
issues solved:  a trie has the same configuration no matter how
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.


No, a trie of any sort is dependent upon distribution of input data 
for balancing. As Peter Todd points out, a malicious actor could 
construct transaction or address hashes in such a way as to grow some 
segment of the trie in an unbalanced fashion. It's not much of an 
attack, but in principle exploitable under particular timing-sensitive 
circumstances.


Self-balancing search trees (KVL, RB, 2-3-4, whatever) don't suffer 
from this problem.


Mark


I was using "unbalanced" to refer to "query time" (and also 
insert/delete time).  If your trie nodes branch based on the next byte 
of your key hash, then the max depth of your trie is 32.  Period.  No 
one can do anything to ever make you do more than 32 hops to 
find/insert/delete your data.   And if you're using a raw trie, you'll 
always use /exactly/ 32 hops regardless of the distribution of the 
underlying data.  Hence, the trie structure is deterministic 
(history-independent) and cannot become unbalanced in terms of access time.


My first concern was that a malicious actor could linearize parts of the 
tree and cause access requests to take much longer than log(N) time.  
With the trie, that's not only impossible, you're actually accessing in 
O(1) time.


However, you are right that disk space can be affected by a malicious 
actor.  The more branching he can induce, the more branch nodes that are 
created to support branches with only one leaf.



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

[Alan Reiner]

On 06/19/2012 01:59 PM, Gregory Maxwell wrote:

On Tue, Jun 19, 2012 at 1:33 PM, Alan Reiner  wrote:

  One app developer updates their
RB tree code which updated the RB-tree optimizations/rebalancing, and
now a significant portion of the network can't agree on the correct
root.  Not only 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

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

[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

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

[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 Todd:
>> 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