Re: [Bitcoin-development] Block Size Increase

2015-05-06 Thread slush
I don't have strong opinion @ block size topic.

But if there'll be a fork, PLEASE, include SIGHASH_WITHINPUTVALUE (
https://bitcointalk.org/index.php?topic=181734.0) or its alternative. All
developers of lightweight (blockchain-less) clients will adore you!

slush

On Thu, May 7, 2015 at 12:12 AM, Matt Corallo bitcoin-l...@bluematt.me
wrote:

 Recently there has been a flurry of posts by Gavin at
 http://gavinandresen.svbtle.com/ which advocate strongly for increasing
 the maximum block size. However, there hasnt been any discussion on this
 mailing list in several years as far as I can tell.

 Block size is a question to which there is no answer, but which
 certainly has a LOT of technical tradeoffs to consider. I know a lot of
 people here have varying levels of strong or very strong opinions about
 this, and the fact that it is not being discussed in a technical
 community publicly anywhere is rather disappointing.

 So, at the risk of starting a flamewar, I'll provide a little bait to
 get some responses and hope the discussion opens up into an honest
 comparison of the tradeoffs here. Certainly a consensus in this kind of
 technical community should be a basic requirement for any serious
 commitment to blocksize increase.

 Personally, I'm rather strongly against any commitment to a block size
 increase in the near future. Long-term incentive compatibility requires
 that there be some fee pressure, and that blocks be relatively
 consistently full or very nearly full. What we see today are
 transactions enjoying next-block confirmations with nearly zero pressure
 to include any fee at all (though many do because it makes wallet code
 simpler).

 This allows the well-funded Bitcoin ecosystem to continue building
 systems which rely on transactions moving quickly into blocks while
 pretending these systems scale. Thus, instead of working on technologies
 which bring Bitcoin's trustlessness to systems which scale beyond a
 blockchain's necessarily slow and (compared to updating numbers in a
 database) expensive settlement, the ecosystem as a whole continues to
 focus on building centralized platforms and advocate for changes to
 Bitcoin which allow them to maintain the status quo[1].

 Matt

 [1] https://twitter.com/coinbase/status/595741967759335426


 --
 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] Electrum 2.0 has been tagged

2015-03-11 Thread slush
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn m...@plan99.net wrote:


- Electrum v2 with a version number but no date
- myTREZOR with no version and no date and BIP44 key derivation. Some
seeds I believe are now being generated with 24 words instead of 12.
- MultiBit HD with no version and a date in a custom form that creates
non-date-like codes you are expected to write down. I think BIP32 and BIP44
are both supported (sorta).
- GreenAddress with no version, no date and BIP32
- Other bitcoinj based wallets, with no version and a date written
down in normal human form, BIP32 only.

 To my knowledge, myTREZOR, Multibit HD and GreenAddress uses BIP39, just
different scheme for key derivation (myTREZOR uses full BIP44, Multibit HD
uses BIP44 with first account only and GreenAddress uses another scheme
because it's multisig only wallet).

I disagree with the need of some version magic flags or creation date
stored in the mnemnonic, for those reasons:

a) If we fail in the way how mnemonic algo is defined, then some magic,
extra version flag won't save our asses, because we'll fail in meaning of
its meaning. Then it will be completely useless, as implementations cannot
rely on it. I know Thomas was sound proponent of this solution, but he was
unable to give any reasonable rules about who/how define meaning of version
flag.

b) Creation date is just a short-term hack. Considering that mnemonic
words are kind of cold storage (longterm storage), it *really* does not
make much difference in 2020, if your wallet has been created in 02/2014 or
10/2016. If there's performance issue with scanning of the blockchain,
creation date don't save our asses. We need to find another solution, and
as a bonus, we don't need users to know some weird numbers on top of
mnemonic itself.

 From my interpretation of BIP39, wordlists DO NOT REQUIRE to be fixed
between wallet providers. There is some recommendations regarding the
wordlists to help with things such as predictive text, so mobile apps can
easily predict the word being typed in after a few chars etc.

Exactly! After some community feedback, we changed BIP39 algo to be one-way
only, which means you can use *any* wordlist to create the mnemonic, and
any other implementation can derive BIP32 root node even without knowing
that particular wordlist. Namely this has been changed because of
constructive criticism of ThomasV, and from discussion on the mailing list
I had a feeling that we've found a consensus. I was *very* surprised that
Electrum 2.0 started to use yet another algo just because.

Shortly said, I think BIP39 does perfect job and there's no need to use
anything else.

Cheers,
Marek
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the 
conversation now. http://goparallel.sourceforge.net/___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread slush
Yes, the step you're missing is and build the table. Dynamic memory
allocation is something you want to avoid, as well as any artifical
restrictions to number of inputs or outputs. Current solution is slow, but
there's really no limitation on tx size.

Plus there're significant restrictions to memory in embedded world.
Actually TREZOR uses pretty powerful (and expensive) MCU just because it
needs to do such validations and calculate such hashes. With
SIGHASH_WITHINPUTVALUE or similar we may cut hardware cost significantly.

Marek

On Fri, Jan 23, 2015 at 5:52 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 I'm not sure where the ^2 is coming from.  So what I'd understand that
 you'd do is stream in the input txid:vouts which you spend, then you'd
 stream the actual inputs which would just be hashed and value
 extracted (but no other verification), and you'd build a table of
 txid:vout-value, then the actual transaction to be signed.

 This should have O(inputs) hashing and communications overhead. Is
 there a step I'm missing?

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


Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread slush
Oh, now I got the 'soft-fork' alternative. If that means that *senders* to
Trezor need to be nice guys and use some special outputs, then it's,
obviously, no-go solution.

I understand political aspect around hard-fork. Anyway, are there any other
pending projects waiting for hard-fork? Maybe we should join our effort in
some way.

M.

On Fri, Jan 23, 2015 at 5:27 PM, Alan Reiner etothe...@gmail.com 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).



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


[Bitcoin-development] SIGHASH_WITHINPUTVALUE

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


Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread slush
 I *strongly* encourage this to be considered for inclusion at some point.

Thanks Alan for a nice summary. I also agree that such stuff should be
implemented at some point. Anyway, I would probably not vote for doing hard
fork *just* for this change, but if I remember well, there're other ideas
flying around in the air and waiting for hardfork...

Marek

On Fri, Jan 23, 2015 at 4:24 PM, Alan Reiner etothe...@gmail.com wrote:

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


Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread slush
Correct, plus the most likely scenario in such attack is that the malware
even don't push such tx with excessive fees to the network, but send it
directly to attacker's pool/miner.

M.

On Fri, Jan 23, 2015 at 4:42 PM, Alan Reiner etothe...@gmail.com wrote:

  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


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


Re: [Bitcoin-development] SIGHASH_WITHINPUTVALUE

2015-01-23 Thread slush
On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

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


Can you send me any reference about this? Of course if that solves the
problem, hard fork would not be necessary anymore. I'm just not aware of
any.

Can you help me understand whats taking 40 minutes here? Thats a
 surprisingly high number, and so I'm wondering if I'm not missing
 something there.


To sign transaction with hundreds of inputs on device with limited memory
capabilities, I need to stream all previous transactions into device, for
every signed input.

That means roughly 200^2 transaction verifications for 200 inputs to sign.
Very slow, but does not limit the device for any particular size of signed
transaction.

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


Re: [Bitcoin-development] Miners MiTM

2014-08-07 Thread slush
AFAIK the only protection is SSL + certificate validation on client side.
However certificate revocation and updates in miners are pain in the ass,
that's why majority of pools (mine including) don't want to play with
that...

slush


On Fri, Aug 8, 2014 at 1:45 AM, Luke Dashjr l...@dashjr.org wrote:

 On Thursday, August 07, 2014 11:02:21 PM Pedro Worcel wrote:
  Hi there,
 
  I was wondering if you guys have come across this article:
 
  http://www.wired.com/2014/08/isp-bitcoin-theft/
 
  The TL;DR is that somebody is abusing the BGP protocol to be in a
 position
  where they can intercept the miner traffic. The concerning point is that
  they seem to be having some degree of success in their endeavour and
  earning profits from it.
 
  I do not understand the impact of this (I don't know much about BGP, the
  mining protocol nor anything else, really), but I thought it might be
 worth
  putting it up here.

 This is old news; both BFGMiner and Eloipool were hardened against it a
 long
 time ago (although no Bitcoin pools have deployed it so far). I'm not
 aware of
 any actual case of it being used against Bitcoin, though - the target has
 always been scamcoins.


 --
 Infragistics Professional
 Build stunning WinForms apps today!
 Reboot your WinForms applications with our WinForms controls.
 Build a bridge from your legacy apps to the future.

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

--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Miners MiTM

2014-08-07 Thread slush
Although 140 BTC sounds scary, actually it was very minor issue and most of
miners aren't even aware about it.

TLS would probably make the attack harder, that's correct. However if
somebody controls ISP routers, then MITM with TLS is harder, yet possible.

slush


On Fri, Aug 8, 2014 at 3:07 AM, Pedro Worcel pe...@worcel.com wrote:


 Seems to me that it would correctly mitigate the attack mentioned in the
 wired article. I am surprised that miners are not worried about losing
 their profits, I would personally be quite annoyed.


--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Decentralizing ming

2014-07-17 Thread slush
On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik jgar...@bitpay.com wrote:

 Historical note:  On one hand, Satoshi seemed to dislike the early
 emergence of GPU mining pools quite a bit.


To my knowledge, Satoshi left the project before mining pools got a
traction.

slush
--
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposed BIP 70 extension

2014-06-25 Thread slush
On Wed, Jun 25, 2014 at 10:25 AM, Mike Hearn m...@plan99.net wrote:

 The protocol is there to contain features! There is zero benefit to
 slavishly following some religious notion of purity or minimalism here.


Good standard must be explicit as much as possible. Having million optional
fields with ambiguous meaning is even worse than not having these fields.

HTTP status codes are good example. There are hundreds of them, still
applications understands just few of them, because other have ambiguous
meaning and software don't know how to handle them.

Good example of such over-engineering is also XMPP. XMPP has milions
extensions and features, but look at Jabber clients; call yourself lucky
when you can send messages and files, although there're various extensions
like searching for contacts (something which has be working in ICQ decade
ago), voice support, end to end encryption or alerting users. These
features are defined, but not widely implemented, because its definition is
vague or the feature is abused because of poor design.

