see lots
of strange nodes and suspicious patterns. You can be certain that we were
not the only ones connected to many nodes.
My takeaway from this: If nodes that do not relay transactions is a problem
then there is stuff to fix.
/Jan
On Fri, Mar 13, 2015 at 10:48 PM, Mike Hearn wrote:
>
ing bitpay at all if you
> are already going through the effort to remove a signature and
> change the memo field?
For their tie-in with the traditional banking system, i.e. cash-out in
fiat. Here in Germany that might currently be the only feasible way of
accepting bitcoins commercially, bec
com/schildbach/bitcoin-wallet/blob/master/wallet/src/de/schildbach/wallet/offline/DirectPaymentTask.java#L238
The latter should probably be at least changed to the reverse check as
for HTTP, but in general some non-memo way of doing that would be nice
of course.
Jan
--
fine with doing changes here - I don't think there is all that much
stuff out there yet which would break from it. At the moment I'm also
modifying BitPay's memo field to contain 'ack', as Andreas' wallet
otherwise reports a failure if I transmit the original via B
to 'repeated string
payment_url' or would you rather introduce a new field
'additional_payment_urls'?
2) @Andreas: Is the r, r1, r2 mechanism already implemented in Bitcoin Wallet?
3) Are there other comments regarding 'h' parameter as per TBIP75?
4) General commen
;
> - the only hash function in use is SHA-256, which is the all-purpose
> hash function in the Bitcoin protocol;
> - double SHA is used for similarity with Bitcoin, although Jan and I
> believe single SHA is enough in this application;
> - bias-less encoding of M and x, because
>Of course, this is an especially difficult case, as you must send the
>double-spend after the original transaction - normally just sending a
>non-standard tx to Eligius first would suffice. Note how this defeats
>Andresen's double-spend-relay patch(3) as proposed since the
>double-spend is a non-s
Treating testnet differently is quite the norm, we have that in BIP 32, 38,
70, SIPA private keys (no BIP for that I guess), bitcoin addresses etc. At
the same time none of them define values for alt coins as far as I recall.
On Tue, Apr 22, 2014 at 5:49 PM, Tamas Blummer wrote:
> I use several
Tue, Apr 22, 2014 at 1:06 AM, Jan Møller wrote:
> > This is a very useful BIP, and I am very much looking forward to
> > implementing it in Mycelium, in particular for bip32 wallets.
>
> I haven't seen commentary from you on the Kogelman draft, it would be
> helpful there:
I am concerned about space, but more about usability :-)
I'll definitely use both M and the checksum.
On Tue, Apr 22, 2014 at 10:43 AM, Matt Whitlock wrote:
> On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> > Necessary Shares = M+1, not a problem
> >
> >
Necessary Shares = M+1, not a problem
I would probably encode N-of-M in 1 byte as I don't see good use cases with
more than 17 shares. Anyway, I am fine with it as it is.
On Tue, Apr 22, 2014 at 10:29 AM, Matt Whitlock wrote:
> On Tuesday, 22 April 2014, at 10:27 am, Jan Møll
>
>
> > - Please allow M=1. From a usability point of view it makes sense to
> allow
> > the user to select 1 share if that is what he wants.
>
> How does that make sense? Decomposing a key/seed into 1 share is
> functionally equivalent to dispensing with the secret sharing scheme
> entirely.
>
>
trong opinions of whether to use GF(2^8) over Shamir's Secret
Sharing, but the simplicity of GF(2^8) is appealing.
- Jan
On Fri, Apr 11, 2014 at 12:31 AM, Nikita Schmidt <
nik...@megiontechnologies.com> wrote:
> > What do you think a big-integer division by a word-sized divisor *is
can be used
for generating a parallel hierarchy for authentication purposes.
- Jan
--
Start Your Social Network Today - Download eXo Platform
Build your Enterprise Intranet with eXo Platform Software
Java Based Open Source
On Thu, Mar 06, 2014 at 02:39:52PM +, Alex Kotenko wrote:
> Not sure if you've seen it, but here is how we do NFC right now
> http://www.youtube.com/watch?v=DGOMIG9JUY8 with XBTerminal.
Very interesting, thanks for sharing! Are the two devices on the same
wifi network in the demo? In my experi
reward value so that the system would not
collapse.
I may be completely wrong with my idea but am asking it this was spoken
before and what opinions do developers have.
Regards,
Jan
--
Rapidly troubleshoot problems before
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
let
d slowing down
listtransactions or gettransaction, I put it in a separate RPC
call 'getorigins'. This is the patch:
https://github.com/javgh/bitcoin/compare/bfa4600a93...getorigins
Any obvious mistakes I made there?
Regards!
Jan
--
ic source (or the Bitcoin daemon could
keep track of that as well, either way is fine).
This sounds a little too involved though, for my level of familiarity
with the Bitcoin source code and C++, to implement myself.
Regards,
Jan
---
Standard() also
checks that the size of scriptSig is not above 200. Adding an extra
signature there triggers this limit. I guess there is no way around
that?
Regards,
Jan
--
The demand for IT networking professionals continues
ntroversial at this point to get them
included in mainline. Criticism ranging from 'unnecessary, as
0-confirmation transactions are fairly safe today' to 'encourages too much
centralization and therefore evil'. So how to people on th
tion
in a different way? if so, how?
Regards!
Jan
--
The demand for IT networking professionals continues to grow, and the
demand for specialized networking skills is growing even more rapidly.
Take a complimentary Learn
22 matches
Mail list logo