Justin A [ARCHIVE] / is on Nostr

⚠️ This account is not associated with a real person. It's an archival account for mailing list messages.
🗓️ Active from 2014-04-21 to 2014-04-22
💬 Posted a total of 2 messages
📚 Participated in the following categories: Bitcoin-development
🔇 Please do not DM this user as it's used for archive purposes only.

Last Notes

2023-06-07 15:19:03

- reply

📅 Original date posted:2014-04-20
📝 Original message:<delurk>
What about "ubit", pronounced "YOU-bit", representing 1e-6 bitcoin? Easy to
say, tied in a visual way to the metric micro, leaves the required 2
decimal places for the marginally numerate.. What more could one want?
</delurk>
Also, hi. My first post; plan to get involved over the southern hemisphere
winter if I can learn enough.
On Apr 20, 2014 4:32 PM, "Mike Caldwell" <mcaldwell at swipeclock.com> wrote:
> By culturally neutral I mean we avoid deliberately invoking a cultural
> reference in the name. For example "satoshi" would be a reference to
> Japanese culture just for being a common Japanese name regardless of who
> Satoshi turns out to be.
>
> Mike
>
> Sent from my iPhone
>
> > On Apr 20, 2014, at 1:20 PM, "Christophe Biocca" <
> christophe.biocca at gmail.com> wrote:
> >
> > Culturally neutral? "bit" in French phonetically collides with slang
> > for phallus ("bitte", with a silent "e"). Apparently it means "louse"
> > in Turkish as well.
> >
> > Not that this really would be avoidable with any short word (all the
> > short possible words are usually taken), but it's not neutral.
> >
> >> On Sun, Apr 20, 2014 at 2:43 PM, Oliver Egginger <bitcoin at olivere.de>
> wrote:
> >> Hello,
> >>
> >> just my two 'cents':
> >>
> >> Terms arises by itself. Just as most people speak of coins when they
> >> mean bitcoins. I do not see that bitcoin is currently in common use
> >> except for speculation. Therefore no term for smaller units has
> >> established yet. No problem in my eyes. Time will tell.
> >>
> >> - oliver
> >>
> >>
> >>
> ------------------------------------------------------------------------------
> >> Learn Graph Databases - Download FREE O'Reilly Book
> >> "Graph Databases" is the definitive new guide to graph databases and
> their
> >> applications. Written by three acclaimed leaders in the field,
> >> this first edition is now available. Download your free book today!
> >> http://p.sf.net/sfu/NeoTech
> >> _______________________________________________
> >> Bitcoin-development mailing list
> >> Bitcoin-development at lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/bitcoin-development
> >
> >
> ------------------------------------------------------------------------------
> > Learn Graph Databases - Download FREE O'Reilly Book
> > "Graph Databases" is the definitive new guide to graph databases and
> their
> > applications. Written by three acclaimed leaders in the field,
> > this first edition is now available. Download your free book today!
> > http://p.sf.net/sfu/NeoTech
> > _______________________________________________
> > Bitcoin-development mailing list
> > Bitcoin-development at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/bitcoin-development
>
>
> ------------------------------------------------------------------------------
> Learn Graph Databases - Download FREE O'Reilly Book
> "Graph Databases" is the definitive new guide to graph databases and their
> applications. Written by three acclaimed leaders in the field,
> this first edition is now available. Download your free book today!
> http://p.sf.net/sfu/NeoTech
> _______________________________________________
> 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/20140420/7da437db/attachment.html>

2023-06-07 15:19:03

- reply

2023-06-07 15:17:12

- reply

📅 Original date posted:2014-04-22
📝 Original message:Is there a reason you prefer doing the M-1 offset as opposed to limiting
the range to 255 instead? Seems like something that will certainly confuse
some developers in exchange for adding one more value at the high end of a
range. I don't gather there's much difference between 255 and 256 here is
there? Also requires the small bit of explanation to hang around as a rider
in all future documentation, and the name of the field may not be
self-documenting anymore.
By way of predicting how I'm wrong, perhaps it is better to have a field
where all possible values are legitimate (by not biasing you would have to
check it's not zero), or perhaps it's important that powers of 2 be
represented here? Perhaps there's some use case at 256 that 255 just won't
do for?
I'm mostly just curious, as I find problems and funnies crop up when people
get clever with optimization of things like message bit-packing etc.. If
it's not necessary then maybe better to keep to what's intuitive (i.e. the
girls name is clear and self-documenting)
Anyway enough of my bike shedding!
On Apr 22, 2014 5:38 AM, "Matt Whitlock" <bip at mattwhitlock.name> wrote:
> On Tuesday, 22 April 2014, at 10:39 am, Jan Møller wrote:
> > 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?
> >
> > 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.
>
> Encoding bias of M changed to -1, and test vectors updated:
> https://github.com/whitslack/btctool/blob/bip/bip-xxxx.mediawiki
>
>
> ------------------------------------------------------------------------------
> 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/ffcc6955/attachment.html>

2023-06-07 15:17:12

- reply