Please don't over-engineer payment protocol.

Thank you for your attention.

slush
--
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] Proposed BIP 70 extension

2014-06-24 Thread slush
Sounds like marketing bullshit to me. It does not have even statistical
meaning; well, you can save a lot of satoshis, but nobody tell you that
the merchant cut you on BTC/USD exchange rate in tens of %.

Payment protocol should not contain these fictional data, which has no real
meaning for the payment itself. Put these marketing claims to memo field
instead...

slush


On Tue, Jun 24, 2014 at 4:24 PM, Mike Hearn m...@plan99.net wrote:

 It also seems like it would be subject to instant inflation, as it's
 unprovable


 The user knows the price that is on the website or menu, they know the
 price they actually paid ... if the numbers don't add up that would seem to
 be pretty easily detectable. But sure it's only for marketing.  I think the
 comment makes it clear it's just for fun.


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


--
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] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

2014-06-19 Thread slush
On Thu, Jun 19, 2014 at 7:35 PM, Mike Hearn m...@plan99.net wrote:

 My (fresh!) understanding is that the reason we don't see people using
 getblocktemplate to decentralise pools is because libblkmaker and other
 implementations don't actually support connecting your own node to the
 miners and choosing your own blocks, even though the protocol does.


Well, I don't want to start flamewar (and this topic has potential!), but
the *real* reason why there isn't such infrastructure is that although GBT
as a protocol *does* support of decentralized building of blocks, it is
*extremely* resource consuming to validate these shares on pool side.

With GBT, simply hashing the block header is not enough, because pool
cannot rely on anything provided by the client. Its not only about things
like withdrawal attacks, but more about hidden bugs in various miners. It
is extremely hard to do full validation for *every* of submitted shares.

Although I see benefits of GBT and I see limits of Stratum, I don't think
that supporting full GBT validation have economic sense for any medium
sized pool, because such pool would need multiply his running costs on
servers many times.

 It's part of a general trend wherein people look at all the things
that can be accomplished in an economy that has a division of labor*,
and see some misbehavior at the edges, and decide that rather than
fixing the misbehavior we should throw out the entire concept of labor
specialization.

Well written! This reminds me - what about Stratum + SPV validation on
miner side?

With SPV, miner cannot choose his own transactions, so it is not fully
decentralized, but at least miner can detect (in real time) two major pool
misbehaviours - selfish mining (building private blockchain) and chain
forking (not working on longest known blockchain).

I read such proposal about Stratum + SPV on reddit and I actually like it;
It removes major drawbacks of centralized Stratum mining, yet is gives
tools to miners to instantly switch to fallback pool when something wrong
is happening.

slush
--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BlockPow: A Practical Proposal to prevent mining pools AND reduce payoff variance:

2014-06-19 Thread slush
Miner issues are just one thing what came to my mind. What about validating
transactions? How the pool can be sure that miner is running up to date
bitcoind which do full validation of transactions? Not talking that if
every miner takes his own set of transaction, pool need to calculate merkle
root for every submit, to check its correctness.

I don't think it *cannot* be done, it is just extremely hard and there's no
economic motivation for such complication on pool side. Just see current
pools, they are full of security and stability bugs even while using such
trivial protocol like Stratum...

slush

On Thu, Jun 19, 2014 at 10:39 PM, Mark Friedenbach m...@monetize.io wrote:

 Do you need to do full validation? There's an economic cost to mining
 invalid blocks, and even if that were acceptable there's really no
 reason to perform such an attack. The result would be similar to a block
 withholding attack, but unlike block withholding it would be trivially
 detectable if/when full validation was performed.

 To protect yourself and to detect incorrect mining software you could
 stochastically validate a randomly selected sample of shares, as your
 hardware requirements allow.

 On 06/19/2014 01:26 PM, slush wrote:
  With GBT, simply hashing the block header is not enough, because pool
  cannot rely on anything provided by the client. Its not only about
  things like withdrawal attacks, but more about hidden bugs in various
  miners. It is extremely hard to do full validation for *every* of
  submitted shares.

--
HPCC Systems Open Source Big Data Platform from LexisNexis Risk Solutions
Find What Matters Most in Your Big Data with HPCC Systems
Open Source. Fast. Scalable. Simple. Ideal for Dirty Data.
Leverages Graph Analysis for Fast Processing  Easy Data Exploration
http://p.sf.net/sfu/hpccsystems___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2014-05-03 Thread slush
Excellent points Christophe!

Although moving to 1e-6 units is fine for me and I see advantages of doing
this, I don't get that people on this mailing list are fine with calling
such unit bit. It's geeky as hell, ambiguous and confusing.

slush


On Sat, May 3, 2014 at 5:48 PM, Christophe Biocca 
christophe.bio...@gmail.com wrote:

 Context as a disambiguator works fine when the interlocutors
 understand the topics they're talking about.
 Not a day goes by without me seeing neurotypical people get horribly
 confused between RAM and Hard Drive sizes, because they share the same
 units (not that that can be helped, as the units are supposed to be
 the same, base 1000 vs 1024 notwithstanding).

 Bit (as a unit) is already really confusing for anyone who doesn't
 deal with it on a regular basis. I think people who don't see an issue
 are making an assumption based on their own lack of confusion. We
 understand computer science AND Bitcoin. Most people have zero
 understanding of either.

 Bitcoin already has a ton of issues with terrible names for things:

 - Mining (for transaction validation).
 - Addresses (which are meant to be one-time use, and don't even really
 exist at the network level).
 - Wallets (which don't hold your bitcoins, can be copied, and all
 backups can be stolen from equally).

 I end up having to make the distinctions obvious every time I explain
 Bitcoin to someone new to it. There's an acceptable tradeoff here,
 because there were arguably no better words to assign to these
 concepts (although I'd argue mining is a really awful metaphor, and is
 the one that prompts the most questions from people). Then add to the
 pile a bunch of third parties naming themselves after parts of the
 protocol (Coinbase,Blockchain.info). Not blaming them for it, but I've
 definitiely seen average people get confused between the blockchain
 and blockchain.info (not so much Coinbase, because that name doesn't
 come up in beginner explanations).

 It seems downright masochistic to add
 yet-another-word-that-doesn't-mean-what-you-think-it-means to the pile
 for no reason other than aesthetics. Are we actively trying to confuse
 people?

 On Sat, May 3, 2014 at 1:41 AM, Aaron Voisine vois...@gmail.com wrote:
  I have to agree with Mike. Human language is surprisingly tolerant of
  overloading and inference from context. Neurotypical people have no
  problem with it and perceive a software engineer's aversion to it as
  being pedantic and strange. Note that bits was a term for a unit of
  money long before the invention of digital computers.
 
  Aaron
 
  There's no trick to being a humorist when you have the whole
  government working for you -- Will Rodgers
 
 
  On Fri, May 2, 2014 at 7:06 PM, Gordon Mohr goj...@gmail.com wrote:
  [resend - apologies if duplicate]
 
  Microbitcoin is a good-sized unit, workable for everyday transaction
  values, with room-to-grow, and a nice relationship to satoshis as
 'cents'.
 
  But bits has problems as a unit name.
 
  Bits will be especially problematic whenever people try to graduate
  from informal use to understanding the system internals - that is, when
  the real bits of key sizes, hash sizes, and storage/bandwidth needs
  become important. The bit as binary digit was important enough that
  Satoshi named the system after it; that homage gets lost if the word is
  muddied with a new retconned meaning that's quite different.
 
  Some examples of possible problems:
 
  * If bit equals 100 satoshis, then the natural-language unpacking of
  bit-coin is 100 satoshi coin, which runs against all prior usage.
 
  * If people are informed that a 256-bit private key is what ultimately
  controls their balances, it could prompt confusion like, if each key
  has 256-bits, will I need 40 keys to hold 10,000.00 bits?
 
  * When people learn that there are 8 bits to a byte, they may think,
  OK, my wallet holding my 80,000.00 bits will then take up 10
 kilobytes.
 
  * When people naturally extend bit into kilobits to mean 1000
  bits, then the new coinage kilobits will mean the exact same amount
  (100,000 satoshi) as many have already been calling millibits.
 
  I believe it'd be best to pick a new made-up single-syllable word as a
  synonym for microbitcoin, and I've laid out the case for zib as that
  word at http://zibcoin.org.
 
  'Zib' also lends itself to an expressive unicode symbol, 'Ƶ'
  (Z-with-stroke), that remains distinctive even if it loses its stroke or
  gets case-reversed. (Comparatively, all 'b'-derived symbols for
  data-bits, bitcoins, or '100 satoshi bits' risk collision in contexts
  where subtleties of casing/stroking are lost.)
 
  (There's summary of more problems with bit in the zibcoin.org FAQ
  at:
  http://zibcoin.org/faq#why-not-bits-to-mean-microbitcoins.)
 
  - Gordon
 
  On 5/1/14, 3:35 PM, Aaron Voisine wrote:
  I'm also a big fan of standardizing on microBTC as the standard unit.
  I didn't like the name bits at first, but the more I think

Re: [Bitcoin-development] New BIP32 structure

2014-04-23 Thread slush
On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 Storing the seed is superior to storing the master node already
 (whether coin specific or not), as it is smaller.


...Except that you're loosing flexibility (serialization, deserialization)
which gives you BIP32 node.

I see bip32 seed as some transitional, internal state from raw entropy to
bip32 master node and this seed should not be handled by the end user in
any form. In the oposite, well-serialized bip32 node (in xpriv, or even in
mnemonic format) can be used very widely and have no downsides against
using raw bip32 seed.



 Fair enough, it would break strictly BIP32. Then again, BIP32 is a
 *Bitcoin* improvement proposal, and not something that necessarily
 applies to other coins (they can adopt it of course, I don't care).


I also don't care too much about altcoins, but people want them so me, as
infrastructure developer, need to think about it. And I don't see any
reason for breaking compatibility between Bitcoin and other altcoins. I
would be happier if there will be another sentence than Bitcoin seed, but
honestly, who cares. It is just some magic string for hashing the raw
seed...


 What I dislike is that this removes the ability of using the magic in
 the serialization to prevent importing a chain from the wrong coin.


The truth is that even existing software which handle bip32 don't care
about 'version' at all. I think that xpub/xprv distinction is the only
useful feature of version, so user se if it stores public or private
information.

But using prefixes which doesn't enforce anything is even more dangerous.
If somebody exports node dogeblablabla, it creates false exceptations
that there's only dogecoin stored.

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

2014-04-23 Thread slush
Using higher gap limit in the software is not prohibited, but then it
breaks the standard as is, in mean that importing such wallet to another
BIP64 wallet won't recover the funds properly, without proper settings of
gap limit...

Gap limit 20 is the most sane defaults for majority of users (actually I
think it is a bit higher than is really necessary for 99% users) and
majority of users won't need to change it at any time.

Marek


On Wed, Apr 23, 2014 at 9:00 PM, Tier Nolan tier.no...@gmail.com wrote:

 On Wed, Apr 23, 2014 at 7:46 PM, Pavol Rusnak st...@gk2.sk wrote:


  Setting the gap limit to high is just a small extra cost in that case.

 Not if you have 100 accounts on 10 different devices.


 I meant for a merchant with a server that is handing out hundreds of
 addresses.

 The point is to have a single system that is compatible over a large
 number of systems.


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


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

2014-04-23 Thread slush
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr l...@dashjr.org wrote:

 Any wallet should import all the coins just fine, it just wouldn't *use*
 any
 account other than 0. Remember addresses are used to receive bitcoins; once
 the UTXOs are in the wallet, they are no longer associated with the
 address or
 any other details of how they were received.


Wallet don't see UTXO until it scans all branches/accounts on HD node
import.
--
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

2014-04-23 Thread slush
On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille pieter.wui...@gmail.comwrote:


 Would you consider software which scans all accounts as specified by
 BIP64, but has no user interface option to distinguish them in any
 way, view them independently, and has no ability to keep the coins
 apart... compatible with BIP64?


No, because one of requirement of BIP64 is to do not mix addressess between
accounts. Without handling those accounts fully, it won't pass this
requirement.

(This level [accounts] splits the key space into independent user
identities, so the wallet never mixes the coins across different accounts.)


Marek
--
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] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread slush
I believe there're plenty bitcoind instances running, but they don't have
configured port forwarding properly.There's uPNP support in bitcoind, but
it works only on simple setups.

Maybe there're some not yet considered way how to expose these *existing*
instances to Internet, to strenghten the network. Maybe just self-test
indicating the node is not reachable from outside (together with short
howto like in some torrent clients).

These days IPv6 is slowly deploying to server environments, but maybe
there's some simple way how to bundle ipv6 tunnelling into bitcoind so any
instance will become ipv6-reachable automatically?

Maybe there're other ideas how to improve current situation without needs
of reworking the architecture.

Marek


On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell gmaxw...@gmail.com wrote:

 On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier justusranv...@gmail.com
 wrote:
  Anyone reading the archives of the list will see about triple the
  number of people independently confirming the resource usage problem
  than they will see denying it, so I'm not particularly worried.

 The list has open membership, there is no particular qualification or
 background required to post here. Optimal use of an information source
 requires critical reading and understanding the limitations of the
 medium. Counting comments is usually not a great way to assess
 technical considerations on an open public forum.  Doubly so because
 those comments were not actually talking about the same thing I am
 talking about.

 Existing implementations are inefficient in many known ways (and, no
 doubt, some unknown ones). This list is about developing protocol and
 implementations including improving their efficiency.  When talking
 about incentives the costs you need to consider are the costs of the
 best realistic option.  As far as I know there is no doubt from anyone
 technically experienced that under the current network rules full
 nodes can be operated with vastly less resources than current
 implementations use, it's just a question of the relatively modest
 implementation improvements.

 When you argue that Bitcoin doesn't have the right incentives (and
 thus something??) I retort that the actual resource _requirements_ are
 for the protocol very low. I gave specific example numbers to enable
 correction or clarification if I've said something wrong or
 controversial. Pointing out that existing implementations are not that
 currently as efficient as the underlying requirements and that some
 large number of users do not like the efficiency of existing
 implementations doesn't tell me anything I disagree with or didn't
 already know. Whats being discussed around here contributes to
 prioritizing improvements over the existing implementations.

 I hope this clarifies something.


 --
 Put Bad Developers to Shame
 Dominate Development with Jenkins Continuous Integration
 Continuously Automate Build, Test  Deployment
 Start a new project now. Try Jenkins in the cloud.
 http://p.sf.net/sfu/13600_Cloudbees
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Bitcoind-in-background mode for SPV wallets

