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 a
On Wed, Mar 11, 2015 at 6:14 PM, Mike Hearn 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 d
You're right, there can be done some optimizations. Workarounds of
workaround. All this adds complexity, which reduces the security.
Marek
On Fri, Jan 23, 2015 at 7:51 PM, Gregory Maxwell wrote:
> On Fri, Jan 23, 2015 at 5:40 PM, slush wrote:
> > Yes, the step you're missin
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 me
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 sh
On Fri, Jan 23, 2015 at 5:05 PM, Gregory Maxwell 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
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 wrote:
> Unfortunately, one major attack vector is someone isolat
a 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://bitcointal
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 vali
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
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 wr
On Thu, Jul 17, 2014 at 6:14 PM, Jeff Garzik 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
tractio
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
ng for the payment itself. Put these marketing claims to memo field
instead...
slush
On Tue, Jun 24, 2014 at 4:24 PM, Mike Hearn 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 websi
ke Stratum...
slush
On Thu, Jun 19, 2014 at 10:39 PM, Mark Friedenbach 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 sim
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 s
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 P
On Wed, Apr 23, 2014 at 10:54 PM, Pieter Wuille wrote:
>
> 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
On Wed, Apr 23, 2014 at 9:55 PM, Luke-Jr 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 o
We do not want BIP64 to be incompatible with BIP32 in any way. BIP64 is
just set of some recommendations for wallet developers how to browse bip32
tree.
Modifying serialization format would break the compatibility.
However we have our solution for storing wallet birth time, which is out of
scope
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 (actu
For those who don't follow github pull requests regularly; there's pull
request for BIP64 defining HD wallet structure as discussed in this thread:
https://github.com/bitcoin/bips/pull/52
On Wed, Apr 23, 2014 at 8:01 PM, slush wrote:
>
>
>
> On Wed, Apr 23, 2014 at
On Wed, Apr 23, 2014 at 7:42 PM, Pieter Wuille wrote:
>
> 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
n Wed, Apr 9, 2014 at 10:35 PM, Wladimir wrote:
>
>
> On Wed, Apr 9, 2014 at 10:12 PM, slush wrote:
>
>> Maybe there're other ideas how to improve current situation without needs
>> of reworking the architecture.
>>
>
> Nothing I've proposed here would requi
ading 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 wrote:
> I believe there&#
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 net
On Tue, Apr 8, 2014 at 5:58 PM, Andreas Schildbach wrote:
> On 04/08/2014 05:46 PM, slush wrote:
>
> > 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 a
On Tue, Apr 8, 2014 at 4:49 PM, Andreas Schildbach wrote:
> 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 B
On Tue, Apr 8, 2014 at 3:53 PM, Pieter Wuille wrote:
> 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 cha
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
On Tue, Apr 8, 2014 at 3:18 PM, Pieter Wuille wrote:
> 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
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
On Fri, Apr 4, 2014 at 5:37 PM, Mike Hearn 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 t
On Fri, Apr 4, 2014 at 5:09 PM, Eric Larchevêque wrote:
> On Fri, Apr 4, 2014 at 4:56 PM, slush wrote:
>
>> 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.
>>
>
On Fri, Apr 4, 2014 at 4:51 PM, Mike Hearn wrote:
>
> I don't want to suggest the problem is unimportant - I'd love it if the
> world could move beyond passwords. But I have many scars from my time in
> the Google account swamps. We had a big team, lots of resources and even
> just getting people
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, m
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
I fully agree, please keep friendly environment on this list. Btw I also
met people who were making fun about Peter's reactions on bitcoin-dev.
slush
On Tue, Mar 25, 2014 at 7:02 PM, Alan Reiner wrote:
> I would echo the need for some kind of moderation.
>
> I believe Pe
Internal accounting in satoshis.
Display based on locale.
Problem solved.
On Thu, Mar 13, 2014 at 5:30 PM, Tamas Blummer wrote:
> BTW, its not like this would be the first time this was raised, instead
> the "ship left" while ignoring arguments.
>
> The idea of is up there for votes since March
rezor 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 wrote:
> > On Mon, Jan 20, 2014 at 04:05:14PM -0600, Brooks Boyd wrote:
> >> On Mon, Jan 20, 2014
e 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
--
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 Fo
> But where are the private keys stored? Crypto in the browser with help,
but although they will expose ECC via the NSS, I dont think bitcoin's
particular curve will be supported, because it's not NIST approved. If the
use case was presented though, they may add it.
Trezor, my f
which can contain some evil data.
B)
Same structured data should be a part of html page in some header tag,
ideally signed by server certificate to confirm that the request is valid.
Then the login request can be processed by machine automatically, without a
need of copy&paste by a user.
Slush
7;o'),
> > ('f', 'i'), ('f', 'j'), ('f', 'l'), ('f', 'p'), ('f', 't'),
> > ('g', 'j'), ('g', 'o'), ('g', 'p&
but right now it is a showstopper for us.
Marek
On Thu, Oct 31, 2013 at 12:11 PM, slush wrote:
>
> bip39:
> + bi-directional
> + passphrase protected
> + shorter mnemonic or shorter wordlist
> - predefined wordlist
>
> ThomasV proposal:
> + any software can has its
On Thu, Oct 31, 2013 at 10:13 AM, Thomas Voegtlin 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
Strange, I didn't receive the response from sipa in separate message, so
I'll respond to him at first place.
Le 26/10/2013 23:30, Pieter Wuille a écrit :
> I'm not sure whether we're ready to standardize on something like that
> yet, not having established best practices regarding different wallet
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 specific
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
-
he
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
ssion, because we already
discussed all this privately, you didn't tell me any reason why this should
not work and still I see that this is coming back as a boomerang.
slush
--
October Webinars: Code for Performance
Fr
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.
Than
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.
'g', 'q'), ('g', 'y'),
('h', 'k'), ('h', 'l'), ('h', 'm'), ('h', 'n'), ('h', 'r'),
('i', 'j'), ('i', '
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 wrote:
>
&
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 c
ving similar problem?
Thanks,
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 fr
t;murder, black, people"
are contained also in Electrum wordlist and nobody complained yet :-).
slush
On 9/11/13, Gregory Maxwell wrote:
> On Tue, Sep 10, 2013 at 2:03 PM, Matthew Mitchell
> wrote:
>> Well let's hope something like "murder black people", "stupid a
o I believe all
three authors mentioned in the BIP are safe against fundamentalist
bitcoin users :-).
slush
On 9/10/13, Matthew Mitchell wrote:
> I like this, though maybe sometimes you'll get rude word combinations
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
-
monic algorithm.
BIP39 is a nice complement to BIP32, which allow users to (paper) backup
and share their wallet accross multiple clients easily.
Link to BIP: https://en.bitcoin.it/wiki/BIP_0039
Thanks for your time,
slush
-
On Thu, Aug 15, 2013 at 11:02 AM, Mike Hearn wrote:
> On Thu, Aug 15, 2013 at 10:22 AM, slush 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.
t;
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
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 wrote:
> This problem is very clearly a *bug* in the o
soon.
slush
On Tue, Dec 4, 2012 at 7:56 PM, Jim 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
> algo
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.
slus
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 develop
I agree. Just imagine those two-inches newspaper titles - "Bitcoin
hacked! Backdoor in official bitcoin client!". We have already some
experience with shortcuts which journalists do...
slush
On Mon, Jul 9, 2012 at 1:34 PM, Jorge Timón wrote:
> Should the web promote them?
> Afte
Hi,
is there any status update from Deepbit? Why he still does not support
anything...
slush
On Tue, Mar 6, 2012 at 4:46 PM, Luke-Jr wrote:
> BIP16: 37% support vs 4% oppose
> BIP17: 4% support vs 0%
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 wrote:
> Tomorrow, Feb 14'th at 21:00 UTC on #bitcoin-dev on Freenode IRC I'
Very interesting. Do you have any plans to push your refactored code into
Bitcoin upstream for future releases someday?
slush
On Wed, Feb 1, 2012 at 3:18 PM, Michael Grønager wrote:
> Dear Bitcoiners,
>
> libcoin is now in a state ready for its first release, which I would like
> t
ers across of all implementations - and it's not only
about json-rpc.
Otherwise I agree, BIP 21 is better than BIP 20 because it's easier to
implement all points of the standard.
Best,
slush
On Tue, Jan 31, 2012 at 3:27 PM, Amir Taaki wrote:
> BIP 20 really has no support among impl
> 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 Reine
t;,
"label" and other parts). I don't see reason why we need some extra payload
yet.
slush
On Mon, Dec 19, 2011 at 7:13 PM, Jordan Mack wrote:
> If the idea is to "KISS", and provide a method that is both quick and
> easy to implement for the average developer, then JS
ssues, but it's another story).
slush
On Mon, Dec 19, 2011 at 6:04 PM, Jordan Mack wrote:
> I thought that JSON support was fairly common these days. I personally
> prefer XML in most cases, but since JSON is already used with the RPC,
> it seemed like a natural fit here. Binary da
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 wrote:
> On Mon, Dec 19, 2011 at 12:58:37AM +0100, slush wr
Maybe I'm retarded, but where's the point in providing alliases containing
yet another hash in URL?
slush
On Sun, Dec 18, 2011 at 10:44 PM, Luke-Jr wrote:
> On Sunday, December 18, 2011 4:05:11 PM Jorge Timón wrote:
> > If we chose the simple URI proposal namecoin can
rstand won't solve the situation, because it will ends up with
some reference implementation in standard client only and nobody else will
use it.
slush
On Fri, Dec 16, 2011 at 6:23 PM, Khalahan wrote:
> **
> Namecoin is a peer-to-peer generic name/value datastore system.
> Don't
l free to provide me some relevant RFCs which are solving
similar problems like BIP 15. And no, it's not sarcasm, I really want to
learn something new. Until now I just feel we're reinventing wheel or
raping some stuff which we should not touch at all (DNS).
slush
On Fri, Dec 16, 2011 at 4:52 PM
) etc. I'm
definitely for this solution.
Best,
slush
On Tue, Dec 13, 2011 at 5:22 PM, Andy Parkins 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.
>
81 matches
Mail list logo
