<unnamed>

Public Key

npub1sv4psc5psjztuewa8xzcxrdsm743zl3lvje7ha36xp3da86hmpyqdjg7a4

Profile Code

nprofile1qqsgx2scv2qcfp97vhwnnpvrpkcdl2c30clkfvlt7carqck7natasjqprpmhxue69uhhyetvv9ujuumwdae8gtnnda3kjctvqy28wumn8ghj7un9d3shjtnyv9kh2uewd9hszrthwden5te0dehhxtnvdakqhku780

Publishing to

relay.snort.social

relay.damus.io

nos.lol

Last Notes

2023-06-07 15:31:56 UTC

- reply

📅 Original date posted:2015-03-16
📝 Original message:What we were trying to achieve was determining the flow of funds between
countries by figuring out which country a transaction originates from.
To do that with a certain accuracy you need many nodes. We chose a class C
IP range as we knew that bitcoin core and others only connect to one node
in any class C IP range. We were not aware that breadwallet didn't follow
this practice. Breadwallet risked getting tar-pitted, but that was not our
intention and we are sorry about that.
Our nodes DID respond with valid blocks and merkle-blocks and allowed
everyone connecting to track the blockchain. We did however not relay
transactions. The 'service' bit in the version message is not meant for
telling whether or how the node relays transactions, it tells whether you
can ask for block headers only or full blocks.
Many implementations enforce non standard rules for handling transactions;
some nodes ignore transactions with address reuse, some nodes happily
forward double spends, and some nodes forward neither blocks not
transactions. We did blocks but not transactions.
In hindsight we should have done two things:
1. relay transactions
2. advertise address from 'foreign' nodes
Both would have fixed the problems that breadwallet experienced. My
understanding is that breadwallet now has the same 'class C' rule as
bitcoind, which would also fix it.
Getting back on the topic of this thread and whether it is illegal, your
guess is as good as mine. I don't think it is illegal to log incoming
connections and make statistical analysis on it. That would more or less
incriminate anyone who runs a web-server and looks into the access log.
At lease one Bitcoin service has been collecting IP addresses for years and
given them to anyone visiting their web-site (you know who) and I believe
that this practise is very wrong. We have no intention of giving IP
addresses away to anyone, but we believe that you are free to make
statistics on connection logs when nodes connect to you.
On a side note: When you make many connections to the network you 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 <mike at plan99.net> wrote:
> That would be rather new and tricky legal territory.
>
> But even putting the legal issues to one side, there are definitional
> issues.
>
> For instance if the Chainalysis nodes started following the protocol specs
> better and became just regular nodes that happen to keep logs, would that
> still be a violation? If so, what about blockchain.info? It'd be shooting
> ourselves in the foot to try and forbid block explorers given how useful
> they are.
>
> If someone non-maliciously runs some nodes with debug logging turned on,
> and makes full system backups every night, and keeps those backups for
> years, are they in violation of whatever pseudo-law is involved?
>
> I think it's a bit early to think about these things right now. Michael
> Grønager and Jan Møller have been Bitcoin hackers for a long time. I'd be
> interested to know their thoughts on all of this.
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20150316/1f5a72c2/attachment.html>

2023-06-07 15:17:22 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:The reason why client side certificates have never gained traction because
it is a pain to safely store/backup secrets.
In bitcoinland we are forced to solve the problem of safely storing
secrets, and over the years we have come up with software and hardware
solutions to make this safer and easier to manage for ordinary people.
Solving this is paramount to the success of Bitcoin, and nobody has solved
it before on a grand scale.
I see no reason for forcing end users to use two different mechanisms for
safely managing secrets.
I agree that using a bitcoin address for authentication purposes might be
confusing and potentially linking your funds with your identity. So I am
all for using something else than bitcoin addresses and bitcoin private
keys.
With bip32 we have finally agreed on a mechanism for generating a hierarchy
of bitcoin private keys from a master seed. A similar approach can be used
for generating a parallel hierarchy for authentication purposes.
- Jan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/34e800f0/attachment.html>