2014-04-09 Thread slush
Another idea: Integrate torrent download of bootstrap.dat into bitcoind.
Normal user (especially a beginner) won't learn how to download bootstrap
separately and import it into bitcoind; he simply give up the
synchronization once he realize it takes too much time. From my experience
downloading the bootstrap significantly improves catching the blockchain,
which may attract some more users to run bitcoind.

Not sure about C++, but simple torrent client in python is like 30 lines of
code (using libtorrent).

Marek


On Wed, Apr 9, 2014 at 10:12 PM, slush sl...@centrum.cz wrote:

 I believe there're plenty bitcoind instances running, but they don't have
 configured port forwarding properly.There's uPNP support in bitcoind, but
 it works only on simple setups.

 Maybe there're some not yet considered way how to expose these *existing*
 instances to Internet, to strenghten the network. Maybe just self-test
 indicating the node is not reachable from outside (together with short
 howto like in some torrent clients).

 These days IPv6 is slowly deploying to server environments, but maybe
 there's some simple way how to bundle ipv6 tunnelling into bitcoind so any
 instance will become ipv6-reachable automatically?

 Maybe there're other ideas how to improve current situation without needs
 of reworking the architecture.

 Marek


 On Wed, Apr 9, 2014 at 9:33 PM, Gregory Maxwell gmaxw...@gmail.comwrote:

 On Wed, Apr 9, 2014 at 11:58 AM, Justus Ranvier justusranv...@gmail.com
 wrote:
  Anyone reading the archives of the list will see about triple the
  number of people independently confirming the resource usage problem
  than they will see denying it, so I'm not particularly worried.

 The list has open membership, there is no particular qualification or
 background required to post here. Optimal use of an information source
 requires critical reading and understanding the limitations of the
 medium. Counting comments is usually not a great way to assess
 technical considerations on an open public forum.  Doubly so because
 those comments were not actually talking about the same thing I am
 talking about.

 Existing implementations are inefficient in many known ways (and, no
 doubt, some unknown ones). This list is about developing protocol and
 implementations including improving their efficiency.  When talking
 about incentives the costs you need to consider are the costs of the
 best realistic option.  As far as I know there is no doubt from anyone
 technically experienced that under the current network rules full
 nodes can be operated with vastly less resources than current
 implementations use, it's just a question of the relatively modest
 implementation improvements.

 When you argue that Bitcoin doesn't have the right incentives (and
 thus something??) I retort that the actual resource _requirements_ are
 for the protocol very low. I gave specific example numbers to enable
 correction or clarification if I've said something wrong or
 controversial. Pointing out that existing implementations are not that
 currently as efficient as the underlying requirements and that some
 large number of users do not like the efficiency of existing
 implementations doesn't tell me anything I disagree with or didn't
 already know. Whats being discussed around here contributes to
 prioritizing improvements over the existing implementations.

 I hope this clarifies something.


 --
 Put Bad Developers to Shame
 Dominate Development with Jenkins Continuous Integration
 Continuously Automate Build, Test  Deployment
 Start a new project now. Try Jenkins in the cloud.
 http://p.sf.net/sfu/13600_Cloudbees
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development



--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread slush
After some off-list discussion about details with wallet developers, it
seems that structure

m/cointype'/account'/change/n

fulfill requirements of all wallet developers around, including myTrezor,
Electrum, Multibit, Wallet32 and other software is willing to adapt once
anything will be standardized (i.e. they don't care).

Because I think that everybody told their comments to the topic already and
because it seems that there's quite wide agreement on that, I would like to
close the discussion and finally implement these paths into our software.

Cheers,
Marek


On Fri, Mar 28, 2014 at 3:59 PM, slush sl...@centrum.cz wrote:

 I agree that 'version' field of bip32 is not necessary and xpriv/xpub
 should be enough for all cases; there's actually no need to use different
 BIP32 roots for different altcoins.

 I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by
 having the cointype distinction in the bip32 path itself, I'm sure that I
 don't reuse the same pubkey across blockchains which may be a privacy issue
 otherwise.

 Marek


 On Thu, Mar 27, 2014 at 5:28 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote:
  Cointype in path is for separation purposes, not for identification.

 I don't understand what that gains you.

 --
 Pieter


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



--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread slush
On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 I still don't understand the purpose of cointype. If you don't want to
 risk reusing the same keys across different currencies, just don't use
 the same seed or the same account? That is purely a client-side issue.


Of course it is purely client-side issue, but it matters.

There's actually no reason to generate, backup and store individual seeds
for various coins and purposes. User can handle all his identities and
altcoins with single seed, avoiding potential issues with using wrong seed
for other purposes.

Actually with accounts and cointypes in the path, you can have all your
crypto funds stored on single seed, which I see as very comfortable
solution.

But to gain advantages of such solution and avoid reusing the same path
across blockchains, we need to separate the space, which is achieved by
cointype.


 If the consensus is to add the cointype anyway, can we fix it to be
 equal to the 4-byte magic in the serialization (after setting the high
 bit to true)? That way there aren't two 4-byte magic codes that need
 to be defined for each, and at the same time make it obvious from the
 serialized form what it is for.


Serialization magic of bip32 seed is in my opinion completely unnecessary.
Most of software does not care about it anyway; You can use xprv/xpub pair
for main net, testnet, litecoin, dogecoin, whatevercoin.

Instead using the same seed (xprv) and then separate the chains *inside*
the bip32 path seems more useful to me.

Marek
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread slush
tl;dr;

It is dangerous to expect that other seed than xprv does not contain
bitcoins or that xprv contains only bitcoins, because technically are
both situations possible. It is still safer to do the lookup; the magic
itself is ambiguous.

Marek

On Tue, Apr 8, 2014 at 3:40 PM, slush sl...@centrum.cz wrote:


 Serialization magic of bip32 seed is in my opinion completely unnecessary.
 Most of software does not care about it anyway; You can use xprv/xpub pair
 for main net, testnet, litecoin, dogecoin, whatevercoin.

 Instead using the same seed (xprv) and then separate the chains *inside*
 the bip32 path seems more useful to me.

 Marek

--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread slush
On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 I see the cause of our disagreement now.

 You actually want to share a single BIP32 tree across different
 currency types, but do it in a way that guarantees that they never use
 the same keys.

 I would have expected that different chains would use independent
 chains, and have serializations encode which chain they belong to.

 Let me offer an alternative suggestion, which is compatible with the
 original default BIP32 structure:
 * You can use one seed across different chains, but the master nodes
 are separate.
 * To derive the master node from the seed, the key string Bitcoin
 seed is replaced by something chain-specific.


I've discussed the solution of Litecoin seed in BIP32 HMAC with Litecoin
devs already, and after long discussion we've concluded that it is
generally bad idea.

When changing Bitcoin seed constant to something different, same
*entropy* will produce different *master node*. That's actually the
opposite what's requested, because xprv serialization format stores *node*,
not *entropy*. By changing HMAC constant, you still won't be able to store
one node and derive wallets for multiple coins at same time.



 * Every encoded node (including master nodes) has a chain-specific
 serialization magic.

This is in practice almost the same as your suggestion, except that
 the m/cointype' in m/cointype'/account'/change/n is replaced by
 different masters. The only disadvantage I see is that you do not have
 a way to encode the super master that is the parent of all
 chain-specific masters. You can - and with the same security
 properties - encode the seed, though.


Actually I don't understand why there's such disagreement about cointype
level here, what it breaks? I see it as the cleanest solution so far. It is
forward and backward compatible, does need any special extension to bip32
(to be strict, bip32 says Bitcoin seed, so client using Litecoin seed
cannot be bip32 compatible).

Of course, the problem of cointype can be solved in zillion ways, but
still using cointype in bip32 path seem to be the most elegant way so far,
because it fullfill all requirements for single backup, for separating
pubkeys and for handling all coins by one master...

Marek
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] New BIP32 structure

2014-04-08 Thread slush
On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach andr...@schildbach.dewrote:

 While there is an agreement that a standard would be useful for sharing
 wallets, we certainly didn't agree on every aspect of a standard. At
 least not on this thread, and also not at the Berlin meeting.


We're going to write down BIP describing such structure. If any wallet want
to be BIP XX compatible, then it has chance to. Of course if any wallet
want to use another format, then it cannot call itself BIP XX compatible,
thus nobody will expect that such software will see/recover all keys
generated by BIP XX wallet.


 I understand each client will implement things a little bit different,
 for example the current plan is bitcoinj will hold all keys in memory
 and start reusing keys on low resources. Electrum uses a chain for their
 private purpose. Etc.


It still doesn't mean that bitcoinj or Electrum cannot share the bare
minimum of BIP XX. Of course if somebody will use Electrum for 2to3
transactions and then move wallet to client which does not offer such
feature, it won't work. But I don't see that as a problem.


 If we cannot 100% agree on a standard and also agree it will not be
 extended in future, I think we should not even try. It's dangerous for
 the money of users.


If some developers agree on some specific BIP, then it should be cross
compatible.  Of course if somebody implements BIP XX in different way, then
it isn't BIP XX compatible.




I propose we keep our chains deliberately separate and only try
 standardizing after each of us has a feel for the specific requirements.


Of course, if somebody don't want to generate compatible bip32 paths, no
problem. It will be the same situation as now.

Marek
--
Put Bad Developers to Shame
Dominate Development with Jenkins Continuous Integration
Continuously Automate Build, Test  Deployment 
Start a new project now. Try Jenkins in the cloud.
http://p.sf.net/sfu/13600_Cloudbees___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Draft BIP for seamless website authentication using Bitcoin address

2014-04-04 Thread slush
I'm cracking my head for many months with the idea of using TREZOR for web
auth purposes. Unfortunately I'm far from any usable solution yet.

My main comments to your BIP: Don't use bitcoin addresses directly and
don't encourage services to use this login for financial purposes. Mike
is right, mixing authentication and financial services is wrong. Use some
function to generate other private/public key from bitcoin's seed/private
key to not leak bitcoin-related data to website.

Cheers,
Marek


On Fri, Apr 4, 2014 at 4:42 PM, Eric Larchevêque ela...@gmail.com wrote:

  The goal of writing a BIP seems to be to get lots of different wallet
 authors to write lots of code for you - but I *am* a wallet author, and
 I don't think that's the right way to get traction with a new scheme.


 I started without a BIP and the feedback I got is that I should to a BIP.
 We cannot write all the code for all the wallets ; this is after all a
 communauty project.
 However we have and we will propose bounties for each wallet to support
 natively the protocol.


 For instance the TREZOR guys would have to support your new protocol
 otherwise if I paid my hotel bill with my TREZOR I couldn't open the door
 when I got there! But they probably have better things to be doing right
 now.


 Yes you are right. But if the concept of authenticating yourself gets
 traction, they will probably do it.


 The key difference between just generating a client certificate and using
 a Bitcoin address is that the client certificate is something that is used
 *specifically* for identification. It leaves no trace in the block
 chain, so no weird privacy issues, it doesn't matter how you manage your
 wallet, and you don't have to persuade lots of people to support your idea
 because it was already done 10 years ago and basically every browser/web
 server supports it.


 My view on this is mainly about the UX and the fact everyone in
 Bitcoinland has a wallet.
 It's a approach leveraging this fact, with the possibility to build
 interesting apps combining address auth and the blockchain.

 I understand the problems related to multisig, contracts etc,
 There is no such thing as a from address in a transaction, however many
 services still take first tx as the return address.
 People will always find way of building and doing stuff (cf the message in
 the blockchain debate).


 Some reasons client certs aren't more widely used boil down to:

1. People like passwords. In particular they like forgetting them and
then having friendly people assist them to get it back. Client certs can
support this use case, but only if apps are checking the identity in them
and not the key.
2. The UI for managing client certs in browsers is pretty horrible.
There's little incentive to improve it because of (1).
3. Cross-device sync doesn't work very well. Apple are starting to
tackle this with their iCloud Keychain Sync service but then of course,
Apple has all your keys and you may well just sign in to things with your
Apple account (if it were to be supported). Cross-device sync where the
server *doesn't* get your keys is supported by Chrome for passwords,
but not client certs, because (1)

 None of the above issues have any obvious fix lurking within Bitcoin.


 There is also the benefit of revocation with certificate and central
 authority.

 But, again, you already have a wallet and a Bitcoin address.
 So if you add a simple auth protocol, people will use it at no cost.

 Eric





 --

 ___
 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] Draft BIP for seamless website authentication using Bitcoin address

2014-04-04 Thread slush
On Fri, Apr 4, 2014 at 5:37 PM, Mike Hearn m...@plan99.net wrote:

 Hmmm, well TREZOR requires a web plugin. So if nobody installs plugins
 then we have a problem :) But regardless, actually like I said, you don't
 need a plugin.


I see the plugin as a temporary solution and we'll eliminate the plugin
once there'll be any way to talk to USB HID directly from browser (which is
not possible yet, but there's some effort already).

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


Re: [Bitcoin-development] New BIP32 structure

2014-03-28 Thread slush
I agree that 'version' field of bip32 is not necessary and xpriv/xpub
should be enough for all cases; there's actually no need to use different
BIP32 roots for different altcoins.

I'm happily using one xpub for Bitcoin/Testnet/Litecoin at once, and by
having the cointype distinction in the bip32 path itself, I'm sure that I
don't reuse the same pubkey across blockchains which may be a privacy issue
otherwise.

Marek


On Thu, Mar 27, 2014 at 5:28 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 On Thu, Mar 27, 2014 at 5:21 PM, Pavol Rusnak st...@gk2.sk wrote:
  Cointype in path is for separation purposes, not for identification.

 I don't understand what that gains you.

 --
 Pieter


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

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


[Bitcoin-development] BIP0039: Final call

2014-01-20 Thread slush
Hi all,

during recent months we've reconsidered all comments which we received from
the community about our BIP39 proposal and we tried to meet all
requirements for such standard. Specifically the proposal now doesn't
require any specific wordlist, so every client can use its very own list of
preferred words. Generated mnemonic can be then applied to any other
BIP39-compatible client. Please follow current draft at
https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.

Because we're quickly moving towards release of Trezor firmware and we need
to finalize this part of the firmware, we're asking for the last comments
to current BIP39 draft.

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


Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread slush
On Mon, Jan 20, 2014 at 9:02 PM, Luke-Jr l...@dashjr.org wrote:


 How are they compatible if they could be using entirely different word
 lists??


Wordlist is necessary for the step [seed]-[mnemonic]. Step
[mnemonic]-[bip32 root] doesn't need any wordlist, there's just hashing
involved.
For this reason client can generate whatever mnemonic and unless all
clients use the same process [mnemonic]-[bip32 root], the result is the
same.


 Maybe I'm missing something, but shouldn't this be a client-side thing, not
 implemented in the Trezor firmware at all?? O.o;;


Trezor generates the seed and transforms it to mnemonic (which is then
shown on internal display). Generating the mnemonic outside the client-side
(computer) is one of main functionality of Trezor.

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


Re: [Bitcoin-development] BIP0039: Final call

2014-01-20 Thread slush
On Tue, Jan 21, 2014 at 12:06 AM, Christophe Biocca 
christophe.bio...@gmail.com wrote:

 I remember the wordlist choice getting bikeshedded to death a month ago.

 I would just include the wordlist as part of the standard (as a
 recommendation) so that fully compliant implementations can correct a
 user's typos regardless of the original generator.


That's exactly our attitude. We realized that have a community-wide
agreement on the wordlist itself is simply imposible, so to reach at least
some consensus we split the proposal to two parts - one what is essential
to call itself a bip39 compatible, i.e. converting the mnemonic to bip32
node and second which is optional, including our proposed wordlist, which
has some advanced features like checksums etc. Now it is up to client
developers to decide if they really insist on their superior wordlist or if
they'll implement checksums following the full specification.



 Those who don't like it will have to deal with the compatibility
 concerns themselves, or get an alternate wordlist approved as a BIP.

Odds are no one will go that route.


At least Trezor and bitcoinj (Multibit) seems to be going in this way,
which is 100% of clients which expressed interest in bip39 :-).