2023-06-07 15:17:14 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message: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 <tamas at bitsofproof.com>wrote:
> I use several test chains while testing my software, the official test
> net, a standalone net in house and even chains only created on the fly for
> unit tests. I found no use of distinguishing serialization of keys while
> using any of them.
>
> If you have some deep insights about why this is needed share it, as I am
> not goint to guess your valuable thoughts.
>
> Regards,
>
> Tamas Blummer
> http://bitsofproof.com
>
> On 22.04.2014, at 17:32, Mark Friedenbach <mark at monetize.io> wrote:
>
> Testnet vs mainnet is quite a separate issue than bitcoin vs altcoin.
> Unfortunately few of the alts ever figured this out.
>
>
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/8c017d18/attachment.html>

2023-06-07 15:17:11 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message: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 <bip at mattwhitlock.name>wrote:
> On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> > 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.
>
> I agree that M > 16 is probably not a viable use case for human beings,
> but machines would probably be able to make use of it. I, for one, welcome
> our new robot overlords.
>
> Also, the byte that encodes M−1 is optional, so if you're concerned about
> space, you can omit it (and the checksum).
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/65bfc4e4/attachment.html>

2023-06-07 15:17:11 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message: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 <bip at mattwhitlock.name>wrote:
> On Tuesday, 22 April 2014, at 10:27 am, Jan Møller wrote:
> > > > - 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.
> > >
> > >
> > I agree that it may look silly to have just one-of-one share from a
> > technical point of view, but from an end-user point of view there could
> be
> > reasons for just having one piece of paper to manage. If M can be 1 then
> > the software/hardware doesn't have to support multiple formats,
> > import/export paths + UI (one for SIPA keys in one share, one for HD
> seeds
> > in one share, one for SIPA keys + HD seeds in multiple shares).
> >
> > Less complexity & more freedom of choice.
>
> Alright. It's a fair argument. Do you agree with encoding M using a bias
> of -1 so that M up to and including 256 can be encoded in one byte?
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/9a2dfdff/attachment.html>

2023-06-07 15:17:10 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:This is a very useful BIP, and I am very much looking forward to
implementing it in Mycelium, in particular for bip32 wallets.
To me this is not about whether to use SSS instead of multisig
transactions. In the end you want to protect a secret (be it a HD master
seed or a private key) in such a way that you can recover it in case of
partial theft/loss. Whether I'll use the master seed to generate keys that
are going to be used for multisig transactions is another discussion IMO.
A few suggestions:
- I think it is very useful to define different prefixes for testnet
keys/seeds. As a developer I use the testnet every day, and many of our
users use it for trying out new functionality. Mixing up keys meant for
testnet and mainnet is bad.
- 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.
I have no strong 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 <
nikita at megiontechnologies.com> wrote:
> > What do you think a big-integer division by a word-sized divisor *is*?
> Obviously rolling your own is always an option. Are you just saying that
> Base58 encoding and decoding is easier than Shamir's Secret Sharing because
> the divisors are small?
>
> Well, yes, to be fair, in fact it is. The small divisor and lack of
> modulo arithmetic make base-58 encoding and decoding noticeably
> smaller and easier than Shamir's Secret Sharing over GF(P256).
>
>
> ------------------------------------------------------------------------------
> 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 at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/1ba69db4/attachment.html>

2023-06-07 15:17:10 UTC

- reply

📅 Original date posted:2014-04-22
📝 Original message:>
>
> > - 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.
>
>
I agree that it may look silly to have just one-of-one share from a
technical point of view, but from an end-user point of view there could be
reasons for just having one piece of paper to manage. If M can be 1 then
the software/hardware doesn't have to support multiple formats,
import/export paths + UI (one for SIPA keys in one share, one for HD seeds
in one share, one for SIPA keys + HD seeds in multiple shares).
Less complexity & more freedom of choice.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.linuxfoundation.org/pipermail/bitcoin-dev/attachments/20140422/50e835f2/attachment.html>