slush


 On Mon, Jan 20, 2014 at 5:35 PM, Peter Todd p...@petertodd.org wrote:
  On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
  On Mon, Jan 20, 2014 at 11:42 AM, slush sl...@centrum.cz wrote:
 
   Hi all,
  
   during recent months we've reconsidered all comments which we received
   from the community about our BIP39 proposal and we tried to meet all
   requirements for such standard. Specifically the proposal now doesn't
   require any specific wordlist, so every client can use its very own
 list of
   preferred words. Generated mnemonic can be then applied to any other
   BIP39-compatible client. Please follow current draft at
   https://github.com/trezor/bips/blob/master/bip-0039.mediawiki.
 
  So, because the [mnemonic]-[bip32 root] is just hashing, you've
  effectively made your mnemonic sentence into a brainwallet? Since
 every
  mnemonic sentence can now lead to a bip32 root, and only the client that
  created the mnemonic can verify the mnemonic passes its checksum
 (assuming
  all clients use different wordlists, the only client that can help you
 if
  you fat-finger the sentence is the client that created it)?
 
  That issue is more than enough to get a NACK from me on making the
  current BIP39 draft a standard - I can easily see that leading to users
  losing a lot of money.
 
  Have any wallets implemented BIP39 this way already in released code?
 
  --
  'peter'[:-1]@petertodd.org
  9c3092c0b245722363df8b29cfbb86368f4f7303e655983a
 
 
 --
  CenturyLink Cloud: The Leader in Enterprise Cloud Services.
  Learn Why More Businesses Are Choosing CenturyLink Cloud For
  Critical Workloads, Development Environments  Everything In Between.
  Get a Quote or Start a Free Trial Today.
 
 http://pubads.g.doubleclick.net/gampad/clk?id=119420431iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development
 


 --
 CenturyLink Cloud: The Leader in Enterprise Cloud Services.
 Learn Why More Businesses Are Choosing CenturyLink Cloud For
 Critical Workloads, Development Environments  Everything In Between.
 Get a Quote or Start a Free Trial Today.

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

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


Re: [Bitcoin-development] BIP39 word list

2013-11-01 Thread slush
'), ('o', 'q'), ('o', 'u'), ('o', 'v'),
  ('p', 'q'), ('p', 'r'),
  ('q', 'y'),
  ('s', 'z'),
  ('u', 'v'), ('u', 'w'), ('u', 'y'),
  ('v', 'w'), ('v', 'y')
  )
  Feel free to review and comment current wordlist, but I think we're
 slowly moving forward final list.
  slush


 --
 Android is increasing in popularity, but the open development platform that
 developers love is also attractive to malware creators. Download this white
 paper to learn more about secure code signing practices that can help keep
 Android apps secure.
 http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-31 Thread slush
On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin thoma...@gmx.de wrote:

 Indeed, I want to include a version number in the seed phrase because
 there are
 multiple ways to define the tree structure used with BIP32. It is
 certainly too early
 to make final decisions on that, or to achieve a common standard.


Well, as we're the first pioneers of bip32, let's start using it in some
sane way and I'm sure the others will join. Just because they don't want to
incompatible software.

Actually I quite like that you're not wasting bip32 space by using some
dynamic allocatons in higher address space, so I'm happy to follow your
rules and I think we can agree on generic discover algorithm which maybe
won't be optimal, but will find all used addresses and won't need any
additional information directly in mnemonic.

As I wrote in previous post, in worst case I can imagine dropdown list on
import dialog, which will ask user which software has been handling the
seed before, to speedup the scan. But for now I don't see this necessary at
all.

Also, I can imagine that bip32 itself might be superseeded in the future.


Although I can imagine that as well, I hope that it won't be the case. We
need to unite and integrate instead of making incompatible applications.

One disadvantage of bip32 is that in fact it is too much flexible, so we
even falled into the necessity of defining version of discovery algorithm.
Lets set up best practices how to use it and other will follow instead of
creating zillion cross-incompatible algorithms which won't understand each
to other.


 The other question we might be solving is strenghtening (your proposal).
 I consider
 that this is not a strong requirement for Electrum, because it does not
 let the user
 choose their seed phrase. However, if a few bits of the seed phrase are


Hardening and password protection are two unrelated requirements. Again,
there are some scenarios in which use can leak part of the mnemonic to
attacker, so hardening prevent to bruteforce the rest information by
attacker, even if the mnemonic isn't passphrase protected.

I'm especially refering to our algorithm of mnemonic import to Trezor
during disaster recovery (when Trezor is destroyed and user wants to import
the seed to another one), so that leak isn't just a theoretical concept,
but real-word scenario.


 allocated

for metadata, then I guess strenghtening can be part of it. That's
 another good
 reason to have a version number encapsulated in the seed.


Actually creating optional features of such algorithm only make things
complicated (and less cross-compatible). Every software still needs to
implement such hardening even if it is optional feature, to be compatible
with other clients. Then I don't see any reason why to have it optional.

Don't forget that the proposal uses only 4 bits of version, which isn't too
much combination for all these optional features ;-).

I too wonder why the transformation needs to be bidirectional in bip39.


Well, I wrote longer answer in previous  email. tl;dr; there's quite easy
way how to make the algorithm bi-directional, so I don't see a necessity to
drop potentially useful feature for no good reason.

I was thinking about your proposal and I realized that both our solutions
solves a bit different problem. Lets summarize features (and forget to
wordlist fights for moment):

bip39:
+ bi-directional
+ passphrase protected
+ shorter mnemonic or shorter wordlist
- predefined wordlist

ThomasV proposal:
+ any software can has its own preferred worlist
? passphrase protected
- one-direction only
- longer mnemonic or longer wordlist

Back to wordlist fights
a) actually I think that the wordlist choice is far less important than it
may look at first glance. Thomas thinks that bip39 wordlist is disaster, me
and many other thinks it is ok, but mainly that it is very subjective.

b) I see the beauty of custom wordlists in Thomas proposal, still if it
means the algorithm is uni-direction only, it is very strong disadvantage
to our usecase.

c) I advocated our wordlist mainly because we put a lot of effort into it
and after many weeks of tuning it is already done; not because I think that
one method of picking the words is superior to other. I mean - if Thomas
can offer any other plain-english wordlist which he'll be happy with, I'll
vote for dropping our own wordlist and to use Thomas's version for the deal
that he'll accept our need for bi-directionality and he agrees on the rest
of bip39 ;-).

Marek
--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-31 Thread slush
Oh, I forgot to one practical aspect; the way how the mnemonic is mined
in Thomas proposal prevents usage in embedded devices, because difficulty
of generating proper mnemonic is simply too high for embedded
microcontrollers. Maybe this can be solved somehow by modifying the
proposal, but right now it is a showstopper for us.

Marek

On Thu, Oct 31, 2013 at 12:11 PM, slush sl...@centrum.cz wrote:


 bip39:
 + bi-directional
 + passphrase protected
 + shorter mnemonic or shorter wordlist
 - predefined wordlist

 ThomasV proposal:
 + any software can has its own preferred worlist
 ? passphrase protected
 - one-direction only
 - longer mnemonic or longer wordlist


--
Android is increasing in popularity, but the open development platform that
developers love is also attractive to malware creators. Download this white
paper to learn more about secure code signing practices that can help keep
Android apps secure.
http://pubads.g.doubleclick.net/gampad/clk?id=65839951iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-26 Thread slush
Hi Thomas,

can you more elaborate on that version bits? What is exact meaning of it?
I still think this is more an implementation problem. What stops Electrum
to do the same algorithm for searching branches as it is now for used
addresses?

These version bits need to be covered by the specification as well,
because if any client will use them differently (or won't use them at all),
it will break cross-compatibility between clients, which was another goal
of bip39.

Marek




On Sat, Oct 26, 2013 at 5:24 PM, Thomas Voegtlin thoma...@gmx.de wrote:

 here is a simple implementation, with some ideas on how to format the
 metadata:
 https://en.bitcoin.it/wiki/Talk:BIP_0039



 --
 October Webinars: Code for Performance
 Free Intel webinars can help you accelerate application performance.
 Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
 the latest Intel processors and coprocessors. See abstracts and register 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP39 word list

2013-10-24 Thread slush
I've just pushed updated wordlist which is filtered to similar characters
taken from this matrix.

BIP39 now consider following character pairs as similar:

similar = (
('a', 'c'), ('a', 'e'), ('a', 'o'),
('b', 'd'), ('b', 'h'), ('b', 'p'), ('b', 'q'), ('b', 'r'),
('c', 'e'), ('c', 'g'), ('c', 'n'), ('c', 'o'), ('c', 'q'),
('c', 'u'),
('d', 'g'), ('d', 'h'), ('d', 'o'), ('d', 'p'), ('d', 'q'),
('e', 'f'), ('e', 'o'),
('f', 'i'), ('f', 'j'), ('f', 'l'), ('f', 'p'), ('f', 't'),
('g', 'j'), ('g', 'o'), ('g', 'p'), ('g', 'q'), ('g', 'y'),
('h', 'k'), ('h', 'l'), ('h', 'm'), ('h', 'n'), ('h', 'r'),
('i', 'j'), ('i', 'l'), ('i', 't'), ('i', 'y'),
('j', 'l'), ('j', 'p'), ('j', 'q'), ('j', 'y'),
('k', 'x'),
('l', 't'),
('m', 'n'), ('m', 'w'),
('n', 'u'), ('n', 'z'),
('o', 'p'), ('o', 'q'), ('o', 'u'), ('o', 'v'),
('p', 'q'), ('p', 'r'),
('q', 'y'),
('s', 'z'),
('u', 'v'), ('u', 'w'), ('u', 'y'),
('v', 'w'), ('v', 'y')
)

Feel free to review and comment current wordlist, but I think we're slowly
moving forward final list.

slush


On Sat, Oct 19, 2013 at 1:58 AM, Gregory Maxwell gmaxw...@gmail.com wrote:

 some fairly old wordlist solver code of mine:

 https://people.xiph.org/~greg/wordlist.visual.py

 it has a 52x52 letter visual similarity matrix in it (along with a
 citation)

 On Fri, Oct 18, 2013 at 4:52 PM, jan jan.mare...@gmail.com wrote:
 
  The words 'public', 'private' and 'secret' could be confusing when
  encoding public and private keys. eg. a private key that begins with
  the word 'public'.
 
  I think avoiding words that could look similar when written down would
  be a good idea aswell. I searched for words that only differ by the
  letters c  e, g  y, u  v and found the following:
 
  car ear
  cat eat
  gear year
  value valve
 
  Other combinations could potentially be problematic depending on the
  handwriting style: ft, ao, ij, vy, possibly even lt and il?
 
  I've included the search utility I used below.
 
 
  #include stdbool.h
  #include string.h
  #include stdio.h
 
  char *similar_char_pairs[] = { ce, gy, uv, NULL };
 
  bool is_similar_char(char c1, char c2)
  {
char **pairs = similar_char_pairs;
do {
  char *p = *pairs;
  if ((c1 == p[0]  c2 == p[1]) ||
  (c1 == p[1]  c2 == p[0]))
return true;
} while (*++pairs);
 
return false;
  }
 
  bool print_words_if_similar(char *word1, char *word2)
  {
/* reject words of different lengths */
if (strlen(word1) != strlen(word2))
  return false;
 
size_t i, similarcount = 0;
 
for (i = 0; i  strlen(word1); i++) {
  /* skip identical letters */
  if (word1[i] == word2[i])
continue;
 
  /* reject words that don't match */
  if (is_similar_char(word1[i], word2[i]) == false)
return false;
 
  similarcount++;
}
 
/* reject words with more than 1 different letter */
//if (similarcount  1)
//  return false;
 
printf(%s %s\n, word1, word2);
 
return true;
  }
 
  int main(void)
  {
/* english.txt is assumed to exist in the working directory
   download from:
 
 https://github.com/trezor/python-mnemonic/blob/master/mnemonic/wordlist/english.txt*/
FILE* f = fopen(english.txt, r);
if (!f) {
  fprintf(stderr, failed to open english.txt\n);
  return 1;
}
 
/* read in word list, assumes one word per line */
#define MAXWORD 16
char wordlist[2048][MAXWORD];
int word = 0;
while (fgets(wordlist[word], MAXWORD, f)) {
  /* strip trailing whitespace, assumes no leading whitespace */
  char *ch = strpbrk(wordlist[word],  \n\t);
  if (ch)
*ch = '\0';
  word++;
}
 
if (word != 2048) {
  fprintf(stderr, word list incorrect length\n);
  return 1;
}
 
/* check each word for similarity against every other word */
int i, j, count = 0;
for (i = 0; i  2048; i++) {
  for (j = i+1; j  2048; j++) {
if (print_words_if_similar(wordlist[i], wordlist[j]))
  count++;
  }
}
 
printf(%d matches\n, count);
 
return 0;
  }
 
 
 --
  October Webinars: Code for Performance
  Free Intel webinars can help you accelerate application performance.
  Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most
 from
  the latest Intel processors and coprocessors. See abstracts and register
 
 
 http://pubads.g.doubleclick.net/gampad/clk?id=60135031iu=/4140/ostg.clktrk
  ___
  Bitcoin-development mailing list
  Bitcoin-development@lists.sourceforge.net
  https://lists.sourceforge.net/lists/listinfo/bitcoin-development

Re: [Bitcoin-development] Proposal to replace BIP0039

2013-10-24 Thread slush
On Thu, Oct 24, 2013 at 7:29 PM, thoma...@gmx.de wrote:


 My initial problem was that BIP0039 is not backward compatible with
 Electrum. When trying to solve that, I realized that the seed encoding used
 in Electrum does not help, because it does not contain a version number
 information. However, BIP0039 suffers the same shortcoming: it does nothing
 to help a future replacement, it wants to be final. My first recommendation
 is to allocate a few bits of the mnemonic, in order to encode a version
 number along with the checksum bits.


Two years ago I proposed exactly this and you refused to add extra
information to mnemonic, because it isn't necessary and it makes it
longer to mnemonization. What changed since then?


 The second problem is the wallet structure. There are multiple ways to use
 a BIP32 tree, and each client will certainly handle this differently. For
 Electrum, it is important to be able to recover an entire wallet from its
 mnemonic, using no extra information. Thus, the client needs to know which
 branches of the BIP32 tree are populated by default. This means that the
 version number I mentioned will not only be about the seed encoding, but
 it should also give some information about the wallet structure, at least
 in the case of Electrum.


Hm, what exactly do you need to store about wallet structure? I lived in
opinion that everything is able to recover using CKD function to generate
new addresses and blockchain lookups for their balances.


 The third problem is the dictionary. I do not like the dictionary proposed
 in BIP0039, because it contains too many short words, which are bad for
 memorization (I explained here how I designed the dictionary used by
 Electrum:
 https://bitcointalk.org/index.php?topic=153990.msg2167909#msg2167909). I
 had some discussions with slush about this, but I do not think it will ever
 be possible to find a consensus on that topic.


Yes, that's true. It isn't possible to make everybody 100% happy. At least
I wanted to be constructive and asked you to replace the most problematic
words. No pull request from you so far.


 BIP0039 also suggests to use localized dictionaries, with non-colliding
 word lists, but it is not clear how that will be achieved; it seems to be
 difficult, because languages often have words in common. It looks like a
 first-come-first-served aproach will be used.


Yes, it was original idea. So far I don't think this is a problem. Of
course some words may have some meaning across languages, but it should be
easy to avoid them. There are tens of thousands words in every language and
we need to pick only 2048 words to wordlist.


 For these reasons, I believe that we need a dictionary-independent
 solution. This will allow developers to use the dictionary they like, and
 localization will be easy.

I would like to suggest the following solution:


If I understand this well, it is basically one-way algorithm mnemonic -
seed, right? Seed cannot be printed out as mnemonic, because there's
hashing involved, but the bi-directionality has been the original
requirement for such algorithm (at least in Electrum and bip39).

Then, how is this different to picking 12 random words from dictionary and
hashing them together? I don't see any benefit in that mining part of the
proposal (except that it is lowering the entropy for given length of
mnemonic).


 This solution makes it possible for developers to define new dictionaries,
 localized or adapted to a particular need.


Are your worries about overlapping words across languages a real issue?

slush
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-10-24 Thread slush
We've reflected many comments about BIP39 wordlist from the community and I
think the wordlist is much better now. Specifically we removed many of
theoretically offensive words as well as we implemented algorithm for
detecting words with similar characters (cat/eat) and we resolved these
duplicities. I'm now quite happy with the wordlist and I want to ask you
for next (final?) round of comments.

From other features, we added password protection of seed and seed
hardening (against bruteforcing) using Rijndael cipher. This has been
chosen because its blocksize can be 128, 192 or 256 bits, so it fits length
of desired seeds. Also there are Rijndael implementations in every
language. Btw password protection has one interesting feature - plausible
deniability. It allows user to have one mnemonic and by using it with
different passwords, it will generate different BIP32 wallets (wink
wink)

I want to be pretty clear that we need to close this topic somehow, because
we want to use such algorithm in Trezor (which deadline is coming quick)
and also other wallet developers want to implement such algorithm into
clients to be compatible with Trezor. There were quite strict requirements
for such algorithm (like the possibility to convert mnemonic to seed as
well as seed to mnemonic) and I think we found a good solution. I'm wildly
asking you for constructive comments, but saying it's a crap, I don't like
it won't help anything.

Thanks,
slush


On Thu, Sep 12, 2013 at 6:02 PM, Matthew Mitchell 
matthewmitch...@godofgod.co.uk wrote:

 I removed some more but I haven't added enough back in. It was taking far
 longer than expected so I gave up, but maybe someone else can try to add
 some more:


 https://github.com/MatthewLM/python-mnemonic/blob/master/mnemonic/wordlist/english.txt

 On 12 Sep 2013, at 13:11, Pavol Rusnak st...@gk2.sk wrote:

  On 10/09/13 23:03, Matthew Mitchell wrote:
  Maybe it would have been better without the aggressive words?
 
  I revisited the wordlist and replaced around 67 words that can be
  found offensive in some context.
 
  --
  Best Regards / S pozdravom,
 
  Pavol Rusnak st...@gk2.sk
 
 
 --
  How ServiceNow helps IT people transform IT departments:
  1. Consolidate legacy IT systems to a single system of record for IT
  2. Standardize and globalize service processes across IT
  3. Implement zero-touch automation to replace manual, redundant tasks
 
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
  ___
  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. Consolidate legacy IT systems to a single system of record for IT
 2. Standardize and globalize service processes across IT
 3. Implement zero-touch automation to replace manual, redundant tasks
 http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-10-24 Thread slush
On Thu, Oct 24, 2013 at 9:23 PM, Pieter Wuille pieter.wui...@gmail.comwrote:

 This is a proposal I wrote a year ago, but never spent enough work to
 push it as a standard:
 https://bitcointalk.org/index.php?topic=102349.0


I think that PoW concept in your proposal is quite smart! However the
problem that it isn't bidirectional; it don't allow to convert back and
forth between mnemonic and seed, which was one of basic requirement for
such algorithm.

slush
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-10-24 Thread slush
On Thu, Oct 24, 2013 at 9:32 PM, Jorge Timón jti...@monetize.io wrote:

 This will probably sound stupid to most of you, but I'll say it anyway.

 The aim of mnemonics is to easily remember, isn't it?


Well, I would say more retype than remember. I really don't think that
common user will memorize it. But of course, it is still an option.


 But the approach of removing offensive words is probably
 counterproductive to achieving that end. These words cause a greater
 emotional impact in our human moral psyches.


No, I dont' think it is stupid! Actually it was my concern as well.
Unfortunately I don't think it is politically correct to include all
bitches, assholes and motherfuckers in end user product :-).


 If we were willing to use that fact in our advantage to optimize the
 maximum unforgettableness criterion, we should actually prefer the
 most generally offensive words in that list. Specially if they can
 combine with each other to produce more offensive results, basically
 the opposite of what we're doing.


 Isn't legalize murder dirty jew much easier to remember for most
 people than sandwich house yellow cauliflower?


Well, bip39 can have more dictionaries and *maybe* swearword dictionary
would gain some popularity ;).

slush
--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP39 word list

2013-10-22 Thread slush
I think this is a good idea; I just pushed new unit test test_similarity()
to github which finds such similar words. Right now it identifies ~90
similar pairs in current wordlist, I'll update wordlist tomorrow to pass
this test.

slush

On Sat, Oct 19, 2013 at 1:52 AM, jan jan.mare...@gmail.com wrote:


 I think avoiding words that could look similar when written down would
 be a good idea aswell. I searched for words that only differ by the
 letters c  e, g  y, u  v and found the following:

 car ear
 cat eat
 gear year
 value valve

 Other combinations could potentially be problematic depending on the
 handwriting style: ft, ao, ij, vy, possibly even lt and il?


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60135991iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] bitcoind stops responding

2013-10-01 Thread slush
ad RPC stops working:

* Client makes a 'getinfo' call and don't receive a response in a minute.

What is your precise RPC usage? 

One process is asking getinfo every second as a fallback to possibly
misconfigured blocknotify. It also calls getblocktemplate every 30 second.
Second process is calling getinfo once a minute to check if bitcoind is
working. If it don't receive a response in a minute, it kills bitcoind and
starts it again.

That's all.

OS is Debian.

On Tue, Oct 1, 2013 at 3:17 AM, Jeff Garzik jgar...@bitpay.com wrote:

 Can you please describe more than RPC stops working?  What is your
 precise RPC usage?  getwork?  getblocktemplate?  other calls?  What is
 your OS?


--
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from 
the latest Intel processors and coprocessors. See abstracts and register 
http://pubads.g.doubleclick.net/gampad/clk?id=60134791iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


[Bitcoin-development] Python implementation of RFC 6979

2013-09-10 Thread slush
Hi all,

yesterday I found some time and implemented RFC 6979 into python-ecdsa
module.

RFC 6979 proposes algorithm of calculating 'k' value for signature from
private key and signed data, so the 'k' is unique, but deterministic for
every signature. This enabled simple unit tests of code using ECDSA
signatures as well as some nice use cases for blackbox testing of 3rd party
software (you can calculate on your own if some software is making valid
signature, because there's no randomnes involved in the process). Yes, I'm
referring Trezor :-).

There's my fork of python-ecdsa with RFC 6979:
https://github.com/trezor/python-ecdsa/

There's pull request waiting for python-ecdsa author aproval:
https://github.com/warner/python-ecdsa/pull/10

Aaand there's RFC 6979: tools.ietf.org/html/rfc6979

Thanks,
slush
--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-09-10 Thread slush
In many iterations of editing the wordlist we made our best to pick
words which are easy to remember, still neutral. Unfortunately it's
almost impossible to exclude some words which may together create
negative co-notations.

Thankfully we removed all racist and religious words so I believe all
three authors mentioned in the BIP are safe against fundamentalist
bitcoin users :-).

slush

On 9/10/13, Matthew Mitchell matthewmitch...@godofgod.co.uk wrote:
 I like this, though maybe sometimes you'll get rude word combinations come
 out.

 Matthew

--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] BIP0039 Mnemonic code for generating deterministic keys

2013-09-10 Thread slush
We're open to changes in the wordlist. We'll accept pull request
replacing potentially offensive words by another more neutral, which
also fits all other requirements.

Putting the wordlist together is really hard job and we spent few
sleepless nights on that. By the way, words murder, black, people
are contained also in Electrum wordlist and nobody complained yet :-).

slush

On 9/11/13, Gregory Maxwell gmaxw...@gmail.com wrote:
 On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell
 matthewmitch...@godofgod.co.uk wrote:
 Well let's hope something like murder black people, stupid asian
 person or whip african slave doesn't come up. :-) Maybe it would have
 been better without the aggressive words?

 Ouch.

 This sounds like something that $20 of mechanical turk time could help
 out with a lot.  Put up the 2048 words and ask people to rate them for
 potential offensiveness and threatening. :)

 Nouns often make for fairly neutral words, though careful for place
 names which have had political complications. E.g. gdansk vs danzig.


--
How ServiceNow helps IT people transform IT departments:
1. Consolidate legacy IT systems to a single system of record for IT
2. Standardize and globalize service processes across IT
3. Implement zero-touch automation to replace manual, redundant tasks
http://pubads.g.doubleclick.net/gampad/clk?id=5127iu=/4140/ostg.clktrk
___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Version 0.9 goals

2013-08-15 Thread slush
 Pieter, Matt and I also agreed that for maximum impact we should really
 try to ship payment protocol support in at least two clients simultaneously
 and ideally with a big merchant signed up too - to send a powerful message
 that we really mean it. Someone volunteered last week to do it for bitcoinj
 and if he doesn't pull through, I have some old code from EOY 2012 that I
 could update to the latest spec and ship at least some basic support. I'd
 hope that we can get Bitcoin Wallet or MultiBit updates out once bcj has
 support pretty fast.


We're planning to support payment protocol in Trezor as well, if it counts.
I think it's a missing piece in absolute security of hardware wallets.

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


Re: [Bitcoin-development] Version 0.9 goals

2013-08-15 Thread slush
On Thu, Aug 15, 2013 at 11:02 AM, Mike Hearn m...@plan99.net wrote:

 On Thu, Aug 15, 2013 at 10:22 AM, slush sl...@centrum.cz wrote:

 We're planning to support payment protocol in Trezor as well, if it
 counts. I think it's a missing piece in absolute security of hardware
 wallets.


 Yup, that's always been the plan :-)

 Any idea how much work it is, and would it be a v1 feature of the Trezor
 or added later via firmware update?


Our plan is to add support for that into v1 firmware, but it also depends
on readiness of surrounding infrastructure; mainly if there'll be support
for payment protocol in multibit in the time of v1 release (I suppose that
the Multibit will be the first wallet  compatible with Trezor AND
supporting payment protocol).

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


Re: [Bitcoin-development] 0.8.1 ideas

2013-03-13 Thread slush
Agree. I quite like Mark's proposal. Yes, formally it is hard fork. But the
step 4) can come very far in the future, when the penetration of 0.8
clients will be mininimal.

slush

On Wed, Mar 13, 2013 at 7:27 PM, Mark Friedenbach m...@monetize.io wrote:

 This problem is very clearly a *bug* in the old codebase. So let's be
 forward thinking and do what we would do in any other situation: fix the
 bug, responsibly notify people and give them time to react, then move on.
 Let's not codify the bug in the protocol.

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

2012-12-04 Thread slush
Jim, perfect idea with some logo indicating wallet compatibility! This
should cover BIP32 + some mnemonic algorithm for easy transferring of
wallets across various clients.

Btw I asked ThomasV for making BIP from his mnemonic algorithm and he
agreed, so I believe some proposal will be here pretty soon.

slush

On Tue, Dec 4, 2012 at 7:56 PM, Jim jim...@fastmail.co.uk wrote:

 Also, as BIP32 support is added to clients and codebases then the actual
 variant of software to use to access your wallet will become relatively
 less important. Combined with a standardised seed - passphrase
 algorithm the user can just type in their long passphrase into any BIP32
 compliant software and click/ buzz/ whirr : there is their wallet. We
 should have a little logo for HD wallet compliance ! :-)


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

2012-11-29 Thread slush
Hi,

not sure if you already noticed, but I and my friends are actively working
on bitcoin hardware wallet. This should be pocket size device with
something like 256kB flash and 80 MHz CPU, talking with the computer over
USB. User will prepare transaction on the machine, send it to the device,
device shows target address on the display and user confirms it by pressing
the button.

We're trying to make bitcoin payments safe even on hacked computer. For
this reason we're also implementing SPV so device don't need to trust
computer with any kind of information. The biggest existing problem is that
user cannot be sure that the address displayed on computer screen is
correct and he's confirming valid address.

I don't have any solution for this problem yet. I just appreciate an
activity in payment protocol area, because it can (with some care) solve
this problem and my appeal si to keep all this simple. I'd be very happy
with simple payment protocol which can be implemented even on devices like
I'm working on, so device with few widely used certificates stored in the
memory will be able to display origin of the invoice and confirm its
validity.

slush


On Thu, Nov 29, 2012 at 1:30 AM, Watson Ladd w...@uchicago.edu wrote:

 After doing more thinking, what about letting a spend sign more
 information associated with the transaction, such as a transaction ID
 provided by the merchant? This seems to solve a lot of the problems being
 put forward, with much less complexity.

 --
 Keep yourself connected to Go Parallel:
 VERIFY Test and improve your parallel project with help from experts
 and peers. http://goparallel.sourceforge.net
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Keep yourself connected to Go Parallel: 
VERIFY Test and improve your parallel project with help from experts 
and peers. http://goparallel.sourceforge.net___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] IRC meeting agenda, 18:00 UTC Thursday

2012-11-06 Thread slush
On Tue, Nov 6, 2012 at 7:13 PM, Luke-Jr l...@dashjr.org wrote:

 But more important to the success of BIP today, I think, is encouraging
 wider
 community participation.


It's not about BIP process, it's possibly about content of particular
proposals.


 The stratum mining mess seems to be a direct result


There's no mess with stratum mining, except in your head. There's no
requirement to have BIP for everything what people do. Stratum is NOT
related to bitcoin protocol or bitcoin implementation, it is just custom,
pooled-mining extension and bitcoin network doesn't need to know about
Stratum existence at all.


 and lack of any peer review/contribution toward the stratum protocol.


There have been peer review of the protocol. You wanted to say I was not
invited to do peer review, right?

Please don't start it AGAIN and stop bashing Stratum in your posts, at
least in bitcoin-dev mailing list.

I promised to write BIP draft for Stratum, I proposed and implemented
get_transactions method to allow Stratum jobs inspection. What more do you
want, seriously? I'm soo tired by you, Luke.

slush

P.S. I'm sorry that other developers had to read such posts. I'll try to
sit on my hands next time.
--
LogMeIn Central: Instant, anywhere, Remote PC access and management.
Stay in control, update software, and manage PCs from one command center
Diagnose problems and improve visibility into emerging IT issues
Automate, monitor and manage. Do more in less time with Central
http://p.sf.net/sfu/logmein12331_d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] IRC meeting Tuesday, Feb 14, 21:00 UTC

2012-02-13 Thread slush
Hello Gavin,

excuse me, but do you think it's good idea to have IRC meeting on
Valentine's evening? Some of us have girlfriends :-).

slush

On Tue, Feb 14, 2012 at 3:49 AM, Gavin Andresen gavinandre...@gmail.comwrote:

 Tomorrow, Feb 14'th at 21:00 UTC on #bitcoin-dev on Freenode IRC I'd
 like to chat about:

 Status of BIP 16 support (progress towards 50% hashing power).

 Protocol change coming up Feb. 20 (checksums in version messages).

 Duplicate coinbase issue (and requiring block height in the coinbase
 as a solution).

 Then when we're done talking tech we can all send each other bitcoins
 with addresses that are cute Valentine's day messages...

 --
 --
 Gavin Andresen


 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


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

2012-01-16 Thread slush
  I agree Bitcoin should avoid making any bold political stands.

I agree on this. Please don't turn Bitcoin project/homepage into some
political agitation. Not everybody care about political attitude of main
project developers.

slush

On Tue, Jan 17, 2012 at 1:46 AM, Alan Reiner etothe...@gmail.com wrote:

 **
 You guys are representing both extremes of the issue.  In response to Jeff
 and Luke-Jr, I don't see how this is *just any other poltical issue*.  It
 strikes at the heart of everything Bitcoin is about.  Barring
 Bitcoin-specific legislation, I don't see how any legislation could be more
 relevant to Bitcoin and the community around it.

 On the other hand, Bitcoin is still a non-entity, and shouldn't get in the
 business of making statements.  A central voice for Bitcoin gives the
 impression that it is actually centralized, and one that has opinions.
 Plus I wouldn't be surprised if some, heavily-invested Bitcoin users were
 of the opinion that SOPA/PIPA/whatever could be a huge profit for
 themselves:  once SOPA kicks in and businesses around the world start
 getting cut off for legit or illegitimate purposes, a lot of them could
 potentially switch to Bitcoin to keep their business going.  That could be
 a huge boon for Bitcoin.  You may not agree it's worth the tradeoff, but
 people are selfish and may not actually understand or even care about SOPA
 legislation itself.

 I think it's *not inappropriate* for something to be mentioned on the
 website about Bitcoin's philosophy being threatened by SOPA, but I agree
 Bitcoin should avoid making any bold political stands.  Users could be
 reminded that SOPA affects yet another thing they care about, but it might
 be better to avoid it altogether.  If any response is made, it should be a
 very light one.

 -Alan



 On 01/16/2012 07:30 PM, Amir Taaki wrote:

 Bunk argument. This is an issue that affects bitcoin directly.

 Wikipedia has far more need to remain neutral and apolitical than bitcoin 
 ever does- you've read Satoshi's politically charged whitepaper or seen the 
 genesis block quote.
 http://en.wikipedia.org/wiki/Wikipedia:SOPA_initiative/Action

 The Wikipedia community decided on a full and global blackout. Bitcoin should 
 do the same in unison with the rest of the web- sites like Reddit, 4chan and 
 Wikipedia.

 It's funny / almost comical how you consign this to being just another issue 
 or case of moral alarm. Sad.



 - Original Message -
 From: Jeff Garzik jgar...@exmulti.com jgar...@exmulti.com
 To: Amir Taaki zgen...@yahoo.com zgen...@yahoo.com
 Cc: bitcoin-development@lists.sourceforge.net 
 bitcoin-development@lists.sourceforge.net 
 bitcoin-development@lists.sourceforge.net 
 bitcoin-development@lists.sourceforge.net
 Sent: Sunday, January 15, 2012 10:37 PM
 Subject: Re: [Bitcoin-development] bitcoin.org SOPA/PIPA blackout

 On Sun, Jan 15, 2012 at 5:09 PM, Amir Taaki zgen...@yahoo.com 
 zgen...@yahoo.com wrote:

  How is this not the most important world issue right now?

 EVERYTHING is under threat. Go nuclear to show our nerd-rage.

 Everybody blank your personal sites too. Americans, take to the streets. 
 World, go scream at the US embassy.

  There are always issues that raise ire and moral outrage.  I would
 rather that bitcoin.org stay apolitical -- our users will appreciate
 this in the long run.





 --
 Keep Your Developer Skills Current with LearnDevNow!
 The most comprehensive online learning library for Microsoft developers
 is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
 Metro Style Apps, more. Free future releases when you subscribe now!
 http://p.sf.net/sfu/learndevnow-d2d
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Keep Your Developer Skills Current with LearnDevNow!
The most comprehensive online learning library for Microsoft developers
is just $99.99! Visual Studio, SharePoint, SQL - plus HTML5, CSS3, MVC3,
Metro Style Apps, more. Free future releases when you subscribe now!
http://p.sf.net/sfu/learndevnow-d2d___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] [BIP 15] Aliases

2011-12-18 Thread slush
Pieter, it was more rhetorical question than asking for explanation, but
thanks anyway. As an Internet application developer, I of course understand
security issues while using HTTPS and CA.

I have a gut feeling that there simply does not exist any single solution
which is both easy to use and secure enough. At least nobody mentioned it
yet. And if I need to choose between easy solution or secure solution for
aliases, I'll pick that easy one. I mean - we need some solution which will
be easy enough for daily use; it is something what we currently don't have.
But if I want to be really really sure I'm using correct destination for
paying $1mil for a house, I can every time ask for real bitcoin addresses,
this is that secure way which we currently have.

slush

On Mon, Dec 19, 2011 at 2:14 AM, Pieter Wuille pieter.wui...@gmail.comwrote:

 On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wrote:
  Maybe I'm retarded, but where's the point in providing alliases
 containing
  yet another hash in URL?

 Any DNS-based alias system is vulnerable to spoofing. If I can make
 people's
 DNS server believe that mining.cz points to my IP, I'll receive payments
 to
 you...

 If no trusted CA is used to authenticate the communication, there is no way
 to be sure the one you are asking how to pay, is the person you want to
 pay.
 Therefore, one solution is to put a bitcoin address in the identification
 string itself, and requiring SSL communication authenticated using the
 respective key.

 This makes the identification strings obviously less useful as aliases,
 but pure aliases in the sense of human-typable strings have imho
 limited usefulness anyway - in most cases these identification strings
 will be communicated through other electronic means anyway.

 Furthermore, the embedded bitcoin address could be hidden from the user:
 retrieved when first connecting, and stored together with the URI in
 an address book. Like ssh, it could warn the user if the key changes
 (which wil be ignored by most users anyway, but what do you do about
 that?)

 --
 Pieter


 --
 Learn Windows Azure Live!  Tuesday, Dec 13, 2011
 Microsoft is holding a special Learn Windows Azure training event for
 developers. It will provide a great way to learn Windows Azure and what it
 provides. You can attend the event by watching it streamed LIVE online.
 Learn more at http://p.sf.net/sfu/ms-windowsazure
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development

--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development


Re: [Bitcoin-development] Fwd: [BIP 15] Aliases

2011-12-15 Thread slush
I really like this proposal with standard URLs. All other proposals like
DNS mapping or email aliases converted to URLs with some weird logic looks
strange to me.

Plain URLs (returning address in response body, redirecting to URI
bitcoin:address or anything else) are very clear solution, easy to
implement in clients and very easy to understand by people. It's also
extremely flexible - almost everybody can somewhere setup static file
containing his personal addresses or it's very easy to integrate such
solution with eshops (providing custom address for given order) etc. I'm
definitely for this solution.

Best,
slush

On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins andypark...@gmail.com wrote:

 On 2011 December 13 Tuesday, Amir Taaki wrote:

  Maybe I wasn't clear enough in the document, but this is the intent with
  the HTTPS proposal.

 I don't like the idea of a hard-coded mapping at all.  We shouldn't be
 making
 choices on behalf of server operators.  It's up to them how they arrange
 their
 domain names and paths.

 I also agree that DNS is not the technology to use.  DNS is a nightmare.

  gen...@foo.org
 
  Contacts https://foo.org/bitcoin-alias/?handle=genjix and the system
  responds with a bitcoin address. Whether the system gives you a new
  address from a pool of addresses, or contacts the merchant behind the
  scenes is implementation defined.
 
  I'll clarify it later. This is the relevant line:
 
  string strRequestUrl = strDomain + /bitcoin-alias/?handle= +
  pszEncodedNick;
 
  Between HTTPS service and server service, I lean slightly towards HTTPS
  (automatic encrypted connection, CAs + all benefits of DNS). But still
  interested in arguments in favour of a server service (daemon answering
  queries).

 Why bother with an encoding scheme at all?  If the address

  gen...@foo.org

 always maps to

  https://foo.org/bitcoin-alias/?handle=genjix

 Then forget the hardcoding of https the hardcoding of bitcoin-alias and
 ?handle= and the original email-looking gen...@foo.org.  Just use the
 URL.
 Then the author of the service can use whatever they want.

  Can I pay you 10 BTC?
  Sure, send it to 'https://bitcoinalias.foo.org/genjix/'

 While I might implement my alias server like this:

  Sure, send it to 'https://google.com/bitcoin/?andyparkins'
  Sure, send it to 'https://parkins.co.uk/;

 ... or any other URL they want -- any of which suit might suit me and my
 webserver better than whatever mapping would otherwise be hard-coded.  The
 world is already very familiar with URLs so this is no more scary than the
 email address.  What's more, the email address form looks _too much_ like
 an
 email address, and will only lead to confusion ... send it to
 gen...@foo.org
 so I use outlook express for that, right?  erm, no, you put it in your
 bitcoin client.

 The URL form could easily be made to detect a browser connecting rather
 than a
 bitcoin client (and this is an area that would benefit from a standards
 document -- define the headers and user agent triggers that an alias server
 expects) and give them better instructions.

 https can be specified as the default, so  https://; can be optional when
 they're typing.  If, in the future, bitcoin gets a distributed peer-to-peer
 alias system, then a new URL type can be added easily
 bcalias://andyparkins
 might automatically find my node in the network and query it for an address
 (or whatever).

 All of the above is exactly why OpenID chose to use URLs for ID.



 Andy

 --
 Dr Andy Parkins
 andypark...@gmail.com


 --
 Systems Optimization Self Assessment
 Improve efficiency and utilization of IT resources. Drive out cost and
 improve service delivery. Take 5 minutes to use this Systems Optimization
 Self Assessment. http://www.accelacomm.com/jaw/sdnl/114/51450054/
 ___
 Bitcoin-development mailing list
 Bitcoin-development@lists.sourceforge.net
 https://lists.sourceforge.net/lists/listinfo/bitcoin-development


--
Learn Windows Azure Live!  Tuesday, Dec 13, 2011
Microsoft is holding a special Learn Windows Azure training event for 
developers. It will provide a great way to learn Windows Azure and what it 
provides. You can attend the event by watching it streamed LIVE online.  
Learn more at http://p.sf.net/sfu/ms-windowsazure___
Bitcoin-development mailing list
Bitcoin-development@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/bitcoin-development